Re: !!!! EDIINT AS#2 - Requirement Voting

[carl@xxxxxxxxx (Carl Hage)]

N/A: 1.0
N/A: 2.0
Required: 2.3
Ambiguous: 2.5
N/A: 3.0
Required(N/A): 4.0
Nice: 5.0
Nice: 6.0

Rik Drummond (drummond@onramp.net) wrote:
: 1.0 General Requirement
: 1.1 An open, interoperable, point-to-point protocol that allows
:  applications to exchange standard EDI data or proprietary data in the
:  following ways:simple sending,simple receiving, real-time, conversational,
:  interactive, and query.

This is what TCP/IP is all about, and inherent in the lower levels of
the protocol layering. I said N/A because this is given with real time
communications, and the protocols are already defined. IPng offers some
new features that are of interest, but aren't available yet.

: 2.0 Data Content
:  2.1 No limitations

TCP/IP makes no limitations on the data exchanged.

:  2.3 Traditional Batch EDI

Of course there are existing Batch EDI users that would like to be
able to use the point-to-point messaging capabilities of the Internet,
and need to know how Batch EDI interchanges need to be exchanged.
Thus, I believe AS#2 really only applies to 2.3.

I believe HL7 already has defined layering of using TCP/IP, so AS#2
wouldn't be applicable to HL7 EDI.

:  2.5 Standardization of Web-forms (cgi) to EDI Format

This could mean many different things. A more precise definition is
needed.

: 3.0 Connectivity

All these are inherent in TCP/IP, except 3.5.

:  3.5 Private Virtual network

This would be a layer on top of TCP/IP, but operates more or less
transparently to the applications. In other words, the PVN is a feature
of the socket (TCP/IP) connections.

: 4.0 Security services
:  4.1 Ability to implement session logging with signatures
:  4.2 Documents/services based on ID
[This is ambiguous]
:  4.3 Confidentiality
:  4.4 Signatures for authentication and non-repudiation
:  4.5 Encryption for privacy
:  4.6 Transaction level and server-to-server level security and signature
:  4.7 Assured delivery

There are a couple of aspects of security services. One is the confidentiality
and assured delivery to authenticated recipients. Another is the logging
to facilitate non-repudiation and auditing. PVNs and SSL more or less
transparently provide the former. However, SSL does not directly provide
logging services.

An AS#2 that defines security services with logging and non-repudiation,
would be useful for EDI and other application independent communications.

: 5.0 Basic functions
:  5.1 Send and receive data objects

The real issue here is the definition of "data object". Is there a need to
define "objects" in a general manner with a protocol layer? There are a
number of efforts underway to define these layers. Some might be useful
for EDI, or new-edi.

However, for the purposes of moving traditional EDI into the realm of
modern internet communications, a simpler objectless (i.e. implied
objects) model within the communuication "stream" is appropriate for
now. Note, TCP/IP provides a "stream" of data bytes as the model.

What is needed for EDI is a definition of the correspondence between
X12/EDIFACT interchanges and the data streams, i.e. how interchanges
map to socket streams. For example, one of the following:

  1) Sender connects, transmits interchange, disconnects
  
  2) Sender connects, transmits interchange, receiver replies with FA,
     receiver disconnects.

  3) Sender connects, transmits interchange, receiver replies with
     FA, FA+ACK transaction, or disconnects, sender replies
     to ACK with FA, sender disconnects.

: 6.0 Acknowledgments and tracking

This is pretty tightly linked to 4.0 Security services, i.e. logging==tracking.
There is a much more sophisticated form of tracking, where a protocol
is defined so a TP's remote logs can be queried, but that seems more
advanced than needed at this point.

:  6.1 Supports immediate response acknowledgment
:  6.2 Possible to record and audit individual activities
:  6.3 Negotiated possibility to send to server at startup
:  6.4 Feedback from the initial message in the form of another
:  6.5 Establish unique dialogue identifiers

Some of these might mean what I descibed above in "data object" modelling,
I don't really understand these definitions.
--------------------------------------------------------------------------
What I think needs to be in AS#2 is:
  - A selection of the lower level protocol used to send X12/EDIFACT
    streams to a TP, which includes security services.
  - A definition of the connect/disconnect, and EDI Functional ACK
    protocol.  (Note that SSL has message ACK/Signature features built-in
    to the low-level protocol.)
  - A definition of the logging/tracking requirements for interchanges to
    support needed non-repudiation and auditing features.

There are some ways to use HTTP, particularly for 1-many messages of RFQs,
product catalogs. However, I would put this in AS#3.
--------------------------------------------------------------------------
What I suggest be in AS#2 is:

- Define "sedi://domain" as a URL for secure EDI messaging. The interchange
  headers distinguish between X12/EDIFACT/etc protocols.
 
- Reserve a socket port for sedi. (SMTP, FTP, HTTP, etc. all have
  assigned port numbers as a default.)

- Define SSL as the protocol to be used for security/acknowledgement.
  SSL provides 4.2?, 4.3, 4.4, 4.5, 4.7. Transaction signatures depended
  on whether a session matches a transaction. Logging is possible, though
  not defined by the SSL spec.

- Define what parts of the SSL security exchange should be logged to
  implement the tracking aspects of 6.0. The IDs, signatures, etc.
  are inherently part of SSL.

[Note: The basic requirements for SSL are pretty close to these AS#2
requirements, given no content restrictions. Also, SSL defines a
means to trivially extend existing protocols like SMTP, FTP, HTTP, Telnet.
In other words, much of AS#2 is already being done within the auspices
of SSL.]

- Define the X12/EDIFACT level functional acknowlegment protocol, e.g.
  1. Sender establishes a connection
  2. Sender transmits an X12/EDIFACT interchange
  3. Recipient reads the message, and after reading the end of interchange,
     processes (parses) the interchange.
  4. Recipient transmits an X12/EDIFACT interchange containing a 997 (for
     X12) FA, and optionally other transactions such as a PO ACK.
  5. If the Recipient's interchange includes a transaction other than
     a FA, then the sender must reply to that interchange with an FA.
     The role of Sender and recipient reverses, and the sender proceeeds
     as a recipient in step 4.
  6. If the interchange from the Recipient only contains an FA, and
     the Sender has additional interchanges to transmit, proceed to
     step 2.
  7. If the interchange from the Recipient only contains an FA and
     no additional interchanges are to be sent, the Sender disconnects.

This protocol simplifies somewhat if the connection is restricted to
interchange+FA. However, the more elaborate interchange protocol allows
a conversational exchange within a single connection, e.g.

RFQ->FA+RFQ_Resp->FA+PO->FA+PO_ACK+INV+ASN->FA+Payment_Order->FA->disconnect

It seems like it would be convienient to hold open the connection,
particularly since public key encryption and signature processing is
relatively expensive, computationally. If transaction processing is
fast (OK a pipe dream from a C programmer who knows it's possible),
then a whole sequence like this could occur within a few seconds.

The SSL signatures, I belive, would be over the complete transaction
sequence, e.g
 {RFQ,FA+PO,FA+Payment_Order} or {FA+RFQ_Resp,FA+PO_ACK+INV+ASN,FA}

Thus these transactions would need to be logged as a set.
--------------------------------------------------------------------------
The way I see this implemented, is that there would be a C program
EDI deamon that always runs and listens for connections on the sedi
TCP port. The daemon would invoke the SSL libraries to process
decryption/encryption and signatures, and match certificates with
the TP ID in the EDI interchange header. Also, this deamon would
log the decrypted data containing the interchanges, signatures,
and session IDs/keys.

After receiving an interchange, the deamon would copy the interchange
to a file to be read by an EDI translator, or pipe the message to the
translator. The translator would create a 997 to be returned by the
deamon, or else the deamon would generate a 997 after successfull processing.
A more integrated system would reply with a response packaged with the
997, while a simpler deamon would rely on a separate connection to
transmit reply interchanges.

A client program similar to the daemon would initiate a connection for
an outgoing EDI interchange. Unreachable hosts would require queuing.

The EDI deamon would log errors and send alerts to sysadmins, e.g. via
email. Depending on the EDI translator, out of order transactions
may need to be held.

With an SSL library as a base, these programs are pretty simple. (E.g.
simpler than a CGI program.) In fact, these could be integrated within
an EDI translator and/or transaction processing system rather than
operated as independent processes.

Note that this provides much the same functionality as SMTP based
messaging, but is more light-weight and can be more easily integrated
tightly with EDI translators.

Unlike SMTP, it's extensible to new-edi where conversational interchanges
are needed. When used for non X12/EDIFACT applications like new-edi,
where the "interchange" and "FA" are not predefined data objects, the
AS#2 is essentially nothing more that SSL with some data logging added.
--------------------------------------------------------------------------
The AS#2 could be used to define a protocol where part-time (dynamic)
internet connected TPs contact a dedicated service TP, where a queue
can be downloaded. However, I believe a better procedure would be to
use AS#1 with POP3 or IMAP.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086