RE: Compression Draft

This was our first thought too but this method was rejected by the Area
Director.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Greg Vesper
Sent: Monday, March 11, 2002 10:45 AM
To: Carl Hage; [email protected]
Subject: RE: Compression Draft



Well said - I agree entirely with Carl's assessment.  Binding compression at
the crypto layer is inherently more restrictive and less interoperable than
compressing at the MIME layer.

Cheers,
-Greg.

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Carl Hage
> Sent: Friday, March 08, 2002 4:18 PM
> To: [email protected]
> Subject: 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