Subject: RE: GISB and EDIINT 2 comparison

From: "Dale Moberg" <[email-masked]>
Date: Tue, 23 Feb 1999 16:53:12 -0500

---------------------- Forwarded by Dale Moberg/Sterling Commerce on 02/23/99
04:51 PM ---------------------------

Dale Moberg
02/23/99 03:51 PM
Ext:

To:   Dick Brooks <[email-masked]>
cc:
Subject:  RE: LAST CALL - I-D ACTION:draft-ietf-ediint-as2-03.txt  (Document
      link not converted)

Dick Brooks <[email-masked]> on 02/23/99 01:29:32 PM
Ext: Unknown
     Hi Dick and Rik,

 Here is an initial comparison  of EDIINT and the list of features Dick
provided.
Corrections and clarifications welcome, but this is just my reaction to start
the process off.

>    - Hundreds of implementations
>    - Supported by multiple industries
>    - privacy via encryption (using PGP with RSA algorithms)
>    - Message integrrity and Non-repudiation (using PGP Digital Signatures)

            EDIINT WG shares PGP and adds S/MIME

>    - Layered approach to existing standards (IETF, W3C and GISB)

         Similar approach in EDIINT: that is, attempt to pinpoint a basis for
interoperability
         within the general approaches of the IETF application level protocols.
"profiling"
         applicability statements.

>    - Based on:
>         - HTTP 1.0 (RFC 1945) (1.1 didn't exist in 96)

                   Should not be an obstacle to a merge

>         - RFC 1341 (the original MIME spec)
>         - All interchanges are passed in Mime multipart/form-data

The multipart/form is not currently used in the data packaging, but since it is
MIME, it
may be able to be merged with minor modifications.  It would be easiest if the
new
media type just dropped in the templates in place of the current
application/edifact etc types.

>           payloads using http POST method ref RFC 1867

         no difference in this yet :-)

>    - Positive acknowledgement using a GISB specified message structure
>      that is HTML based (RFC 1866)

    EDIINT has used the MDN structures: multipart/signed over multipart/report.
Possibly
    using Carl's observation that we can return other data as well, we could put
the GISB
   payload alongside the MDN with a multipart/alternative. Or maybe the MDN
request
   headers in the POST request can be omitted and other GISB headers added.
ate
>    - Authentication of trading partners using username/password (again
>      using RFC 1945)
 There are a lot of authentication methods defined, and I think there is a great
reluctance
to be adding new plaintext password authentication methods. There may be room
for discussion
here. Presumably these "authentication" methods are really functioning as access
control to
prevent arbitary users from posting to URLs and wasting resources, because the
PGP already
supplies better authentication. Maybe there is room for discussion on this. But
generally most password
methods can be added to the AS2 without much problem (even though this is not
mentioned anywhere)

>    - Key exchange procedures (GISB specified)

  There are no real specifications in EDIINT for these--just in the
interoperability tests.

>    - Time Synchronization (using NIST)
    Compatible with EDIINT

>    - Clearly defined Error specifications (GISB specifications)

 The error conditions are defined in the MDN and can be augmented with open text
in the first part of the MDN.
The other error conditions (for the POST for example) are not to be used in
specifying application responses
according a draft from the IETF Application Area directors. This would need to
be worked out carefully.

>    - Supports both batch and interactive processing models

   Protocol is really for automated systems in EDIINT. I am not certain how that
relates to the batch/interactive distinction,
  but there is no standardization of human data-entry forms or the HTML/XML that
would produce them. EDIINT is compatible
  with a lot of different approaches to human forms interfaces.

>    - Proven interoperability
>    - Model Trading Partner Agreements that follow the GISB standard
>    - Well documented
Trying :-)
     - Multiple vendors offering GISB solutions
     - Momentum, Momentum, Momentum...!

>If this group is genuinely interested in finding a path to common ground
>then I am certainly interested in participating.

I hope this helps for a start.