Laird Breyer wrote:
I'm not suggesting rescanning the entire archive each time a new message
is submitted (accepted), an up to date index is all that's needed.
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.
I suspect I got confused. What is your position on threading in
mailing lists? Are you suggesting that:
1) In-Reply-To is the only reliable existing means of discovering
relations between messages?
2) In-Reply-To is not honoured by MUAs with sufficient frequency in practice?
3) Therefore, threading is not worth considering for mailing lists?
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.
and separately, for example:
4) embedding a thread ID token into subject lines of list propagated messages
cannot mitigate the shortcomings of 1-3?
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.
How do lists handle posting privileges now?
Not all lists are closed. Different lists have different policies
and use different mechanisms.
You're right. If such a person is not a member, then his/her preferences
can't be known.
They can be known if and only if he as a message author indicates
where he wants responses to be sent, in his message (via Reply-To).
What about his receipt preferences for messages sent by anybody else
on the list?
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.
Ok, it's a good question, but I think that's bordering on recursively
reimplementing the mailing list. My personal inclination is that a
response to a response is not a response to the original poster, so
needn't concern him or her.
Hypothetical situation:
A asks a question
B gives a wrong answer, which is copied to A
C, D, E, and F respond that B's answer was incorrect, and giving
the correct answer -- none of which is seen by A.
I don't see the problem with that. When did the matter of correctness
of an answer enter the debate? I see the point of what you're saying,
but I don't see that it is a list server's job to inspect the message
content for accuracy.
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
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.]. They need to so indicate to the other humans involved
because the responses come from those humans, not from some magic
oracle. Expecting a mailing list expander to become such a magic
oracle is an unrealistic expectation, at least with current
mail protocols [and this is not the place to discuss possible
future protocols, that would be the mail-ng list]. The implicit
assumptions that you made all bear upon that:
* 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.
* 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.
* 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.
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.