Adam M. Costello wrote:
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.
Any new MIME extension fields (viz. those with field names beginning
with "Content-" -- barring inappropriate use as in some early MIXER
fields) should be handled correctly. But for others, that is an issue
that occasionally pops up -- RFC 561/724/733/822/2822 message header
fields aren't self-describing and don't have a regimented fixed format.
That means that for certain operations, an implementation must carry
hard-coded information about how to process specific fields, and changes
or additions require updated code (or may lead to interoperability
issues). Simply parsing header fields requires some hard-coded
information; for example one cannot simply assume that in all cases
parentheses delimit comments -- that doesn't apply to unstructured
fields (or unstructured parts of fields that mix structure and
unstructured content), MIXER fields (where comments are forbidden and
parentheses are used for other constructs), fields that use RFC 2533
"features" specifications (which use parentheses for grouping), or
fields which may contain URIs (parentheses -- not necessarily balanced --
are legal characters in URIs).
Message fragmentation seems pretty hairy. Does anything actually use
it?
I can't say for certain. I haven't seen any actual use of message/partial,
although ad-hoc approaches to splitting large messages and recombining
are in widespread use in Usenet binary newsgroups. Somebody claimed (a
few months ago) that message/partial constituted a "new" exploit of
anti-virus software, but in reality it turned out that certain AV software
that claimed to function as an email gateway wasn't correctly handling
message/partial (and most likely message/external-body) as documented in
the decade-old RFC 1344.
Incidentally, there's an error in the fragmentation/reassembly example
in RFC 2046 (and as repeated and modified here): the order of Message-ID
and Subject fields is reversed in the reassembled message as compared to
the enclosed header in the first piece, in violation of the "in order"
part of rule 3.