Re: Compression Draft

From:           	"David Fischer" <[email protected]>

> We are beginning to implement the Compression Draft
> specification:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-compression-00.txt

The use of:

Content-Type: application/pkcs7-mime; smime-type=compressed-data

seems inappropriate.

The application "pkcs-mime" shouldn't be used. PKCS7 is a different
and inconsistent method of doing the same as what MIME does.

It really should be pure MIME, independent of PKCS7.

The original intent in the MIME design was to use Content-Transfer-
Encoding for compression. From RFC2048: "Transfer encodings can 
be used to apply general-purpose non-lossy compression algorithms to 
MIME entities.  "

The intent was for someone to define a new encoding type to include 
compression, e.g. "Content-Transfer-Encoding:gzip" or
"Content-Transfer-Encoding:base64-gzip", which could be equivalent to 
httpd content-encoding, or base64 encoded gzip.

Adding a new content-transfer-encoding would be universally useful
in all MIME messages, and simplify encoding.

Alternatively, a new type, e.g.

"Content-Type: application/mime-gzip" or 
"Content-Type: application/mime-encoded; encoding=gzip"

could be defined to mean an application that decodes, then
processes mime headers. However, it would be better to use:

"Content-Type: encoding/gzip" (already built into Netscape)

Where the media type "encoding" means decode and continue parsing
MIME headers, just like multipart or message.

Shouldn't compression be defined completely independently of 
encryption, signatures, etc.? Then EDIINT can use MIME compression 
with multipart/signed, etc. and other independent MIME standards.
--------------------------------------------------------------------------
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