Wrong. The "Content-" prefix serves a very important purpose -- it allows for
use of the header with body parts of messages rather than messages as a whole.
From RFC1521, section 7.2:
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-". No existing MIME applications discard these fields -- in fact,
they are explicitly forbidden from doing so by another section of RFC 1521.
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.
The only thing that the above section accomplishes is waste bytes.
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.
This paragraph is explicitly disregarded in HTTP, and should be removed
from the draft standard for MIME.
...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/