RE: Need help on AS2

Dale,

Sorry for the long delayed response, I've been traveling.

For the past several weeks I've been talking with people about the
similarities and differences between EDIINT AS1, AS2, SOAP, ebXML, GISB EDM
and W3C XP. I'm convinced that this forest of "B2B standards" and all the
vendor marketing hype is creating  confusion and concern.  There is
significant overlap in functionality between these different standards, and
more importantly, they are NOT interoperable. The "lack of consensus" within
the vendor and standards making communities is causing concern within the
business community.

In 1996 the Energy industry created a INDUSTRY NEUTRAL Internet B2B standard
to enable the secure, reliable exchange of data over the Internet to meet
their needs. The Energy industry B2B standard has been used for mission
critical B2B since April of 1997. Companies in other industries, Healthcare
in particular, also use the Energy Industry B2B standard for exchanging
data. The Energy industry B2B standard, along with AIAG E-5, formed the
basis of the GENERALIZED RECEIPTS portion of the EDIINT AS2 specification.
Approximately 20 vendors implement the Energy industry B2B standard;
Sterling Commerce, BTrade, IPNet and Group 8760 from the AS2 community also
implement the Energy Industry B2B standard.

You claim that I'm being misleading with some of my comments on this list. I
believe I've been completely above board in my assertions. But, how about
the vendors who have been issuing press releases claiming to be "AS2
compliant", some are even claiming they are AS2 "certified", because they
participated in a "clean room" interoperability test. Their software
implements functionality that DOESN'T exist in the current AS2 spec. Do you
consider their claims of AS2 compliance/certification misleading?

I think it's time the AS2 community stops the "war of words" and starts
pursuing true convergence. Software vendors, end users and industry
standards bodies must come together to define a single interoperable AS2
standard that everyone could rally around/support.


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
[email protected]
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Moberg, Dale
> Sent: Wednesday, January 10, 2001 10:57 AM
> To: '[email protected]'; Santanu De
> Cc: [email protected]
> Subject: RE: Need help on AS2
>
>
> Comments in-line.
>
> > -----Original Message-----
> > From: Dick Brooks [mailto:[email protected]]
> > Sent: Wednesday, January 10, 2001 11:25 AM
> > To: Moberg, Dale; Santanu De
> > Cc: [email protected]
> > Subject: RE: Need help on AS2
> >
> >
> > Dale,
> >
> > > Sorry, Dick, but I think this remark is misleading.
> > >
> > > The so-called "email" packaging makes use of IETF standards
> > > for MIME, the security multiparts, and the specifications
> > > for Open-PGP and SMIME. It is as much
> > > based on standards as is the packaging that makes
> > > use of "multipart/form-data."
> >
> > My comment about the email packaging of AS2 being
> > non-standard refers to the
> > fact that
> > neither RFC 822 nor RFC 2045 nor RFC 2616 define the AS2-to
> > or AS2-From
> > headers. In fact, these don't exist in the current AS2 draft (ref:
> > http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.t
> xt) nor any
> previous draft of AS2. I know AS2 will be enhanced to support AS2-To and
> AS2-From, but as of right now, these headers aren't defined in any RFC or
> Internet Draft. Is this factual?
>
>
> That detail is not a significant basis for saying that
> the _packaging_ is nonstandard. As you well know, HTTP
> allows headers to be added without the X- qualifier.
> And if we use AS2-To and AS2-From in the final draft,
> we can ask IANA to register these, in my opinion.
>
> Some on the list have proposed using different header field
> names from AS2-to and AS2-From.
>
> We should continue to discuss what field to use  on this
> list if there are reasons for one way of proceeding rather
> than another. And we should discuss these final issues
> at an IETF meeting to see if we can determine the consensus.
>
>
> >I also wanted to point out that the email packaging specification within
> AS2
> >doesn't follow MIME (RFC 2045) or RFC 822 (which defines the standard
> syntax
> >for e-mail messages) specifications for extension headers. According to
> >these specs extension headers are supposed to contain an "X-" prefix,
> >reference this excerpt from section 4.1 (Message Specification/Syntax) of
> >RFC 822:
>
>
> In the same spirit, HTTP doesn't follow every rule of RFC 2045 or
> RFC 822. That is one very good reason to stop calling AS2 "email"
> packaging. (As you will remember me saying more than once before ;-).
> That is one very specific way in which you are being misleading.
>
> We are instead following MIME as used in HTTP which,
> as we are at pains to point out in the AS2 spec, differs in some
> details from the way it is used in the SMTP context.
> Because these differences do not make HTTP RFCs 2068 or 2616
> nonstandard, I think it is misleading to say that the use of
> MIME in AS2 is nonstandard. Rather the usage of MIME that we recommend
> follows how MIME is used in accordance with the standards in 2068
> and 2616, and that makes it standard. We are, after all, describing
> "HTTP Transport for Secure EDI." and that is why we adhere
> to RFC 2068/2616 on those points where HTTP MIME differs from
> 2045... It might have been simpler if the HTTP and SMTP MIME
> were identical (and they are very similar) but that is not
> the case. So as a group chartered to find an applicability
> statement of existing standards, we have followed the existing
> standards even when those standards diverge slightly. (It
> is, after all, to be expected that a binary clean transport
> might need to say slightly different things about packaging
> than one whose default is 7 bit...)
>
>
>
>