FWIW, I think having a compressing transfer-encoding would be useful,
especially if it's rolled out at the same time as a "widetext" toplevel
type where compression would be particularly useful (especially if we
decide it'd be cleaner to send around pure UCS-4 rather than UTF-16).
Now it's true that deploying such a transfer-encoding for general use in
email is unlikely without something like mailcap.
It's also true that applying compression to already compressed objects
(e.g., mpeg, jpeg, etc) can cause an increase in size. The solution is
not to use compression on such objects.
I think we should consider LZJU90 as a potential alternative to gzip +
base64. LZJU90 is certainly much simpler than gzip, although it also
provides significantly less compression. From what I can tell, both
LZJU90 and gzip are based on LZ77, so the main difference is that gzip
adds huffman coding with optional adaptive tables on top of what LZJU90
does and that gzip is far more widely deployed.
A few specific problems with the current LZJU90 draft:
* LZJU90 <name>
It's a layering violation for a content transfer-encoding to include a
filename. Filenames belong in the Content-Disposition header. The
count makes me a bit uncomfortable. I'm also inclined to say that CRCs
have little value at the applications-level these days. I can't
say that I've ever seen a MIME object damaged in transit unintentially.
If we're going to do any sort of integrity protection, it should be
cryptographic, IMHO. CRCs just don't provide enough functionality for the
code complexity.
EBCDIC. The 64 six-bit strings 000000 through 111111 are represented
by the characters "+", "-", "0" to "9", "A" to "Z", and "a" to "z".
This is the wrong base64 alphabet. Use the same one that MIME uses, or go
for something more compact like base 85 (which makes sense if one is
trying to improve compression).
- Chris