RE: Compression Draft

From:           	"David Fischer" <[email protected]>
> Since we are working with HTTP, we cannot use CTE.  Whatever we use
> must be the same for SMTP and HTTP. 

Well, that makes sense to me, but HTTP already has a specification 
for compression, using Content-Encoding, but does not explicitly 
permit Content-Transfer-Encoding.

For email, a "Content-Transfer-Encoding: zlib-base64" (or gzip-base64)
is equivalent to encoding with the equivalent of HTTP
"Content-Encoding: gzip" then encoded with
"Content-Transfer-Encoding: base64".

If you are using HTTP, you can send binary data and compress using 
the existing "Content-Encoding: gzip" specification defined in the HTTP 
RFC. This would be equivalent to a
"Content-Transfer-Encoding:zlib-binary".

If you are using SMTP, we could define "zlib-base64" Content-Transfer-
Encoding. The software would compress (as when using content-
encoding), then base64 encode. There is no need for "zlib-binary" as 
long as compression is done at the top level.

["zlib-base64" is probably a good name since the RFC defining the   
format calls it zlib.]

Though the headers are a little different when used with HTTP or 
SMTP, the software works pretty much the same. It would be easy to 
write a MIME encoder/decoder that would work with either HTTP or 
SMTP, but adjust the MIME headers as needed.

Adding a new content-transfer-encoding format is useful outside the 
scope of EDI and is a simpler extension than the proposed alteration 
encryption/signature MIME types. It's also explicitly mentioned as the 
strategy intended in the MIME RFCs.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email protected]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086