On 11/15/2011 6:52 PM, Barry Warsaw wrote:
On Oct 29, 2011, at 06:39 AM, Patrick Ben Koetter wrote:
I suggest we use the term 'Mediator' as introduced by D. Crocker in RFC 5598 <http://www.rfc-editor.org/in-notes/rfc5598.txt> instead:
A Mediator attempts to preserve the original Author's information in the message it reformulates but is permitted to make meaningful changes to the message content or envelope.
A Mediator's role is complex and contingent, for example, modifying and adding content or regulating which Users are allowed to participate and when. The common example of this role is a group Mailing List.
(see section "2.1.4. Mediator" and also section "5. Mediators") That makes a good case for Mediator.
Hmmm. To me, the above definition for Mediator is reason enough to abandon it (for the time at least) because it is not well thought out regarding everything that may touch, modify, add content, regulate user, etc. Together with the above and a line from a previous message Patrick sent to the list:
"The term 'Mediator' describes the same, but it is general in
meaning. Any instance modifying and forwarding a message can use it. "
I can't help but consider the rash of useless Mediator headers. Consider the following example:
Person 1 sends a message to a list which is then sent to Person 2. Person 1's site has separate appliances for the MTA, Spam checking, Anti-Virus, and Spy-ware, likewise for the receiver's site and the site the MLM is for the list. My reading of the above definitions tells me:
- Person 1's MUA adds a Mediator header (creating a message is a simple special case of modifying/adding a message,
- Person 1's site adds 4 additional Mediator headers (one each for the MTA, Spam, Anti-Virus, Spy-ware since each modify/forward/add to the message,
- The MLM's site adds 9 additional Mediator headers (4 inbound [item 2], 1 for the MLM [maybe more], and 4 outbound),
- Person 2's site adds 4 additional Mediator headers (4 inbound [item 2]),
- Person 2's MUA may or may not add a Mediator header depending on any rules/filters Person 2 has in place.
So, at the end of this simple posting of a message to a list, we have 18+ Mediator headers, one for each time an instance adds content, modifies a message, or regulates a user.
Granted, I may be making this a worst case scenario, but also consider any sites the message is relayed through - adding even more Mediator headers. Looking at a worst case scenario helps see where the problems occur and cracks in specifications happen.
I am not opposed to a Mediator header. I just think since our discussion is focused on MLMs that List-Agent is the best choice that all MLM developers can come to an agreement on.
As for other applications (news, web forum, etc), a discussion with those developers should (and needs to) take place to come up with a more generic header - be it Mediator or not.
In any case, let's focus on MLM related headers, like List-Agent :), and then work on a more generic, non-conflicting header for others at a later time. I just see including non-MLM information into a MLM header discussion as feature-creep.
Hmm, if there are no intermediate processes between receiving a message and approving it a List-Approved-Date seems fine. But if there are we run into the same problem as described below with List-Archived-Date - you can't tell when it was queued and when processing took place.
Adding a second header might make the useful distinction:
List-Received-Date RFC 2822 date timestamp when message was received by MLM
List-Approved-Date RFC 2822 date timestamp when message was approved by moderator What if the message is automatically approved? Does it get a List-Approved-Date header? Merging with Murray's concept of Received states, it might just make more sense to put all that information into Received headers.
The only issue I can see is if the Received headers are removed as part of processing, whether in an appliance, an MTA, or an MUA. I know it shouldn't happen but I received messages with missing Received headers. Having the information in a List-* header wouldn't hurt.
Another header that might be useful here would be List-Approved-By which could be the name or email address of the moderator who approved it. Right now, MM3 doesn't fill that in, and it could of course be filled in by say list-owner@example.com, but in MM3 it could be potentially filled in with the preferred address for the moderator that approved it. I see the benefit because it helps if you moderate in a team. But I fear the anger of people whose postings we decline. They search for moderator identities and then start molesting them e.g. by subscribing them to mailing lists that don't require opt-in. (Happend to me python.org postmaster. The angry person subscribed my address to various pr0n mailing lists and it took me weeks to get unsubscribed.) Good point. I do want to provide the opportunity to "anonymize" ownership roles via generic owner email addresses. E.g. on the listinfo page.
:) So far, I haven't had anyone that grumpy at me to add me to various "other" lists. But they do occasionally go over my head to get authorization so they can post without being moderated (at least until they send a message that exceeds the size limit).
ACK with the notion that hashtag seems to closely realted with twitter and a more general 'tag' would stay away from that.
Is there or should there be a distinction between 'tag' and http 'keywords' <http://en.wikipedia.org/wiki/Meta_element#The_keywords_attribute>? Should we use 'keywords' instead? We can't use Keywords, because that header is already used as input to various functions such as the topic tagger. We have to use a different header for "output". I can't think of anything better than List-Tags though.
List-Archive-Send-Date 'List-Archive-Send-Date' sounds pretty clumsy and overly long. OTOH we needn't care, as it will only be added to messages that go to the archive, right?
Archive-Transmit-Date, Archive-Transfer-Date, Archiv-Transfer Marks the beginning in opposition to Archive-Received-Date or Archive-Received. But then again an archiver could simply add a Received:-header!
Not an easy one. Agreed. :/
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/cnulk%40scu.edu
Security Policy: http://wiki.list.org/x/QIA9
Thanks for bearing with me, Chris