RFC 2822 discusses In-Reply-To and References header fields with respect to
the Message-ID field. I believe that ignores the situation where at least
one Resent-Message-ID field exists in addition to (or possibly in lieu of)
a Message-ID field. I further believe that in the case of a response to a
message containing at least one Resent-Message-ID field, the msg-id placed
in the response In-Reply-To and/or References fields should be that of the
most recent Resent-Message-ID rather than that in the Message-ID field (if
present) or any other Resent-Message-ID field which might be present. Also
in the case where at least one Resent-Message-ID field is present, response
message In-Reply-To and References fields should be prepared as described
above whether or not the message being responded to has a Message-ID field.
I propose that whereas RFC 2822 text regarding this topic says:
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 will contain the contents of the "Message-
ID:" field of the message to which this one is a reply (the "parent
message"). If there is more than one parent message, then the "In-
Reply-To:" field will contain the contents of all of the parents'
"Message-ID:" fields. If there is no "Message-ID:" field in any of
the parent messages, then the new message will have no "In-Reply-To:"
field.
The "References:" field will contain the contents of the parent's
"References:" field (if any) followed by the contents of the parent's
"Message-ID:" field (if any). If the parent message does not contain
a "References:" field but does have an "In-Reply-To:" field
containing a single message identifier, then the "References:" field
will contain the contents of the parent's "In-Reply-To:" field
followed by the contents of the parent's "Message-ID:" field (if
any). If the parent has none of the "References:", "In-Reply-To:",
or "Message-ID:" fields, then the new message will have no
"References:" field.
The successor to RFC 2822 should probably say something like:
The "In-Reply-To:" and "References:" fields are used when creating a
reply to a message. They hold the most recent message identifier of
the original message and the most recent 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 will contain the field body of the most recent
"Resent-Message-ID:" field if any such field is present in the message
to which this one is a reply (the "parent message"), or, if no
"Resent-Message-ID" field is present in the parent message, the
field body of the "Message-ID:" field of the parent message. If there
is more than one parent message, then the "In-Reply-To:" field will
contain the field bodies of all of the parents' most recent "Resent-
Message-ID:" or "Message-ID:" fields. If there are no
"Resent-Message-ID:" or "Message-ID:" field in any of the parent
messages, then the new message will have no "In-Reply-To:" field.
The "References:" field will contain the field body of the parent's
"References:" field (if any) followed by the field body of the parent's
most recent "Resent-Message-ID:" or "Message-ID:" field (if any). If
the parent message does not contain a "References:" field but does
have an "In-Reply-To:" field containing a single message identifier,
then the "References:" field will contain the field body of the parent's
"In-Reply-To:" field followed by the field body of the parent's most
recent "Resent-Message-ID:" or "Message-ID:" field (if any). If the
parent has none of the "References:", "In-Reply-To:", "Resent-Message-ID:",
or "Message-ID:" fields, then the new message will have no
"References:" field.
Note that I have replaced the undefined term "contents" with the
RFC 2822-defined term "field body".
While responses to multiple messages were discussed briefly in June 2003
on this mailing list, I am not addressing that issue here.
Also in June of last year, the issue of message fragmentation and reassembly
using the MIME message/partial media type was briefly discussed. RFC 2046
specifies special treatment for a limited set of header fields, that set
having been amended by RFC 3798 (formerly 2298). Message-ID is part of
that set, while Resent-Message-ID is not. In order to survive a
fragmentation/reassembly cycle, the Resent-Message-ID field (and indeed all
fields not part of the set specified in 2046/3798) must be copied (or
moved) to the header of the first fragment. That means that in addition
to the issue of the semantics of the Date field mentioned last year, the
first part will also attain the semantics associated with Resent-Date
and other Resent- fields. In the case of the Resent-Message-ID field(s),
that means that the first fragment has the same Resent- msg-id identifiers
as the unfragmented message, violating the principle of uniqueness. Note
that that does not happen when there are no Resent-Message-ID fields in
the unfragmented message, because the Message-ID field is in the set of
fields mentioned above, which are taken from the header of the
encapsulated message during reassembly.
I believe the fragmentation/reassembly issue is more challenging, as
it does not appear to be possible to preserve transparency across
a fragmentation/reassembly cycle while maintaining message origination
date and identification semantics with the current (2046/3798)
fragmentation/reassembly rules; at least one of the three -- transparency,
semantics, or rules -- would have to change. I believe that it would be
possible to preserve transparency and semantics, but ensuring
interoperability would entail a new media type similar to message/partial
but with different fragmentation/reassembly rules (or a MIME-Version
change with updated rules applying to message/partial; unfortunately
MIME-Version semantics for a version other than 1.0 aren't provided for).
There are probably other header fields where the message/partial rules
may lead to problems; I expect to be able to summarize several of those
in a future message; I'm concentrating on Resent-Message-ID here.