FAQ Electronic Data Interchange on the Internet

A. This is the current draft of an informational RFC to answer frequently asked questions about 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. Some understanding of EDI is assumed. Readers are invited to add questions that need to be answered; include an answer if you know or want to suggest one. Of course corrections and comments are welcome; send them to houser.walt@forum.va.gov.

A. It is the interworking 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. Messages may be interpersonal (persontoperson) EMail or process to process EDI. Messages may be inquiries to shared databases and responses. Messages may be entire files.

A. Electronic Data Interchange (EDI) is defined as the interprocess (computer application to computer application) communication of business documents in a standardized electronic form. Electronic Commerce includes EDI, but recognizes the need for interpersonal (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.

A. 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. 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 single 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.

A. The greatest benefits will derive from: . Adoption of common standards and proven interoperable systems. . Adoption and deployment of a distributed Directory Service capability. . Explicit commitment by participating organizations to cooperatively route traffic, work to resolve addresses, and meet required standards.

A. The specific requirements are dependent on your choice of connectivity solutions and service provider offerings. The following provides a general overview of options now available: a) Internet Simple Mail Transfer Protocol. Companies with existing connectivity to the Internet may use SMTP to transfer EDI transaction to their VAN who will provide the Internet IP address, userid, and security procedures. This solution requires TCP/IP as support layers for the SMTP application. The Post Office Protocol (POP) is used to hold messages until one can connect to the Internet; POP is recommended for sites with intermittent connectivity to the Internet. (See (d) Dialup Connections.) b) Internet File Transfer Protocol (FTP). Companies with existing connectivity to the Internet may use FTP to transfer flatfiles to their VAN who will provide the Internet IP address, userid, and security procedures. This solution requires TCP/IP as support layers for the FTP application. c) Mosaic and Hypertext Markup Language provide a Graphical User Interface (GUI) that facilitates user access to information on the Internet. Mosaic provides a graphical interface to the World Wide Web (WWW) and hypertext based information, 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) Dialup Connections are easier to install but slower and less convenient. Internet Service Providers (ISP) and VANs typically support the following dialup solutions: 1. XMODEM This protocol is supported by most dialup communications software packages (e.g., Procomm, Crosstalk, etc.) for file transfers. ISP and VANs give their customers the necessary telephone numbers, userids and passwords. 2. UUCP UNIX to UNIX Copy provides dialup file transfers between UNIX hosts. UUCP can be used to transfer EDI transactions. 3. SLIP or PPP dialup connections using 14.4 or 28.8 modems or ISDN will allow you to use more sophisticated applications such as gopher, WAIS, or Mosaic, which are not possible with most dialup connections.

A. You need to know your existing telecommunications connectivity, address resolution, and routing capabilities. Then you need to establish and operate an EMail 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 Email or FTP.

A. 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 email system so that you can handle your own EDI transactions.

A. Presently, companies called Value added networks (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.

A. In many instances, 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. Except that prices will fall as VANs share telecommunications resources through Internet Protocols rather than maintain their own costly proprietary telecommunications services.

A. 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.

A. Yes, but that puts you in the role of being your own VAN. By acting independently, organizations have established their own dialup 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.

A. 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 EDIspecific agreements.

A. 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 reengineered 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).

A. There is a strong likelihood communications 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 nonEDI/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 nonEDI messages.

A. For EC/EDI transactions of nominal value and sensitivity, there are no special security requirements. Trading partners are responsible for meeting 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.

A. 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 (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 dialup access to a VAN, then they will have to callin for their messages.

A. 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 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; the introduction of VANs may be appropriate afterwards and the level of communication becomes more important. 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. If your current VAN is not capable of using the Internet, you may wish to consider an alternative route for those messages.

A. You should be looking to enhancing 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.

A. The Logistics Management Institute (LMI) of McLean, Va recently 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 Institute. Federal agencies may have up to five free copies by sending requests to Logistics Management Institute, Attn. Library, 2000 Corporate Ridge, McLean, Virginia, 221027805. You can fax a typed request to the LMI library at (703) 9177597 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) 9177286 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).

A. There are a number of generic implementation conventions (ICs) or guidelines; most ICs are prepared on an industrybyindustry 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. X12 standards are published by DISA and may be obtained through EDI Support Services, PO Box 203, Chardon, OH 440240203, fax (216) 9747655 or phone (800) 3344912.

A. The US. Federal Implementation Guidelines for Electronic Commerce for Acquisition, are available for free via FTP at DS.INTERNIC.NET. These cover 810, 820, 824, 836, 838, 840, 843, 850, 855, 864, and 997. The SPEEDE/ExPRESS Project, funded by the National Center for Education Statistics of the U.S. Dept. of Ed., publishes two versions of the Implementation Guide for TSs 130, 131, 146, 147, and 997. These 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/speede. The Postscript files are found in pub/psguide. Complete directions for retrieving these files can be found in the AACRAO gopher at AACRAODEC.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).

A. It is wise to be concerned. As the weakest link is people and passwords, your current practices for managing both will apply to use of the Internet. Steps you can take include: Obtain, study, implement, and enforce the NIST FIPS (112) on passwords. Make the practice of safe computing a condition of continued employment and let your staff know it. Conduct a risk assessment as described in Appendix M of Streamlining Procurement Through Electronic Commerce. Look to the ECAPMO for further guidance. Apply the recommendations from NIST Special Publication 8009, Good Security Practices for Electronic Commerce, Including Electronic Data Interchange as appropriate. Establish necessary internal and external "Firewalls" Review RFC 1281 Guidelines for the Secure Operation of the Internet Firewalls and Internet Security Repelling the Wily Hacker, by Cheswick and Bellovin, AddisonWesley Consider implementing active countermeasures in your firewalls. See "There Be Dragons" by S. Bellovin, Proceedings of the Third Usenix UNIX Security Symposium, September 1992. You can contact Bellovin at smb@ulysses.att.com.

A. 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. However, digital techniques will require additional infrastructure and support systems. The 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 online. We expect to see expansion of several government pilot programs in the later half of 1994. Source material on the subject of Public Key Infrastructure (PKI) and related policy issues is the recent NIST publication titled PKI.

A. 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).

A. There was an unsuccessful X12 DM (data maintenance) request 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.

A. The Internet email 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 email users (and Postal users) don't have to call up their service provider before sending a message across an "interconnect" to another service provider.

A. 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.

A. There are several EDI related mailing lists on (and off) the Internet, ietfedi, edil, edinew, _ediopen_, openedi, and the ecat mailing list. Information on subscription is listed below.

sub ietfedi

Messages may be sent to IETFEDI@BYU.EDU

subscribe edil

Messages may be sent to EDIl@uccvma.ucop.edu

edinewrequest@tegsun.harvard.edu

Messages may be sent to edinew@tegsun.harvard.edu

Majordomo@utu.premenos.com

The text of the message should only contain the following:

subscribe ediopen

Messages may be sent to EDIOPEN@utu.premenos.com

subscribe ecat firstname lastname

The address of the ECAT forum is:

ECAT@forums.fed.gov.

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 a message to: majordomo@utu.premenos.com

with the following text in the message body: subscribe openedi

Messages may be sent to OPENEDI@utu.premenos.com

A. Yes. Messages that have appeared on the list are available via FTP from ftp.sterling.com (192.124.9.3).

A. 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 ediarchive@sparky.sterling.com Sterling is making the archive publicly available to the community. Anyone who wants to distribute EDI related documents should feel free to contact Kent. He will sure make your documents are made publicly available on ftp.sterling.com.

A. You can access the EDIFACT standards via GOPHER from the International Telecommunications Union (info.itu.ch). Here are the general directions in getting to the standards. 1. Launch the gopher client as gopher info.itu.ch 2. Select entry 11 (UN and international organizations) 3. Select entry 1 (UN EDITRANS, UN/EDIFACT (EDICORE)) 4. Select entry 3 (UNEDIFACT Standards Database (EDICORE)) 5. Select entry 1, Publications. 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.