Request for Comments: 1865 Dept. of Veterans Affairs
Category: Informational J. Griffin
Athena Associates
C. Hage
C. Hage Associates
January 1996
EDI Meets the Internet
Frequently Asked Questions about
Electronic Data Interchange (EDI) on the Internet
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memo is targeted towards the EDI community that is unfamiliar
with the Internet, including EDI software developers, users, and
service providers. The memo introduces the Internet and assumes a
basic knowledge of EDI.
Table of Contents
1. Introduction ................................................ 4
1.1. What is this document .................................... 4
1.2. What do you mean by electronic data interchange (EDI) ? . 4
1.3. What are the X12 Standards that I should be aware of ? .. 4
1.4. To whom do I send comments and suggestions ? ............. 5
1.5. How can I get a copy of this document? ................... 5
2. General Information ......................................... 6
2.1. What is the Internet ? .................................. 6
2.2. Is there a difference between EDI and
electronic commerce (EC) ? ............................... 6
2.3. What makes the Internet useful for EDI ? ................ 6
2.4. Does this means we will now have to coordinate our
EC/EDI activities with the Internet? .................... 7
2.5. How do I find the addresses of other Trading partners
on the Internet if I don't have to coordinate my EDI
activities with a central organization or VAN? .......... 7
2.6. How fast is the Internet? ............................... 7
2.7. What about reliability of the Internet? ................. 7
2.8. What are RFCs and where can I get them ? ................ 8
2.9. Where can I get general information about the Internet? . 8
3. Getting Connected To The Internet ........................... 9
3.1. What do I need to get to use the Internet? .............. 9
3.2. What software is used to support electronic mail? ....... 9
3.3. What types of client-server or server-server
protocols exist on the Internet? ........................ 10
3.4. What methods exist to broadcast information across
the Internet? ........................................... 12
3.5. What are the ways to connect to the Internet ? .......... 13
4. Organizational Issues ....................................... 15
4.1. Why is the way we currently do EDI so limiting to its
growth? .................................................. 15
4.2. My organization has an internal automated system for
processing requisitions and issuing purchase orders, but it
does not create the X12 formatted EDI transactions; what
should we do ? ........................................... 16
4.3. My organization already has a dial-in bulletin board
service (BBS) where we post transactions; should we
keep it? .................................................. 16
4.4. My organization currently has a Trading Partner
Agreement with each trading partner we're currently
doing business with. Can we keep them ? .................. 16
4.5. It would be nice to get more trading partners and/or
more competition, but I'm worried about getting too many
transactions to be able to handle them. Has this been a
problem ? ................................................ 17
4.6. Does this mean that I'll receive more messages ? ......... 17
4.7. If we see a transaction posted on VAN, how do we
respond in electronic format ? ........................... 18
4.8. My organization has an established bilateral
relationship (such as an existing contract. Can we
send these transactions via the Internet ? ............... 18
5. The Role Of Value Added Networks ............................ 18
5.1. What is a VAN? ................... ....................... 18
5.2. What is an Internet Service Provider (ISP)? .............. 19
5.3. How might an ISP be used for EDI? ........................ 19
5.4. Doesn't EDI presume the services of companies called
Value Added Networks (VANs)? ............................. 19
5.5. If I can use X12 protocol and my VAN to send
transactions, what is the benefit of using
the Internet? ............................................ 20
5.6. Can we expect VANs to offer connections to other VANs
via the Internet? ........................................ 20
5.7. How can I use the Internet directly for exchanging EDI
messages without going through a VAN? .................... 20
5.8. Can the ISA 06 or 08 identify any entity other than the
'end' Trading Partners (i.e. a routing entity) ? ......... 21
5.9. Can we specify both the recipient's address and their
VAN address in the ISA ? ................................ 22
5.10. Are there other options for routing EDI X12
messages ? ............................................... 22
6. US Federal Involvement ...................................... 22
6.1. What is the commitment of the US Federal Government
to EDI ? ................................................ 22
6.2. What is the timetable for the Federal effort ? .......... 23
6.3. Will the US Government use the Internet to send
EDI transactions ? ...................................... 23
6.4. I heard the US Government prohibited commercial use
of the Internet? ........................................ 24
6.5. The US Government is using both Internet and OSI
E-mail protocols. What should one consider when
choosing which to use ? ................................. 24
6.6. How is the US Government using VANs to distribute
business opportunities? ................................. 25
6.7. How would use of the Internet for Federal procurement
change this RFQ process? ................................ 25
7. EDI Resources On The Internet ............................... 26
7.1. Are EDI Standards available on the Internet ? ........... 26
7.2. Are EDIFACT Standards available on the Internet ? ....... 28
7.3. The EDI X12 standards are quite complex. How do we
decide what X12 transactions to implement and how ? ..... 29
7.4. What Implementation Conventions (ICs) are available
over the Internet ? ..................................... 29
7.5. How can a trading partner keep up with all these
implementation conventions (ICs) and revisions in
X12 and EDIFACT? ......................................... 31
7.6 Where can I get information on EDI translation
software ? ............................................... 31
7.7. How do I keep in touch with others pursuing EDI and
Electronic Commerce on the Internet ? .................... 32
7.8. Can I get messages that have been previously posted
to the EDI mailing lists ? ............................... 35
7.9. How do I make EDI related material available
to the Internet community ? .............................. 35
7.10. Where are EDI Archives on the Internet ? ................. 35
8. Security Considerations ..................................... 36
8.1. What security measures are needed to connect to the
Internet ? ............................................... 36
8.2. How do we go about protecting our system ? ............... 36
8.3. Is there good publicly available software I can use? ..... 37
8.4. How good are electronic or digital signatures ?
Can they be used in court ? .............................. 38
8.5. Are there other US government standards publications
I should be aware of? .................................... 38
9. References .................................................. 39
10. Credits .................................................... 40
11. Authors' Addresses ......................................... 41
1. Introduction
1.1. What is this document
This document is informational in nature and attempts to answer
frequently asked questions concerning the use of the Internet for
Electronic Data Interchange (EDI). The primary audience is the EDI
community that is unfamiliar with the Internet, including software
developers, users, and service providers. The reader needs some
understanding of EDI. Informational RFCs are prepared by the
Internet Engineering Task Force (IETF) to improve understanding and
effectiveness in the use of the Internet.
1.2. What do you mean by electronic data interchange (EDI) ?
Except as noted, the document refers to EDI as the use of the
1) X12 standard developed by the ANSI Accredited Standards
Committee X12 or
2) EDIFACT[1] standard United Nations Economic Commission for
Europe (UN/ECE), Working Party for the Facilitation of
International Trade Procedures (WP.4).
The differences between these standards is beyond the scope of this
FAQ. Both standards activities are managed in the US by:
Data Interchange Standards Association, Inc,
1800 Diagonal Road, Suite 200
Alexandria, Virginia, 22314-2852
Voice: 703-548-7005
FAX: 703-548-5738
There are numerous other standards one could use for EDI, but
discussion of them is not in the scope of this document.
1.3. What are the X12 Standards that I should be aware of ?
ACCREDITED STANDARDS COMMITTEE (ASC) X12 Standards are available from
DISA at the address specified in Question 1. The following is a good
starting set of X12 standards.
1. ASC X12S/94-172, An Introduction to Electronic
Data Interchange, DISA 1994 Publications Catalog
2. ASC X12.3 Data Element Dictionary
3. ASC X12.5 Interchange Control Structure
4. ASC X12.6 Application Control Structure
5. ASC X12.22 Segment Directory
6. ASC X12.58 Security Structures
1.4. To whom do I send comments and suggestions ?
Readers are invited to add questions; please include an answer if you
know or want to suggest one. Of course corrections and comments are
welcome; send them to the IETF-EDI mail list by subscribing as
described in question 7.6. Or a send your comment to
houser.walt@forum.va.gov.
1.5. How can I get a copy of this document?
Request for Comments documents (RFC) are available by anonymous FTP.
Login with the username "anonymous" and a password of your e-mail
address. After logging in, type "cd rfc" and then
"get rfc1865.txt".
A Web address for the RFCis:
ftp://ds.internic.net/rfc/rfc1865.txt
RFCdirectories are located at:
o Africa at: ftp.is.co.za (196.4.160.2)
o Europe: nic.nordu.net (192.36.148.17)
o Pacific Rim: munnari.oz.au (128.250.1.21)
o US East Coast: ds.internic.net (198.49.45.10)
o US West Coast: ftp.isi.edu (128.9.0.32)
RFCs are also available by mail. Send a message to:
mailserv@ds.internic.net. In the body type:
"FILE /rfc/rfc1865.txt"
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this feature,
insert the command "ENCODING mime" before the "FILE" command. To
decode the response(s), you will need "munpack" or a MIME-compliant
mail reader. Different MIME-compliant mail readers exhibit different
behavior, especially when dealing with "multipart" MIME messages
(i.e., documents which have been split up into multiple messages), so
check your local documentation on how to manipulate these messages.
2. General Information
2.1. What is the Internet ?
It is the inter-working of existing corporate and government networks
using commonly used telecommunications standards. It is not a new
physical network, although some new facilities may be needed.
Rather, it is based on mutual interests of users to communicate more
effectively via electronic message and file transfers. Internet
communications may be interpersonal (person-to-person) E-Mail or
process-to-process like EDI. Messages may be inquiries to shared
databases and responses. Messages may be entire files.
2.2. Is there a difference between EDI and electronic commerce (EC) ?
Electronic Data Interchange (EDI) is defined as the inter-process
(computer application to computer application) communication of
business information in a standardized electronic form. Electronic
Commerce includes EDI, but recognizes the need for inter-personal
(human to human) communications, the transfer of moneys, and the
sharing of common data bases as additional activities that aid in the
efficient conduct of business. By incorporating a wide range of
technologies, EC is much broader than EDI. However, the focus of
this document in on EDI, not electronic commerce.
2.3. What makes the Internet useful for EDI ?
The greatest benefits will derive from:
o Adoption of common standards and proven inter-operable systems,
o Adoption and deployment of a distributed Directory Service
capability, so that one can readily contact electronically any
other organization in the world.
o Explicit commitment by participating organizations to
cooperatively route traffic, work to resolve addresses, and
meet required standards.
o Ubiquitous network coverage from many service providers. This
allows the customer to choose the level of service needed.
o Layering of applications (such as EDI) over existing, proven,
applications.
o A standards process with reference implementations which
all vendors have equal access. (a.k.a. a level playing field).
o Widely available public domain software including but not
limited to applications, protocol/transports and multiple
platform development tools.
2.4. Does this means we will now have to coordinate our EC/EDI
activities with the Internet?
The Internet is not an organization or government agency. You use
the Internet to do business like you would use the telephone. The
same Internet connection your organization uses to send electronic
mail would be the one you use to send EDI transactions. Software
developers write EDI translators, packages or templates for your e-
mail system so that you can handle your own EDI transactions. Your
EDI activities do not need to be coordinated, but your connection to
the Internet does.
2.5. How do I find the addresses of other Trading partners on the
Internet if I don't have to coordinate my EDI activities with
a central organization or VAN?
The Internet works by assigning names or "domains" to
networks/companies/machines. This is called the Domain Name Service
(DNS). It works from a distributed tree structure. The Internet
requires registration of your Internet Protocol (IP) address and
Domain Name in the Domain Name Service (DNS). Your internet service
provider can do this for you or assist you in contacting the right
people to get your assigned addresses and domain names.
2.6. How fast is the Internet?
For a modest amount of data with a dedicated connection, a message
transmission would occur in a matter of seconds, unless the ISP
selected one of the trading partners is overloaded. The maximum
delay over the internet backbones is at most a few seconds. Like the
interstate highway system, speed depends on how close you and your
trading partner are to Internet backbones. Unfortunately, some areas
may lack the capacity or "bandwidth" to handle the workload your
organization requires. Contact your local Internet Service Provider
for details on service in your area. Also, the more you are willing
to spend, the better the service. The Internet is inexpensive, but
(contrary to popular mythology) it is not free.
2.7. What about reliability of the Internet?
For high reliability mission critical applications, redundant ISPs
may be used (with separate backbones), and redundant mail servers at
separate locations can be used. A single internet email or server
address can be used to transparently route to any of the redundant
servers or network connections.
If a dedicated Internet connection is used to transmit information,
e.g., via SMTP (see questions 3.2 and 3.5), then the message is
delivered directly to the trading partner's system and delivery is
assured. If a part time store and forward connection is used, then
the integrity of the message depends on the ISP or other computers
used in the forwarding of a message.
2.8. What are RFCs and where can I get them ?
RFCstands for Request For Comments. The RFCseries of notes covers
a broad range of topics related to computer communications. The core
topics are the Internet and the TCP/IP protocol suite. There are
three categories of RFCs today, Standards Track, Informational, or
Experimental. Many of the RFCs describe de-facto standards in the
Internet Community. Copies of RFCs are often posted to the USENET
newsgroup comp.doc and obtainable from archive sites such as
ds.internic.net.
ftp://ds.internic.net/rfc/
2.9. Where can I get general information about the Internet?
Your local bookstore probably has one of the many recent introductory
publications on the Internet. In addition, look for (or have someone
get you) the following bibliographies for free:
RFC1175
Bowers, K., LaQuey, T., Reynolds, J., Roubicek, K.,
Stahl, M., and A. Yuan, "FYI on Where to Start -
A Bibliography of Internetworking Information",
08/16/1990 (FYI 3)
ftp://ds.internic.net/rfc/rfc1175.txt
RFC1463
Hoffman, E., and L. Jackson, "FYI on Introducing the
Internet -- A Short Bibliography of Introductory
Internetworking Readings for the Network Novice",
05/27/93 (FYI 19)
ftp://ds.internic.net/rfc/rfc1463.txt
The reader may want to look at the Frequently Asked Questions (FAQ)
document for the newsgroup alt.internet.services. This FAQ, as well
as all Usenet FAQs, can be retrieved via ftp from rtfm.mit.edu in the
directory /pub/usenet/news.answers. These FAQs are also available
from ftp.sterling.com in the directory /usenet/news.answers.
3. Getting Connected To The Internet
3.1. What do I need to get to use the Internet?
You need to know your existing telecommunications connectivity,
address resolution, and routing capabilities. Then you need to
establish and operate an Electronic Mail gateway and/or other
application gateway, e.g., for the file transfer protocol (FTP).
Larger organizations may supply their trading partners with the
TCP/IP software and X12 translator interfaced to E-mail or FTP.
3.2. What software is used to support electronic mail?
a) Simple Mail Transfer Protocol (SMTP) Servers
A dedicated internet connection usually uses SMTP software to send
and receive messages. The SMTP server may transfer messages to the
"spool" area for incoming email in the file system, may queue the
messages for transmission via UUCP, may hold mail in a POP server,
or may transfer the message to a proprietary email system.
b) Unix-to-Unix Copy (UUCP) Servers
A UUCP server is used to transfer messages when a store and
forward is used, either between machines within a WAN, or to
another machine with a dialup link.
c) Post Office Protocol (POP) mail Servers
A POP server holds email which can later be retrieved by a client
application run by the user, typically on a PC which might not be
running 24 hours a day. The TCP/IP protocol is used either over a
LAN or dialup SLIP connection to retrieve messages.
d) Mail User Agents (Mail Readers)
Uses or applications employ client programs to retrieve and
display email messages from the file system mail spool area, or
from another server computer using POP or some other proprietary
protocol (e.g. Microsoft-Mail). This mail user agent (UA) software
is also used to compose and send email via a POP server or system
email.
The mail user agent may also process attached files using a
proprietary format within a mail message, using one of the common
de-facto standards, or using the Multipurpose Internet Mail
Extensions (MIME) internet standard. Among other things, MIME
permits the identification and concatenation of message parts
(called "body parts") into a single message that can traverse the
Internet using the SMTP protocol. The Work in Progress, "EDI in
MIME" provides the necessary standards for MIME compliant user
agents to identify EDI body parts. A MIME compliant mail reader
can process the contents of the messages and dispatch data to
external software. For example, files can be dragged to file
system directories, images can be displayed, and audio data can be
played. In the case of EDI, a message formatted according to the
MIME-EDI specification could be automatically transferred to an
EDI processing program.
e) Automated Mail Processing
A typical Mail User Agents is an interactive application. However
there are automated email message processing programs which can
sort incoming mail, process forms returned by others, or in the
case of EDI data, transfer the message contents to the EDI system.
Messages formatted according to the MIME EDI specification can be
properly recognized by any MIME compliant mail processing program.
3.3. What types of client-server or server-server protocols exist on
the Internet?
Internet email is typically used for two party messaging. The FTP,
gopher, and HTTP protocols allow many users, possibly anonymous, to
retrieve data from a central source. For example, corporate catalogs
can be restricted by potential customers.
a) File Transfer Protocol (FTP)
Companies with existing connectivity to the Internet may use FTP
to transfer files to one-another or to their VAN. This solution
employs the same TCP/IP used for SMTP. Furthermore, Internet
documents such as EDI in MIME Work in Progress are available via
FTP on the FTP server "ds.internic.net."
b) gopher service protocol.
Gopher service is a way of organizing selected documents and files
on an Internet server in a simple tree menu, so that users on
other Internet computers can find them easily. Most gopher menus
are also linked to other gopher menus elsewhere, so that users can
easily jump from one Internet server to another. There are
thousands of gopher servers in operation worldwide.
c) The Hypertext Transfer Protocol (HTTP)
HTTP defines http-server and http-clients that comprise the World
Wide Web (WWW). WWW was developed by the European Laboratory for
Particle Physics (CERN) as a tool for exchanging multimedia data
between researchers. Although there is also no specification for
graphics in HTTP, most web browsers are graphical in nature.
Mosaic, available free from the National Center for Supercomputer
Applications (NCSA), provides a Graphical User Interface (GUI)
that facilitates user access to information on the Internet.
Mosaic interprets hypertext based information on the WWW, as well
as to other linked Index/Directory services such as Archie, FTP,
Gopher, and X.500 Directory information. Mosaic also supports on
line Graphic Interchange Format (GIF), Joint Photographic Experts
Group (JPEG), Motion Picture Experts Group (MPEG), QuickTime, and
other document, image, and audio types. Vendors have developed
product catalogues using Mosaic servers.
d) WHOIS
WHOIS servers generally offer information about the organization
to which they belong. There are many WHOIS servers scattered
throughout the Internet. To obtain a list of registered WHOIS
servers, anonymous FTP to rtfm.mit.edu and get the file
/pub/whois/whois-servers.list. You can:
o run a client program on your own machine to access the
WHOIS server,
o telnet to a site which hosts the server, eg: telnet to
whois.internic.net and type help to access the full online
help
o send an email message to retrieve information from the
database. eg: send email to mailserv@internic.net with
a command in the Subject field. Any information in the
body part of message will be ignored. ie.
Subject: whois <search string>
Therefore, to find information on the Internic Registration
Service, the subject should contain: whois internic
Moreover, to obtain help information on this service you can
send two separate email with the following in their subject
line, respectively:
help
whois help
3.4. What methods exist to broadcast information across the Internet?
There are also some usual methods to broadcast messages to multiple
recipients as described below:
a) Usenet News
Usenet news is a cooperative broadcast of messages to all
participants. Messages are organized into categories called
newsgroups, and there are over 10,000 newsgroups carried by the
major ISPs. Individual customers typically subscribe to some
subset of these which is of interest to the organization.
Messages are typically held for a week or two, then either
archived or discarded. Some newsgroups are free form, i.e. anyone
can post a message, while others are "moderated", i.e. require
approval prior to posting.
Though not currently used for any type of EDI, Usenet news could
be used to broadcast RFQs. For example, comp.newprod is used to
announce new products, and misc.jobs.wanted is used to announce
job openings.
b) Mailing Lists
If the interest is limited, a mailing list may be used in lieu of
a newsgroup. These are typically used for discussion groups or
announcements of a particular nature. Mailing lists are typically
open, i.e. anyone can "subscribe" by sending an email message to a
server. For discussion groups, anyone can send a message to the
server which is then rebroadcast to all subscribers. Since
Internet email is extremely inexpensive, there is normally no
charge for use of a mailing list, except for the content of
e-magazines, etc. Sponsors of an email list typically provide the
list as a public service.
For example, a mailing list could be used to broadcast EDI RFQs,
etc. Vendors might subscribe to various lists related to their
product or service in order to receive messages sent by potential
customers. Mailing lists could be provided by large companies for
internal use, by industry organizations, or VANs. For example, a
firm or government agency could sponsor various mailing lists for
EDI RFQ's, new product announcements, etc. related to procurement.
The organization could easily allow other potential customers to
use the same mailing lists to contact vendors. All parties would
benefit, and the improved access to vendors from an open mailing
list would more than offset the cost to support the mailing list
server. Thus service might be available for free.
3.5. What are the ways to connect to the Internet ?
The following provides a general overview of connectivity options now
available:
a) Dedicated Connection
Typically a leased telephone line is used to connect a gateway
computer or Typically a leased telephone line is used to connect a
gateway computer or bridge/router of a corporate LAN/WAN to the
router of the Internet Service Provider's (ISP) Point-Of-Presence
(POP, not to be confused with the Post Office Protocol). The
connection may be of various types and speeds, e.g. modem, ISDN,
DS0, or DS1 line.
With a dedicated connection, the SMTP protocol is typically used
to deliver email directly to a trading partners system. Also,
real-time client server applications can be run directly with a
trading partners system, including information transferred using
the FTP and HTTP protocols.
Some ISPs provide optional services even with dedicated
connections. For example, store and forward email on an ISP
server can be used as a backup for a direct SMTP server operated
by a trading partner. The ISP may offer disk space on their FTP
and HTTP servers with a high speed connection to the Internet.
For example, a trading partner might use a 14.4Kb modem for
dedicated email transfers and use a 1.5Mb connection operated by
the ISP to distribute FTP and HTTP information.
b) On-demand Connection
An on-demand connection operates like a dedicated connection,
except a dialup ISDN or modem connection is used. If the link
remains idle for a certain period of time, the connection is
dropped. Some ISPs offer dial-out capability so any inbound or
outbound traffic can reestablish the link. However, many ISPs
require their customers to dial-in, so only outbound traffic and
regular polling will establish the link. In the latter case, store
and forward would likely be used for email, and the ISP servers
would be used for FTP and HTTP information.
c) Part-time Polled Connection
The Unix-to-Unix Copy (UUCP) protocol is typically used for email,
news, and (rarely) file transfers. A client organization
periodically dials the ISP and transfers email and Usenet news for
the organization, then disconnects. Typically, the client polls
the ISP at regular intervals, e.g. every 20 minutes, though some
ISPs dial out when a message is to be delivered. Outgoing email
can be sent immediately, or queued for transmission with a
specified maximum delay.
A UUCP connection may be used to transfer messages to an arbitrary
number of people or automated mail processing programs. A single
UUCP connection may also route messages to other systems, e.g.
divisions within a corporation. UUCP and store-and-forward are
synonymous.
Since UUCP is only used to transfer mail and news messages,
interactive internet client-server applications like FTP and HTTP
are not available, except using a server provided by an ISP. Thus
a separate dialup account might be needed to retrieve information
from other FTP or HTTP servers. UUCP might be used for automated
email transfer, and a on-demand dialup connection would be used
for interactive internet client applications.
Though UUCP accounts imply a delay (up to the polling interval) in
processing a message, many ISPs allow a customer supplied script
to process messages immediately on the ISP's machine. Though UUCP
can be used to transfer files directly, usually files are
transferred by encoding them within an email message.
Transmission within internet email messages is much more widely
supported and can be gatewayed into proprietary systems.
d) Dial-up Shell Account
With a dial-up account, a single user with a personal computer
running a terminal emulator connects to the ISP's computer. Mail
readers, news readers, HTTP browsers, etc. can be run on the ISP
machine. Data on the ISP machine can be transferred to the
personal computer manually using a protocol like X-Modem, Z-Modem,
or Kermit.
The ISP's host computer may run one of the usual UNIX command line
(shell) programs, or may use a custom BBS or other menu driven
user interface. A proprietary client-server program may be used in
lieu of a terminal emulator to provide a graphic user interface.
Some of the proprietary GUI clients provide access to selected
internet applications, e.g. gopher.
A dialup ISP typically has a direct internet connection, however
very low cost providers might only have a UUCP connection to the
Internet. Some large proprietary networks such as CompuServe do
not offer a direct internet connection, and only support UUCP
email and, sometimes, Usenet news gateways to the Internet.
d) Personal Serial Line Internet Protocol (SLIP) or Point to Point
Protocol (PPP) Account
A SLIP/PPP account is also available as a cross between the on
demand and dial- up. Like the on-demand account, a single user can
connect to an ISP and run mail reader, news reader, FTP, HTTP
browser, etc. client applications directly from a personal
computer. Unlike the on-demand account, the dial-out computer
functions as a client only and not a server, and would be used by
a single user rather than as a gateway to a LAN.
With a SLIP/PPP account, the POP (Post-Office-Protocol) protocol
is used for a user's mail reader client to retrieve messages
stored in the ISP's server. Unlike, UUCP, the POP servers hold
mail for a single user (i.e. individual email address).
With a SLIP/PPP connection any standard TCP/IP application is tied
directly into the internet. Thus unlike the proprietary GUI
software supplied by the ISP, any TCP/IP client application can be
used.
A program such as TIA (The Internet Adapter) can be run on a shell
account which allows a standard UNIX shell account to function as
a SLIP/PPP account. However, some ISPs do not support TIA as they
charge extra for SLIP.
4. Organizational Issues
4.1. Why is the way we currently do EDI so limiting to its growth?
There is a tendency for each organization to establish is own rules
and administrative policies, leading to rising costs of dealing with
multiple trading partners, each in turn with its own requirements and
procedures. However, new technologies and business practices are
necessary if EDI is to move beyond the 30 to 40,000 organizations
presently using EDI. According to Department of Labor and Internal
Revenue Service statistics, there are about 6.2 million entities with
employees and about 14 million other "business" entities. A business
that wants to sell chairs, for example, would have to check with many
different customers to see if they had any requirements. By making
it possible for a business to use a common method to look for
customers, the barriers entering to the electronic marketplace are
greatly eased. This does not mean that there is only one source that
everyone goes to for a list of current business opportunities.
Rather, a prospective supplier only needs to go to a single
electronic marketplace. To communicate with each other, the various
participants in electronic commerce need to harmonize their
procedures and processes. Examples include common trading partner
registration and the adoption of standard implementation conventions
for EDI messages.
4.2. My organization has an internal automated system for processing
requisitions and issuing purchase orders, but it does not create
the X12 formatted EDI transactions; what should we do ?
You could enhance your existing system, for example, by adding EDI
translation software. VANs often offer EDI "translation"
capabilities that convert flat text files into EDI X12 or EDIFACT
format. This translation software may be designed with a particular
technical solution in mind; carefully consider how the software would
be used and what applications and telecommunications software would
need to interact with it. You don't want to inadvertently lock
yourself into using only one supplier.
4.3. My organization already has a dial-in bulletin board service
(BBS) where we post transactions; should we keep it?
Yes, but that puts you in the role of being your own VAN. By acting
independently, organizations have established their own dial-up
electronic bulletin board system with their own unique, but
functionally equivalent, operating rules. Your BBS will be a little
different that the next organization's, making it difficult for
suppliers to access. By getting transactions from the VANs who
specialize in moving information, your organization will get the
widest circulation possible. You will be able to reach trading
partners you may not even know existed, resulting in more competitive
bids. Because of their idiosyncratic nature, BBS are not consistent
with the idea of a "single face to industry" espoused by the Federal
Government.
4.4. My organization currently has a Trading Partner Agreement
with each trading partner we're currently doing business with.
Can we keep them ?
In the short run you may want to keep some Agreements in place to
cover unique circumstances. But be careful not to create conflicting
agreements and directions for your trading partners. Follow the
procedures common to your particular line of business. In the long
run, less is better. Hopefully, the introduction of EDI into common
commercial practice will eliminate the need for EDI-specific
agreements.
4.5. It would be nice to get more trading partners and/or more
competition, but I'm worried about getting too many transactions
to be able to handle them. Has this been a problem ?
The answers to this and related questions presupposes a willingness
to participate in the open bidding process. While this process is a
legal requirement for government agencies, many private organizations
choose not to adopt the practice. The technology of the Internet
facilitates competition, but the cost of putting these practices in
place limit their value. This is a business decision, not a
technical one. Will companies competitively procure critical
supplies absent a long term relationship with the supplier? For
essential inputs that will make or break customer satisfaction and
productivity, the benefits of competition may not be worth the risks.
Many organizations experience some increase in the number of
transactions; for competitive procurements, the winning bid should be
significantly better than those received prior to using the
electronic system. The impact of an increase in volume needs to be
evaluated on a situation by situation basis. For example, your
acquisition support system may need to be re-engineered to quickly
handle bids by ranking and presenting them to your buyers in low to
high order. Your new or enhanced system should make it easy to
receive and reply to any inter-personal messages that are sent and
linked to a bid (that is, an SMTP/MIME message or the EDI X12.864
text message transaction set).
4.6. Does this mean that I'll receive more messages ?
There is a strong likelihood the number of messages will increase as
There is a strong likelihood the number of messages will increase as
you reach more and more trading partners. After a reasonable trial
period, your EDI trading partners should be relying on EDI and
disinclined to use alternative forms of communication that don't fit
EDI/EC. Once you use EDI/EC to communicate with a trading partner,
you should consider discouraging the use of telephone calls or fax
messages or other non-EDI/EC messages by pointing out the fact that
telephone or fax messages are processed more slowly. By using
electronic messaging, you can establish a written and dated audit
trail. Your application system can route the message to the buyer
and "attach" it to a "case file". However, if your organization does
not use automated systems, you will want to adjust your approach to
dealing with non-EDI messages.
4.7. If we see a transaction posted on VAN, how do we respond in
electronic format ?
This function is typically handled by applications software, not by
the Internet. For example, a vendor that wishes to bid on a
particular Request For Quotation (RFQ) would prepare a bid (X12-843)
and send it via their VAN of choice. The identification information
in the interchange control header (ISA) and functional group header
(GS) will be interpreted by your VAN and forwarded to the buyer's VAN
or to the buyer directly, depending on the reply address. VANs may
reject messages from unregistered sources; otherwise they are
forwarded to (or otherwise made available to) the buyer. If a buyer
is using dial-up access to a VAN, then they will have to call-in for
their messages.
4.8. My organization has an established bilateral relationship
(such as an existing contract. Can we send these transaction
via the Internet ?
Yes, the Internet can be used to send transaction sets to existing
trading partners via SMTP or FTP messages. VANs were typically used
for bilateral relationships between companies, whereas the Internet
is useful for establishing multilateral relationships. These
bilateral relationships are usually quite stable, but both parties
had to agree to share the same VAN or get their VANs to interconnect.
Multilateral relationships are between organizations that don't
necessarily have existing relationships and may be rather ephemeral.
The Internet is suited to dynamic multilateral relationships that may
later evolve into static bilateral relationships between companies
using VANs. Therefore, the issues concerning the Internet (security,
availability, etc.) are manageable in the early stages of forming a
relationship. If your current VAN is not capable of using the
Internet, you may need an alternative route for those messages.
Later, as the business relationship matures, the use of VANs may be
appropriate as the level of communication becomes more important.
For example, unless your system has a directory of all registered
trading partners, you lack the capabilities to screen and validate
transactions that arrive at your site.
5. The Role Of Value Added Networks
5.1. What is a VAN?
The use of EDI over the Internet is in the early stages, although the
technology and services are developing remarkably rapidly. In the
past, organizations doing EDI typically have relied on specialized
firms called Value Added Networks (VANs) for technical assistance.
Many of these organizations will look to their VAN for assistance in
using the Internet. VANs specializing in EDI applications provide
technical support, help desk and troubleshooting for EDI and
telecommunications problems. They assist in configuration of
software, upgrades to telecommunications connectivity, data and
computer security, auditing and tracing of transactions, recovery of
lost data, service reliability and availability. Some EDI specific
services can include broadcasting an RFQ to a collection of vendors,
or storage of EDI information for later search and retrieval.
5.2. What is an Internet Service Provider (ISP)?
VAN services have typically used proprietary network or a network
gatewayed with a specific set of other proprietary networks. In
contrast an Internet Service Provider (ISP) offers generic network
access (i.e. not specific to EDI) for all computers connected to the
internet. A direct internet connection permits real time computer-
computer communication for client-server applications.
Alternatively, a part time internet connection can be used to access
internet servers using an on-demand basis, or access another system
via email which includes a store and forward method. Internet email
may be used as a gateway to proprietary networks if the proprietary
network has an email gateway.
5.3. How might an ISP be used for EDI?
Internet email can be configured for a dedicated connection with
real-time transfers, or a store and forward method (like traditional
VANs), or a combination of the two, e.g. where a direct delivery to a
trading partners system is used when a link is operational, and a
store and forward from an ISP is used as a backup.
A large organization can connect their network to the Internet at an
internet exchange point, however, most use a commercial ISP, either a
major backbone provider, or local resellers of service off one or
more backbones. The ISP provides technical assistance and access to
local telecommunications links.
5.4. Doesn't EDI presume the services of companies called
Value Added Networks (VANs)?
EDI only specifies a format for business information; the
transmission of the information is covered under other standards. A
real world analog is sending a business form from one company to
another. The "form" could be sent via US mail, US Registered mail,
via private carrier (UPS/FEDEX) or simply faxed between the
companies. EDI only requires that the trading partners follow the
content standards.
5.5. If I can use X12 protocol and my VAN to send transactions,
what is the benefit of using the Internet?
The Internet E-mail standards have hierarchical address spaces that
are defined and updated in what the Internet calls "domain name
servers." Unfortunately, X12 has a flat address space. So, when you
send an interchange (not via the Internet) to a partner who is on a
different VAN, your VAN must do a table look up to figure out what
VAN the receiving party is on. If you use only X12 without the
Internet, before you can send a message to this partner, you must
first contact the recipient's VAN and have them add you as an entry
to his VAN's table. If the ISA contained the VAN ID of the
recipient, then you could (in theory) send interchanges to partners
via the VAN interconnects without having to notify the recipient's
VAN first. However, this theory needs to be worked out in practice.
In contrast, thanks to the domain name service, Internet e-mail users
(and Postal users) don't have to call up their service provider
before sending a message across an "interconnect" to another service
provider.
5.6. Can we expect VANs to offer connections to other VANs via the
Internet?
All VANs connected to the Internet are connected to one another, thus
avoiding most of the problems of interconnecting proprietary
networks. VANs can then focus on services to their customers such as
automatic bid submission, market and business opportunity analysis,
and translation software.
5.7. How can I use the Internet directly for exchanging EDI messages
without going through a VAN?
You and your trading partner must agree on one of the Internet
protocols for exchanging messages and then agree upon some details
with the exchange.
a) Email based messaging
The simplest and most widely supported means of exchanging
messages is via internet email. Typically, the IETF-MIME
encapsulation specification would be used to enclose the EDI
data within the email message, and the trading partners would
need to agree upon an encryption method for secure email,
typically PEM or PGP (see question 8.4).
The trading partners would then exchange:
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.
A convention for naming email addresses might be
established, e.g. edi@edi.xyzcorp.com for messages,
ediinfo@xyzcorp.com for an automated response for human readable
information on establishing internet EDI, and
edisupport@xyzcorp.com for a personal contact.
b) FTP based messaging
To exchange EDI messages via FTP, some setup information must be
included in the trading partner agreement. Typically, an account
would be created for each trading partner for a FTP login,
including a password. Typically, each X12 or EDIFACT message
would be stored in a file, and the trading partner agreement would
define the conventions for naming files and directories for
the messages.
The trading partner agreement would include:
1. FTP login name and password
2. Machine(s) from which the login will be accepted
3. Additional security protocols, e.g. Kerberos[?]
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.
There are several compression routines and utilities available for
virtually any computer system that uses the Internet. Many of these
utilities will convert across platforms (say UNIX to Mac, UNIX to PC,