RFC 1865

EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet

๐Ÿ“… published January 1996, from ietf

RFC 1865: EDI Meets the Internet ๐ŸŽ€

Okay bestie, let's start with the title block โœจ This is RFC 1865, called EDI Meets the Internet, with the subtitle "Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet." It came out of the Network Working Group ๐Ÿซถ Three authors wrote it: W. Houser from the Dept. of Veterans Affairs, J. Griffin from Athena Associates, and C. Hage from C. Hage Associates ๐Ÿ’œ It's Informational in category and it's dated January 1996 ๐Ÿ“… The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own ๐Ÿงš


Status of this Memo ๐Ÿ’œ

Okay so this memo gives information for the Internet community ๐Ÿ’– It does not specify an Internet standard of any kind, so don't go looking for a spec in here ๐Ÿ™… 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 ๐Ÿฆ‹ It introduces the Internet and assumes you already have a basic knowledge of EDI, so no pressure ๐Ÿ’…

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

Okay bestie, this doc is informational in nature and it answers frequently asked questions about using the Internet for Electronic Data Interchange (EDI) ๐Ÿ’… The main audience is the EDI crowd who aren't super familiar with the Internet yet, including software developers, users, and service providers ๐Ÿงš You need some understanding of EDI to vibe with it. 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) ?

So, unless it says otherwise, when this document says EDI, it means the use of either of these two standards ๐ŸŽ€

  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 digging into them isn't in scope for this document ๐Ÿซถ

1.3. What are the X12 Standards that I should be aware of ?

ngl this is the good stuff ๐Ÿ”ฅ ACCREDITED STANDARDS COMMITTEE (ASC) X12 Standards are available from DISA at the address specified in Question 1 ๐Ÿ’– Here's a solid starter pack 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 literally invited to add questions ๐Ÿ™ˆ Please include an answer if you know one or want to suggest one. Corrections and comments are always welcome too ๐Ÿ’œ Send them to the IETF-EDI mail list, and you subscribe the way question 7.6 describes. Or a send your comment to houser.walt@forum.va.gov โœจ

1.5. How can I get a copy of this document? ๐Ÿ’Œ

Okay bestie, getting your hands on this RFC is so easy ๐Ÿฅฐ RFCs (Request for Comments documents) can be grabbed by anonymous FTP. Log in with the username anonymous and use your e-mail address as the password. Once you're in, type cd rfc, then:

cd rfc
get rfc1865.txt

The web address for the RFC is:

ftp://ds.internic.net/rfc/rfc1865.txt

RFC directories live at these mirrors:

  • Africa: ftp.is.co.za (196.4.160.2) ๐ŸŒ
  • Europe: nic.nordu.net (192.36.148.17) ๐Ÿ‡ช๐Ÿ‡บ
  • Pacific Rim: munnari.oz.au (128.250.1.21) ๐ŸŒŠ
  • US East Coast: ds.internic.net (198.49.45.10) ๐Ÿ—ฝ
  • US West Coast: ftp.isi.edu (128.9.0.32) ๐ŸŒ…

Prefer email? RFCs are also available by mail. Send a message to mailserv@ds.internic.net and put this in the body:

FILE /rfc/rfc1865.txt
NOTE: The mail server at ds.internic.net can send the document back in MIME-encoded form using the mpack utility. To turn this on, put ENCODING mime before the FILE command. To decode the response(s), you'll need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers act differently, especially with "multipart" MIME messages (aka documents split up into multiple messages), so check your local docs on how to handle these messages. ๐Ÿซถ

2. General Information ๐ŸŒˆ

2.1. What is the Internet ? ๐ŸŒ

Okay so the Internet isn't some brand-new physical network, just existing corporate and government networks talking to each other using commonly used telecommunications standards. Some new facilities might be needed, sure, but the real vibe is that users want to communicate better through electronic messages and file transfers ๐Ÿ’– Internet communication can be interpersonal (person-to-person) E-Mail, or process-to-process like EDI. Messages can be inquiries to shared databases plus the responses, or even entire files. Iconic โœจ

2.2. Is there a difference between EDI and electronic commerce (EC) ? ๐Ÿ›๏ธ

Yes! EDI (Electronic Data Interchange) is the inter-process (computer application to computer application) communication of business information in a standardized electronic form. Electronic Commerce includes EDI, but it also recognizes the need for inter-personal (human to human) communication, the transfer of moneys, and sharing common databases as extra activities that help businesses run efficiently. EC pulls in a wide range of technologies, so it's way broader than EDI ๐Ÿ’… Just so you know, though, this document is focused on EDI, not electronic commerce.

2.3. What makes the Internet useful for EDI ? ๐Ÿ’œ

The biggest perks come from:

  • Adopting common standards and proven interoperable systems ๐Ÿค
  • Adopting and deploying a distributed Directory Service capability, so you can easily contact any other organization in the world electronically ๐ŸŒŽ
  • Explicit commitment from participating organizations to cooperatively route traffic, work to resolve addresses, and meet required standards ๐Ÿ“ฌ
  • Ubiquitous network coverage from many service providers, so the customer can pick the level of service they need ๐ŸŽฏ
  • Layering applications (like EDI) over existing, proven applications ๐Ÿฐ
  • A standards process with reference implementations that all vendors have equal access to (aka a level playing field) โš–๏ธ
  • 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 a government agency, babe. You use it to do business the same way you'd use the telephone ๐Ÿ“ž The same Internet connection your organization uses to send electronic mail is the one you'd use to send EDI transactions. Software developers write EDI translators, packages, or templates for your e-mail system so you can handle your own EDI transactions. So no, your EDI activities don't need coordinating, 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, and machines. This is called the Domain Name Service (DNS), and it works from a distributed tree structure. The Internet requires your Internet Protocol (IP) address and Domain Name to be registered in the Domain Name Service (DNS). Your internet service provider can handle this for you, or help you figure out who to contact to get your assigned addresses and domain names ๐Ÿงš

2.6. How fast is the Internet? โšก

For a modest amount of data over a dedicated connection, a message transmission happens in a matter of seconds, unless the ISP selected by 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 the Internet backbones. Unfortunately, some areas may lack the capacity or "bandwidth" needed for your organization's workload, so contact your local Internet Service Provider for service details in your area. Also, the more you're 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 (with separate backbones) can be used, and redundant mail servers at separate locations can be used too. A single internet email or server address can 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 instead, then the integrity of the message depends on the ISP or other computers used to forward it ๐Ÿ˜ฌ

2.8. What are RFCs and where can I get them ? ๐Ÿ“š

RFC stands for Request For Comments. The RFC series of notes covers a broad range of topics related to computer communications, with the core topics being the Internet and the TCP/IP protocol suite. There are three categories of RFCs today: Standards Track, Informational, or Experimental. Lots of RFCs describe de-facto standards in the Internet Community. Copies of RFCs are often posted to the USENET newsgroup comp.doc and can be obtained 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. You can also look for (or have someone get you) these bibliographies, which are 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 check out 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 set up 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 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 setup 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 that can be retrieved later by a client application run by the user, typically on a PC that might not be running 24 hours a day. The TCP/IP protocol is used either over a LAN or a dialup SLIP connection to retrieve messages.

d) Mail User Agents (Mail Readers) ๐Ÿ‘€

Applications use 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 lets you identify and concatenate 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 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 Agent is an interactive application. However, there are automated email message processing programs that 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? ๐ŸŒ

Okay so Internet email is typically used for two party messaging ๐Ÿ’Œ, which is cute, but it's not the only game in town. The FTP, gopher, and HTTP protocols let many users, possibly anonymous ones ๐Ÿ‘€, pull data from one central source ๐Ÿ—‚๏ธ. Like, corporate catalogs can be restricted by potential customers. That's giving VIP access ๐Ÿ‘‘

a) File Transfer Protocol (FTP) ๐Ÿ“

Companies with existing connectivity to the Internet can use FTP to transfer files to one-another or to their VAN ๐Ÿšš. The lowkey iconic part is that this solution runs on the same TCP/IP used for SMTP ๐Ÿ”ฅ. Also, 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 is a way of organizing selected documents and files on an Internet server in a simple tree menu ๐ŸŒณ, so users on other Internet computers can find them easily โœจ. Most gopher menus are also linked to other gopher menus elsewhere, so users can totally 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 ๐Ÿ”ฌ. Even though there's 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 they belong to ๐Ÿข. There are many WHOIS servers scattered throughout the Internet. To get a list of registered WHOIS servers, do an anonymous FTP to rtfm.mit.edu and get the file /pub/whois/whois-servers.list. You can:

  • run a client program on your own machine to access the WHOIS server,
  • telnet to a site which hosts the server, eg: telnet to whois.internic.net and type help to access the full online help
  • 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 ? ๐ŸŒˆ

okay bestie, let's talk connection options ๐Ÿ”Œ here's the overview of the ways you can actually hook up to the Internet rn โœจ

a) Dedicated Connection ๐Ÿ’–

so a dedicated connection is basically a leased telephone line linking a gateway computer, or a bridge/router, from a corporate LAN/WAN to the router at the Internet Service Provider's (ISP) Point-Of-Presence (POP, and no, not the Post Office Protocol ๐Ÿ™ˆ). the line can come in different types and speeds, like modem, ISDN, DS0, or DS1 ๐Ÿ”ฅ

with a dedicated connection, SMTP is usually what delivers email straight to a trading partner's system ๐Ÿ“จ real-time client-server apps can run directly with a trading partner's system too, including info moved over FTP and HTTP ๐Ÿฆ‹

some ISPs throw in optional extras even with dedicated lines โœจ like store-and-forward email on an ISP server that works as a backup for a direct SMTP server run by a trading partner ๐Ÿ’… the ISP might also offer disk space on its FTP and HTTP servers, which have a high speed connection to the Internet ๐ŸŒธ for example, a trading partner could use a 14.4Kb modem for dedicated email transfers and a 1.5Mb connection run by the ISP to distribute FTP and HTTP info ๐Ÿ’œ

b) On-demand Connection ๐Ÿ“

an on-demand connection works like a dedicated one, except it uses a dialup ISDN or modem connection ๐Ÿ“ž if the link sits idle for a certain amount of time, the connection gets dropped ๐Ÿ’€ some ISPs offer dial-out, so any inbound or outbound traffic can bring the link back up ๐Ÿซถ but lots of ISPs make customers dial in, which means only outbound traffic and regular polling can set up the link ๐Ÿ˜ญ in that case, store-and-forward would probably handle email, and the ISP's servers would handle FTP and HTTP info ๐Ÿงš

c) Part-time Polled Connection ๐ŸŒˆ

the Unix-to-Unix Copy (UUCP) protocol is usually used for email, news, and (rarely) file transfers ๐Ÿ“ฌ a client org periodically dials the ISP, transfers email and Usenet news for the org, then disconnects ๐Ÿ‘‹ the client usually polls the ISP at regular intervals, like every 20 minutes, though some ISPs dial out when a message needs delivering โœจ outgoing email can go out immediately, or get queued for transmission with a specified maximum delay โณ

a UUCP connection can move messages to an arbitrary number of people or automated mail processing programs ๐Ÿ’Œ one UUCP connection can also route messages to other systems, like divisions inside a corporation ๐Ÿข UUCP and store-and-forward are basically the same thing, iykyk ๐Ÿ’…

since UUCP only moves mail and news, interactive internet client-server apps like FTP and HTTP aren't available, except through a server the ISP provides ๐Ÿ™ƒ so you might need a separate dialup account to grab info from other FTP or HTTP servers ๐Ÿ˜ค UUCP might handle automated email transfer, while an on-demand dialup connection handles interactive internet client apps ๐ŸŽ€

UUCP accounts do come with a delay (up to the polling interval) before a message gets processed โฐ but lots of ISPs let a customer-supplied script process messages right away on the ISP's machine ๐Ÿคฉ UUCP can transfer files directly, but usually files get sent by encoding them inside an email message ๐Ÿ“Ž transmission inside internet email is way more widely supported and can be gatewayed into proprietary systems ๐Ÿ‘‘

d) Dial-up Shell Account ๐ŸŒธ

with a dial-up account, one user on a personal computer running a terminal emulator connects to the ISP's computer ๐Ÿ’ป mail readers, news readers, HTTP browsers, etc. can all run on the ISP machine ๐Ÿ™Œ data on the ISP machine can be moved to the personal computer by hand using a protocol like X-Modem, Z-Modem, or Kermit ๐Ÿงธ

the ISP's host might run one of the usual UNIX command line (shell) programs, or it might use a custom BBS or another menu driven user interface ๐Ÿ–ฅ๏ธ a proprietary client-server program can replace the terminal emulator to give a graphic user interface ๐ŸŽจ some proprietary GUI clients give access to selected internet apps, like gopher ๐Ÿฟ๏ธ

a dialup ISP usually has a direct internet connection, but very low cost providers might only have a UUCP connection to the Internet ๐Ÿ’ธ some big proprietary networks like CompuServe don't 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 kinda a cross between on-demand and dial-up ๐Ÿซ  like the on-demand account, a single user can connect to an ISP and run mail readers, news readers, FTP, HTTP browsers, etc. client apps straight from a personal computer ๐ŸŽ€ but unlike on-demand, the dial-out computer is only a client, not a server, and it's for a single user rather than acting as a gateway to a LAN ๐Ÿ™…โ€โ™€๏ธ

with a SLIP/PPP account, the POP (Post-Office-Protocol) protocol is how a user's mail reader client pulls down messages stored on the ISP's server ๐Ÿ“ฅ unlike UUCP, POP servers hold mail for a single user (aka one individual email address) ๐Ÿ’œ

with a SLIP/PPP connection, any standard TCP/IP app is plugged right into the internet ๐Ÿ”Œ so unlike the proprietary GUI software from the ISP, any TCP/IP client app can be used ๐Ÿฅณ

a program like TIA (The Internet Adapter) can run on a shell account and let a standard UNIX shell account function as a SLIP/PPP account ๐Ÿช„ but some ISPs don't support TIA because they charge extra for SLIP ๐Ÿ’€


4. Organizational Issues ๐Ÿขโœจ

4.1. Why is the way we currently do EDI so limiting to its growth? ๐Ÿค”

okay so there's a tendency for each org to set up its own rules and admin policies ๐Ÿ™ƒ which makes costs rise when you're dealing with multiple trading partners, each with its own requirements and procedures ๐Ÿ’ธ but new technologies and business practices are needed if EDI is going to move beyond the 30 to 40,000 organizations using it right now ๐Ÿš€

according to Department of Labor and Internal Revenue Service stats, there are about 6.2 million entities with employees and about 14 million other "business" entities ๐Ÿ“Š say a business wants to sell chairs ๐Ÿช‘ it'd have to check with a bunch of different customers to see if they have any requirements. by letting a business use a common method to look for customers, the barriers to entering the electronic marketplace get way easier ๐Ÿซถ

that doesn't mean there's just one source everyone goes to for a list of current business opportunities ๐Ÿ™…โ€โ™€๏ธ instead, a prospective supplier only needs to go to a single electronic marketplace โœจ to talk to each other, the different participants in electronic commerce need to harmonize their procedures and processes ๐Ÿค examples include common trading partner registration and adopting 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 might be built around one particular technical solution, so think carefully about how it'd be used and what applications and telecom software would need to interact with it ๐Ÿง you don't want to accidentally lock yourself into 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 makes you your own VAN ๐Ÿคณ organizations acting independently have set up their own dial-up electronic bulletin board systems with unique but functionally equivalent operating rules ๐Ÿงฉ your BBS will be a little different from the next org's, which makes it hard for suppliers to access ๐Ÿ˜ต

by getting transactions from the VANs who specialize in moving info, your org gets the widest circulation possible ๐Ÿ“ฃ you'll be able to reach trading partners you might not even know existed, which means more competitive bids ๐Ÿ’ฐ because of their idiosyncratic nature, BBSs aren't consistent with the idea of a "single face to industry" championed 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 might want to keep some Agreements in place for unique situations ๐Ÿซถ but be careful not to create conflicting agreements and directions for your trading partners โš ๏ธ follow the procedures common to your particular line of business ๐Ÿงญ

long run, less is better โœŒ๏ธ hopefully, bringing EDI into common commercial practice will get rid of 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 assume a willingness to take part in the open bidding process ๐Ÿ™‹ while this process is a legal requirement for government agencies, lots of private orgs choose not to adopt it ๐Ÿคท the technology of the Internet makes competition easier, but the cost of putting these practices in place limits their value ๐Ÿ’ธ

this is a business decision, not a technical one ๐Ÿง  will companies competitively procure critical supplies without a long term relationship with the supplier? for essential inputs that make or break customer satisfaction and productivity, the benefits of competition might not be worth the risks โš–๏ธ

many organizations see some increase in the number of transactions ๐Ÿ“ˆ for competitive procurements, though, the winning bid should be significantly better than the ones received before using the electronic system ๐Ÿ† the impact of more volume needs evaluating on a situation by situation basis ๐Ÿ” for example, your acquisition support system may need re-engineering 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 ? ๐Ÿ“ฌ

Okay bestie, yes, 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 phone calls, faxes, and other non-EDI/EC messages by pointing out that telephone or fax messages are processed more slowly ๐Ÿข. Electronic messaging also gives you a written and dated audit trail ๐Ÿงพโœจ. Your application system can route the message to the buyer and "attach" it to a "case file" ๐Ÿ—‚๏ธ. Still, 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 one is typically handled by applications software, not by the Internet, so don't panic ๐Ÿซถ. Say a vendor wants to bid on a particular Request For Quotation (RFQ). They 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) gets interpreted by your VAN and forwarded to the buyer's VAN, or straight to the buyer, depending on the reply address ๐Ÿ“จ. VANs may reject messages from unregistered sources. Otherwise, the messages are forwarded to (or otherwise made available to) the buyer. And if a buyer is using dial-up access to a VAN, 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 ๐ŸŒˆ. 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 they may be rather ephemeral ๐Ÿ’จ. The Internet is suited to dynamic multilateral relationships that may later evolve into static bilateral relationships between companies using VANs ๐Ÿฆ‹. So 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, since the level of communication becomes more important ๐Ÿ“Š. Also, 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 relied on specialized firms called Value Added Networks (VANs) for technical assistance. Many of these organizations will look to their VAN for help using the Internet. VANs specializing in EDI applications provide technical support, a help desk, and troubleshooting for EDI and telecommunications problems ๐Ÿ› ๏ธ. They assist with configuration of software, upgrades to telecommunications connectivity, data and computer security, auditing and tracing of transactions, recovery of lost data, and service reliability and availability ๐Ÿ”. Some EDI-specific services can include broadcasting an RFQ to a collection of vendors, or storing EDI information for later search and retrieval ๐Ÿ”.

5.2. What is an Internet Service Provider (ISP)? ๐ŸŒ

VAN services have typically used a 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-to-computer communication for client-server applications โšก. Alternatively, a part-time internet connection can be used to access internet servers on a demand basis, or to 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 ๐Ÿฐ. For example, direct delivery to a trading partner's system can be used when a link is operational, with a store and forward from an ISP used as a backup ๐Ÿ›Ÿ.

A large organization can connect its 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 that 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, a 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 has to do a table look-up to figure out which VAN the receiving party is on ๐Ÿ”Ž. If you use only X12 without the Internet, then 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 its table ๐Ÿ“. If the ISA contained the VAN ID of the recipient, 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, which avoids most of the problems of interconnecting proprietary networks ๐Ÿ™Œ. That frees VANs to focus on services for 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 of the exchange ๐Ÿค.

a) Email based messaging ๐Ÿ’Œ

The simplest and most widely supported means of exchanging messages is internet email ๐Ÿ“ง. Typically, the IETF-MIME encapsulation specification would be used to enclose the EDI data within the email message. The trading partners would also 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 with 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 an 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, and vice versa), and they are available for free from one of several FTP archive servers ๐Ÿ†“. Use of these compression routines should be handled with care when you're employing an encryption technique such as PEM or PGP โš ๏ธ.

5.8. Can the ISA 06 or 08 identify any entity other than the 'end' Trading Partners (i.e. a routing entity)? ๐Ÿ›ฃ๏ธ

Yes! Although the ISA06 and ISA08 elements are supposed 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) ๐Ÿ—บ๏ธโœจ.

5.9. Can we specify both the recipient's address and their VAN address in the ISA ? ๐ŸŽ€

okay so bestie, this one is a whole saga ๐Ÿ˜ญ There was an X12 DM (data maintenance) request proposed to the X12 standards committee for a change to the ISA segment (X12 header information). It would let users specify the recipient's VAN, in addition to the recipient's ID. The vibe was a hierarchical address in the ISA: the top level is the VAN ID, and the next level is the recipient ID โœจ Iconic, right? Well, ngl, this DM has not been approved yet ๐Ÿ’€

5.10. Are there other options for routing EDI X12 messages ? ๐Ÿงš

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 to route a functional group to a particular department or application inside the receiver's corporation. For example, you could use the ISA08 to identify the receiver as "Acme Corporation," and then use the GS03 to identify the receiving application as "Purchasing department (within Acme Corporation)" ๐Ÿ“

Many EDI users simply put the same value in the ISA06 and the GS02, and 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 of 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 ๐Ÿซถ


6. US Federal Involvement โœจ

6.1. What is the commitment of the US Federal Government to EDI ? ๐Ÿฆ‹

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 of Science and Technology (NIST) maintains an HTML home page for the ECA-PMO:

http://snad.ncsl.nist.gov/dartg/edi/fededi.html

6.2. What is the timetable for the Federal effort ? โฐ

To implement EC and to achieve his objectives for EC, the President set forth the following four milestones:

  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 ๐Ÿ”ฅ

6.3. Will the US Government use the Internet to send EDI transactions ? ๐Ÿ“ฌ

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 ๐Ÿ’œ

6.4. I heard the US Government prohibited commercial use of the Internet? ๐Ÿ™ˆ

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), which 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 ๐ŸŒธ

6.5. The US Government is using both Internet and OSI E-mail protocols. What should one consider when choosing which to use ? โš–๏ธ

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. ๐Ÿ‘‘

6.6. How is the US Government using VANs to distribute business opportunities? ๐Ÿ“ฆ

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 ๐Ÿง

6.7. How would use of the Internet for Federal procurement change this RFQ process? ๐ŸŒˆ

Initially, very few changes may be apparent. New and existing VANs will use the Internet to collect and disseminate EDI transactions, and 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 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 ๐Ÿ’…


7. EDI Resources On The Internet ๐Ÿฆ‹

7.1. Are EDI Standards available on the Internet ? ๐ŸŒ

Okay bestie, the Data Interchange Standards Association (DISA) has a World Wide Web server at http://www.disa.org/ ๐Ÿ•ธ๏ธ and it's giving a lot: a list of new standards, a list of all the X12 transaction sets, meeting minutes, a calendar of events, and lists of courses ๐Ÿ“…. The tea is that as of this date, the X12 standards are not available electronically ๐Ÿ˜ญ [soap ...] Hopefully that will be added soon. [...soap] DISA also set up a gopher server (gopher.disa.org) and an FTP server (ftp.disa.org) ๐Ÿงš

The principal docs about ANSI ASC X12's planned alignment with EDIFACT are up on the Web too โœจ The alignment plan that got adopted by a mail ballot of X12 in December 1994/January 1995 lives here:

http:/www.disa.org/info/alinplan.html

The "floor motion" adopted at the X12 meeting in February 1995 is here:

http:/www.disa.org/meetings/alinmotn.html

Okay, and there are a few mail lists and exploders that support X12 and EDIFACT standards development work ๐Ÿ’Œ

X12G Mailing list: ๐ŸŽ€

This one is a fully open exploder set up to support X12G. To subscribe, send an e-mail to x12g-request@snad.ncsl.nist.gov and make the body contain only this:

subscribe x12g

Once you're subscribed, you can broadcast your messages to the other participants (who have subscribed) at x12g@snad.ncsl.nist.gov. ๐Ÿซถ

FED-REG Mailing list: ๐Ÿ’œ

This new exploder is all about the federal EDI Registry, how IMPDEF gets implemented within the registry, EDI Viewers and Editors, and using IMPDEF to upgrade EDI products ๐Ÿ”ฅ Since it's a mailing list about pragmatic issues, it's meant for informal discussion.

To subscribe, send an e-mail to fed-reg-request@snad.ncsl.nist.gov with only this in the body:

subscribe fed-reg

Messages meant for the fed-reg list go to fed-reg@snad.ncsl.nist.gov. ๐Ÿ’…

X12C-IMPDEF Mailing list: ๐Ÿฆ‹

This exploder is where the formal talk happens, in the context of X12, about how IMPDEF evolves ๐Ÿ‘‘ The expectation is that discussions over in the "fed-reg" exploder will turn into formal DMRs submitted to "x12c-impdef" and X12C. Anyway, the process gets defined and controlled by the appropriate X12C authority, so no freelancing ๐Ÿ™ˆ

To subscribe, send an e-mail to x12c-impdef-request@snad.ncsl.nist.gov with only this in the body:

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 ๐ŸŒˆ


7.2. Are EDIFACT Standards available on the Internet ? ๐ŸŒธ

You can get the EDIFACT standards over GOPHER from the International Telecommunications Union (gopher://info.itu.ch). Here are the general directions, bestie ๐Ÿ—บ๏ธ

  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 (UN-EDIFACT Standards Database (EDICORE))
  5. Select entry 1, Publications.

If you want the actual standards, select 1, Drafts. You'll 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 whichever path you choose, press D (i.e. upper case D) to download. Pick the protocol that suits you and boom, 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 this as the message body:

START
GET ITU-1900
END

7.3. The EDI X12 standards are quite complex. How do we decide what X12 transactions to implement and how ?

Okay, the standards are a lot, ngl ๐Ÿ˜ญ There are a number of generic implementation conventions (ICs), or guidelines, and most ICs are prepared industry by industry ๐Ÿงฉ The big rule is to make sure you and your current trading partners are working from the same set, fr fr ๐Ÿซถ The Federal Electronic Commerce for Acquisition Program Management Office has been pushing the 3040 version across 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), so contact DISA at the address above for info about ICs for your applications. Certain ICs, as well as the X12 standards, can be obtained through:

Washington Publishing Company
c/o EDI Support Services
P.O. Box 203
Chardon, OH 44024-0203

US Phone     (800) 334-4912
Non-US Phone (216) 974-7650
Fax          (216) 974-7655

7.4. What Implementation Conventions (ICs) are available over the Internet ? ๐Ÿ’ป

The US. Federal Implementation Guidelines for Electronic Commerce for Acquisition are available for free over FTP at ds.internic.net ๐Ÿ†“ They 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) can be grabbed by anonymous FTP at admissions.carleton.ca. The WordPerfect 5.1 files are in /pub/wp_speede_2, while the Postscript files are in /pub/ps_guide_2.

ftp://admissions.carleton.ca/pub/wp_speede_2/
ftp://admissions.carleton.ca/pub/psguide_2/

Full directions for retrieving these files are 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 their 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 is available via anonymous FTP from ftp.sterling.com in the /edi/DoD-edi/ directory. It holds DoD EDI ICs split 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 is designated as Mandatory for test purposes ๐Ÿงช Implementation convention files, both user and test versions, can be downloaded individually or all together in compressed self-extracting files. When decompressed, all the implementation files are available 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 ๐Ÿ’พ

Okay, here's the DoD breakdown, and it's a lot ๐Ÿ˜ตโ€๐Ÿ’ซ

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. The 3010 based conventions will never progress to approved status, but various DoD agencies will use them temporarily 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
Heads up, these 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've been submitted to the Federal IC configuration management process for adoption throughout the federal government. Since they're subject to Federal review and based on a standard not yet released, changes can be anticipated. (See ECA PMO above)

7.5. How can a trading partner keep up with all these implementation conventions (ICs) and revisions in X12 and EDIFACT? ๐Ÿ”„

Okay so the US government is trying to standardize electronic communications internally and with its 300,000 plus suppliers ๐Ÿ‡บ๐Ÿ‡ธ That means standardizing the standards process itself, plus cross communication between programs, which is a big ask but iconic if it works. The IMPDEF message and the NIST Federal IC Registry will put electronic versions of all its ICs on the Registry, both full federal ICs and individual agency ICs, so any trading partner can download and use them ๐Ÿ“ฅ Combined with message data compliance checking as well, smaller firms should be able to get into EDI and start benefitting both themselves and the government ๐Ÿ’–

7.6. Where can I get information on EDI translation software ? ๐Ÿ’…

Okay bestie, you want translation software? Several commercial trade magazines publish periodic guides to EDI translation software, so start there โœจ. The Logistics Management Institute (LMI) of McLean, Va. published "A Guide to EDI Translation Software, 1994 Edition" under commission by the US Government. It's literally a comparison shopping bible ๐Ÿคฉ, since it describes the features and characteristics of EDI software from more than 60 vendors.

Commercial organizations can get copies for $20 each by sending a check made out to 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). ๐Ÿฆ‹

7.7. How do I keep in touch with others pursuing EDI and Electronic Commerce on the Internet ? ๐ŸŒˆ

There are several EDI related mailing lists on (and off) the Internet, and the subscription info is right below ๐Ÿ“ฌ.

IETF-EDI Mailing list

The IETF-EDI list is a forum for discussing methods of operating EDI transactions over the Internet, and for discussing specifications which permit such operation. It's focused on the technology of Internet usage of EDI, not the more general EDI technology or use stuff ๐Ÿงš.

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 aimed at more general EDI discussions ๐ŸŒธ. It's 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, and it's giving new-approaches energy ๐Ÿฆ‹. 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 set up an open mail list for anyone into 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 to 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

7.8. Can I get messages that have been previously posted to the EDI mailing lists ? ๐Ÿ“ผ

Yes! Messages that have appeared on the ecat, edi-l, edi-new, fed-reg, x12c-impdef and ietf-edi lists 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 don't want 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/ ๐Ÿ‘‘.

7.10. Where are EDI Archives on the Internet ? ๐Ÿ—‚๏ธ

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 โœจ.


8. Security Considerations ๐Ÿ”

8.1. What security measures are needed to connect to the Internet ? ๐Ÿ›ก๏ธ

Internet security measures fall into two broad categories: protecting your system from intruders, and protecting the content and integrity of your messages. For the second one, 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 the 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 ๐Ÿ™….

8.2. How do we go about protecting our system ? ๐Ÿ’–

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:

  • 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 the Federal Electronic Commerce for Acquisition Team report Streamlining Procurement Through Electronic Commerce. This document is available via FTP at ds.internic.net in the directory /pub/ecat.library.
  • Apply the recommendations from NIST Special Publication 800-9, Good Security Practices for Electronic Commerce, Including Electronic Data Interchange as appropriate.
  • Establish necessary internal and external "Firewalls." See John Wack and Lisa Carnahan, "Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls," NIST Special Publication 800-10, undated ๐Ÿงฑ.
  • Review RFC 1281[4] Guidelines for the Secure Operation of the Internet and RFC 1244 Holbrook and Reynolds "Site Security Handbook" ๐Ÿ“š.
  • Review Cheswick and Bellovin's "Firewalls and Internet Security - Repelling the Wily Hacker," Addison-Wesley [5] ๐Ÿฆ‹.
  • Consider implementing active countermeasures in your firewalls. See "There Be Dragons" by S. Bellovin, Proceedings of the Third Usenix UNIX Security Symposium, September 1992[6]. You can contact Bellovin at smb@ulysses.att.com ๐Ÿ‰.

8.3. Is there good publicly available software I can use? ๐Ÿ› ๏ธ

okay so bestie, these are a few free, publicly available security tools you can grab over ftp from one of the many good archives ๐Ÿ’– If your company uses UNIX systems to connect to the Internet, or has UNIX systems connected to the Internet, you'll want to get and use these:

  1. The Purdue University COAST - Security Archive (Computer Operations, Audit, and Security Tools, run by Gene Spafford) is located at coast.cs.purdue.edu and mirrored in a few places, including ftp.sterling.com.
  2. COPS available from ftp.cert.org in /pub/tools
  3. TIGER available from net.tamu.edu in pub/

These tools are a series of scripts and programs that will alert you to many well-known problems and holes in UNIX systems, and how to fix them ๐Ÿ”งโœจ

The Computer Emergency Response Team (CERT) at Carnegie Mellon University can help with computer break-ins, and it also shares 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 that fosters cooperation and coordination among computer security teams worldwide ๐ŸŒ๐Ÿ’œ

8.4. How good are electronic or digital signatures ? Can they be used in court ? โœ๏ธ

Properly used, these signature systems are better than existing paper based authentication and forgery detection technology ๐Ÿ’… You'll 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. Without 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 ๐Ÿ“ž

8.5. Are there other US government standards publications I should be aware of? ๐Ÿ“š

Yes! Here is a sample of those you will often hear mentioned ๐Ÿ™ˆ

  1. Federal Information Processing Standard (FIPS) Publication 46-1, Data Encryption Standard, January 1988.
  2. FIPS Publication 65, Guideline for Automated Data Processing Risk Analysis, August 1979.
  3. FIPS Publication 113, Computer Data Authentication, May 1985.
  4. FIPS Publication 180, Secure Hash Standard - (SHS), May 1993.
  5. FIPS Publication 186, Digital Signature Standard - (DSS), May 1994.
  6. NIST Special Publication 800-9, Good Security Practices for Electronic Commerce Including Electronic Data Interchange, December 1993.

The FIPS standards may be ordered from the:

U.S. Department of Commerce
National Technical Information Service
Springfield, VA 22161.

9. References ๐Ÿ“–

[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

10. Credits ๐Ÿซถ

James A.(Artch) Griffin <artch@AGRIFFIN.CPCUG.ORG> is credited with co-authorship, because 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 of 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, and Jean-Philippe Favreau. I'm sorry if I left out any one of the many folks who responded to my many calls for comments ๐Ÿ™

I really appreciate Kent Landfield for his editorial assistance during the 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.

11. Authors' Addresses ๐Ÿ“ฎ

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
C. Hage Associates
1180 Reed Ave #51
Sunnyvale, CA 94086

EMail: carl@chage.com
http://www.chage.com/chage/
๐Ÿ“ฆ where this page comes from