Subject: References/In-Reply-To replacement text

From: Pete Resnick <[email-masked]>
Date: Mon, 15 Mar 1999 11:46:47 -0600

Here's what I've got as replacement text. If there are no objections, 
I will post it to the Last Call list as "what we've decided to put in 
3.6.4."

-----
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 contains 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 contains 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 has no "In-Reply-To:" field.

If the parent message has a "References:" field, then the 
"References:" field of the new message contains the contents of the 
parent's "References:" field 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 contain an "In-Reply-To:" field, then 
"References:" field of the new message contains 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 message contains 
neither a "References:" field nor an "In-Reply-To:" field, then the 
"References:" field of the new message contains the contents of the 
parent's "Message-ID:" field. If the parent also has no "Message-ID:" 
field, then the new message shall 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.
------

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

---

From: [email-masked] (Claus André Färber)
Date: 15 Mar 1999 21:33:00 +0100

Pete Resnick <[email-masked]> schrieb/wrote:
> "Message-ID:" fields.

Breaks old software. Currently, multiple IDs in In-Reply-To are not  
allowed. Software that still accepts them will assume that it is the  
same as References and contains a hierarchical thread.

> If there is no "Message-ID:" field in any of
> parent's "Message-ID:" field (if any).

This will break software that assumes that References contains a list of  
IDs where one message is the parent of the next one as soon as the In- 
Reply-To field of the parent message contained multiple parents (as you  
propose).

Besides that, you are not handling the case where a message has both an  
In-Reply-To field that contains the direct parent and References fields  
that contains the parent's parents but not the ID of the parent itsself.
AFAIR, such a format is created by some software and therefore should be  
handled properly.

> If the parent message contains

This is bad as it completly breaks threading.

The better and compatible was to handle multiple parents messages is to  
basically follow the one-parent-per-message rule, i.e. declare one  
message the primary parent and allow to include the other messages as  
secondary parents in another header field, which should probably be  
named See-Also as in RFC 1036.

This of course will make it impossible to directly retrieve the ID of  
secondary parents of the parent message. However, this is still better  
than the mess above where software will incorrectly believe that is is  
the parent of the parent's parent.

If we do not introduce See-Also because it would be a new feature, I  
have no objections.
Actually, the new feature is multiple parents per reply. If it is  
introduced it is better to do it properly and not hide the fact that it  
is new by overloading (and breaking) old features.

-- 
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC

---

From: Brad Knowles <[email-masked]>
Date: Tue, 16 Feb 1999 10:06:23 +0100

>the parent messages, then the new message has no "In-Reply-To:" field.

    I thought that "Message-ID:" was a required field?  Can we really do
anything intelligible with regard to either of these headers if there is
no "Message-ID:" field?

>"References:" field for a reply that has multiple parents is 

    Do we want to make any statement about a suggested method of
determining which of multiple parent messages would be the "canonical
parent", in the case that you didn't want to try to "form a 'References:'
field for a reply that has multiple parents"?

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit

---

From: Pete Resnick <[email-masked]>
Date: Tue, 16 Mar 1999 09:38:21 -0600

On 3/15/99 at 9:33 PM +0100, Claus André Färber wrote:

>> If there is more than one parent message, then the "In-Reply-To:" 
>> field contains the contents of all of the parents' "Message-ID:" 
>> fields.
>
> Breaks old software.

What software? I've never heard of anyone parsing In-Reply-To. There 
are lots of people now who include all kinds of crap in their 
In-Reply-To fields.

> Currently, multiple IDs in In-Reply-To are not allowed.

False. Clearly allowed in 822:

                 /  "In-Reply-To"       ":"  *(phrase / msg-id)

In fact, according to 822, phrases alone are legal in In-Reply-To 
(let alone References).

> Software that still accepts them will assume that it is the same as 
> References and contains a hierarchical thread.

Again, what software?

>> If the parent message does not contain a "References:" field, but 
>> does contain an "In-Reply-To:" field, then "References:" field of 
>> the new message contains the contents of the parent's 
>> "In-Reply-To:" field followed by the contents of the parent's 
>> "Message-ID:" field (if any).
>
> This will break software that assumes that References contains a 
> list of  IDs where one message is the parent of the next one as 
> soon as the In-Reply-To field of the parent message contained 
> multiple parents (as you propose).

Sorry, you're right. I forgot that case. You should only do this part 
if In-Reply-To contains a single message-id. I'll fix that and 
resubmit to the list.

> Besides that, you are not handling the case where a message has 
> both an In-Reply-To field that contains the direct parent and 
> References fields that contains the parent's parents but not the ID 
> of the parent itsself. AFAIR, such a format is created by some 
> software and therefore should be handled properly.

The only one I know that did that was a few broken beta versions of 
Eudora. I'm not inclined to deal with that.

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

How? It says, "Don't do it."

> The better and compatible was to handle multiple parents messages 
> is to basically follow the one-parent-per-message rule, i.e. 
> declare one message the primary parent and allow to include the 
> other messages as secondary parents in another header field, which 
> should probably be named See-Also as in RFC 1036.

I am disinclined to put more new rules about this into this document. 
Currently, we are limiting what 822 allowed; adding new fields seems 
like it goes overboard.

> If we do not introduce See-Also because it would be a new feature, 
> I have no objections.

No objections to which part?

> introduced it is better to do it properly and not hide the fact 
> that it is new by overloading (and breaking) old features.

Multiple parents are not a new feature. Obviously the action is not a 
new feature and multiple message-ids in In-Reply-To is not a new 
feature. The semantics of the latter are pretty obvious. The only 
problem is References with multiple parents.

We had consensus on this two weeks ago. Unless there is a bunch of 
support for Claus's position here, I'm going to consider the issue 
closed (with the exception of In-Reply-To -> References with multiple 
parents, which I will fix).

pr

---

From: Paul Overell <[email-masked]>
Date: Tue, 16 Mar 1999 16:30:15 +0000

In article <v04204a03b3142482896e@[129.46.85.87]>, Pete Resnick
<[email-masked]> writes
>are lots of people now who include all kinds of crap in their 

Turnpike parses In-Reply-To.  It can thread mailing lists and will use
the In-Reply-To: if there is no References:.

Despite the frequent crap in In-Reply-To: it works tolerably well.

As Turnpike expects to find crap in the In-Reply-To: it would not be
broken by multiple parents.
 
I have no problem with the proposed changes to the In-Reply-To: header
since it is a subset of RFC822.  Any RFC822 compliant UA will not be
broken by these changes. 

Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 1999 23:50:13 -0000

What's the benefit of creating both In-Reply-To and References when
there's only one parent? This seems unnecessarily complicated.

Are there some mail readers that can extract the parent's ID from
In-Reply-To but not from References?

---Dan

---

From: Pete Resnick <[email-masked]>
Date: Tue, 16 Mar 1999 09:38:21 -0600

Again, what software?

pr

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 1999 23:50:13 -0000

---Dan

---

From: Paul Overell <[email-masked]>
Date: Tue, 16 Mar 1999 16:30:15 +0000

Regards

---

From: [email-masked] (Claus André Färber)
Date: 17 Mar 1999 10:36:00 +0100

Pete Resnick <[email-masked]> schrieb/wrote:
> In fact, according to 822, phrases alone are legal in In-Reply-To...

I was so sure about that... Sorry. It is rarely used, though, and might  
still break software.

AFAIR there was software to handle In-Reply-To just the way References  
are handled in news (and 822bis). Anyone confirm that?

If there isn't such software, I don't care too much about In-Reply-To.  
References is much more important.

> Eudora. I'm not inclined to deal with that.

Hm, if previous correspondance in RFC 822 means the(all) direct  
parent(s) and other correspondance means everything else, including  
grandparents and their ancestors, this behaviour is the correct one.

I just can't believe that only a beta version of a single product  
actually did it that way.

> How? It says, "Don't do it."

Exactly. So you won't have any threading information (if one assumes  
that software only uses References, which will probably be soon the  
case).

The solution here could be to put the Message-ID of one parent in the  
References header. (It is still possible to later introduce a new header  
field and drop In-Reply-To for the remainig parents.)

So software that assumes a singple-parent thread is happy and other  
software can look at the In-Reply-To header of any message to find out o
about other parents.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 17 Mar 1999 09:25:03 +0100

>there's only one parent? This seems unnecessarily complicated.

    You have obviously not been reading your mail.  There is not just one
parent.  Existing RFC 821 terminology allows for multiple parents.  What
we have been discussing is the exact wording of how these fields should
be described so as to make this fact more explicit, and to give a little
more active direction to those folks who are writing MUAs that might make
use of these facts when constructing message threads.

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
   Usenet is not the web.  Just because the web handles some things
 poorly is not a good reason to apply those same solutions to Usenet.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Mar 1999 21:49:45 -0000

Once again: If I'm replying to a single message, why should I create
both In-Reply-To and References? What benefits does this have over
creating References alone?

Brad Knowles writes:
> You have obviously not been reading your mail.

I apologize if the word ``when'' is beyond your vocabulary.

---Dan

---

From: Pete Resnick <[email-masked]>
Date: Mon, 22 Mar 1999 15:03:23 -0600

>creating References alone?

Random possibilities:

1. Simplification of implementation. You can derive the two fields 
independently and don't have to worry about interdependencies or 
counting the number of parents at the get-go.

2. Slightly different semantics. It may be that you want to continue 
a thread but reply to an earlier message in the thread. It's at least 
consistent with the 822 semantics to have it as a separate field.

Maybe someone else can envision other future uses that would make it 
convenient to have both.

Bigger picture: There's no real benefit given the 822bis instructions 
for how to form the fields since the In-Reply-To message-id will 
*always* appear at the end of the References. Do I think it's worth 
the note which will say "This stuff is fully redundant if you're only 
talking about 1 message"? (*Shrug*)

pr