On Fri February 18 2005 02:48, Martin Duerst wrote:
>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.
Well, I could just say that it updates RFC 2046. But I'm not
sure this is necessary.
>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).
Well, I could just say that for partial messages, the semantics
may be either-or. Not the best solution, but that would make
spec an reality match, at least, without any updates to
infrastructure.
>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.
Ok, so that would mean that the semantics would have to be
extended even a bit more. What about the following sentence:
"Note that due to the way header fields are handled with message
fragmentation and reassembly [RFC2046], there
may be cases where the URI in an Archived-At message header field
points to the archived version of an original (unfragmented) message
from a fragmented part of a message or the archivedversion of a
fragmented part of a message from the reassembled message."
It's a tough call, and the cause of the difficulty is the way
message/partial fragmentation and reassembly operates. Long-term
the best solution would be a replacement for message/partial that
doesn't have the same difficulties -- that's on my list of things
to do.
In the meantime, the architecturally-consistent (but backwards
incompatible) resolution would be to amend RFC 2046 in the same
manner as RFCs 2998/3798.