[I am sending this message to the IETF-822(_at_)imc(_dot_)org mailing list and I
am Bcc'ing the USEFOR list. Please post all follow-ups to the
IETF-822 list; it is a discussion that USEFOR people will be
interested, but certainly doesn't belong on that list.]
Though I am not working on Eudora full-time anymore, occasionally I
still do write code and discuss new features. We've got a new feature
we're implementing in Eudora: Replying to multiple messages. With
this feature, you can select multiple messages and hit "Reply", and
Eudora will address the reply to all of the senders of the original
message (Cc'ing all of the recipients if you say "Reply-to-All"),
quote the text of those messages in the reply (in some fancy ways
that have to do with another feature that's being worked on), and
allow you to edit your reply. That's all well and good.
When the reply is formed, two additional fields appear in the header
of the message you send: "In-Reply-To:" and "References:". Forming
the "In-Reply-To:" is easy. You take the message-id's of all of the
messages to which you're replying and put them in.
But "References:" is a different problem. As it is used in usenet and
elsewhere now, everything assumes a single rooted thread. But when
replying to multiple messages, you can end up with a multi-rooted
thread. And if you reply to two messages that have a common root, you
end up with branches re-joining. I've got an idea of what a
"References": field should look like, but I thought others might want
to give their input.
Below is a message from Steve Dorner with the idea that he and I
worked out. We'd like a little feedback on the proposal, including
how badly it's going to screw up current implementations. (Screwing
up current implementations is not a show-stopper, but we'd consider
reasonable workarounds if you can come up with some.) All of the
below is perfectly within the 822/2822 semantics, but it's definitely
not something that anything can deal with now.
Comments?
pr
--- begin forwarded text
Date: Thu, 29 May 2003 11:23:12 -0700
To: Eudora-Losers:;
From: Steve Dorner <sdorner(_at_)qualcomm(_dot_)com>
Subject: multi reply and references
Pete and I spent some time discussing how to build proper
In-Reply-To: and References: headers for replying to more than one
message at a time.
Review:
When you reply to a message, you put that message's message-id in the
In-Reply-To header. You copy any References header from that message
into the new message, and append the original message-id to it. So
if I have messages 1 (the original), 2 (a reply to 1) and 3 (a reply
to 2), the headers look like:
1:
Message-Id: 1
2:
Message-Id: 2
In-Reply-To: 1
References: 1
3:
Message-Id: 3
In-Reply-To: 2
References: 1 2
Now let's suppose we have message 4 as a reply to 1, and 5 as a reply
to 4. Those messages look like:
4:
Message-Id: 4
In-Reply-To: 1
References: 1
5:
Message-Id: 5
In-Reply-To: 4
References: 1 4
Now, through the magic of the content concentrator and multiple
reply, we reply to 3 and 5 simultaneously. The resulting message
should be constructed as follows:
6:
Message-Id: 6
In-Reply-To: 3 5
References: 1 2 3 1 4 5
Now let's assume message 7 is a reply to messages 1-5. It should be
constructed thus:
7:
Message-Id: 7
In-Reply-To: 1 2 3 4 5
References: 1 2 3 1 4 5
How did we come up with that? Well, the theory behind the references
header is that it should trace the entire thread. In our case, we're
combining threads, and so we want to represent each thread uniquely
and distinctly, but not redundantly. The algorithm is as follows:
- Make a list of all messages being replied to.
- Take all the message-id's from the messages in the list and put
them into the new In-Reply-To:.
- Aggregate all the references from all the messages in the list. For
each message in the list, search for that message's message-id in the
aggregated references. If it appears, remove it from the list
(because it is being referred to by another message, it's clear
- For each message left in the list, take its references, append its
own message-id, and add it to the references for the new message.
There are two more complications.
First complication: replying to a combined thread. Suppose message 8
is a reply to 7. We think its References header should reflect all
the threads it continues, and therefore should be constructed thus:
8:
Message-Id: 8
In-Reply-To: 7
References: 1 2 3 7 1 4 5 7
You know that the threads have been combined because 1 appears twice,
and you can figure out the sequencing. (What a doctrinaire reference
threading UI does with this, I neither know nor care, but at least
the information is there.)
Second complication: replying to combined DISTINCT threads.
Suppose we have message A, B as a reply to A, and C as a reply to B.
We now reply to 3 and C, to form message X. The references header
would be generated thus, according to the above algorithm:
X:
Message-Id: X
In-Reply-To: 3 C
References: 1 2 3 A B C
The problem is that there is no way to tell that A is not a reply to
3. Here is where we will have to invent syntax. Either we make a
special "new thread" message-id and insert it:
References: 1 2 3 iamspecial A B C
Or we add a new header:
Thread-Heads: 1 A
References: 1 2 3 A B C
Either option would preserve the information that 1 2 3 and A B C are
distinct threads. Probably we would revise message 8 to follow
whatever explicit syntax we use to solve this problem, even though
it's not strictly necessary:
8':
Message-Id: 8
In-Reply-To: 7
References: 1 2 3 7 iamspecial 1 4 5 7
8'':
Message-Id: 8
In-Reply-To: 7
Thread-Heads: 1
References: 1 2 3 7 1 4 5 7
--- end forwarded text
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102