RE: EDI over http?

[Rik Drummond <drummond@xxxxxxxxxx>]

Good points....Ya know,  this establishes the secure process to process connection, but does not establish the protocol for the exchange of the data objects. Would we not have to establish a new protocol or use something like smtp, esmtp, http, or ftp inside of these?

later, Rik

-----Original Message-----
From:	Dave Darnell [SMTP:dave_d@xxxxxxxxxxxxx]
Sent:	Wednesday, July 02, 1997 12:04 PM
To:	Rik Drummond; 'Carl Hage'; ietf-ediint@xxxxxxx
Cc:	David Bennett
Subject:	RE: EDI over http?

Rik and Carl,

I like what Carl is saying and think SSL is a better choice than smtp or http.

But what about PPTP (Point to Point Tunneling Protocol) or IPSec where you
could have multiple secure IP connections?

This is how I am establishing Internet enabled backup and disaster recovery
services for several of my clients.

I could see where an EDI hub could be set up like this to do real-time EDI
with its spokes. No need for SSL library calls.  Just set up the encrypted
"tunnels" for each spoke using the same PKI (Public Key Infrastructure)
technology that SSL uses.

There could be a problem with this technology if the trading partner base
is large.  SSL is in all our browsers and PPTP or IPSec client/server
software is not as widely available (although it is now in WinNT 4.0 -- and
a client is available now for Win95).

Just another idea to consider.  I would like to hear from anyone with ideas
on the pro's and con's of this concept.

Regards,
dave_d

At 09:57 AM 7/2/97 -0500, Rik Drummond wrote:
>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.
>
>
>
>
================================================================
|   Dave Darnell              
|   SysTrends, Inc. &  Arizona EC/EDI Roundtable     
|   1343 N. Alma School Rd. #155       H.Office: 	1850 East Carver Road       
|   Chandler, AZ 85224			Tempe, AZ 85284            
|   Tel:(602)899-4787			Tel:(602)838-5316 
|   Fax:(602)899-2813			Fax:(602)897-8032          
|   mailto://dave_d@xxxxxxxxxxxxx      http://www.systrends.com
=================================================================