[Sorry, couldn't resist continuing to play with the subject line.]
On Nov 30, 2004, at 8:09 PM, Keith Moore wrote:
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.
I'm not sure this is a problem. Is it a problem if a search engine
builds in a smart spelling algorithm, so that searching for "colour"
finds "color" and "collor"? It seems to me that a similarly "smart"
email system would build in heuristics based on common human email
conventions. Where's the problem?
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?
As usual, you've asked precisely the right question. I think it points
to the fundamentally human element here, which is that some lists have
the former purpose and some the latter. One might taxonimize them as
"transparent mailing lists," "header-modifying mailing lists,"
"body-modifying mailing lists," and "non-transparent mailing lists."
Any of these might reflect a reasonably legitimate set of needs on the
part of the list owner. I think we just have to deal with it. It
might be nice, however, if there were a way to tell the difference.
For instance, the message-id should be changed, in-reply-to and
references fields should be cleared or altered, etc.
Or, perhaps, a "List-modifications" field could be defined.
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.
Perhaps we need the equivalent of a "Curb Your Dog" sign for mail sent
to mailing lists? A "please don't screw with this message" flag?
Would that be useful in any way?
Humans want things to be mostly unstructured; computer programs want
things to be highly structured. Humans prefer loose definitions for
data elements; computer programs prefer strict definitions. And yet
we want computer programs that deal with human natural language
communications. This seems like an inherent conflict that we're not
likely to resolve.
Very well put. But a good first step is to distinguish the parts of a
program (e.g. an MUA) that are dealing with structured protocols like
MIME from those that are dealing with human conventions like those in
the subject lines. That way you can keep the heuristics in the parts
of the software that actually need them. Your MIME parser really
shouldn't have to make too many guesses, but your subject line parser
will probably be better if it makes some informed guesses about human
conventions. -- Nathaniel