RE: EDI over http?

[Peter Rawlinson <PeterR@xxxxxxxxxxxxx>]

Rik
I think the use of IP connection could run into some difficulties.  I
can't immediately see the benefit in using a new port, when HTTP is a
well established medium for 'dropping off' information over 80.  Company
firewall policy will be far more 'agreeable' over the established port
80, rather than a 'proprietary' standard which adopts IP connection over
another designated port.  Additional testing would have to be conducted
to confirm prevention of malicious acts using this port.

By the way, have you heard of the IETF doing any work with the Templar
solution for Real Time EDI?  Maybe we could levergae some information
from this.

Pete
>-----Original Message-----
>From:	Rik Drummond [SMTP:drummond@xxxxxxxxxx]
>Sent:	Wednesday, July 02, 1997 10:58 AM
>To:	'Carl Hage'; ietf-ediint@xxxxxxx
>Subject:	RE: EDI over http?
>
>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.
>
>