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.
Unless you intend for this mechanism to only work for messages as a whole,
it
has to begin with "Content-".
Ned, this section doesn't make any sense to me, and I think I understand
MIME from a technical point of view about as well as anyone not directly
involved in writing the document. There is no technical reason why an
agent should ignore header fields in body parts that do not begin with
"Content-".
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.
No existing MIME applications discard these fields -- in fact,
they are explicitly forbidden from doing so by another section of RFC 1521.
This is entirely beside the point. There are lots of things out there that
don't qualify as MIME applications and thus don't have to play by these rules.
The obvious example are gateways (which are specifically exempted), and like it
or not, we already have *standard* rules for gateways that only preserve
"content-" fields and implementations that follow these rules.
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.
My own MIME applications are a case in point. They follow the stated rules and
they only make "content-" fields available for MIME processing. Everything else
is preserved, per the specifications, but not "passed down" to the MIME
processing code.
The only thing that the above section accomplishes is waste bytes.
Incorrect. See above.
The only sensible interpretation is that ANY header fields within a
body part are applicable to that body part (otherwise, nobody would
bother to put them there). I can understand reserving the Content-*
prefix for fields describing the content (and thus defined by MIME),
but specifically excluding other fields doesn't make any sense.
Well, all can say is that I disagree. I think it is quite sensible to implement
mechanisms that make other header fields inaccessible to MIME processing, I
have done exactly this in my implementations, and changing this at this late
date is simply not acceptable to me.
This paragraph is explicitly disregarded in HTTP, and should be removed
from the draft standard for MIME.
Let me be blunt. This is a showstopper issue for me, since I have thousands of
sites in the field that depend on the present specification staying the way it
has been for the past four years. I am not going to change the documents on
your say-so or anyone else's.
If you want to change it you are going to have to convince the IESG to
reconvene the IETF-822 WG and get a consensus there to change it, in spite of
the fact that there are fielded implementations that follow the current set of
rules. At that point I will insist on a recycle to proposed since this is a
substantive change, and that will blow away five years of work on MIME.
Ned