Subject: Take 2: References/In-Reply-To replacement text

From: Pete Resnick <[email-masked]>
Date: Fri, 21 May 1999 13:09:58 -0500

Here is what I've got now. This replaces everything in 3.6.4 after 
the "Note:" which starts "There are many instances...":

---

The "In-Reply-To:" and "References:" fields are used when creating a 
reply to a message. They hold the message identifier of the original 
message and the message identifiers of other messages (for example, 
in the case of a reply to a message which was itself a reply). The 
"In-Reply-To:" field may be used to identify the message (or 
messages) to which the new message is a reply, while the 
"References:" field may be used to identify a "thread" of 
conversation.

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.

Note: Some implementations parse the "References:" field to display 
the "thread of the discussion". These implementations assume that 
each new message is a reply to a single parent and hence that they 
can walk backwards through the "References:" field to find the parent 
of each message listed there. Therefore, trying to form a 
"References:" field for a reply that has multiple parents is 
discouraged.

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 
an similar syntax to addr-spec (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.

Semantically, the angle bracket characters are not part of the 
msg-id; the msg-id is what is contained between the two angle bracket 
characters.

---

If this looks good, I will post it to the last call list.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 May 1999 11:40:54 +1000

Date:        Fri, 21 May 1999 13:09:58 -0500
    From:        Pete Resnick <[email-masked]>
    Message-ID:  <[email-masked]>

  | Therefore, trying to form a 
  | "References:" field for a reply that has multiple parents is 
  | discouraged.

Grunge.   But I guess we are not going to agree on anything better.

  | 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 
  | an similar syntax to addr-spec (identical except that comments and 

s/an/a/

  | 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 

s/)/, provided the IP address concerned is known globally unique)/

  | 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.

add

It is best to use a representation (which need not be comprehensible
by humans) of the date expressed in UTC here, to avoid the slight
potential for problems should a domain name or IP address move to a
different timezone.

  | 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.

Why is this just recommended?   I always thought that was the whole
point of the message-id syntax, and that nothing else has a hope of
working.   The domain name used must be one in which the generator of
the message-id can guarantee that the local part (of the message-id) is
unique (so that the whole thing is then unique).   That can be a host name,
or a higher level domain name (or even a domain literal (IP address) though
that is harder to do correctly).  I had never conceived of the domain name
part of the message-id being something about which there was any debate
or difference of opinion.  Is there?

kre

---

From: Pete Resnick <[email-masked]>
Date: Wed, 26 May 1999 11:18:01 -0500

>s/an/a/

Oy. Done.

>s/)/, provided the IP address concerned is known globally unique)/

It's just a "good method" here, so I think the extra verbiage is 
unnecessary at this point.

>potential for problems should a domain name or IP address move to a

A little wordy, but I'll throw in something to that affect.

>or difference of opinion.  Is there?

Remember, RECOMMENDED is equivalent to SHOULD; that is, do it unless 
you've got some good overriding reason not to. So for example, the 
rhs could be a faked-up identifier if someone chose to do that: 
"message-id.munnari.oz.au" might be reasonable even if it is not a 
registered domain name and doesn't correspond to any particular 
machine. There are all sorts of interesting circumstances where 
getting a real domain name (or IP address) might be a real pain in 
the butt.

pr

---

From: Simon Lyall <[email-masked]>
Date: Thu, 27 May 1999 05:37:45 +1200 (NZST)

With respect to this little message-id thing, I"d like to point people to:

draft-ietf-usefor-message-id-01
draft-ietf-usefor-msg-id-alt-00

-- 
Simon J. Lyall.  |   Very  Busy  |   Mail: [email-masked]
"To stay awake all night adds a day to your life" - Stilgar | MT.

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 May 1999 20:48:45 +1000

Date:        Wed, 26 May 1999 11:18:01 -0500
    From:        Pete Resnick <[email-masked]>
    Message-ID:  <[email-masked]>

  | A little wordy,
Typical for me...

  | Remember, RECOMMENDED is equivalent to SHOULD;

Yes, I know.   What I am attempting to discover is whether there is
any other way at all that can work.   That is, why is this not a MUST?

Peter Sylvester pointed out rfc1327 - but that's not any kind of
counter example, it is, in fact, exactly on point.   The "@MHS" it
uses is a domain name (using the essentially reserved TLD "MHS")
in which the local part of the message-id is guaranteed unique, using,
in that case, the id algorithm of X.400.

  | you've got some good overriding reason not to. So for example, the 
  | rhs could be a faked-up identifier if someone chose to do that:
  | "message-id.munnari.oz.au" might be reasonable even if it is not a 
  | registered domain name and doesn't correspond to any particular 
  | machine.

Um - no, that's not the issue.   Nothing anywhere mentioned "registered"
domain names in this sense.   Certainly creating "non-DNS" domain names
for message-id use is just fine.  That's what "@MHS" is.   If my previous
comment confused the issue by not being general enough, I apologise.
All I meant was that the DNS naming space be used, not that the domain name
used be in any particular way related to the system on which the id is
actually generated.

The point is that we need a namespace to name the various generation
algorithms that can exist.   Conveniently, we have a namespace fairly
easily available to us - the DNS namespace.   That allows a hierarchy
of names to be defined in a reliable way.

The question is whether any other (different) hierarchy could conceivably
be used, and still cause unique IDs to be generated?   I cannot imagine
how that could be possible.

  | There are all sorts of interesting circumstances where 
  | getting a real domain name (or IP address) might be a real pain in 
  | the butt.

"real" in this case isn't necessarily important (whatever "real" means),
what is needed is one in which the local-part of the message-id is going to
be unique.   This is the sole point of the domain name part - it doesn't
need to actually exist in the DNS at all, or anything like that, it just
needs to be properly allocated using DNS assignment procedures.

kre