ietf-822
[Top] [All Lists]

Re: gzip-8bit

2003-03-01 13:53:07


ned+ietf-822(_at_)mrochek(_dot_)com wrote:

We've been over this many times before.  Compression cannot be a
separate attribute because current agents assume that once the CTE
is removed they have the data identified by the content-type in hand
and no further processing is required.  Adding compression as, say, a
different header is therefore something that is guaranteed to cause
massive breakage.  Whereas adding compression through a new CTE is
something that should not cause problems with standards compliant
agents.

Except for the 1000:1 expansion risk that could bring down transport
agents that aren't sufficiently paranoid when altering the
transfer-encoding.

And the solution is to call this out as a security consideration so transport
agents can be made to be sufficiently paranoid.

And it's a bit gross to have to define N*M transfer
encodings to support N escape mechanisms (quoted-printable, base64,
escaped-8bit) and M compression schemes (gzip, deflate, bzip2, ...).

Gross perhaps, but hardly necessary.

Here's a way to separate the compression from the escaping in a
backward-compatible way.  I don't claim that this is the best way, but
it's something to consider.

Sorry, it isn't worth considering. This just breaks a different rule, that of
media types actually describing the associated content. There is a vast amount
of infrastructure that depends on this being the case. (This is why the use of
content-disposition filenames is seen by many of as such an egregious offense.)

BTW, this particular rule is written down. See RFC 2048 section 2.2.1. It
really could not be clearer.

Another approach would be to introduce structure into the
transfer-encoding, and recommend that transport agents ignore all but
the last component:

Content-Type: application/postscript
Content-Disposition: attachment; filename="foo.ps"
Content-Transfer-Encoding: gzip|escaped-8bit

Note that the semantics of these two approaches are different, as
reflected in the suggested filename.

At the time MIME was defined I argued for such a structure. If memory serves
I was pretty much a lone voice in this; the opposition to it was overwhelming.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>