[Top] [All Lists]

Re: MoreOn: Attempts at establishing harmful conventions

2004-11-30 18:09:29

The "[listname]" insertion is clearly the "sore point" case. This is natural because it seems to defy the otherwise reasonable-sounding rule that i myself proposed, which is that the Subject field is for human beings. However, I'm not sure that this is really as bad a layering violation as it might seem. While the list processor is indeed inserting something into the "human" part of the stream, it is (at least in theory) doing so in accord with a policy set by a list owner. A list owner should be able to choose to insert any strings he wants to in messages that go through his list, to convey a meaning that he wants to convey. The fact that list processors make it so easy to insert such strings may be simply a reflection of the fact that so many list owners want to be able to do that. But they want it for its human meaning, not for any intended protocol consequences.

I see (at least) two distinct kinds of badness associated with [listname] tags. One is that they get in the way of searches, comparisons, display, etc. so there's a temptation to remove or ignore them just as with Re:, Fwd: and similar tags.

The other is the harm to transparency - these tags alter the message content from what the original author intended. Footers added by lists cause the same kinds of problems. This begs the question - is the purpose of the list to be a transparent multicast channel or is it an original source of content? In many cases the same content that is submitted to a list is also transmitted to other recipients, who will think they're all receiving the same message - but they're not.

While a case can probably be made that at least a few lists should be content sources, IMHO lists that alter subject fields or message bodies should also alter other portions of the message to avoid confusion with the message as originally written by the author. For instance, the message-id should be changed, in-reply-to and references fields should be cleared or altered, etc.

As for the "dog" analogy: we can scarcely prevent any kind of protocol violation. But we can at least point out that some practices are undesirable and try to discourage them.

<Prev in Thread] Current Thread [Next in Thread>