Re: EDI over http?

[Carl Hage <chage@xxxxxxxxx>]

On Tue, 17 Jun 1997, Robert Moskowitz wrote:

> At 01:07 PM 6/17/97 -0700, Matthew James Gering wrote:
> >I can think of two advantages:
> >
> >* Real-Time response
> >I question the necessity of this. Could someone please elaborate.
> 
> This debate goes on for some time.  But an HTTP exchange can be done in two
> flows, throw the ASN to one end in one PUT (HTTP File Upload) and ack comes
> back in the reply.  When I only have 3 minutes to turn around an ASN and 1
> minute is eaten up by IMS, I care about how chatty SMTP is.

The issue of real-time response is misguided, or at least there is
often a comparison of gatewayed SMTP with interactive HTTP.

SMTP is hardly chatty. It's about the same as HTTP. However, SMTP
is designed to be "push" and HTTP is normally "pull". EDI is push,
and so HTTP (or FTP) is not well suited to EDI.

SMTP is often used with queued and gatewayed/forwarded transmissions,
but there is no inherent need to queue, and so real-time (<1s) exchanges
can take place.

> >* Session encryption
> >has security advantages over document encryption only.
> 
> You need them both.  Or at least doc sig and session or network encrypt.
> Yes someone has specified SSL for SMTP, but then the EDI SMTP model is
> based on many SMTP MTAs so here SSL would not be end to end like HTTPS.

Actually, document encryption has advantages over session encryption,
since messages can be forwarded securely, and signatures, etc. provide
auditing trails per transaction. Session security loses the audit
trails of document/transaction security.

> >And following disadvantages:
> >
> >* Fault Taulerance
> >through the use of multiple MX records, it handles transmission to hosts
> >that are not immediately available, routing around network outages and
> >unreachable hosts, etc, etc.
> 
> An advantage, but for real time, if my hosts are not reachable, I've got
> bigger problems.

HTTP has the same fault tolerance as SMTP, and HTTP servers can have
multiple IP addresses per name..

> 
> >* Gateways
> >SMTP can be gatewayed through Firewalls, gatewayed to other networks and/or
> >converted to other transport mechanisms such as X.400, etc..
> 
> HTTP can traverse firewalls also.   Do I care about X.400?  Well maybe OFTP...

SMTP can be gatewayed across networks, whereas HTTP required IP.

SMTP works with store and forward and part time networks. HTTP can't.
This is the main difference. Since SMTP is push, it works with
forwarding, where HTTP must always be active.

> >* Congestion
> >SMTP is friendlier on the network than HTTP.
> 
> It is?  For this usage?  The studies I saw were based on all of those
> little HTTP connections.  Those are not the case here.

SMTP and HTTP are almost equivalent, and better than FTP.

> >* Reliability
> >Denial of Service (DoS) attacks against web servers are far too trivial.
> 
> And not for SMTP?  Well they are different ones, but I've seen many an
> SMTP's /tmp or /var/mail fill up.

SMTP and HTTP are almost equivalent in this respect.

> >* Efficiency
> >SMTP is a much more efficient protocol than HTTP, both in file transfer and
> >server load.
> 
> SMTP is chatty, HTTP is not.  There are multi-threaded HTTPs out now, is
> SENDMAIL?

They are almost equivalent. Both exchange a few bytes, send the message,
and terminate.

> One very important advantage of HTTP is it is basically a 2-phase
> transaction, where as SMTP is a 1-phase.  The work to coordinate the
> response to an EDI over SMTP is not needed over HTTP.  They occur on the
> same TCP connection.

The problem is that HTTP is a pull technology, and pushing data is a
kludge. Thus the greater complixity. However, this is irrelevant for
practical purposes.

> Another important advantage is third party participation.  Via chained
> URLs, I can have, say a bank, involved in the EDI between two partners.  I
> suppose that bang paths could do the same thing.

There is a disadvantage. SMTP is delivery of messages, period,
and URLs are meaningless except as a kludge to map message
delivery onto HTTP. Everyone might do it differently.

SMTP has an advantage. email addresses are universal and could have third
party participation, even across networks.