Tony Hansen <tony(_at_)att(_dot_)com> writes:
Keith, I usually agree with you, but not in this case. This suggested
content-type DOES describe the content type: it IS a zip-compressed file
that's enclosed there. It just happens that you also know what was
compressed.
But no one cares that it's ZIP-compressed except the mail system (in the
broader sense that incorporates the automatic actions of the user's MUA).
The user certainly doesn't unless they're an expert.
Users, and by this I mean average mail users, not sophisticated e-mail
experts like the people on this mailing list, expect compression to be a
transparent process (if they're even aware that it exists and is
possible). Having to deal with compression confuses them, and web
browsers just automatically decompress things because of this. That's
what they're used to, and that view of things makes sense. It shouldn't
*matter* that something is compressed. We compress files to reduce the
transit time, not because it's somehow important that a particular file be
compressed.
In order to have end-to-end transparency of compression, where you can do
compression or not do compression as fits the particular situation and
have the content handled the same regardless, I think Keith and Ned are
right and you *have* to mark the real content in the Content-Type header.
Content is dispatched to applications on the basis of the Content-Type.
With the sort of Content-Type that's been proposed here, the application
is going to uncompress the message, pull the *correct* content type out of
the parameter, and then act as if that was the Content-Type anyway for the
purpose of dispatch, which argues that one is shoehorning things into the
wrong model. Any protocol is described with a step that goes something
like "now pretend that this header field *actually* said..." is, IMO,
probably misdesigned.
Compression is fundamentally a transport issue, not an application issue,
and as such should be added or removed as part of the transport layer, not
as part of the application dispatch layer. The Content-Transfer-Encoding
vs. Content-Type distinction already encapsulates that, and shouldn't be
abandoned.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>