James Newton, Host wrote:

>> That brought up a bunch of posts, but not the beginning of the thread. 
>> Strange.
> 
> The thread got changed with an extra Re[2]: in it. That effectively
> broke it into two threads according to the PICList archive program. On
> the other hand, I'm not sure any email reader could follow that... 

I don't know which readers can follow that, but probably a few. (40tude 
Dialog can, for example.)

This is because of the References header. If I'm not mistaken, the first 
message with that offending "Re[2]" in the subject is the one with 
Message-ID <1903010234.20060715214415@mirosat.com>. It carries in the 
References header the message ID of Olin's previous message 
(<009601c6a81b$228fa360$0300a8c0@main>). That allows normal threading 
mailers to follow the chain.


FWIW, the headers Message-ID, References and In-Reply-To are explained in
RFC2822, section 3.6.4. Identification fields
http://tools.ietf.org/html/2822#section-3.6.4 (I've recently had the chance
to review these standards a bit :)

This is what is says about the In-Reply-To and References headers:

--------------------------------
When creating a reply to a message, the "In-Reply-To:" and "References:"
fields of the resultant message are constructed as follows:

The "In-Reply-To:" field will contain the contents of the "Message-ID:"
field of the message to which this one is a reply (the "parent message").
If there is more than one parent message, then the "In-Reply-To:" field
will contain the contents of all of the parents' "Message-ID:" fields.  If
there is no "Message-ID:" field in any of the parent messages, then the new
message will have no "In-Reply-To:" field.

The "References:" field will contain the contents of the parent's
"References:" field (if any) followed by the contents of the parent's
"Message-ID:" field (if any).  If the parent message does not contain a
"References:" field but does have an "In-Reply-To:" field containing a
single message identifier, then the "References:" field will contain the
contents of the parent's "In-Reply-To:" field followed by the contents of
the parent's "Message-ID:" field (if any).  If the parent has none of the
"References:", "In-Reply-To:", or "Message-ID:" fields, then the new
message will have no "References:" field.
--------------------------------

Basically, the References header is for redundancy and for cases where a
message in the thread is missing; otherwise, the In-Reply-To header should
be enough. It is also interesting that the In-Reply-To header in theory
supports replies to multiple messages (it may contain multiple message
IDs); something that actually happens quite a bit on a list like this (at
least for me). But few if any mailers allow sending such messages, and none
that I know of is capable of showing such a non-tree thread relationship
graphically or otherwise doing something sensible with such an information.


Later on it defines the Message-ID header. Olin's message identifier
<009601c6a81b$228fa360$0300a8c0@main> may not be standard-conform, even
though it seems to be pretty close. The standard requires "globally unique"
message IDs. A server generating IDs can guarantee local uniqueness, and an
easy way to transform that local uniqueness into global uniqueness is to
append the domain or IP address. "@main" however is not a globally unique
domain, so it's not clear how globally unique this ID is. Probably it is
globally unique due to the generation of the part to the left of the @
character, but also probably it is not guaranteed to be unique due to the
not unique part to the right of the @ character.

Here is the relevant text from the standard:

--------------------------------
"The message identifier (msg-id) itself MUST be a globally unique
identifier for a message.  The generator of the message identifier MUST
guarantee that the msg-id is unique.  There are several algorithms that can
be used to accomplish this.  Since the msg-id has a similar syntax to
angle-addr (identical except that comments and folding white space are not
allowed), a good method is to put the domain name (or a domain literal IP
address) of the host on which the message identifier was created on the
right hand side of the "@", and put a combination of the current absolute
date and time along with some other currently unique (perhaps sequential)
identifier available on the system (for example, a process id number) on
the left hand side.  Using a date on the left hand side and a domain name
or domain literal on the right hand side makes it possible to guarantee
uniqueness since no two hosts use the same domain name or IP address at the
same time.  Though other algorithms will work, it is RECOMMENDED that the
right hand side contain some domain identifier (either of the host itself
or otherwise) such that the generator of the message identifier can
guarantee the uniqueness of the left hand side within the scope of that
domain."
--------------------------------

So replacing "@main" with "@embedinc.com" in that message identifier
<009601c6a81b$228fa360$0300a8c0@main> probably would guarantee global
uniqueness (depending on the local uniqueness of the part before the @
character). 

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist