Bruce,
You make some good points. I'll answer them below for completeness,
but you've convinced me this approach is somewhat off topic for the
822 standards list, so it may be best to leave the topic here.
On Oct 04 2004, Bruce Lilly wrote:
What are you going to index? Message-ID, In-Reply-To, References are
not always present, Subject is a poor choice (it changes when the
topic doesn't change, it can be similar or the same for unrelated
messages, etc.). The fact of the matter is that you cannot achieve
absolute accuracy in identifying relationships between messages,
and any scheme that relies on such accuracy (whether explicitly stated
or not) is doomed.
No, the messages in this scheme should be indexed by node id within
the forest of threads comprising the mailing list. Remember that
the server's job in this case requires building an internal
forest of thread trees, which grows over time as new messages are received.
When a new message is received by the server, its parent node must be
computed from its contents. I fully accept that the current Message-ID,
In-Reply-To, References and Subject are insufficient for reliably
computing the parent node (see nice example given by Martin Trautmann),
but don't (yet?) accept that a scheme for reliably computing the parent
node is impossible with the current crop of MUAs.
I gave such a scheme, based on the idea of the server embedding a node
id in the Subject field, and called it a hack. It has no relation to
2822 standards, which is why we're off topic, but I still think it is
quite workable within the system envisaged, namely a server system
which already keeps an internal forest of threads.
I suspect I got confused. What is your position on threading in
mailing lists? Are you suggesting that:
First, it's a UA display issue, and a UA author can use whatever
heuristics he likes. It doesn't affect any protocol. Second, not
every reader wants a "threaded" display -- some might prefer
most-recent first or other methods of arranging message display.
Ok, that makes sense. The threads I'm discussing are kept internally
by the server for its own purposes, and do not represent guidelines
for display in a UA.
There are several problems with that:
1. The Subject field is defined as an unstructured field. Attempting
to impose structure on it is a very bad idea.
2. The Subject field is intended as an only human-readable
description of the message topic. Attempting to turn that into
a machine-parsed repository for protocol information is a
very bad idea.
3. As a general principle, mailing list software should not
alter any message header fields supplied by the author,
including the Subject field.
I agree that my proposal breaks these principles.
For completeness: the important aspect here is only to find a part of
the message headers which is highly likely to be returned intact to
the mailing list server when replies are sent, even by stupid MUAs. If
we could rely on MUAs always following standards, this whole
discussion would be moot. Other than the Subject field (whose prefix
may change in a thread reply, but whose suffix is typically intact), I
don't know of another candidate.
For somebody not on the list? Obviously he shouldn't receive list
messages unrelated to any that he might have submitted. If he wants
copies of any extended discussion (such as the example below) he'll
have to indicate so and rely on list members to cooperate with that
request.
That is a problem which an intelligent server as proposed can address
automatically. If the server keeps its own internal forest of
threads, then there is no need to rely on the cooperation of list
members. The list server can examine the thread topology, and decide
what messages are to be sent to whom with high accuracy. Of course,
it doesn't preclude extra cooperation from list members if they choose.
The problem was intended to be obvious; A only sees an incorrect
answer. That problem stems from the presumption that a mailing
list expander can magically determine message relationships and
send out copies of "related" messages to a non-list author. The
You're seeing more into this than I intended. I presume that a (new
generation) list server can keep a reasonable record of who replies to
whom, and allows humans to construct preference rules which affect
only themselves, based on the pattern of responses. Clustering
messages by topic is beyond the scope.
basic function of a mailing list is to facilitate human group
communication by distributing messages to that group. The humans
involved need to indicate (to the other humans) their individual
preferences for responses [do they want responses to go only to
the list, do they want personal responses only, do they want both,
etc.].
But the list server can act as a proxy for these mundane tasks. If
the human can indicate his response preferences inside the message he
is sending, then surely the human can tell the server those response
preferences once, and the server can then insert these inside all the
messages being transmitted to the list.
* expecting software to be able to deduce message relationships
is unrealistic because there is no mandatory feature of the
mail protocols which can be used (Message-ID, In-Reply-To, and
References are all optional). That leaves examining the entire
archive content and making some sort of guess as an alternative;
albeit an expensive alternative that still amounts to mere
guesswork.
Yes. I accept this is unrealistic with current software.
* lacking strong authentication in the core mail protocol, it
is not possible for mailing list software (or humans for that
matter) to accurately determine the identity of a message
author or sender [without depending on the sender to include
some optional authentication information such as a digital
signature]. Inability to identify the author/sender means
an inability to perform some feat of magic based on author/
sender identity.
The identity/authentication of the author is not of concern (more
precisely, all these problems exist now in exactly this same form -
you expect other humans on the mailing list to accurately determine
the identity of some message's author, and send him a courtesy copy
etc. - does that make authors magicians?)
* because different humans have different preferences, a one-
size-fits-all approach enforced by fascist software won't
work for a group with diverse preferences.
That is already the problem we face with mailing lists now.
In fact, we are discussing this very problem on this list.
But that's not a problem, because human authors *can* indicate
their preferences to others, within existing protocol framework,
with no meddling from list expanders. Indeed, any such meddling
is more likely to cause problems than to solve them, as has
been the case with some list expansion software which has been
implemented in such a manner as to overwrite the authors'
expressed preferences.
That is a very good point. All systems have bugs and new systems are
poorly understood quasi by definition. Intelligent list servers are
no exception.
(Just to repeat: I'm willing to end this thread here, given its off
topic nature for this list, but I didn't want to leave your good
objections hanging.)
--
Laird Breyer.