Tim,
thanks for the comment!
I hope we can make sure that the WWW definition is the same as the
"official" one (whether amending one or the other).
The content- piece got into there for 2 reasons:
1) The language in RFC 1521 says:
Global mechanisms are best addressed, in the MIME model, by the
definition of additional Content-* header fields.
Also, in chapter 7.2 (Multipart):
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.
2) The Language: parameter is defined in RFC 1327, with slightly different
semantics (only one language permitted).
Reusing existing names with a slightly incompatible interpretation
can get painful, so I would like to opt for a new name.
Harald A