RE: EDI over http?

[Rik Drummond <drummond@xxxxxxxxxx>]

Carl's comments have merit on not using either smtp or http for EDI, just use ssl. Anyone else.

At this time we have three proposals for doing interactive/real-time EDI: 1) smtp, 2) http or 3) ssl.  Any others before we focus. Please make sure you have read the posting by Lincoln a couple weeks ago on the requirements for this area.

Later, Rik

-----Original Message-----
From:	Carl Hage [SMTP:chage@xxxxxxxxx]
Sent:	Monday, June 30, 1997 3:01 AM
To:	ietf-ediint@xxxxxxx
Subject:	RE: EDI over http?



On Fri, 27 Jun 1997, Andras Salamon wrote:

> Basic SMTP does not have sufficiently powerful mechanisms for a two-way
> information flow.  The server-side responses are essentially three-digit
> numeric codes, so it becomes necessary to either send server-generated
> information in the text comments (for instance message identifiers or
> transport acknowledgements), which is nonstandard, or a separate return
> SMTP message needs to be used, which increases the nondeterminacy and
> ordering problems.

SMTP is one way "push" delivery of messages (including replies), not
ideal for two way messaging. Using nonstandard text or a weird new
protocol would be inappropriate.

In the AS1 model, a return message is always used to deliver a signed
reciept. Ordering is outside the scope of the transport.

With AS1, the processing time is not assurred, e.g. it could be hours
or until the next morning before a transaction is processed. If you
compare SMTP overhead to the time I spend waiting for credit card or ATM
transactions (the "quick" pay :-/), it's pretty small.

The advantage of SMTP is universal access. If a TP has no-delay transfer
of incoming messages to the EDI system, transactions happen in real time.
If a TP has a gateway (groan!) it still works (or via VAN gateway). Also
if a TP has an offline account or is down with an ISP backup for
deliveries, it still works.

For truely interactive EDI, even HTTP1.0 isn't good, since there is
basically just a query+response. HTTP1.1 extends this with persistent
connections, but I think adding interactive EDI on top of HTTP is
unnecessary overhead. I don't see that HTTP buys anything, except
eliminates the IP code. But HTTP would add complexity in creating
new processes, parsing CGI interface commands, etc.

A simpler approach for interactive EDI is to dispense completely
with all unneeded protocol layers (no need to kludge EDI into some
existing system). Instead of writing a CGI interface and defining
procedures for mapping transactions into CGI exchanges, just
call SSL libraries to initiate or accept connections directly
between EDI application processes. The protocol would be X12 or
EDIFACT (or whatever), with no overhead. One EDI process could
accept multiple connections (if desired), making the exchanges
very efficient. SSL (extended with a final signature) provides
the needed security and non-repudiation. IP provides the basic
application-application messaging for two way real time transfer.

I guess what I'm saying is that nothing is better than HTTP or SMTP,
meaning "nothing" is plain secure IP.