Subject: Re: We do have a marketing problem ...

From: Dick Brooks <[email-masked]>
Date: Sun, 25 Apr 1999 16:56:37 -0500 (CDT)

SMTP based solutions are adequate when the following conditions are met:
	- immediate acknowledgement is NOT required
	- guaranteed timely delivery is NOT required
	- login/password authorization is NOT needed
	- Delays of minutes to days are acceptable
	- No gateways/relays encountered during transmission to affect the 
	  integrity of signed multiparts
	- Messages are reasonably small ( < 20 MB)
	- Business process involving the data exchange is NOT time sensitive

HTTP based solutions, like those specified in GISB and EDIINT AS2 are 
appropriate when the following conditions are met:
	- immediate acknowledgement IS REQUIRED
	- guaranteed timely delivery IS REQUIRED
	- login/password authorization IS NEEDED
	- Delays of minutes to days are NOT ACCEPTABLE 
	- Message size can be large (> 200 MB)
	- Business process involving the data exchange IS time sensitive

Some on this list have suggested that the objection to e-mail is more emotional
than technical. I strongly disagree. The Internet's E-mail infrastructre 
is an adequate solution for casual messaging and a certain class of business
transactions. It is completely inadequate when it comes to guaranteeing the
timely delivery of data and acknowledgements. Relays can cause delay leaving
trading partner systems "blind" to the state of a transaction. In cases where
deadlines exist an e-mail based solution could delay transaction delivery and
this could have financial impact (serious financial impact). 

Yes I know there is direct SMTP, but it is not widely deployed. The off the
shelf "sendmail" based MTA is a store and forward system that will route mail
to a relay automatically based on MX precedence, when primary SMTP servers are
unavailable. This has the "unwanted" side effect of passing delivery 
responsibility  to another MTA that may/may not be aware of the time 
sensitivity and other requirements of a transaction.

These are SMTP technical issues, which provoke an emotional response.

HTTP based solutions, as deployed by GISB, are DIRECT communication only. No
relays allowed. There is an error reporting mechansim defined in GISB that 
is designed to "alarm" interested parties IMMEDIATELY when failures occur so 
that action can be taken. This provides more insight into the delivery process 
and results in a higher degree of confidence by those responsible, than a 
typical e-mail based approach.

The decision to use HTTP or SMTP should be based on business requirements.

Dick Brooks                            [email-masked]
Tel. 205-250-8053		       Birmingham, Alabama
Group 8760 LLC                         WWW URL:  http://www.8760.com/
SECURE ELECTRONIC COMMERCE SOLUTIONS FOR HEALTHCARE AND NATURAL GAS INDUSTRIES

---

From: "Carl Hage" <[email-masked]>
Date: Sun, 25 Apr 1999 16:53:22 -0800

From:           	Dick Brooks <[email-masked]>

>  - immediate acknowledgement is NOT required

SMTP provides immediate acks (within 1 second of an HTTP 
implementation) provided the TP has the network connection 
required for HTTP, and does not use a store-and-forward gateway.

Please do not equate "queued sendmail + store-and-forward 
gateway" with "SMTP". SMTP has no queuing and no delay. Use 
of store-and-forward is also not part of SMTP except an SMTP 
server can deliver to a store-and-forward system if configured that 
way.

>  - guaranteed timely delivery is NOT required

SMTP can provide guaranteed delivery in an identical time as 
HTTP. However, SMTP also works with non-dedicated links where 
immediate response is not possible.

>  - login/password authorization is NOT needed

AS1/2 uses digital signatures and certificates, which provide 
authentication but do not require logins or secret passwords.

>  - Delays of minutes to days are acceptable

SMTP has no delay unless the TP is not directly reachable, in 
which case it still succeeds, even though a TP might not connect 
for minutes to days.

>    integrity of signed multiparts

SMTP/AS1 works with gateways, including those which cannot 
confirm delivery immediately.

>  - Messages are reasonably small ( < 20 MB)

Neither SMTP nor HTTP have length limits unless set as 
administrative policy.

>  - Business process involving the data exchange is NOT time sensitive

SMTP supports transactions in less than one second, assuming 
net transmission is <1s and encryption hardware is available.

-----

Note: An SMTP-based EDIINT messaging subsystem can work in 
a synchronous manner, e.g. 

status =     
sendmessage(tp_id,message,max_wait,&reply_buf,&status_buf);

where status could be
   0 - succeeded with reply in buf
   1 - failed with reply in buf
   2 - succeeded, no reply
   3 - failed, no reply
   4 - deferred

An HTTP-based system would either do the same, or not support 
the deferred mode.

Note: The only difference between HTTP and SMTP is that SMTP 
should normally encode binary data.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

---

From: "Gary Morin" <[email-masked]>
Date: Mon, 26 Apr 1999 10:07:02 -0400

Carl --

From a "technical" protocol centric approach you are correct in every statement
you make.  But to paraphrase the old line, "You can write Fortran in any
computer language",  I'd say "You can make any protocol look like _____"  (fill
in the blank).  Here is what is missing from this discussion.

1. Having run the production EDI and E-mail facility for a $4 billion (US)
automotive supplier I can tell you that if I had as many problems with my EDI as
I had with my e-mail I would have been de-sourced by my customer.  SMTP based
E-mail particularly as implemented by our friends at Lotus and Microsoft and
delivered by our friendly neighborhood ISP's is *not* a bulletproof process.

2. Spamming an EDI E-mail mailbox, particularly for a high profile Automotive
company, makes the open mail box with signitures a less desireable solution than
a "log in" (or SSL) session oriented approach from a "cycles spent to deter"
point of view.  Recognising that denial of service attacks are hard to prevent
anyway.  Best, is the route we have taken in Automotive to move to an industry
wide VPN. (I do agree we still need digital signitures for lots of other
reasons)

3.  The SMTP encode/decode has a price to pay in cycles spent and a one more
thing to go wrong sense.  Remember to that EDI goes a lot further than just X12
or UN/EDIFACT messages.  Tons of both ASCII and binary "messages" move across
our networks daily.  This is not as trivial a problem as it might seem.

4.  Having written both E-mail pre & post processors and ASP pages on the http
side I can tell you I will take the ASP approach every time.  In your example
the "messages" in the buffer will likley need to be programmed by a high order
application to be of any use to the sender.  This will be tougher to do with
todays SMTP "sendmail like" agents than with http servers.

There is no doubt in my mind that for EDI as we do it today, SMTP would work for
all but the most demanding environments.  The problem is that EDI is changing
even as we speak.  What is going to work best in the new world of VPN's and XML
is http and a machine to machine "dialog" approach to EDI best done with http.
Let's not do what we in the standards groups often do and that is to fight the
last war I have personally done it and have always paid the price later.

I agree with Dick Brooks.

Gary Morin
Co-chainman AIAG Message Routing Work Group.