RE: Compression Draft

Ned,

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

I wish to express the importance of EDIINT AS2 by pointing out that the Gas
Industry Standards Board, an ANSI SDO, (now the North American Energy
Standards Board),ref: http://www.naesb.org/, references EDIINT AS2 in it's
Internet E-Commerce standard. The Federal Energy Regulatory Commission
(http://www.ferc.gov) within the Department of Energy
(http://www.energy.gov/) has mandated NAESB's Internet E-Commerce/AS2
standard into law and all Interstate Gas pipelines are required to use the
NAESB/AS2 standard for Internet E-Commerce.

Note: The NAESB E-Commerce standard references the portion of AS2 that
complies with RFC 2616, RFC 2617, RFC 2388 for framing and RFC 1847/2015 for
MIME identification of PGP payloads. PGP performs all compression functions
within the NAESB portion of EDIINT AS2 and is therefore not dependent on
CTE's to identify compressed content.

Please do not associate the "compression issue" with all of EDIINT AS2. I
believe the issues raised with compressed content are germane to the UCC
portion of EDIINT AS2 and do not impact the Energy Industry/NAESB "profile"
within the specification. Please contact me (co-chair of NAESB's Internet
E-Commerce standard committee) to discuss the Energy Industry portion of
EDIINT AS2. I want to ensure that the Energy Industry E-Commerce
specifications are aligned with the principles and processes defined by the
Internet Engineering Task Force.


Thank you,

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of
[email protected]
Sent: Friday, March 22, 2002 9:45 PM
To: Terry Harding
Cc: Carl Hage; [email protected]
Subject: 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