AMC> Here is the first idea that comes to my mind:
AMC> References: *( [parents] message-ID )
AMC> Each message-ID is optionally preceeded by a parents marker, which is a
AMC> It might be better to use a new header field for this. The References
AMC> field was not originally intended to be a reply history, and certainly
AMC> not intended to be this structured.
I think this topic is best pursued in two parts. The part involving an
abstraction is defining a way to notate a forest of thread trees
(remembering that there may be independent origins.) I do not see how
to do this reasnably, for the References definition in 2822, since it
lacks an internal syntax, and intuiting breakpoints is risky, at best.
I find myself fearing that References is now suffering mightily from the same
Reply-To. It is a very reasonable field, for its original goal, but is
now suffering from overloading of a second goal.
The problem with the examples that Pete gave in his original posting is
that examples with message id's that are sequential numbers seduces us
into thinking that message id's are related, and of course they are not.
So the current definition relies on repeating some earlier message id
and/or inventing a meta-syntax for References. I'd class the proposal
to have a Thread-heads header that somehow correlates with References as
You get what you need by defining a Threads header that has a real
meta-syntax for laying out a forest of threads in a sequentail
At best, References should be a flat list of "relevant" messages. If
you want to a thread meta-structure, define it separate. If everyone
can be convinced that this meta-structure can be retrofitted to
References, without breaking any existing software, then fine.
Otherwise, use a new header.
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>