Excerpts from ext.ietf-822: 29-Apr-91 Another approach to Encodings
Nathaniel Borenstein(_at_)thu (4169)
Content-type: type [/ charset] [ (encoding) ] [ ; ver-num [ ; resource-ref]
]
(Ignore the syntax for now). The encoding would be one of a very small
set -- probably base64, quoted-printable, and compressed. Then, in the
prose describing each content-type, we could mention which encodings
were acceptable, if any.
This proposal could be re-thought. I find the Content-Type and
Content-Encoding orthogonal; I see no reason to specify or, more
importantly, UNDERSTAND acceptable encodings on a per-content-type
basis. Overloading & intertwining meanings almost always leads to
complicated and poorly implemented/accepted systems.
Look at the problems that are being addressed: "Content-Type" handles
the need that people have to pass formatted messages around, and have
the receiving mail agent know what the message body is, so that it can
be displayed properly. "Content-Encoding" handles the need that people
have to package the message in some way so that they feel that it will
make it past intervening mailers unscathed -- it has nothing to do with
the Content-Type, in a strict sense (sure, various encodings might be
more frequently applied to various content-types, but it also depends on
user knowledge/hopes/fears about the intervening transport system and
receiving UA).
From the discussion, it looks as if we need a couple of others:
"Text-Charset" handles the need that people have to pass text in
non-ASCII character sets (default is RFC822ASCII) (again, this is
orthogonal to Content-Type and Content-Encoding), and
"Transport-Byte-Type" handles the need that people have to express their
assumptions that the transport path is 7BIT, 8BIT, or BINARY (default is
7BIT). With suitable conventions, "Transport-Byte-Type" might perhaps
be deduced from Content-Encoding, but again, it would be better to break
this out on its own, so that MTA's know what to do with oddball X-FOO
Content-Encodings.
Bill