On Tue, Jan 6, 2009 at 7:17 PM, Ed Greshko <Ed.Greshko@xxxxxxxxxxx> wrote: > Patrick O'Callaghan wrote: >> >> Then I'm somewhat at a loss to understand what you mean by threading. >> The linking of replies to the messages being replied to joins the >> entire set together into a thread. The presentation of the thread as a >> visual hierarchy or whatever is a matter for the MUA. >> > Take 4 messages, each written by a different person.... > > W - Original Message > X - In-Reply-To W > Y - In-Reply-To X > Z - In-Reply-To Y > > If you rely solely on the "In-Reply-To" header there is no practical > method to link Z to W. Except by linking Z to Y to X to W, which amazingly is what mail clients actually do! This would be especially true in the event where > either X or Y did not arrive or does not exist on the message store of > the local MUA. Once has always to take into account these types of > circumstances. Naturally. One quickly learns that when the Internet Gods say that mail is unreliable, they really mean it, and any software which doesn't take this into account will crash and burn. To return to the point: when delayed messages arrive, they are appropriately inserted in the thread the next time the MUA refreshes its folder view, and of course if they don't, they aren't. An additional header called References might help in some cases, but not if the original message never arrived, so we're back where we started. The MUA does what it can with partial information (and it almost never knows if what it has is partial or complete). >>> FWIW, I've found that RFC 2822 has a better discussion of the use of >>> "in-reply-to" and "references" headers and their intended usage. >>> >> >> I quoted RFC822 because you said you weren't aware of RFCs which >> specify threading, and 822 is the original standard reference for >> email (at least in the form that's still in use). >> > But... RFC822 *does not* talk about threading. You are implying that. As I already said, I know it doesn't talk about threading, but it implies certain things about it (otherwise, what is the point of the In-Reply-To header?). The RFC authors are usually very careful not to overspecify things, especially when there isn't enough real-world experience, so it's no surprise that RFC 2822 (which obsoletes 822) has more to say on the subject as it was written a good few years later. > And, even if that were the intent of the authors, it is not clear and > thus very much open to interpretation. >> 2822 is certainly more extensive, but I don't think it adds anything >> to the present discussion. For example, I'm not aware of any mail >> clients that use the References header, or that allow a message to be >> in reply to more than one originating message (such clients may of >> course exist, in which case it would be interesting to know about >> them). RFCs often specify stuff that most clients don't implement, >> e.g. not many people know that you can have a mail message with >> multiple From: headers (the canonical example is a message sent by a >> committee, each member of which appears in the From: line with their >> own address). I've never seen such a message and I doubt I could >> construct one with any of the clients I use, but the RFCs allow it. >> >> > Thunderbird uses the "References" header. If you were to reply to a > virgin message and examine the outgoing message you'd notice that it > adds the "In-Reply-To" and "References" headers which are identical. If > you reply to a non-virgin message it adds the "In-Reply-To" header with > the single message id of the non-virgin message and appends that to the > "References" header. Evolution also does this. That isn't the point: creating the References header is relatively simple. When I say "uses" I mean "pays attention to in incoming mail". Can you give a specific example where the MUA uses the References header to display messages (i.e. derives some information from it that is not present in the In-Reply-To header, other than simply copying it to further replies)? I don't say this never happens, just that it would seem at best to be rare. IOW, everyday threading uses the In-Reply-To header, which is my original point. > T-bird also uses the "Subject" line as a hint to threading to assist it > displaying threads when certain MUAs don't handle the "References" > header...as it strips it out on a reply. As in violates the RFCs. Does it favour Subject over In-Reply-To? Evolution also has an option to take Subject into account, but only as a last resort. > FWIW, not many people know that the "From" header in the message body > may be totally different from the "From" in the SMTP envelope and that > the "From" header isn't used for message transport or delivery. They also don't know the difference between From and Sender, so what else is new? :-) poc -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines