Re: Compression Draft

> 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.

I note in passing that it is extremely unlikely that EDIINT is going to be
around to develop such bindings.

> 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.

Then the AS2 authors are in need a reality check. CTEs within messages are not
only encouraged, they are essential. And here is nothing, repeat NOTHING, they
can do about this.

Like it or not, HTTP elected to go one way on this and SMTP elected to
go another. Both approaches have advantages and disadvantages, as you note.
But you cannot change them and you cannot make them compatible. And more to
the point, you cannot get rid of the use of CTEs in SMTP.

> 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.

Which offers a third set of tradeoffs.

> For SMTP we looked at using Content-Encoding, but again we were discouraged
> from this approach.

Actually, you were told it is flatly unacceptable on technical grounds, and
why. There's nothing capricious or arbitrary going on here.

> 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.

And if the WG choses S/MIME compression that's fine. The only reason I jumped
in s the situation in regards to defining new compression services in SMTP had
been, and continues to be, mischaracterized.

				Ned