Re: gzip/deflate compression/encoding

On Mon June 27 2005 10:58, [email protected] wrote:

> (1) Put some sort of "escape" label in the CTE field saying that
>     content-compression needs to be looked at.
> (2) Bump the MIME-Version value to 2.0.

Changing C-T-E semantics itself would probably warrant changing the
version.

I'm not convinced that 2.0 is the next step (as opposed to 1.1 for
example).

> is fundamental: An existing, standards-compliant client seees this and thinks
> all it has to do is undo the base64 encoding and a bunch of text will pop out.
> But when it actually does this aa pile of binary goo appears instead. The
> resulting mess won't make users very happy even if clients handle it well, and
> the odds are good they won't.

True.
 
> Now, many folks believe bumping the MIME version is not possible. I'm
> personally not convinced of that, but I do think it would be hugely difficult.
> Bumping it just to get a compression field added strikes me as way too
> much trouble for way too little gain, so (2), while technically possible,
> is a practical nonstarter IMO.

Another change-C-T-E method (again, probably warranting a version change)
would be to change the syntax to permit a list of keywords, so e.g. one
could have
 Content-Transfer-Encoding: 7bit
 Content-Transfer-Encoding: deflate
 Content-Transfer-Encoding: deflate, base64
etc.
 
> Embedding compression information in the CTE is, OTOH, entirely doable. And
> not only was this understood back when MIME was first standardized, the
> reason we didn't define content-compression or something similar is exactly
> because this possibility existed and there was no real need for
> content-compression.
> 
> Of course this leaves open exactly what compression/encoding pairs
> need to be defined for use as CTEs. As you say, there are potentially
> five of them, but I only see three that are genuinely useful:
> 
>    binary-8bit
>    deflate-8bit
>    deflate-base64
>    deflate-binary
> 
> Of these I see little value in the last, but the others all make good sense.

Compression alone may be useful for transmitting large, sparse binary
files efficiently (e.g. files containing long runs of NUL octets).  Of
course, that requires binary transport (e.g. ftp via message/external-body
or SMTP BINARYMIME).
 
> However, I'm still not seeing the sort of community interest that's really
> needed to get this off the ground. (In fact I'm see pretty much the opposite.)

There are disadvantages to all of the approaches.  For adding encodings,
the primary disadvantage is:
o add 3 encodings per compression scheme (suppose somebody comes up with
  a scheme better than deflate)

The alternative ideas address that issue.  Push here, something else
pops out there.

A binary-to-8bit encoding scheme would work with SMTP 8BITMIME where
available even if BINARYMIME is not supported, and with other protocols
(IMAP, NNTP) which support 8bit but not binary content transfer.  That
may have some use independent of the compression issue, so maybe that
could be standardized now, deferring the compression issue until there
is interest in it.