Re: Message Header Info

["William J. Kammerer" <wkammerer@foresightcorp.com>]

I'm attaching an e-mail entitled "Re: E D I, OR Why VANs aren't all that
useless..." that I sent to EDI-L re: logical address resolution and
global EDI directories, including mention of EDIRA (EDI Registration
Authorities).  To subscribe to
EDI-L, mailto:EDI-L-subscribe-request@listserv.net.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"

-----Original Message-----
From: Matti.Vasara@fingrid.fi <Matti.Vasara@fingrid.fi>
To: wkammerer@foresightcorp.com <wkammerer@foresightcorp.com>;
ebXML-Transport@lists.oasis-open.org
<ebXML-Transport@lists.oasis-open.org>
Date: Tuesday, February 15, 2000 2:04 AM
Subject: VS: Message Header Info


The most comprehensive system for EDIFACT is in the EDIRA work now by
Afnor
Alain Thiénot. Email i suspect is alain.thienot@email.afnor.fr.
Matti Vasara

---

• From: "William J. Kammerer" <wkammerer@foresightcorp.com>
• To: <EDI-L@LISTSERV.UCOP.EDU>
• Date: Mon, 1 Nov 1999 08:06:04 -0500

Sted Chen, of SoftCare Electronic Commerce Inc., wrote acknowledging to
me that he stands corrected, in that VANs *do* provide useful services:

   I do believe VANs do provide useful "people" services such as
   consulting, project management, etc. just like any other EC/EDI
   consultant, vendor, SI firm, etc.  That is where it ends though.
   In terms of using the VAN in a traditional sense of routing or
   as a communications backbone I do not see the use of a VAN's
   backbone.

Dear Sted:

That's all very nice.  But I never said anything about a VAN's "people"
services (though Doug Anderson of Kleinschmidt and Tom Fennelly of
Unisource Worldwide certainly did touch on these).  The only point I
made in favor of a VAN, its sine qua non, was:

   A VAN performs an important routing service that is hard
   to replicate without odious maintenance (e.g., SMTP e-mail
   addresses, TCP/IP addresses, FTP directories, etc., etc.)
   for each trading partner.  You can't yet just throw X12 or
   EDIFACT interchanges into the ether of the Internet and
   expect them to be automatically and securely routed
   according to the SCAC, UCC Comm ID or DUNS number in the
   recipient ID.

I fully realize that "[a]ll a business would have to do is create an
e-mail user 'edi@<your domain>' or have an ftp login for EDI."  That,
plus the certificate, hooking it up to your translator, and perhaps a
couple dozen other items done to identify and setup one's own EDI server
really would not take too long or be too difficult.  I'll even concede
that these would be nits when compared to the awesome savings you'd
achieve by using Internet EDI.

But when you're all done setting up your server, who are you gonna talk
to?  First of all, every one of your trading partners will have to
install a compatible EDI server before you can pull the plug on the VAN.
Softcare, Harbinger and Cyclone don't give the EDI server software away
for free, do they? (Or if your trading partner wants to go the cheap
route, they'll have to agree to juryrig WSFTP with scripts.)   Assuming
all your partners agreed to use the Internet,  then every one of them
will have to be defined to your system.  As IETF RFC 1865 (EDI Meets the
Internet FAQ), at http://www.ietf.org/rfc/rfc1865.txt, reminds us, for
e-mail EDI exchanges conforming to the IETF EDIINT standard we need:

   1. The internet email address for EDI messages
   2. An internet email address for personal communications related
      to EDI
   3. Agreement on the encryption and digital signature protocols,
      including email acknowledgment, e.g. support for the
      "Return-Receipt-To:" email header, or X.400 extended email
      header fields.
   4. Public Keys for PEM or PGP encryption and digital signatures.
      (or private keys for DES encryption)
   5. Agreement on the format of the message, e.g. IETF MIME/EDI.

And RFC 1865 says FTP based messaging would require the following for
each trading partner:

   1. FTP login name and password
   2. Machine(s) from which the login will be accepted
   3. Additional security protocols
   4. Directory and file naming conventions
   5. File encryption protocols and keys
   6. Wrappers around EDI data, e.g. MIME/EDI headers,
      PEM/PGP wrappers, etc.

This all sounds even more complicated than programming a VCR, which is
why mine has always blinked 00:00AM.   I've seen the multi-page screens
for defining trading partners and exchanging keys in Templar-like
products;  it seems an  arduous exercise that would be worth doing only
for those few trading partners that make up the bulk of my traffic.
Would I really want to dedicate the resources to define 500 or 3000
trading partners in this fashion?  This "human touch" (i.e.,
maintenance) that the VAN insulated me from is now something I'd have to
do myself.  And every time a trading partner moved their e-mail server
and gave me a new e-mail ID, or changed their key, I'd be back at it
again.

With EDI, I identify a trading partner by an ID which is already natural
to use, and is readily found in the ISA or UNB:  the SCAC,  the EAN
location, the DUNS number, the ACT college ID, and on and on.  I want
Internet EDI to be as easy to use as the telephone or the VAN - I just
want to dump my interchanges into one funnel and have it worry about
automatically and securely routing them to the right place, based on the
recipient ID.  VANs currently have the monopoly on this kind of routing
information.  I have to think that they recognize their crown jewels
consist of EDI (trading partner) directories, not so much their warm and
fuzzy hand-holding.  I believe you may underestimate the value of this
monopoly.

Internet EDI would perhaps become viable if a global EDI directory
became available;  this is a service I doubt VANs would be keen to
provide.  Noble attempts at this in the past, usually involving global
X.500 directories, seem to have gone nowhere: e.g., the EMA Directory
Challenge, the North American Directory Forum (NADF), EDI Registration
Authorities Project (EDIRA), and the Directory-based EDI Certificate
Access and management project (DEDICA).   Unfortunately, none so far
have been built around an economic model that seems to work.  If we had
a truly global EDI directory a major barrier to SME participation in EDI
would be removed.  It would even be possible for the first time to
enable Open-EDI whereby upfront negotiation could be eliminated before
the exchange of EDI.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"

---