Re: Message From KO/Office

[PETER_MCKINNEY@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]

Item Subject: Message From KO/Office
     Mark,
     
     Nicely written , but I have aproblem with one thing.
     
     That is, the idea of using an email reader to handle EDI traffic.
     
     A reader is a stand-alone piece of software that generally must be 
     under the control of the user.
     
     As Ken Steele and many of us others know and desire to achieve, EDI , 
     to be effective, must be application to application. 
     
     The email reader concept, as propositioned by you and others runs 
     counter to that idea, and is, to use the words of others, a 
     "non-starter" for the businesses, small and medium-sized ones, that I 
     consult to.
     
     It is the same kind of confused thinking that has people believeing 
     that Templar is a translator, or that it has special communications 
     lines requirements. It is neither. It is a security module.
     
     Thus, a corporation that does EDI always has at least 2 modules , and 
     they are sometimes tightly bound, otherwise they are independant but 
     co-exisiting. A translator module, and a comms module.
     
     Slipping a security module in beyween is easy and has been done.
     
     To you many users, they will not know that they are using two security 
     systems. In the email reader, it is seamless.
     
     In the App to App EDI, it will require management since they must 
     enter in the keys of their trading partners, just as they have to 
     enter in the control data that defines a trading partner to their 
     translator.
     
     The incremental amount of work involved is neglible.
     
     I do not want to get religious on this. I just feel strongly that the 
     business side of the argument is being left behind in the dust of the 
     pursuit of technical elegance.
     
     Email and EDI *are* different. The only network where they are treated 
     almost the same is ont he AT&T Easylink system. On every other 
     network, there are distinctly different network services.
     
     And because they are different, business management does and will look 
     at EDI versus email with a critical eye.
     
     Any standard we propose should address the business angle of 
     electronic commerce, and not just the objective of technical elegance.
     
     
     By the way, what is AUSTRALIA-CCA  HDQ  ?
     
     Best regards,
     
     Peter


______________________________ Reply Separator _________________________________
Subject: Message From KO/Office
Author:  Non-HP-owner-ietf-ediint (owner-ietf-ediint@imc.org) at 
HP-Boise,mimegw2
Date:    5/22/96 12:03 AM


     
     
Dale,
as a business user of both EDI and E-mail with our Trading Partners, 
we will not use one data encryption method for EDI (X12.58) and a 
different one for E-mail.
And we will progess to sending all our EDI as e-mail to e-mail 
addresses as well; we have no interest in sending over a proprietary 
VAN using proprietary addressing (some funny characters in the ISA 
or UNB segments) when we can send it on the Internet.
We have 100,000 business customers here in Australia, and hundreds 
of thousands more in other countries.  Many of them are small 
organisations (1-10 people total, no IS department).  The idea that 
they are going to use encryption method A for their email and method 
B for EDI is, to put it kindly, a poor joke.  Its the sort of 
solution that big companies with lots of IS resources come up with. 
EDI is just e-mail.  Sure, its application to application rather 
than person to person, but its just e-mail.  And we need a simple 
encryption method that is consistent so our customers' off the shelf 
e-mail package can receive a person to person or application to 
application message and decrypt it.
So encryption of just part of the EDI message is a solution with no 
long term future for 99.9 percent of businesses around the world. If 
that means that all the good work you did on X12.58 while at 
Sterling is a complete waste of time and effort, then all I can do 
is commiserate, and admit that in the past I too have wasted time on 
proprietary EDI solutions that will never be implemented.
Regards Mark
     
     
     
 * * * * * * * * * * * * * * * * * * * *
*  Message From : HUGHES, MARK          * 
*  Location     : AUSTRALIA-CCA HDQ     * 
*  KOMAIL ID    : N17503  (CCAMCQN1)    * 
*  Date and Time: 05/22/96  17:04:35    *
 * * * * * * * * * * * * * * * * * * * *

.......................................................................

TO: mark.hughes@ccamatil.com,
    owner-ietf-ediint@imc.org