Bruce Lilly <blilly(_at_)erols(_dot_)com> wrote:
However the first piece body does contain X-Weird-Header-1 and
X-Weird-Header-2 which are not in F but have neither been copied to
the enclosing message header nor elided.
I think the purpose of those fields in the example is to illustrate that
putting non-F fields into the enclosed header is pointless, because they
won't survive into the assembled message. If you want a non-F field to
appear in the assembled message, the only way to accomplish that is to
put it in the first enclosing header. If you want an F field to appear
in the assembled message, the only way to accomplish that is to put it
in the enclosed header.
Duplicating an F field in both the enclosed and first enclosing header
will cause it to be duplicated in the assembled message, which is
probably not what you want.
Duplicating a non-F field in both the enclosed and first enclosing
header is harmless, but the copy in the enclosed header is just a waste
of space, because it is completely ignored.
Fields in non-first enclosing headers have no effect on the assembled
message, but could affect the handling of the outer message before
assembly.
Although the sections of the spec are called "Message Fragmentation
and Reassembly" and "Fragmentation and Reassembly Example", they don't
actually specify or exemplify fragmentation; they specify and exemplify
reassembly (and give one constraint on fragmentation--the line boundary
rule).
But given the reassembly spec, the fragmentor can deduce what it needs
to do in order to cause any desired result at the other end.
(5) All of the header fields from the enclosed message,
You mean the message to be enclosed; it hasn't yet been enclosed.
except those that start with "Content-" and the specific
header fields "Subject", "Message-ID", "Encrypted", and
"MIME-Version", MUST be copied, in order, to the header of
the initial enclosing message. Fields so copied MAY be
elided from the enclosed message fields which appear in the
body of the initial piece,
That looks like a correct deduction. Well, I'm not so sure that the
order MUST be preserved. They MUST be copied, and based on RFC 2822
ordering requirements, the order SHOULD be preserved, and the order of
trace and resent fields MUST be preserved.
and those which are mandatory in a message SHOULD be copied
to the header of subsequent pieces.
That might be a good recommendation, but it would be new; it's not
implied by the existing reassembly spec. For example, when a message is
fragmented, the Date field is copied into the first enclosing header.
The Date fields of the other enclosing headers could be copies of that
one, or they could indicate the time that the fragmentation took place.
Either behavior seems reasonable to me, and both result in the correct
reassembled message.
All pieces MUST meet the message format requirements;
Of course.
in particular, if the message format limits the number of
instances of a field type in a message and that number
of instances appeared in the enclosed message, an entity
generating pieces MUST NOT exceed the limit by producing
another instance of that field type in the initial enclosing
message header.
The "in particular" connector doesn't make sense, because this is
talking about ensuring the correct formatting of the reassembled
message, not the pieces.
More importantly, it's overstated. For example, the message format
limits the number of Date fields to 1, but an entity generating pieces
MAY put instances of Date in both the enclosed header and the first
enclosing header, because the instance in the enclosed header will be
ignored. The restriction you describe applies only to F fields.
By the way, the assembled message will have Received fields reflecting
the path taken by the first part, but the paths taken by the other parts
will be lost. Hmmm...
AMC