RE: MIME-based Secure EDI -- AS1

David,

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

I don't think of the ebXML work as a continuation of AS1, but rather as an
evolutionary
step forward. When I see the word "continuation" I somehow assume that the
later version
is somehow "backward compatible" with previous works. Maybe that's just me,
but I don't think
I'm alone. ebXML's Message Service and AS1 are not compatible, and in
reality share very little.

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

When I think of something as a "standard" I look for broad, public adoption
and a formal "claim" by a Standards making body claiming ownership of the
"standard". Can you provide references to which Standards Making body claims
AS1 as a standard and/or organizations or industry groups that have publicly
announced AS1 as their "standard" for transporting data reliably and
securely via the Internet.

I refer you to section 2.2 of RFC 2026, "The Internet Standards Process --
Revision 3"), regarding the status of Internet Drafts.

  "Internet-Drafts have no formal status, and are
   subject to change or removal at any time.

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************"


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

I certainly agree with this sentiment. However I suspect this may not change
the perception
of Pae, Kit and others that AS1/AS2/GISB
EDM/ebXML/SOAP-with-Attachments/HTTPR/BizTalk/DIME/et al, are competing
"options", because they provide similar functionality but are not
interoperable.

I think we will continue to see competing options in the Reliable/Secure
Messaging space, because there are "competing entities" creating
specifications and no apparent desire to consolidate efforts, unfortunately.

Technically speaking, I believe GISB EDM is the only "standard" in the
options I listed above. GISB EDM was created by the Gas Industry Standards
Board, an ANSI accredited Standards Development Organization, and it's use
as a secure, reliable Internet Data Transport (B2B) standard, has been
mandated (by law) by the Federal Energy Regulatory Commission and several
state Public Utility Commissions.


Dick Brooks
Co-author GISB EDM
Co-author EDIINT AS2
Co-author ebXML Message Service Version 1.0


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of David Fischer
Sent: Friday, December 21, 2001 8:22 AM
To: Pae Choi; Gary Crough; [email protected]
Cc: Ned Freed; Rik Drummond
Subject: 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.
>