References
-
RFC 2822 -- Internet Message Format; Section 3.6.4. Identification fields defines "In-Reply-To" and "References"
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.
-
RFC 1036 -- Standard for Interchange of USENET Messages; Section 2.2.5. References defines "References"
This field lists the Message-ID's of any messages prompting the submission of this message. It is required for all follow-up messages, and forbidden when a new subject is raised. [...] If there is no "References" line on the original header, the "References" line should contain the Message-ID of the original message (including the angle brackets). If the original message does have a "References" line, the follow-up message should have a "References" line containing the text of the original "References" line, a blank, and the Message-ID of the original message.
-
DublinCore -- DCMI Metadata Terms defines "relation" (generic) defines "references" (more generic than in-reply-to or parent)
The described resource references, cites, or otherwise points to the referenced resource.
-
W3C -- Annotea Protocols defines "inReplyTo" and "root"
Annotations are commonly thought of as comments that people can make about a Web document. To facilitate discussion about Web documents through the use of annotations, the Annotea protocol includes a separate class of resource called Reply. Replies are a mechanism that allows people to publish replies to annotations; for example, they allow someone to reply to a comment. Replies can also be made to other replies and thus promote threads of discussion. Moreover, as each reply is identified with a unique URI, the Annotea protocol also permits a client to annotate a reply.
-
"t:inReplyTo" whose value is the URI of the resource the user is replying to (in this case, either an annotation or another reply).
-
"t:root" whose value is the URI of the resource naming the start of a discussion (in this case, the annotation that was first replied to). This is used to identify a given discussion thread.
-
Threading: Message-ID, References, In-Reply-To -- D. J. Bernstein; background info on in-reply-to and references in mail and Usenet
-
message threading -- JamieZawinski; "the best known algorithm for threading messages"
-
ThreadsML -- defines "Thread" construct with a sequence of complete thread resources defines "parent" and "children" properties for each resource.
Are there any implementations?
-
RDF Site Summary 1.0 Modules: Threading -- defines "children".
Never adopted as it requires the parent to always know its children, which is not practical in a distributed environment.
There are also specs which have further refinements of replies, such as "agree" or "disagree", including IBIS and Annotea: http://www.w3.org/2001/12/replyType (RDF schema that defines "seeAlso", "Agree", "Disagree", and "Comment")
local vs. distributed
MessageThreading can be implemented as "local to publishing system", where all resources are guaranteed to be consistent and available, and "distribute", where resources cross system boundaries and individual links are less likely to be available. The logical relationships remain the same, but the implementation can be more difficult.
"parent" vs. "in-reply-to"
Discussion of the terms "parent" and "in-reply-to" concerning message threading, mostly centering around "generic" vs. "specific".