Regarding this part of RFC 1521:
A body part is NOT to be interpreted as actually being an RFC 822
message. To begin with, NO header fields are actually required in
body parts. A body part that starts with a blank line, therefore, is
allowed and is a body part for which all default values are to be
assumed. In such a case, the absence of a Content-Type header field
implies that the corresponding body is plain US-ASCII text. 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. Although they should
generally be retained in mail processing, they may be discarded by
gateways if necessary. Such other fields are permitted to appear in
body parts but must not be depended on. "X-" fields may be created
for experimental or private purposes, with the recognition that the
information they contain may be lost at some gateways.
Ned wrote:
Actually, there is a *very* good reason for doing this. When we defined MIME
we
elected to exploit RFC822's extensibility rather than embed everything in
message bodies. This led to a curious situation where MIME objects effectively
appear in a wide variety of contexts -- with their header fields mixed into an
RFC822 header, with their header fields mixed into a News header, with their
header fields mixed into HTTP headers, and finally, as standalone objects.
This can be quite confusing, and we decided to have a textual convention for
distinguishing fields associated with MIME. We picked "Content-" as this
textual convention.
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.
Whether or not they are ignored by an application is irrelevent; all header
fields are ignored by an application which doesn't intend to use them.
There is not way to confuse them with "normal" RFC 822 header fields, since
normal RFC 822 header fields wouldn't be in the body part to begin with.
Apparently you didn't read the section very carefully. Applications are
supposed to ignore them, and while it is true that implementations are
supposed
to preserve them, there is nothing that says they are required to make these
fields available to MIME processing. In fact my interpretation is and always
has been that MIME processors should not make these fields available.
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.
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. 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).
...Roy T. Fielding
Department of Information & Computer Science
(fielding(_at_)ics(_dot_)uci(_dot_)edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/