RE: MIME-based Secure EDI -- AS1

Yes, the latest version is -14.txt.  I sent version 15 to the administrators
yesterday but I received a reply indicating it will not be posted until after
the new year.  The only change is to the title and the dates.

Many of us are also involved in the ebXML effort.  I am the editor of the
ebXML-Messaging team.  The apparent duplication of effort is actual not a
duplication at all but a continuation.  The AS1 standard has been in work for
several years but it is only now, after there are several vendors with products
on the market and an imbedded base of users, that this method is actually
becoming a "standard".  In this case, the paperwork is just now catching up with
the industry.

In ebXML, the effort is still on paper without implementations.  Some vendors
are in the process of coding, including some of the vendors on this list.
Instead of being a duplicate effort, one might suggest that the ebXML effort
"grew out of" the AS1/AS2 effort (and other efforts such as RosettaNet).  Many
of the contributors to all these specifications are the same.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Pae Choi
Sent: Friday, December 21, 2001 3:47 AM
To: Gary Crough; David Fischer; [email protected]
Cc: Ned Freed; Rik Drummond
Subject: Re: MIME-based Secure EDI -- AS1



Hello,

My appologies to stepping into you folks' conversation. Jut FYI,
there is no
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-15.txt.
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[1], which is also
covering the MIME part as SOAP Attachment[2].

In addition to some similarity, the OASIS consortium just announced a news
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.

Best regards,


Pae


[1] ebXML Specification "Message Service Specification";
     http://www.ebxml.org/specs/index.htm
[2] W3C Note "SOAP Messages with Attachments";
     http://www.w3.org/TR/SOAP-attachments
[3] OASIS News " XML Standards Converge at OASIS";
     http://www.oasis-open.org/news/oasis_news_12_19_01.shtml


----- Original Message -----
From: "Gary Crough" <[email protected]>
To: "David Fischer" <[email protected]>; <[email protected]>
Cc: "Ned Freed" <[email protected]>; "Rik Drummond"
<[email protected]>
Sent: Thursday, December 20, 2001 1:56 PM
Subject: RE: MIME-based Secure EDI -- AS1


>
> David,
> 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 sense
> EDI means "Electronic Data Interchange" which is fine ... but in common
> usage EDI has come to be closely associated with X12 and readers assume
> something called "EDIINT" cannot handle other data structures such as
> XML.
> EDIINT AS1 and EDIINT AS2 are both "Secure Peer-to-Peer Business
> Quality Data Transports".  Right?
>
> -----Original Message-----
> From: David Fischer [mailto:[email protected]]
> Sent: Thursday, December 20, 2001 1:28 PM
> To: [email protected]
> Cc: Ned Freed; Rik Drummond
> Subject: MIME-based Secure EDI -- AS1
>
>
>
>
> After reading the comments from the Last Call on AS1, it seems there are
> two
> concerns:
>
> 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 the
> 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.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-15.txt
>
> Best Regards,
>
> David Fischer
> Drummond Group.
>