ietf-822
[Top] [All Lists]

Re: gzip-8bit

2003-03-01 13:28:02

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 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, ...).

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.

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

This would remove any temptation for transport agents to decompress the
body.

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.

AMC

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