Excerpts from mail: 24-Apr-91 Re: compressed as Content-E.. Bill
Janssen(_at_)parc(_dot_)xerox(_dot_) (857)
But if we take this mechanism to extremes, we really don't need
Content-Encoding at all, as we can keep on recursively applying decoding
mechanisms. I feel that "compressed" should be another
Content-Encoding, rather than part of the Content-Type.
I could sooner agere to this, actually, than to a genuine proliferation
of content-encodings, although I don't think that's what Bill's
proposing so it isn't really a fair comparison.
Here's the way I see it: Content-type, together with encapsulated
messages & multipart content-types, really is a powerful enough
mechanism to do ANY of the things we've discussed on this list.
Content-Encoding isn't strictly necessary at all. HOWEVER, the 7-bit
and line-length limitations of SMTP pose a set of problems that affect
LOTS of different content-types, notably including 8-bit text. Having a
very standard mechanism of turning any arbitrary content-type into an
8-bit-safe content type is, in my opinion, highly desirable, and worth
the extra mechanism of a Content-Encoding header. At least, it is so
long as it is simple enough to admit of a "standard" implementation,
because this is never going to be true of content-types, which are going
to proliferate. If Content-Encodings are not going to be standard --
that is, if they're going to proliferate just as Content-types do --
then I see no reason at all for the separate header.
I think there's a very strong argument for two content-encodings, the
base64 and the quoted-printable, because they correspond to very
different situations (binary content types vs. near-ascii). The case
for hexadecimal is much weaker, and I think they get weaker still from
there. I can see the argument for a compressed encoding, because it
offers a significant advantage, but I'm not sure the world is ready to
argree on a standard compression algorithm. Beyond that, I think that
multiple encodings opens up a Pandora's box of complication. If we're
going to go down that road, I for one would advocate stepping back and
taking the approach the Bill mentions, though I don't think he really
advocated it: giving up Content-Encoding entirely, in favor of a few
additional content-types such as "base64-encoded-message". That
alternative is sounding better to me all the time! -- Nathaniel