In <p06020400bc7cd1043481(_at_)[130(_dot_)237(_dot_)157(_dot_)77]> Jacob Palme
<jpalme(_at_)dsv(_dot_)su(_dot_)se> writes:
Sorry if this reply is somewhat dated, I am reading this mailing
list with a :-) slight (-: time delay.
At 06.11 +0000 03-06-07, D. J. Bernstein wrote:
RFC 2822 is incorrect when it suggests that References has all of the
message's ancestors. What References actually has is the start of the
thread, followed by the most recent ancestors, ending with the parent.
Ancient ancestors other than the start of the thread are often missing.
I remember that I pointed this out when RFC 2822 was
developed. Other people then said, that although they knew
this was done, they did not like it, and therefore did not
want it mentioned in the standards document.
Maybe this practice of omitting middle Message-IDs, but
always keeping the first and the last two or three, could
be mentioned in a revised RFC 2822 in chapter "4. Obsolete
Syntax", in the description of "obs-references". That
chapter is meant to describe syntax which occurs but which
is not recommended. It could also contain a description of
practice which is not recommended.
In Netnews, the GNKSA suggests keeping only the last three.
However, USEFOR has taken the view that you should keep the first and the
last 20. That will probably go in the Current Practices document rather
than in the standard itself.
However, now that this topic is opened again, I would like to revisit the
original topic of this thread, namely Multi-message reply and
"References:". I said nothing on this thread at the time, because my
subscription to this list was all screwed up following an address change.
ISTM that the fundamental property required of the References header is
that messages should be placed later in the list than any message which is
a precursor of it (note that in the usual case, where the thread is a pure
tree, that is exactly equivalent to the present rule). Replying
simultaneously to two messages and adding them both to the end of the
References chain (in either order) would achieve that property.
Now when it comes to presenting the messages in a MUA, one needs the same
property, so that you will not try to read a message until you have read
all of its precursors. So it should be possible to get that effect if the
References header is constructed as I have suggested.
What may be more difficult is to reconstruct the whole graph (strictly a
DAG) from such References headers, but the question is whether it is
really necessary to do that in order to provide an adequate presentation.
Some solutions which were being propounded the last time this came up
involved additional syntax in the References header which it would be
difficult to introduce on the existing network. A solution which sticks
with the present syntax but slightly extends the semantics would have a much
better chance of smooth deployment.
This topic is also under discussion on the Usefor list - not that Usefor
has any declared intention of introducing a change at this time, but it
might if there was a simple solution that had a broad consensus.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5