Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Message-Id: <v0410470eb2f4a7ecb50e@resnick2.qualcomm.com>
Date: Sat, 20 Feb 1999 11:57:53 -0600
To: kaih@khms.westfalen.de (Kai Henningsen)
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: References and In-Reply-To (section 3.6.4)
Cc: drums@cs.utk.edu, lc-drums-msg-fmt@apps.ietf.org

My apologies for the resend to DRUMS, but the address for 
lc-drums-msg-fmt was incorrect in the original message. Please only 
reply to this one.

On 2/20/99 at 2:31 PM +0200, Kai Henningsen wrote:

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

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.

But that said:

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

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