Re: Compression Draft

Carl, Ned,

Our goal in developing a compression method for AS1 and AS2 was to find
something that already existed and could be used for SMTP and HTTP(s) and
any future transport protocols defined by the EDIINT group.

For HTTP we looked at using Content-Encoding, but since this only applied to
the outermost layer of a message, we would not be able to take advantage of
the benefits of compressing the mime layers inside the message and any
compression applied on the outermost layer would not have any effect
compressing a binary blob of encrypted data.  I also looked at using
Content-Encoding within the inner mime layers, but was informed by Ned that
utilizing Content-Encoding within MIME was not acceptable.  We also
looked at utlizing CTE in the inner most layers, but also received
objections from the AS2 authors that CTE anywhere within the message was not
encouraged. Also the MIME group did not have a CTE defined for compression
and we would have to develop a brand new CTE acceptable to EDIINT players
and the MIME guardians. We also looked at the compression spec from the
S/MIME group, as this is the security mechanism utlized by AS1 and AS2.
Note: the S/MIME group had already developed a compression spec.

For SMTP we looked at using Content-Encoding, but again we were discouraged
from this approach. It was suggested that we use CTE with new encodings
defined for compression.  We also looked at compression developed by the
S/MIME group.

So it came down to utilizing a compression method already defined by a
working group  and having it approved by the EDIINT forks or developing a
new mechanism and having it approved by two working groups. The EDIINT group
on the most part trys to utilize existing methods and explain their usage in
our applicability statements.

So the reasons above led us to utilize the compression method developed by
the S/MIME group. The original EDIINT compression was first released in
September of 2001 to the ediint ietf group for comments and suggestions.  At
that time we were looking for discussion on the selected method.  We
received some suggestions and comments, but nothing close to the remark from
Carl, indicating that the compression method selected was "OVERKILL".

Note: Currently 7 AS1 vendors have implemented the selected compression
method and 5 additional
vendors will be adding compression for AS2..

Terry Harding
Cyclone Commerce











----- Original Message -----
From: "Carl Hage" <[email protected]>
To: <[email protected]>
Sent: Thursday, March 21, 2002 8:55 PM
Subject: 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