Subject: Re: References and In-Reply-To (section 3.6.4)

From: Brad Knowles <[email-masked]>
Date: Wed, 24 Feb 1999 10:08:24 +0100

On Wed, Feb 24, 1999, Pete Resnick <[email-masked]> wrote:

>3. Let's put a warning in 822bisthat says trying to form a References 
>line from multiple parents is likely to confuse certain clients and 
>therefore shouldn't be done.

    Then we need to introduce the idea of a "canonical" parent, which is
the only one to get it's "References:" header copied into that of the
child, and to which the child would add the message-id of the "canonical"
parent.  Determining which message would be the "canonical" parent might
be difficult.

    IMO, I don't think that having additional articles listed in the
"References:" header is going to cause all that big of a problem.  If
nothing else, we know that this header is likely to be somewhat
incomplete anyway, since I believe that we're going to limit the size to
which it can grow (either by placing an arbitrary limit on the number of
message-ids that can be listed, or by placing an arbitrary limit on the
length of the header after unfolding).

    Therefore, having some additional information in there that you might
not otherwise expect could at least be easily ignored by MUAs that don't
implement multiple parent threading.

    However, I am willing to defer to your greater expertise (and that of
others on this list) in this matter.

>Would this make all sides sufficiently happy and not violate anything 
>that is currently going on in the world?

    I would be willing to support this proposal.

-- 
  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: Jamie Zawinski <[email-masked]>
Date: Wed, 24 Feb 1999 10:26:49 -0800

> length of the header after unfolding).

The current text doesn't place any such limits or recommend any
truncation rules, does it?  Unless this is elsewhere in the document 
and I missed it.

I believe USEFOR has also given up on the idea that you have to truncate
headers, but I'm not sure (this has been being argued about over there
for a long time.)

>> that is currently going on in the world?

I think so.

What I want is for 822bis to codify References as the existing behavior
as described by 1036.  I don't particularly care about what 822bis says
about the In-Reply-To header.  So if you want to define In-Reply-To as
the place where multiple parents can live, that's fine with me.

By the way, since 822 defines that header as

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

does that mean that <>-bracketed text must have the semantics of
"msg-id" and not "route-addr", even though they're syntactically
indistinguishable?  And does that mean that an In-Reply-To header
like this:

	Message-Id: <[email-masked]>
	From: Eric Allman <[email-masked]>
	X-Mailer: exmh version 2.0.1 12/23/97
	In-reply-to: Mail from John C Klensin <[email-masked]> 
		dated Wed, 03 Jun 1998 21:38:36 EDT
		<[email-masked]> 

and this:

	From: [email-masked] (Ran Atkinson)
	Message-Id: <[email-masked]>
	X-Mailer: Z-Mail (4.0.1 13Jan97)
	In-Reply-To: "D. J. Bernstein" <[email-masked]>
	        "subversion of WGs by document editors" (May  8,  4:07)

are illegal, since "<[email-masked]>" and "<[email-masked]>" are not
intended to be interpreted as message IDs?

If I can't get the In-Reply-To header deprecated, then I at least want
to make sure that totally unparsable forms like these are illegal in the
future.

-- 
Jamie Zawinski
[email-masked]    http://www.mozilla.org/   (work)
[email-masked]        http://www.jwz.org/       (play)

---

From: Pete Resnick <[email-masked]>
Date: Wed, 24 Feb 1999 12:57:14 -0600

On 2/24/99 at 10:26 AM -0800, Jamie Zawinski wrote:

> truncation rules, does it?

Nope
> I believe USEFOR has also given up on the idea that you have to 
> truncate headers, but I'm not sure (this has been being argued 
> about over there for a long time.)

Trimming is still in the current draft.

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

First of all, 822bis *only* allows 1*msg-id so this is no longer an 

> 		<[email-masked]>

That one's violently illegal since "," and ":" (in the date) are both 
specials and not allowed unquoted in phrase. If something tried to 
parse the above, even under the 822 syntax, they'd be in trouble.

> 	        "subversion of WGs by document editors" (May  8,  4:07)

That looks like it should be interpreted (leaving out whitespace) 
"phrase msg-id phrase comment" where the two phrases are 
quoted-strings.

But like I said, neither are generated in the 822bis generate syntax.

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

---

From: Russ Allbery <[email-masked]>
Date: 24 Feb 1999 21:10:35 -0800

>> truncate headers, but I'm not sure (this has been being argued about
>> over there for a long time.)

> Trimming is still in the current draft.

I think the References trimming argument finally reached resolution on
USEFOR with the conclusion that References should be trimmed in Usenet
posts.  But the motivating reasons for this were backwards compatibility
with some older (and buggy) servers and because on Usenet there are
threads that tend to last forever, their References headers constantly
increasing in length.

The latter is much less likely to be a problem in e-mail, where at least
in my experience threads are shorter-lived.  But *optional* trimming
should probably be allowed just in case (one doesn't want to mandate that
one include 40K of References header in a one-line message).

-- 
Russ Allbery ([email-masked])         <URL:http://www.eyrie.org/~eagle/>

---

From: Pete Resnick <[email-masked]>
Date: Sun, 28 Feb 1999 01:07:27 -0600

The following seems to have made the folks who were arguing about 
this topic on the DRUMS list sufficiently happy:

1. In-Reply-To in 822 can take multiple message IDs. The semantics of 
that are clear: multiple parents. So in 822bis let's just define 
In-Reply-To to contain a list of one or more message IDs which is 
formed by taking the contents of the Message-ID field(s) of the 
parent message(s) and be done with it. In the MUA which I write, we 
have been planning to make use of this feature to deal with multiple 
parent replies and I'd like for that use not to be "outlawed" just as 
we release a new feature. News isn't using In-Reply-To anyway, so no 
harm done.

2. Forming a References field from one parent is easy, and Jamie 
provided decent text to do that. So in 822bis let's define References 
to contain the contents of the References field of the parent message 
(if any) followed by th Message-ID field of the parent message (if 
any).

3. Let's put a warning in 822bisthat says trying to form a References 
line from multiple parents is likely to confuse certain clients and 
therefore shouldn't be done. Then one of us bright people can go 
either (a) define a new field which will appear in some other 
document or (b) convince the USEFOR group to define References in 
such a way that it behaves differently in the presense of a 
multi-parent In-Reply-To.

Brad Knowles added the following caveat:

Then we need to introduce the idea of a "canonical" parent, which is 
the only one to get it's "References:" header copied into that of the 
child, and to which the child would add the message-id of the 
"canonical" parent. Determining which message would be the 
"canonical" parent might be difficult.

I will try to work out some text which takes all of this into account 
and post it first to the group list for discussion. If others (hint, 
hint, Jamie) have some suggested text that can do this, please either 
send it to me privately or post it to the group list. When it is all 
hashed out, replacement text for 3.6.4 will be posted to both the 
group and the last call lists.

pr