That is a justification for requiring MIME header fields to begin with
"Content-" -- I understand and agree with that convention. However, that
does not justify this part:
The only
header fields that have defined meaning for body parts are those the
names of which begin with "Content-". All other header fields are
generally to be ignored in body parts.
which has no technical justification and should not be in the spec.
On the contrary. Let's consider the case of an X.400 gateway. An X.400 gateway
tunnels RFC822 message header fields it cannot translate by using a heading
extension defined for the purpose. Header fields that apply to the actual body,
on the other hand, cannot do this, since there's no association of what's in
the heading extension with what's in a particular body part. (There's also at
least one instance of a widely used X.400 system that inserts additional
message contexts under some conditions, which has the effect of completely
disassociating the heading extensions from its body parts.)
There is (or will be) a separate extension for file transfer body parts that
can be used specifically to carry body-part-specific headers that cannot
be translated.
This in turn means that there has to be a rule that can be used to delineate
the two. MIME provides such a rule -- the text you object to.
Similar considerations also apply to gateways into other environments. I used
X.400 as an example only because there is a standard to back up this approach.
I know what the spec says, and I say it is wrong. It is wrong because it
presumes that all header information meaningful to a body part has been
defined with the intention of being in a body-part. The fact is that
there are many header fields which may apply to an entity that were not
defined with body-parts in mind -- this arbitrary restriction prevents
MIME multiparts from being used for hierarchical encapsulation without
the additional overhead of the multipart/digest equivalent.
It does nothing of the sort. Additional header fields specifying MIME semantics
have to be defined before you can use them, and they are supposed to be defined
according to what the standards say. That is why I objected in the first place.
A header that isn't defined to have any MIME semantics doesn't have any MIME
semantics -- its a tautology. And the minute it does, it needs to begin with
"content-".
I can understand why you don't want to change the MIME spec at this point.
However, I consider any MIME implementation that does not make all of the
header fields available to MIME processing to be broken by design, regardless
of what the spec says they should do. Making a broken design a standard
doesn't fix it.
Well, all I can say is that you are a helluva a long way away from
demonstrating this to my satisfaction. Demonstrate that the specification is
broken and I won't oppose changing it. However, my current position is that the
specification is 100% correct and its your changes that are completely broken.
HTTP disregards this part of the MIME spec because it
must do so in order retain entity information within body parts,
and I don't like disregarding the MIME spec when I shouldn't have to
(i.e., when the design constraints of the two systems are identical).
I was not aware that HTTP disregards this. If so its only because I was asleep
at the switch, and didn't catch it when the document was reviewed. Now that you
have pointed it out I will be alert to it and will lobby to have HTTP changed
and not MIME.
Ned