Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Message-Id: <v04204a03b3142482896e@[129.46.85.87]>
In-Reply-To: <7CvQA5gZcDB@faerber.muc.de>
References: <7CvQA5gZcDB@faerber.muc.de>
Date: Tue, 16 Mar 1999 09:38:21 -0600
To: mail-std-list@faerber.muc.de (Claus =?iso-8859-1?Q?Andr=E9?=
 =?iso-8859-1?Q?_?= =?iso-8859-1?Q?F=E4rber?= )
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: References/In-Reply-To replacement text
Cc: drums@cs.utk.edu

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

> Pete Resnick <presnick@qualcomm.com> schrieb/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.
>
> This is bad as it completly breaks threading.

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?

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

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
--
Pete Resnick <mailto:presnick@qualcomm.com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102