ietf-822
[Top] [All Lists]

Re: Content-Transfer-Encoding and yEnc

2002-04-09 19:19:27

Quoteing rra(_at_)stanford(_dot_)edu, on Tue, Apr 09, 2002 at 06:01:47PM -0700:
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

They do? It must be really transparent then, because I myself keep
downoading zipped .pdfs and gzipped postscript, and either I save
it to a file (on Linux) and deal with it myself, or IE opens the
file with WinZIP, and then I double-click it in WinZIP, which opens
acrobat, for example. Pretty much exactly what I do with email, and
its annoying in both cases.

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.

I agree it should be transparent. An "encapsulates" parameter to
content-type would allow this, and downgrade gracefully, TO THE CURRENT
SITUATION, as far as I can tell.

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.

You could look at it like that. Or you could say people take things mpegs,
and tar them up. Then they take the tar file, and they gzip it. Then it gets
base64 encoded by the mail agent. The content-type should reflect the real
nature of the content, and allow it to be generated and manipulated
automatically, by tools that wish to. It looks to me like the kind of
recursion you get with nested multiparts.

The content-transfer-encoding/content-type pair is just 2 deep. It doesn't
look like it can represent this.

Anyhow, a few people seem to think this is the wrong way, but only one
person has suggested a CTE that would do compression, and that idea was
shot down as being hopelessly complicated (the b64+zip-... approach).

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.

I agree CTE seems a great place to put transport-layer compression. But...
you can't do it without apps that don't understand the new CTEs (all of them,
right now) not decoding the content, and in addition they will treat it
as application/octet-stream.

Isn't that what will happen? It just seems to me there is no migration
path. Am I missing something?

The one thing may folks seem to agee on is that there is a problem,
so if having the content-type describe how content of one type was
used to wrap content of another isn't right, what would the CTEs look
like? What's the other approach?

Sam

-- 
Sam Roberts <sroberts(_at_)uniserve(_dot_)com> (Vivez sans temps mort!)