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

From: Pete Resnick <[email-masked]>
Date: Thu, 18 Feb 1999 11:32:20 -0600

I finally got back to looking at this problem. The only two concerns 
I have about Jamie's text is that it doesn't take into account 
multiple parent messages (In-Reply-To can take multiple message-id's) 
and it uses the word "shall", which even when lowercased I'd like to 
avoid. See if the following rearrangement of his text is acceptable:

-------

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 contains the contents of the "Message-ID:" 
field(s) of the message(s) to which this one is a reply (the "parent 
message(s)"). If there is no "Message-ID:" field in the parent 
message(s), then the new message shall have no "In-Reply-To:" field.

If a parent message contains a "References:" field, then the contents 
of the "References:" field and the contents of the "Message-ID:" 
field (if any) of the parent message are appended to the 
"References:" field of the new message.

If a parent message does not contain a "References:" field, but does 
contain an "In-Reply-To:" field, then the contents of the 
"In-Reply-To:" field and the contents of the "Message-ID:" field (if 
any) of the parent message are appended to the "References:" field of 
the new message.

If a parent message contains neither a "References:" field nor an 
"In-Reply-To:" field, then the contents of the "Message-ID:" field of 
the parent message are appended to the "References:" field of the new 
message.

If no parent message has any "References:", "In-Reply-To:", or 
"Message-ID:" field, then the new message shall have no "References:" 
field.

Note that these rules mean that if both "References:" and 
"In-Reply-To:" fields are present in a parent message, the 
"In-Reply-To:" field will not be consulted when constructing the 
headers of the reply message.

-------

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

---

From: Jamie Zawinski <[email-masked]>
Date: Thu, 18 Feb 1999 10:14:15 -0800

> multiple parent messages (In-Reply-To can take multiple message-id's)

I don't know what it means for a message to have multiple parents.
Like I said:

  I guess my feeling is, you have to decide whether "References" is to
  be a grab-bag of related message IDs, or a map through the thread.

The thread idioms we use in the real world today don't allow messages to
sensibly have multiple parents.  If you want to allow multiple parents,
then you're back to the 822 "grab bag of related IDs" model, which I
claim is not as useful as the 1036 "map through the thread" model.

I don't like describing these headers in terms of "appending."
My description was declarative ("if this condition exists, then the
header contains these N things") whereas yours is procedural ("first
append this then append that") yet at the same time, isn't as explicit
about ordering, due to the vagueries associated with multiple parents.

Also, these two sentences can easily be interpreted as saying totally
different things:

My version:

    Note that these rules mean that if both "References:" and
    "In-Reply-To:" fields are present in the parent message, the
    "In-Reply-To:" field will not be consulted when constructing the
    headers of the reply message.

Your version:

Does the latter say "present in any parent message" or "present in some
specific parent message"?  Maybe more wordsmithing could clear up
ambiguities like this, but I think it's much easier (and utterly
sufficient) to simply talk about a *single* parent message, because it's
easier to think about, easier to understand, and observable in the real
world today.  Multiple parent messages do not exist in the real world
today, unless you go back to the useless 822 "grab bag" model.

> avoid. See if the following rearrangement of his text is acceptable:

Your new text still uses "shall".  Is there a more proper way to say
that?

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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 18 Feb 1999 12:50:07 -0600

> I don't know what it means for a message to have multiple parents.

Select multiple messages. Hit the reply command in your mail client. 
Assume you're mail client is smart enough to say "Aha! He wants to 
reply to all of these in one big reply." (My client is currently not 
so smart, but it soon will be.) Voila, multiple parents.

> claim is not as useful as the 1036 "map through the thread" model.

We can perfectly well represent multiple parents in the In-Reply-To 
field, it is often desireable to have multiple parents, and it seems 
perfectly clear what the semantics of the operation are. I don't 
think our inability to represent multiple parents in the References 
field and still preserve the thread semantics should make us take 
away the ability to use multiple parents.

> about ordering, due to the vagueries associated with multiple parents.

I'd be happy to go back to declarative if you can give me text that 
deals with multiple parents.

> ambiguities like this...

In this case, it's clearly the latter, and I think could be cleared 
up simply by inserting "of that parent" before "will not be 
consulted".

> ...but I think it's much easier (and utterly

Of course multiple parent messages exist in the real world today: How 
many messages on this list have "Jamie wrote this:......" and "Robert 
wrote this:......" and "Here's my reply."? They occur all of the 
time. And we do have a way to represent that in the In-Reply-To 
field. What we don't have is a way to preserve that *and* the thread 
semantics in References. We could theoretically define those 
semantics (like saying that you look at In-Reply-To to discover the 
orderinging of the information in References), but given the lack of 
thread semantics in mail today, why bother.

>> and it uses the word "shall", which even when lowercased I'd like 
>> to avoid. See if the following rearrangement of his text is 
>> acceptable:
>

Yes, I let two slip through accidentally. My textual method is to use 
"has" instead of "shall have", or sometimes "will have" or "is 
supposed to have" if those fit better.

pr

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Feb 1999 16:33:09 +1100

Date:	 Thu, 18 Feb 1999 11:32:20 -0600
    From:	 Pete Resnick <[email-masked]>
    Message-id:	 <[email-masked]>

  PR> I finally got back to looking at this problem. The only two concerns
  PR> I have about Jamie's text is that it doesn't take into account
  PR> multiple parent messages (In-Reply-To can take multiple message-id's)

Yes, there was a brief discussion of that issue, but it went nowhere.

    Date:        Thu, 18 Feb 1999 10:14:15 -0800
    From:        Jamie Zawinski <[email-masked]>
    Message-ID:  <[email-masked]>

  JZ> I don't know what it means for a message to have multiple parents.

This message does - I am replying to both yours, and Pete's messages.
Limiting the world to never be able to reply to two messages at once
is way too restrictive.  I don't care what usenet does, that has always been
based upon a particularly restricted form of 822.

In this case the distinction is perhaps not very obvious, as your message
was a reply to Pete's - but I could easily reply to two (or more) messages
that aren't related that way.

  JZ> I don't like describing these headers in terms of "appending."
  JZ> My description was declarative ("if this condition exists, then the
  JZ> header contains these N things") whereas yours is procedural ("first
  JZ> append this then append that") yet at the same time, isn't as explicit
  JZ> about ordering, due to the vagueries associated with multiple parents.

I think I agree with that.   It is generally better to say what should be
done than how it should be done.

  JZ> but I think it's much easier (and utterly sufficient) to simply talk
  JZ> about a *single* parent message,

But that I disagree with.

  JZ> Multiple parent messages do not exist in the real world today,

Unless you consider me to be not a part of the real world (which is
certainly an option), this is proof by counter example (and I can send
more even less related multi-parent replies if you so desire).

kre

---

From: [email-masked] (Kai Henningsen)
Date: 20 Feb 1999 14:31:00 +0200

>     From:	 Pete Resnick <[email-masked]>

JZ>> I don't know what it means for a message to have multiple parents.

> based upon a particularly restricted form of 822.

Well, considering that only an extremely small percentage of people ever  
manually interpret References: or In-Reply-To: headers, all *I* care about  
is what to do with these headers under program control.

For the mail recipient, this means how to show the user a map of related  
messages, and how to allow him to navigate that map.

Thanks to news usage, it is very well understood (even though an appalling  
number of MUAs just ignore this feature) how to do this in case of single  
parents.

As far as I can make out, *nobody* has an answer of how to do it in case  
of multiple parents, at least without hopelessly confusing most users.

Unless someone can come up with *any* scheme of how to do it that can be  
understood by the average user, I *strongly* object to any notion of  
multiple parents as completely useless protocol bloat. (This does not mean  
that such a scheme should be part of the protocol, but it does mean that I  
require an existence proof of the possibility of such a scheme.)

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 20 Feb 1999 14:07:00 +0200

> multiple parent messages (In-Reply-To can take multiple message-id's)

I consider this a feature. I *strongly* object to any multiple parent  
language.

MfG Kai

---

From: Pete Resnick <[email-masked]>
Date: Sat, 20 Feb 1999 11:54:31 -0600

> number of MUAs just ignore this feature) how to do this in case of single 

Let me start by denying this assertion. Though I have seen countless 
examples of how to do this when there is a simple thread, I believe 
once a thread has multiple branches most of these navigation 
utilities are as incomprehensible to the average user as multiple 
parent presentation would be. At least I know that they're 
incomprehensible to me once you get around 5 branches coming off of 5 
replies to a single message.

> require an existence proof of the possibility of such a scheme.)

OK, an existence proof, though I would not at all be in favor of 
putting this into the protocol at this time:

Protocol: When you have multiple parents, the References field of the 
child is formed by appending the References and Message-ID of each 
parent in the order that each parent's Message-ID appears in the 
In-Reply-To field. Now you can walk the References field and find out 
the references chain for each parent. (Yes, there are problems with 
this if one of the parents is in the chain of another parent, but we 
can make some arbitrary syntactic moves to help with that. But this 
is just a back-of-envelope exposition.)

Presentation: Those of us who write graphical MUAs can use the same 
kind of viewing engine that we've got in the class-hierarchy browsers 
in our development environments: boxes representing each message, 
lines representing the thread "inheritance". Click on a box, open the 
message. Perhaps we can display a portion of the hierarchy in the 
message window or in a separate floating palette showing where you 
are in the tree.

My claim is that: (a) It's perfectly "doable"; (b) The ability to 
indicate multiple parents is in 822 now since it allows multiple 
msg-ids in the In-Reply-To field; and (c) It corresponds to reality 
in that people do replies to multiple messages all of the time and 
it's absurd to deny those semantics and remove something that's in 
the current standard just because we don't have the tools to display 
those semantics at the moment.

I would (I think equally) strongly object to the removal of multiple 
parents from the 822 syntax, and therefore want us to explain the 
semantics of them in some way in 822bis. I think some combination of 
the text that Jamie and I have suggested on the DRUMS list is a 
reasonable way to go.

pr

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Feb 1999 20:07:30 -0000

Pete Resnick writes:
> people do replies to multiple messages all of the time

People also reply to web pages. Do you allow URLs in References?

Perhaps someday USENET will develop new header fields for web pages and
for merged followups. Perhaps it will allow multiple References fields.
Perhaps it will extend the References syntax.

Meanwhile, many readers interpret References according to the USENET
followup semantics. Those semantics specify exactly one ``precursor''
for each followup, with Message-ID shown at the end of References.

---Dan

---

From: Pete Resnick <[email-masked]>
Date: Sun, 21 Feb 1999 16:53:15 -0600

> People also reply to web pages. Do you allow URLs in References?

Nope, because it violates 822 syntax. Multiple message id's in 
In-Reply-To does not.

> for each followup, with Message-ID shown at the end of References.

So what do we do about In-Reply-To? It certainly allows multiple 
message id's in 822 and the semantics is clear enough; I assume noone 
wants me to change In-Reply-To *again* to remove a legal 822 syntax, 
does anyone? And if I leave In-Reply-To with multiple message id's, 
what do I say about its relationship (if any) to References? And what 
do I say about multiple parents wrt References? Deny the existence of 
such a construct?

So far there's only 6 of us talking about this; anyone else care to 
lend an opinion (or some text).

pr

---

From: "Bart Schaefer" <[email-masked]>
Date: Sun, 21 Feb 1999 15:43:05 -0800

On Feb 21,  4:53pm, Pete Resnick wrote:
} Subject: Re: References and In-Reply-To (section 3.6.4)
}
} So far there's only 6 of us talking about this; anyone else care to 
} lend an opinion (or some text).

I don't have time to write at length about this just now, but:

I use heavily the "apply [command] to all marked messages" feature in
Pine, with "reply" being the command.  I also use heavily the similar
"reply to all selected messages" that's been in Z-Mail for years.

It is true that in most cases, the messages so replied-to all have a
common parent (which is sometimes one of the messages included in the
collection), and the intent is to reply to the original and capture
all the follow-on conversation.  This is sort of a "reply to thread"
operation, and I don't see any reason to prohibit it.  At the very
least, the new message *is* in reference to all the messages in the
thread, so why shouldn't the References: or In-Reply-To: fields reflect
that?

The days of References/In-Reply-To being purely a means of generating
a linear thread display in the UI are fast passing.  (JWZ, you should
read your own Intertwingle document again.)

And I definitely concur that we should not be invalidating any more 822
syntax at this point.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

---

From: Brad Knowles <[email-masked]>
Date: Mon, 22 Feb 1999 05:47:24 +0100

>lend an opinion (or some text).

    In-Reply-To: would appear to be fine as-is, with multiple parents. 
References probably should contain the same message ids as In-Reply-To:,
plus any earlier messages that might have been earlier in the reply
chain, etc....

-- 
  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: Mon, 22 Feb 1999 09:59:27 -0800

> Nope, because it violates 822 syntax. Multiple message id's in

And allowing multiple parents in References violates 1036 semantics.
So, we need to pick one, and in this case, I choose 1036 over 822.

> do I say about multiple parents wrt References? Deny the existence of

I find it hard to see changing the semantics of In-Reply-To as being a
big deal, given that in my surveys of common usage of In-Reply-To, I've
not once come across a real-world usage of In-Reply-To that contained
multiple message IDs.  I've come across In-Reply-To fields that
contained "<X@Y>" text -- but in the examples I've grepped for, it has
always been the case that only one was an ID, the rest were addresses.

Perhaps some MUAs do this, but the simple fact is, it's so uncommon that
it hardly counts as an installed base we need to be compatible with,
especially when compared to the installed base that uses 1036 semantics,
and especially when considering that this is a semantic change and not a
syntactic change, and isn't going to cause anything to malfunction.

The 1036 semantics are proven to be useful; the 822 semantics are vague
and have no proven utility.

---

From: Jamie Zawinski <[email-masked]>
Date: Mon, 22 Feb 1999 10:12:56 -0800

> read your own Intertwingle document again.)

What I'm interested in doing here is codifying existing behavior.
The 1036-style usage of References is common, and has a proven track
record.  The vagueries of the 822-style usage of References have never
done anything useful, in the whole time they've existed.  I think it's
more important, at this point, to give people something concrete to
work with than to leave the path open for other hypothetical and/or
unproven innovations.

When we start seeing common UIs that support the kind of nonlinear
navigation you're talking about, then perhaps it'll be time to extend
the protocol to support them better, but frankly it's not clear to me
that even that will be necessary (but I don't know, because nobody has
built good UIs like that yet.)  For now, let's just have something that
works *today*.

> And I definitely concur that we should not be invalidating any more
> 822 syntax at this point.

This whole conversation is predicated on the fact that we're changing
the 822 interpretation of both References and In-Reply-To.  The current
DRUMS draft has *already* changed them.  So unless you're arguing that
we merely revert to the 822 text, this argument doesn't make sense to
me.

I say, given that we're changing them, we should change them to
correspond to current real-world widely-implemented usage, rather than
some theoretically-useful forward-looking semantics that have thus far
gone almost universally unused.

---

From: [email-masked] (Kai Henningsen)
Date: 01 Mar 1999 20:27:00 +0200

> replies to a single message.

I must say I find this completely unbelievable. I cannot see how the  
number of branches is relevant at all in this respect.

> message window or in a separate floating palette showing where you

"Tree" being the operative word here. That's more or less what I'm using  
right now, except no clicking is involved. (And no floating palette  
either. No silly graphics in this thing.)

And it breaks horribly if there is no tree.

Just as an illustration, this is the current tree:

--- snip screenshot ---
  XPoint  Wartung  Nachricht  NeTcall  Fido  EDit  Config  Zusatz
  Adresse  Halten  Löschen  Kill  BrettBrief  PM  Info  Sonstige           Esc
                                                                          kaih  
 Bezugsnachrichten zu "References and In-Reply-To (section"
        996 18.01  Robert Elz (PM)          Re: References and In-Reply-To (sec
       4129 28.01  +-Jamie Zawinski (PM)
       1439 29.01    +-Robert Elz (PM)
       2137 28.01      +-Bart Schaefer (PM)
       1532 28.01      +-Jamie Zawinski (PM)
  +    2551 18.02      +-Pete Resnick                             /»Killed-Mail
  +    2541 18.02        +-Jamie Zawinski
  +    2063 19.02        | +-Robert Elz
       3338 20.02        |   +-Pete Resnick (PM)
  +    3352 20.02        |   | +-Pete Resnick                     /»Killed-Mail
·>+     564 20.02        |   | +-D. J. Bernstein                  /»Killed-Mail
 >        0 20.02        |   | | +-D. J. Bernstein                    /»Replies
 >        0 20.02        |   | +-Pete Resnick                         /»Replies
 >        0 20.02        |   | +-Pete Resnick                         /»Replies
 >      506 21.02        |   | +-Jacob Palme (PM)            URLs in References
 >        0 21.02        |   | | +-Jacob Palme                        /»Replies
·>+    1337 21.02        |   | +-Pete Resnick                     /»Killed-Mail
 >     1426 21.02        |   | | +-Bart Schaefer (PM)
 >        0 22.02        |   | | | +-Bart Schaefer                    /»Replies
 >     1805 22.02        |   | | | +-Jamie Zawinski (PM)
 >        0 22.02        |   | | |   +-Jamie Zawinski                 /»Replies
 >        0 22.02        |   | | +-Pete Resnick                       /»Replies
·>+     966 22.02        |   | | +-Brad Knowles
·>+    1865 22.02        |   | | +-Jamie Zawinski
 >        0 22.02        |   | |   +-Jamie Zawinski                   /»Replies
   !   2688 01.03        |   | +-Kai Henningsen (PM)
·>+    1539 20.02        |   +-Kai Henningsen
                                                                                
S1-FndMdg.BTM C1-Userwechsel/khms C2-kaih@khms C3-postmaster@khms C5-SigCheck
--- snip ---

(The stuff in "Killed Mail" is because cs.utk.edu is in ORBS, and the  
stuff in "Replies" is from my reply detector. And the think with the "!"  
marker is the current, yet unsent message. And (PM) is this program's way  
of saying "email". ">" is still unread.)

I might add that this tree can very easily be navigated by right/left/up/ 
down indicators (for example, cursor keys). The moment you do multiple  
parents, you lose a comprehensible display, and you lose a comprehensible  
navigation.

MfG Kai