Clearly, the proposed Archived-At field applies to a specific message
(like Message-ID), and should be in the same category as those
specifically mentioned. However, unlike RFC 3798 and its
predecessor, the archived-at draft does not amend the RFC2046
list of fields which are reassembled from the encapsulated message
header. Consequently, Archived-At would be treated like Comments;
when fragmenting a message, the field would be copied to the
first fragment message header, and would be reassembled from there
to the reconstituted facsimile of the original unfragmented
message (any such fields within the encapsulated message header
would be ignored, in accordance with the RFC 2046 rules). That
is inconsistent with the semantics proposed for Archived-At, viz. that
it references an archived copy of the specific message in which it
is conveyed. An Archived-At field that originally referred to an
archive of an unfragmented message would therefore be
inappropriately placed in the message header of a different message
(viz. the first fragment message). Moreover, it would be
indistinguishable there from an appropriate Archived-At field which
referred to an archive of that (first fragment) message. And
as fragments may be further fragmented, that issue may be
compounded.
seems like an easy problem to fix:
a) specify that Archived-At is one of those fields that should be taken
from the encapsulated message header, and perhaps
b) specify that Archived-At should not be used to point to archives of
message/partial
or
c) specify that Archived-At fields should be removed from any message
that is fragmented
I don't see that this is a showstopper for archived-at. even if
archived-at and message/partial were completely incompatible,
archived-at (in some form) seems a lot more valuable than
message/partial.
Keith