[Top] [All Lists]

Re: RFC 2046 message/partial (sect. 5.2.2) clarification

2003-06-09 03:54:18

Bruce Lilly <blilly(_at_)erols(_dot_)com> wrote:

(the text was copied and modified from rule 2, so the same objections
apply to rules 2 and 3).

Good point.  The fragmentation & reassembly rules should be consistent
with each other, and I guess it won't hurt if they are stricter about
order than RFC 822/2822, but it won't really help either, since you
can't assume that the order that is being so carefully preserved is
meaningful in the first place.  And as you pointed out, some orders are
impossible to preserve, because the F and non-F fields get segregated.

What I had in mind was the pieces and non-F fields.  If those are to
be preserved through the fragmentation/reassembly process, they have
to appear in the initial piece message header, and that precludes the
fragmentation agent from adding its own instance of any such field.

Okay, sorry, I misunderstood the point you were making.  I get it now.

I think I agree with your new recommendation about copying the original
header (except for the F fields) into the header of every fragment.
MIME fragmentation seems very analogous to IPv6 fragmentation, which
specifies that the fragmenter copy all the non-enclosed headers into
every fragment, and that the reassembler keep the first enclosing header
and drop the others.

I notice one key difference, though.  In IPv6, even as new options are
defined, which are unknown to existing implementations of fragmentation
and reassembly, those options will be handled correctly, because they
will appear inside one of a few known header types that indicate whether
they should be outside or inside the fragmentation enclosure (hop-by-hop
and routing headers go outside, others go inside).

IPv4 options have a flag indicating whether they are copied into all
fragments or just the first fragment, to address the same concern.

But for new message header fields, if they try to define themselves as
"F fields" (fields that should go in the enclosed header), existing
implementations won't know that, and will put them in the enclosing
header instead.  RFC 2298 provides an example of new header fields
needing to go in the enclosed header.  If it happened once, it can
happen again.

Message fragmentation seems pretty hairy.  Does anything actually use