ietf-822
[Top] [All Lists]

Re: References with multiple precursore [sic] (was Attempts at establishing harmful conventions)

2005-01-12 08:53:38

On Tue January 11 2005 06:46, Charles Lindsey wrote:

Currently, where a response has only one precursor, a discussion thread
consists of a tree, and the References header consists of the path from
the root of the tree to the message at the tip of the tree which contains
that References header.
[...]
If you want to extend that to responses to multiple precursors, then the
tree becomes a DAG (Directed Acyclic Graph), and there are many possible
paths from the root to each tip

Yes, as noted (more succinctly) by Adam M. Costello a year and a half
ago.

So here is a suggestion to get around the problem in a way that will
probaby allow existing MUAs to do a reasonable job:

Simply allow there to be multiple occurrences of the References header in
each message - one for each path from the root to the tip in question.

No. Expressly forbidden by RFC 2822 section 3.6.2, which specifies
a maximum of one References field per header.
 
Then an updated MUA can look at them all, and has full information
available to give the best possible presentation. Meanwhile, an unupdated
MUA will probably just take the first, or the last, or a randomly chosen
one, and will at least produce a plausible thread.

That is not backwards compatible. We don't foist illegal content
(in this case multiple References fields) on widely deployed
implementations and shrug off the incompatibility with an off-hand
remark hypothesizing that those implementations will "probably"
cope in some way.
 
And it is not actually necessary for the whole of each of the various
paths to appear in the various References headers. Just the segment that
differs from the others should suffice, though careful thought would have
to be given to defining exactly what the rule should be.

Having failed to give careful thought, you still claim that deployed
MUAs "will at least produce a plausible thread".  Incredible.

You also failed to take note of the summary of conclusions of the
earlier discussion; your scheme, in addition to failing to be
backwards compatible:

a. ignores that "expecting UAs to coordinate updates to multiple fields
   is probably over-optimistic"; you fail to even mention how the
   multiple References fields which you propose would be updated when
   such a message is responded to.

b. ignores the fact that "several existing UAs botch References and
   In-Reply-To fields, destroying their utility"; illegally adding
   more instances of the field can only exacerbate that problem.

c. does not address repetition of message-ids and the bulk associated
   with such repetition; indeed, it involves such repetition

d. ignores the conclusion that "rather than overload additional
   semantics on the References field, a new field or set of fields
   should be developed"