Hello Bruce,
Please see below.
At 02:05 04/10/31, Bruce Lilly wrote:
>On Thu October 28 2004 19:54, Keith Moore wrote:
>
>> > A message may contain an arbitrary
>> > number of Comments fields. However, it does not solve the
>> > problem of the incompatibility with RFC 2046 message/partial.
>>
>> could you explain that supposed incompatibility again?
>
>Fragmentation/reassembly is defined in RFC 2046 section 5.2.2 and
>its subsections. The issue was discussed in some detail on the ietf-822
>mailing list in June 2003 and again very briefly regarding specific
>field (References, In-Reply-To, and Resent-Message-ID) in September
>2004. Briefly, the fragmentation/reassembly process distributes
>original (unfragmented) message header fields between the header
>of the first fragment and the header of the encapsulated message
>(which appears within the message/partial wrapper in the first
>fragment; reassembly combines fields from those two headers to
>produce a facsimile of the original message from fragment messages.
>RFC 2046 lists specific fields which are taken from the encapsulated
>header -- MIME Content- fields, Subject, Message-ID, Encrypted,
>and MIME-version -- that list is amended by RFCs 2298/3798 to
>include Disposition-Notification-To, Disposition-Notification-Options,
>and Original-Recipient; these fields are the ones which pertain
>specifically to the unfragmented original message as opposed to
>any fragment.
>
>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."
If that's not good enough, please feel free (or better, encouraged)
to provide better text.
Regards, Martin.