[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIME-based Secure EDI -- AS1
As an outside observer with a primary interest in the work of the
Automotive Industry Action Group (AIAG) and their messaging guideline
(E-5) I can tell you that these "duplicated efforts" go far beyond
EDIINT and ebXML. To put it in perspective, you must look at the
timelines involved in these projects. I checked my archives and the
oldest rev of AS1 I could find was 9 and it had a date of December 1998.
I'm not sure of the exact dates for AS1 but I do know that the AIAG and
the Gas Industry (GISB) have been working on this stuff since 1996. I
assume AS1 dates back that far as well. In the past there have been
differences in opinion on messaging methodologies. AS1 was originally
email (SMTP) based, GISB was HTTP/MIME with PGP, AIAG was HTTP/MIME
without PGP, etc... We all had (and still do in some cases) different
ideas about security, authentication, protocols and what constitutes
reliable messaging. We've all been through multiple revisions of our
work to improve on our original assumptions. Each of the existing
methodologies has its merits and a formidable installed base. New
efforts like ebXML continue to pop up (I assure you that its not the
last) ensuring that duplicate work will (unfortunately) continue for
some time. I forget who said it first, but "the greatest thing about
standards is that there are so many to choose from..."
From: Pae Choi [mailto:paechoi@xxxxxxxxxxxxx]
Sent: Friday, December 21, 2001 4:47 AM
To: Gary Crough; David Fischer; ietf-ediint@xxxxxxx
Cc: Ned Freed; Rik Drummond
Subject: Re: MIME-based Secure EDI -- AS1
My appologies to stepping into you folks' conversation. Jut FYI,
there is no
The latest one I can find is "...-14.txt".
Also, would someone or some people share some visions and relationships
between EDIINT and ebXML standard specification, ebMS, which is also
covering the MIME part as SOAP Attachment.
In addition to some similarity, the OASIS consortium just announced a
that is saying about the XML and the related security as well as others.
It seems to me we have duplicated efforts going on. I am here to express
which is better to what nor lobbing for something. I am just trying to
understand and minimize our duplicated efforts.
Again, my appolgies for this foray.
 ebXML Specification "Message Service Specification";
 W3C Note "SOAP Messages with Attachments";
 OASIS News " XML Standards Converge at OASIS";
----- Original Message -----
From: "Gary Crough" <gcrough@xxxxxxxxxxxxxxxxxxx>
To: "David Fischer" <david@xxxxxxxxxxxxxxxxx>; <ietf-ediint@xxxxxxx>
Cc: "Ned Freed" <ned.freed@xxxxxxxxxxx>; "Rik Drummond"
Sent: Thursday, December 20, 2001 1:56 PM
Subject: RE: MIME-based Secure EDI -- AS1
> As you indicate EDIINT AS1 is not used for all EDI transported
> over the Internet ... but just as important not all data being
> transported via EDIINT AS1 is EDI data. Here is my 2 cents...
> I believe the UCC asked for XML data to be used in the testing
> of EDIINT AS2 to insure there was no marriage to X12 etc. If neither
> AS1 nor AS2 is married to EDI data, ideally the title of the
> specification would not make such an inference. In its broadest
> EDI means "Electronic Data Interchange" which is fine ... but in
> usage EDI has come to be closely associated with X12 and readers
> something called "EDIINT" cannot handle other data structures such as
> EDIINT AS1 and EDIINT AS2 are both "Secure Peer-to-Peer Business
> Quality Data Transports". Right?
> -----Original Message-----
> From: David Fischer [mailto:david@xxxxxxxxxxxxxxxxx]
> Sent: Thursday, December 20, 2001 1:28 PM
> To: ietf-ediint@xxxxxxx
> Cc: Ned Freed; Rik Drummond
> Subject: MIME-based Secure EDI -- AS1
> After reading the comments from the Last Call on AS1, it seems there
> 1) The name might suggest that all EDI on the Internet would be done
> this way.
> Solution: Add the words Peer-to-Peer in the title.
> 2) There is some dissent to the way in which security is applied in
> this spec.
> Solution: Changing the security methods in AS1 would not align with
> original functional specification of this group. Support for VANs was
> not part
> of the functional spec. No change.
> A new Draft IETF specification will be issued today with the change in
> title as
> in (1) above.
> Best Regards,
> David Fischer
> Drummond Group.