Excerpts from ext.ietf-822: 24-Apr-91 Re: Comments on Draft RFC
Nathaniel Borenstein(_at_)thu (2624)
I think Vincent's distinction between transport-dependent and
data-dependent encodings is a very clarifying notion. I have always
thought of the Content-encoding as a transport-dependent encoding, and
that data-dependent encoding can be fully specified with the
content-type header.
I like the thought of putting all the information about the "type" of
document into the Content-Type header, and putting all the information
about how to extract a document of that type from the message, into the
Content-Encoding header. I think of the Content-Encoding as describing
a small set of actions that a UA might be expected to perform, while the
Content-Type might involve arbitrary other formatting, display, and
interaction systems. The Content-Encoding is specified mainly for the
purpose of getting a document of Content-Type from the sender UA to the
receiver UA without change.
I also like Vincent's notion of dropping HEXADECIMAL in favor of BASE64
or BASE85. Do we then assume that basically every UA is able to deal
with BASE64 (via free code, etc.)? I believe that this would then
quickly make UUENCODED obsolete.
I also feel that there should be the standard Content-Encoding
"COMPRESSED", for which I do not have a rigorous definition, but which
would mean something like "run through UNIX 'compress' (and then encoded
with BASE64?)". I appreciate the legal tangles with compress, but also
know there's a lot of copies out there. Of course, perhaps a standard
compression routine could also be donated, and made freely available, so
that it is not necessary to use UNIX compress.
Bill