Re: the gap regarding Archived-At

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.