Re: the gap regarding Archived-At

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.