RE: Compression Draft

[ned.freed@xxxxxxxxxxx]

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

I'm sorry, but this is flatly wrong. I never rejected the notion of adding
compression at the MIME layer. What I rejected was doing it with a separate
field nobody has ever seen before and no existing agent will know to look for.
Nor is it acceptable for this to be done by using a content-type based
wrapper.

As I pointed out before, the addition of compression to MIME is done by adding
one or more content transfer encodings. The process for defining a new CTE is
laid out in RFC 2048. The process is intentionally a stringent one, but is
isn't impossible.

Adding, say, zlib-base64 or even zlib-base85 would be easy. Adding something
like zlib-binary or zlib-8bit is harder, but still doable.

				Ned


> -----Original Message-----
> From: owner-ietf-ediint@xxxxxxxxxxxx
> [mailto:owner-ietf-ediint@xxxxxxxxxxxx]On Behalf Of Greg Vesper
> Sent: Monday, March 11, 2002 10:45 AM
> To: Carl Hage; ietf-ediint@xxxxxxx
> 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: owner-ietf-ediint@xxxxxxxxxxxx
> > [mailto:owner-ietf-ediint@xxxxxxxxxxxx]On Behalf Of Carl Hage
> > Sent: Friday, March 08, 2002 4:18 PM
> > To: ietf-ediint@xxxxxxx
> > Subject: Re: Compression Draft
> >
> >
> >
> > From:           	"David Fischer" <david@xxxxxxxxxxxxxxxxx>
> >
> > > 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:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> > <http://www.chage.com/chage/>                          Sunnyvale,
> > CA 94086