Network Working Group W. Houser Request for Comments: 1865 Dept. of Veterans Affairs Category: Informational J. Griffin Athena Associates C. Hage C. Hage Associates January 1996
Frequently Asked Questions about
Electronic Data Interchange (EDI) on the Internet
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.
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.
1. Introduction
1.1. What is this document
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 ? .. 41.4. To whom do I send comments and suggestions ?
2.9. Where can I get general information about the Internet? . 83. Getting Connected To The Internet
7.6 Where can I get information on EDI translationsoftware ?
8. Security Considerations
8.1. What security measures are needed to connect to the
Internet ?
8.2. How do we go about protecting our system ?
8.3. Is there good publicly available software I can use?
8.4. How good are electronic or digital signatures ?
Can they be used in court ?
8.5. Are there other US government standards publications
I should be aware of?
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.
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.
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.
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.
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 RFC is:
ftp://ds.internic.net/rfc/rfc1865.txt
RFC directories are located at:
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.
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.
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.
The greatest benefits will derive from:
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.
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.
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.
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.
RFC stands for Request For Comments. The RFC series 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/
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:
RFC 1175
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
RFC 1463
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.
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.
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.
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:
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
related to 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:
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, and vise versa) and are available for free from one of several ftp archive servers. Use of these compression routines should be used with care when one is employing an encryption technique such as PEM or PGP.
Yes, although the ISA06 and ISA08 elements are supposed to be used to identify the sender and receiver of the interchange, the receiver of the interchange could be a clearinghouse (as well as a VAN) that
processes the interchange and then forwards the data to the ultimate recipient. In this case, you could put the receiver ID of the clearinghouse into the ISA08. The clearinghouse would probably have to determine the ultimate recipient of the message by looking inside the transaction set (or perhaps by using the GS03). Alternatively, you could put the receiver ID of the ultimate recipient into the ISA08 and the clearinghouse would route the interchange based on the ISA08 value (just as a VAN does).
There was an X12 DM (data maintenance) request proposed to the X12 standards committee for a change to the ISA segment (X12 header information) that would allow users to specify the recipient's VAN, in addition to the recipient's ID. The intent was to provide a hierarchical address in the ISA. The top level would be the VAN ID, and the next level would be the recipient ID. To date, this DM has not been approved.
Yes, the GS02 and GS03 data elements can be used for a second level of routing. The GS03 is the application receiver's code. Some EDI users use the GS03 for routing a functional group to a particular department or application within the receiver's corporation. For example, you could use the ISA08 to identify the receiver as "Acme Corporation" and use the GS03 to identify the receiving application as the "Purchasing department (within Acme Corporation)". Many EDI users simply put the same value in the ISA06 and the GS02, and put the same value in the ISA08 and the GS03. Interestingly, there are VANs that will broadcast a message. Other VANs will map the value of the ISA08 into a distribution list VAN mailbox ids maintained by the VAN. Thus, each recipient receives the exact same copy of the interchange and the value of the ISA08 is not changed by the VAN.
In the Federal Information Processing Standard (FIPS) 161-1 for Electronic Data Interchange[2], the US Government committed to using EDI X12 and EDIFACT standards in the exchange of business information with trading partners already using EDI. On October 26, 1993, President Clinton signed an Executive memorandum requiring Federal agencies to implement the use of electronic commerce in Federal purchases as quickly as possible. As the initial step the President's Management Council (PMC) Electronic Commerce Task Force
(ECTF), chaired by the Administrator, Office of Federal Procurement Policy (OFPP), chartered the Federal Electronic Commerce Acquisition Team (ECAT) memorandum. The PMC gave ECAT the task of defining the architecture for the government-wide electronic commerce acquisition system and identifying the executive departments or agencies responsible for developing, implementing, operating, and maintaining the Federal electronic system.
ECAT has become the Federal Electronic Commerce Program Management Office (ECA-PMO). The National Institute or Science and Technology (NIST) maintains an HTML home page for the ECA-PMO:
http://snad.ncsl.nist.gov/dartg/edi/fededi.html
1) By March 1994, define the architecture for the
government-wide EC acquisition system and identify
executive departments or agencies responsible for
developing, implementing, operating, and maintaining
the Federal electronic system. The ECAT identified
the architecture and recommend actions that each agency
should take. These documents are available via ftp at
ds.internic.net in the directory /pub/ecat.library.
ftp://ds.internic.net/pub/ecat.library/
2) By September 1994, establish an initial EC capability to enable the Federal government and private suppliers to exchange standardized requests for quotations (RFQs), quotes, purchase orders, and notice of awards and begin government-wide implementation.
3) By July 1995, implement a full-scale Federal EC system that expands initial capabilities to include electronic payments, document interchange, and supporting data bases.
4) By January 1997, complete government-wide implementation of EC for appropriate Federal purchases, to the maximum extent possible.
According to the ECAT, achieving the following objectives are essential for a successful ubiquitous government EDI capability:
1) E-mail systems may be used as the transport medium for EDI transactions.
2) FTP, FTAM, SMTP, X.400, or X.400 compatible substitutes are the preferable transport methods for EDI.
3) EDI functionality must be supported such that the user can choose between the Internet Protocol Suite (IPS) and Open Systems Interconnection (OSI) protocol support.
4) Directory services will be provided through the X.500 model as services become available.
5) Initial implementation of X.400 shall support the user agent services defined in P2 and P22 protocols.
6) By 1996, the X.400 implementations shall contain the services defined in the X.435 specification.
7) The Internet network may be used for EDI transactions when it is capable of providing the essential reliability, security, and privacy needed for business transactions.
The Internet contains many Internet Service Providers (ISPs), each with its own internal policies governing the conduct of its customers. One of the largest ISPs is the National Science Foundation. At one time, NSF adopted what is called the Acceptable Use Policy of the National Science Foundation (NSF) was intended to prevent commercial uses of the original NSF-sponsored Internet telecommunications backbone. However, the growing number of commercial providers and backbones now part of the Internet have made this policy obsolescent. NSF is currently reducing its direct support in favor of subsidies to universities and other NSF sponsored organizations. Today the US Government is actively encouraging commercial uses of the Internet.
For more than a decade, Federal policy has been to promote the Open Systems Interconnection (OSI) telecommunications protocols developed by international standards bodies. Despite this policy, Government agencies, like the private sector, have invested far more in Internet than OSI compliant products. Marshall T. Rose's "The Internet Message"[3] compares the two alternative protocol suites and finds
clearly in favor of the IPS for messaging in general. For EDI specifically, the advantages of the IPS are its simplicity, wide availability, and security provided by Privacy Enhanced Mail (PEM, see below). IPS lacks a number of desirable features and incurs something of an efficiency penalty for binary transfers. On the other hand, the OSI standard for messaging handling service (X.400) promises a complete solution for EDI; the X.435 protocol includes responsibility notifications, X.500 directory support, EDI-specific addressing, message store support, message security, and other EDI- specific services. Unfortunately, only a handful of X.435 products have actually reached the market, their interoperability is not assured, and their prices are substantially greater than for their IPS counterparts. X.400 addressing tends to lock the customer into the domain of the service provider, whereas SMTP/MIME addresses are independent of the provider, permitting the customer to take his/her business elsewhere relatively easily. The bottom line is that a lot more organizations do EDI via the Internet than via OSI.
Presently, VANs make EDI request for quotation (RFQ) transactions available to their subscribers (along with other services). For example, a VAN client may ask that all RFQs for chairs be forwarded immediately to them but the client is not interested in being notified about RFQs for paper products. When a VAN sends an RFQ to a specific client mailbox, the VAN modifies the "to address" to that of the client. In this way, a vendor need only subscribe to a VAN that is certified to receive and post the RFQs. The vendor then sees a single source for all RFQs of interest, regardless of which buying organization originated them. The screening and filtering process performed by the VANs prevents the spread of electronic "junk" mail. However, a trading partner could use an email filtering program to filter and sort email, saving on VAN charges.
Initially, very few changes may be apparent. New and existing VANs will use the Internet to collect and disseminate EDI transactions; trading partners may be totally unaware of the change in technology. Prices may fall as VANs share telecommunications resources through Internet Protocols rather than maintain their own costly proprietary telecommunications services. Instead of competing with VANs, the ubiquitous connectivity of the Internet offers VANs even greater business opportunities. General purpose Internet Service Providers (ISPs) do not typically offer EDI specific services, but they can provide an alternative means to transfer EDI messages at a small
fraction of the cost of typical EDI VANs.
The impact of an organization's moving EDI onto the Internet, independent of a VAN, is more difficult to assess. In the view of some, the introduction of the Internet in the near term (1-5 years) adds additional interfaces and complexity to the organization's existing EDI environment. This may in the short term increase costs and raise new costs. But a corporate commitment to an open systems environment through the use of Internet Protocols offers the potential for a greater interoperability, integration of application systems, and therefore the promise of higher performance and lower costs. Some organizations will be able to get to these benefits others will pay for a set of largely incompatible services. The return on investment largely depends on one's ability to consider EDI on the Internet as a part of the organization's overall information systems strategy and the organization's plans for a presence on the Internet.
The Data Interchange Standards Association (DISA) has a World Wide Web server at "http://www.disa.org/" This Web server has considerable information, including a list of new standards, a list of all the X12 transaction sets, meeting minutes, calendar of events, and lists of courses. Unfortunately, as of this date, the X12 standards are not available electronically. [soap ...] Hopefully that will be added soon. [...soap]. DISA has also set up a gopher server (gopher.disa.org) and an FTP server (ftp.disa.org).
The principle documents regarding ANSI ASC X12's planned alignment with EDIFACT are available on the World Wide Web. The alignment plan adopted by a mail ballot of X12 in December 1994/January 1995 is at
http:/www.disa.org/info/alinplan.html
The "floor motion" adopted at the X12 meeting in February 1995 is at:
http:/www.disa.org/meetings/alinmotn.html
The following mail lists and exploders support X12 and EDIFACT standards development work.
------------------ X12G Mailing list: ------------------
This is a fully open exploder set up to support X12G.
To subscribe send an e-mail message to:
x12g-request@snad.ncsl.nist.gov
The text of the message should only contain the following:
subscribe x12g
After you subscribe, you can broadcast your messages to the participants (who have subscribed) via the address
x12g@snad.ncsl.nist.gov.
--------------------- FED-REG Mailing list: ---------------------
This new exploder is concerned with the federal EDI Registry and the implementation of IMPDEF within the registry, the EDI Viewers and Editors, and the use of IMPDEF to upgrade EDI products. The nature of this mailist calls for informal discussion focusing on pragmatic issues.
To subscribe send an e-mail message to:
fed-reg-request@snad.ncsl.nist.gov
The text of the message should only contain the following:
subscribe fed-reg
Messages intended for the fed-reg list should be sent to:
fed-reg@snad.ncsl.nist.gov
------------------------- X12C-IMPDEF Mailing list: -------------------------
This exploder deals with formal discussion in the context of X12 regarding the evolution of IMPDEF. If would expect that discussions in the context of the "fed-reg" exploder result in
formal DMRs submitted to "x12c-impdef" and X12C. Anyway, the process will be defined and controlled by the appropriate X12C authority.
To subscribe send an e-mail message to:
x12c-impdef-request@snad.ncsl.nist.gov
The text of the message should only contain the following:
subscribe x12c-impdef
Messages intended for the fed-reg list should be sent to:
x12c-impdef@snad.ncsl.nist.gov
See section 7.7 for additional EDI related mailing lists.
You can access the EDIFACT standards via GOPHER from the
International Telecommunications Union (gopher://info.itu.ch). Here
are the general directions in getting to the standards.
If you want the actual standards, select 1, Drafts. You will get
D93A (which becomes the standard S94a)
D94A (which will be next year's standard).
If you want the UNTDED, select 2. If you want the UNTDID, select 3. When you get to the lowest level directory in which ever path you choose, press D (i.e. upper case D) to download. Choose the protocol that suits and you are the proud owner of an EDIFACT Standards Directory.
For electronic mail retrieval, send your message to itudoc@itu.ch with no subject and the following message body:
START
GET ITU-1900
END
There are a number of generic implementation conventions (ICs) or guidelines; most ICs are prepared on an industry-by-industry basis. Be sure that both you and your current trading partners are working from the same set. The Federal Electronic Commerce for Acquisition Program Management Office has been promoting the 3040 version throughout the government and the private sector. Older versions may be used in accordance with the ASC X12 rules. Certain ICs are published by the Data Interchange Standards Association (DISA); contact DISA at the address above for information about ICs for your applications. Certain ICs as well as the X12 standards may be obtained through:
Washington Publishing Company
c/o EDI Support Services
US Phone (800) 334-4912 Non-US Phone (216) 974-7650 Fax (216) 974-7655
The US. Federal Implementation Guidelines for Electronic Commerce for Acquisition are available for free via FTP at ds.internic.net. These cover X12 transaction sets 810, 820, 824, 836, 838, 840, 843, 850, 855, 864, and 997. The path is pub/ecat.library/fed.ic/xxx where xxx can be acrobat.pdf, postscript or ascii file formats.
ftp://ds.internic.net/pub/ecat.library/fed.ic/
The SPEEDE/ExPRESS Project, funded by the National Center for Education Statistics of the U.S. Dept. of Ed., publishes an Implementation Guide for X12 transaction sets 130, 131, 146, 147, and 997. The July 1994 versions (each in WordPerfect and in Postscript) may be retrieved by anonymous FTP at admissions.carleton.ca. The WordPerfect 5.1 files are found in /pub/wp_speede_2 while the Postscript files are found in /pub/ps_guide_2.
ftp://admissions.carleton.ca/pub/wp_speede_2/ ftp://admissions.carleton.ca/pub/psguide_2/
Complete directions for retrieving these files can be found in the AACRAO gopher at AACRAO-DEC.NCHE.EDU. Choose the SPEEDE/ ExPRESS
menu item, then Publications, and then select a version of the Implementation Guide. Note that guidelines are sometimes referred to by the release/version designation (currently 3040).
The Defense Information Systems Agency (DISA) Center for Standards is
the designated configuration manager for DoD Electronic
Commerce/Electronic Data Interchange (EC/EDI) standards. The DoD
EC/EDI Standards repository system, available via anonymous FTP from
ftp.sterling.com in the /edi/DoD-edi/ directory, contains DoD EDI ICs
separated into two categories, User and Test.
ftp://ftp.sterling.com/edi/DoD-edi/
Test conventions are identical to User, except that the condition designator for all applicable transaction sets, data segments and data elements used by that convention are designated as Mandatory for test purposes. Implementation convention files, both user and test versions, can be downloaded either individually or all together in compressed self-extracting files. All the implementation files are available, when decompressed, in both WordPerfect 5.1/5.2 (.WP) file format and Standard Exchange Format (SEF) test files which are for use with EDISIM software or any other EDI software that conforms with the EDISIM .SEF file format.
The /DoD-edi/2003_User & _Test directories contain draft DoD Implementation Conventions based on ANSI X12 Version 2 Release 3 (2003):
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
997 Functional Acknowledgement
The /DoD-edi/3010_User & _Test directories contain draft DoD Implementation Conventions based on ANSI X12 Version 3 Release 1 (3010):
810 Invoice:
810 Commercial
810 Progress Payment
810 Public Voucher
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
997 Functional Acknowledgement
Additional 2003 and 3010 based conventions may be added in the near future. 3010 based conventions will never progress to approved
status but will be used temporarily by various DoD agencies to implement phase I of the DoD Electronic Commerce (EC)/Electronic Data Interchange (EDI) in Contracting Report.
The /DoD-edi/3050_User directory contains draft DoD Implementation Conventions based on ANSI X12 Version 3 Release 5 (3050):
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
855 Purchase Order Acknowledgement
860 Purchase Order Change Request - Buyer Initiated
865 Purchase Order Change Acknowledgement/Request - Seller
Initiated
Note that the ICs in the /DoD-edi/3050_USER directory were developed as a means to express DOD requirements for an ANSI X12 3050 based transaction set. They are not approved for implementation. They have been submitted to the Federal IC configuration management process for adoption throughout the federal government. Since they are subject to Federal review and are based upon a standard not yet released, changes can be anticipated. (See ECA PMO above)
The US government is trying to standardize electronic communications internally and with it's 300,000 plus suppliers. This requires standardization of the standards process and cross communication between programs. The IMPDEF message and the NIST Federal IC Registry will place electronic versions of all its ICs on the Registry - both full federal ICs and individual agency ICs - so that any trading partner can download and use them. In combination with message data compliance checking as well, smaller firms should be able to get into EDI and start benefitting both themselves and the government.
Several commercial trade magazines publish periodic guides to EDI translation software. Under commission by the US Government, the Logistics Management Institute (LMI) of McLean, Va. published "A Guide to EDI Translation Software, 1994 Edition." The guide describes the features and characteristics of EDI software offered by more than 60 vendors. Commercial organizations can get copies for $20 each by sending a check made out to the Logistics Management nstitute. Federal agencies may have up to five free copies by sending requests to
Logistics Management Institute
Attn. Library
2000 Corporate Ridge
McLean, Virginia, 22102-7805
You can fax a typed request to the LMI library at (703) 917-7597 or send a request to library@lmi.org. Requests for hard copies of the Guide must include the requester's name, organization, address, telephone number, and number of copies desired. All requests should cite Report IR421RD1. If you have questions about the Guide, you can contact the author, Harold Frohman, at (703) 917-7286 or send him an Internet message at hfrohman@lmi.org. A somewhat older LMI report (1992), but still quite relevant, is EDI Planning and Implementation Guide (DL204RD1, August 1992).
There are several EDI related mailing lists on (and off) the Internet. Information on subscription follows below.
---------------------- IETF-EDI Mailing list: ----------------------
The IETF-EDI list has been established as a forum for discussing methods of operating EDI transactions over the Internet, and for discussing specifications which permit such operation. This list is therefore focused on the technology of Internet usage of EDI, rather than on more general aspects of EDI technology or use.
To subscribe, send an e-mail message to:
LISTSERV@BYU.EDU.
The text of the message should only contain the following:
sub ietf-edi <your-name>
Messages intended for the ietf-edi list should be sent to:
IETF-EDI@BYU.EDU.
------------------- EDI-L Mailing list: -------------------
The EDI-L list is target towards more general EDI discussions. The edi-l mailing list is also gatewayed to the USENET newsgroup bit.listserv.edi-l.
To subscribe, send an e-mail message to:
listserv@uccvma.ucop.edu
The text of the message should only contain the following:
subscribe edi-l <your-name>
Messages intended for the edi-l list should be sent to:
EDI-l@uccvma.ucop.edu
--------------------- EDI-NEW Mailing list: ---------------------
This list complements ietf-edi in the sense that it promotes discussion of new approaches to edi and the extension of edi beyond its traditional domains.
To subscribe, send an e-mail message to:
edi-new-request@tegsun.harvard.edu
The text of the message should only contain the following:
subscribe edi-new <your-name>
Messages intended for the edi-new list should be sent to:
edi-new@tegsun.harvard.edu
---------------------- SPEEDE-L Mailing list: ----------------------
The main purpose of this list is for discussions of Educational EDI Standards.
To subscribe, send an e-mail message to:
listserv@vtvm1.cc.vt.edu
The text of the message should only contain the following:
SUBSCRIBE SPEEDE-L firstname lastname
Messages intended for the speede-l list should be sent to:
speede-l@vtvm1.cc.vt.edu
---------------------- OPEN-EDI Mailing list: ----------------------
The main purpose of this list is for UN/EDIFACT users to review the work of JTC1/SC30.
To subscribe, send an e-mail message to:
majordomo@utu.premenos.com
The text of the message should only contain the following:
subscribe open-edi
Messages intended for the open-edi list should be sent to:
OPEN-EDI@utu.premenos.com
------------------ ECAT Mailing list: ------------------
The Federal Electronic Commerce for Acquisition Team (ECAT) has established an open mail list for those interested in ECAT activities.
Information sent to the forum address is automatically distributed to all forum members. This forum is available 24 hours a day, 7 days a week. Currently, only ASCII text messages up to 250kb are supported. For best results when sending messages to this forum, each line should be limited 70 characters followed by a carriage return. Also, your name and email address should be included in the body of messages sent.
To subscribe, send an e-mail message to:
listserv@forums.fed.gov
The text of the message should only contain the following:
subscribe ecat firstname lastname
Messages intended for the ECAT list should be sent to:
ECAT@forums.fed.gov.
Yes. Messages that have appeared on the ecat, edi-l, edi-new, fed- reg, x12c-impdef and ietf-edi list are available via FTP from
ftp://ftp.sterling.com/edi/lists/
If you have an existing Internet connected site, you can make the information available via FTP or WWW. If you do not wish to go to the effort, send mail to Kent Landfield at
edi-archive@sterling.com
Sterling Software is making the archive publicly available to the community. Anyone who wants to distribute EDI related documents may contact Sterling to make your documents publicly available on ftp.sterling.com. For example, the Department of Veterans Affairs has posted numerous studies and training materials on EDI which are available to the public at ftp.sterling.com/edi/va/.
Some have been discussed previously while others have not. Here is a very incomplete list of sites that archive EDI related material and
make that information publicly available.
Internet security measures can be placed in two broad categories: protecting your system from intruders and protecting the content and integrity of your messages. With respect to the latter, EC/EDI transactions of nominal value and sensitivity do not require special security requirements. However, if the information has any sensitive aspects, you will need to take measures discussed below. Competitors might intercept your bids and undercut your proposal. Or they could monitor your purchases and shipping notices to determine your firm's production capacity. To ensure confidentiality of the message, your e-mail system should offer some means of encrypting the message in a manner only the intended recipient can read. Trading partners are responsible for satisfying existing rules and regulations relating to computer security and privacy. For example, bid data received by government systems is subject to the appropriate controls. Trading partner financial account data is likewise subject to disclosure restrictions. To thwart those who might tamper with a message to divert delivery by changing the "ship-to" address, digital signatures can attest to the integrity of the message. Digital signatures can also authenticate messages, preventing pranksters or rivals from submitting false orders.
The weakest link in most systems are people and passwords; your current practices for managing both will apply to use of the Internet. Steps you can take include:
These are several free, publicly available, security tools one can obtain via ftp from one of many good archives. If your company uses UNIX systems to connect to the Internet or has UNIX systems connected to the Internet get and use the following tools:
These tools are a series of scripts and programs that will alert you to many well-know problems and holes in UNIX systems and how to fix them.
The Computer Emergency Response Team (CERT) at Carnegie Mellon University can assist with computer break-ins as well as provide notices of security activity on the Internet. The US Department of Energy's Computer Incident Advisory Capability (CIAC), located at Lawrence Livermore National Laboratory, can provide assistance at ciac@llnl.gov or at 510-422-8193. CIAC offers software and documents on their anonymous ftp server at ciac.llnl.gov. Both CERT and CIAC are members of the Forum of Incident Response and Security Teams (FIRST), a global organization to foster cooperation and coordination among computer security teams worldwide.
Properly used, these signature systems are better than existing paper
based authentication and forgery detection technology. You will find
a clear and concise description of how these signatures work in Gary
Ratterree's RIPEM Beginner's Guide; contact Ratterree at
grayr@cs.tamu.edu. Other references include:
ftp://ftp.tis.com/pub/PEM/ for Privacy Enhanced Mail ftp://ftp.rsa.com/ for PEM ftp net-dist.mit.edu:/pub/PGP for Pretty Good Privacy (PGP)
An "infrastructure" for public keys is not required to use public key encryption or digital signatures. In the absence of such an infrastructure, the encryption protocol and the public keys would need to be exchanged bilaterally, such as part of the trading partner agreement. A public key infrastructure would provide a secure means to obtain a public key without a need for a manual key exchange.
But digital techniques will become more convenient with the arrival of additional infrastructure and support systems. The US government is taking steps to ensure the admissibility in court of such systems. We anticipate that the necessary regulatory and legal infrastructure will be in place about the same time as the necessary directory and certificate services and other supporting systems come on-line. We expect to see expansion of several government pilot programs in the later half of 1994. NIST recently published a report on the Public Key Infrastructure (PKI) and related policy issues; for information contact the NIST Computer Security Division at 301-975-2934.
Yes. Here is a sample of those you will often hear mentioned.
The FIPS standards may be ordered from the
[1] UN/EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) Syntax Rules (ISO 9735), March 1993, United Nations Economic Commission for Europe (UN/ECE), Working Party for the Facilitation of International Trade Procedures (WP.4)
[2] FIPS Publication 161-1, Electronic Data Interchange (EDI), National Institute of Standards and Technology, April 1993.
[3] The Internet Message: Closing the book with electronic mail, Marshal T. Rose., Prentice Hall, Englewood Cliffs, New Jersey, 1993.
[4] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for the Secure Operation of the Internet", RFC 1281, Software Engineering Institute, Trusted Information Systems, Inc., Software Engineering Institute, November 1991
[5] Firewalls and Internet Security - Repelling the Wily Hacker,
by Cheswick and Bellovin, Addison-Wesley, 1994,
ISBN 0-201-63357-4
[6] There Be Dragons, S. Bellovin, Proceedings of the Third Usenix UNIX Security Symposium, Baltimore, Maryland, September 1992. USENIX Association, ISBN 1-880446-46-4
James A.(Artch) Griffin <artch@AGRIFFIN.CPCUG.ORG> is credited with co-authorship as he prepared the ECAT FAQ which I used (or perhaps abused) as the base document. Artch was judicious and patient as he watched his original text being rewritten over and over.
Carl Hage contributed detailed explanations and clarifications of the various Internet protocols and services and how EDI can employ them.
I would like to thank the following people for their comments and specific contributions: Kent Landfield, Mike Bauer, Kit Lueder, Eric Christ, Betsy Bainbridge, Bob Lyons, Kirby Spencer, Sally Hambridge, Ed Levinson, Warren Smith, Steve Bass, Jerry Johnson, Randy VandenBrink, John Pillay, Jim W.C. Smith, Mark Charles, Jean- Philippe Favreau. I apologize if I omitted any one of the many folks who responded to my many calls for comments.
I greatly appreciate Kent Landfield for his editorial assistance during final preparation of this document. Sterling Software graciously hosted the work in progress for ftp access and review, saving many bits of Internet SMTP traffic.
Finally, I am grateful for the patient cooperation of the IETF Working Group and the participants of the IETF-EDI and EDI-L lists. It's a nice cyberplace to work!
WRH, Washington, DC.
Walter Houser
Department of Veterans Affairs
810 Vermont Avenue
Washington DC, 20240
Phone: 202-786-9572
EMail: houser.walt@forum.va.gov
houser@cpcug.org
http://www.va.gov/
James A. (Artch) Griffin
President, Athena Associates
18924 High Point Drive
Gaithersburg, Maryland 20879
Phone: 301-972-2502
EMail: agriffin@cpcug.org
Carl Hage
EMail: carl@chage.com
http://www.chage.com/chage/