GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1865

Network Working Group W. Houser Request for Comments: 1865 Dept. of Veterans Affairs Category: Informational J. Griffin

                                                     Athena Associates
                                                               C. Hage
                                                    C. Hage Associates
                                                          January 1996
                       EDI Meets the Internet
                  Frequently Asked Questions about
         Electronic Data Interchange (EDI) on the Internet

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.

Abstract

 This memo is targeted towards the EDI community that is unfamiliar
 with the Internet, including EDI software developers, users, and
 service providers.  The memo introduces the Internet and assumes a
 basic knowledge of EDI.

Table of Contents

 1. Introduction ................................................    4
 1.1.  What is this document ....................................    4
 1.2.  What do you mean by electronic data interchange (EDI) ?  .    4
 1.3.  What are the X12 Standards that I should be aware of ?  ..    4
 1.4.  To whom do I send comments and suggestions ? .............    5
 1.5.  How can I get a copy of this document? ...................    5
 2. General Information .........................................    6
 2.1.  What is the Internet ?  ..................................    6
 2.2.  Is there a difference between EDI and
       electronic commerce (EC) ? ...............................    6
 2.3.  What makes the Internet useful for EDI ?  ................    6
 2.4.  Does this means we will now have to coordinate our
       EC/EDI activities with the Internet?  ....................    7
 2.5.  How do I find the addresses of other Trading partners
       on the Internet if I don't have to coordinate my EDI
       activities with a central organization or VAN?  ..........    7
 2.6.  How fast is the Internet?  ...............................    7
 2.7.  What about reliability of the Internet?  .................    7
 2.8.  What are RFCs and where can I get them ?  ................    8

Houser, et al Informational [Page 1] RFC 1865 EDI Meets the Internet January 1996

 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

Houser, et al Informational [Page 2] RFC 1865 EDI Meets the Internet January 1996

 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

Houser, et al Informational [Page 3] RFC 1865 EDI Meets the Internet January 1996

 9. References ..................................................   39
 10. Credits ....................................................   40
 11. Authors' Addresses .........................................   41

1. Introduction

1.1. What is this document

 This document is informational in nature and attempts to answer
 frequently asked questions concerning the use of the Internet for
 Electronic Data Interchange (EDI).  The primary audience is the EDI
 community that is unfamiliar with the Internet, including software
 developers, users, and service providers.   The reader needs some
 understanding of EDI.  Informational RFCs are prepared by the
 Internet Engineering Task Force (IETF) to improve understanding and
 effectiveness in the use of the Internet.

1.2. What do you mean by electronic data interchange (EDI) ?

 Except as noted, the document refers to EDI as the use of the
      1) X12 standard developed by the ANSI Accredited Standards
         Committee X12 or
      2) EDIFACT[1] standard United Nations Economic Commission for
         Europe (UN/ECE), Working Party for the Facilitation of
         International Trade Procedures (WP.4).
 The differences between these standards is beyond the scope of this
 FAQ.  Both standards activities are managed in the US by:
              Data Interchange Standards Association, Inc,
              1800 Diagonal Road, Suite 200
              Alexandria, Virginia, 22314-2852
              Voice: 703-548-7005
              FAX: 703-548-5738
 There are numerous other standards one could use for EDI, but
 discussion of them is not in the scope of this document.

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

 ACCREDITED STANDARDS COMMITTEE (ASC) X12 Standards are available from
 DISA at the address specified in Question 1.  The following is a good
 starting set of X12 standards.
     1.  ASC X12S/94-172, An Introduction to Electronic
         Data Interchange, DISA 1994 Publications Catalog

Houser, et al Informational [Page 4] RFC 1865 EDI Meets the Internet January 1996

     2.  ASC X12.3 Data Element Dictionary
     3.  ASC X12.5 Interchange Control Structure
     4.  ASC X12.6 Application Control Structure
     5.  ASC X12.22 Segment Directory
     6.  ASC X12.58 Security Structures

1.4. To whom do I send comments and suggestions ?

 Readers are invited to add questions; please include an answer if you
 know or want to suggest one.  Of course corrections and comments are
 welcome; send them to the IETF-EDI mail list by subscribing as
 described in question 7.6.  Or a send your comment to
 houser.walt@forum.va.gov.

1.5. How can I get a copy of this document?

 Request for Comments documents (RFC) are available by anonymous FTP.
 Login with the username "anonymous" and a password of your e-mail
 address.  After logging in, type "cd rfc" and then
      "get rfc1865.txt".
 A Web address for the RFC is:
    ftp://ds.internic.net/rfc/rfc1865.txt
 RFC directories are located at:
      o  Africa at:        ftp.is.co.za    (196.4.160.2)
      o  Europe:           nic.nordu.net   (192.36.148.17)
      o  Pacific Rim:      munnari.oz.au   (128.250.1.21)
      o  US East Coast:    ds.internic.net (198.49.45.10)
      o  US West Coast:    ftp.isi.edu     (128.9.0.32)
 RFCs are also available by mail.  Send a message to:
 mailserv@ds.internic.net. In the body type:
      "FILE /rfc/rfc1865.txt"
 NOTE: The mail server at ds.internic.net can return the document in
 MIME-encoded form by using the "mpack" utility.  To use this feature,
 insert the command "ENCODING mime" before the "FILE" command.  To
 decode the response(s), you will need "munpack" or a MIME-compliant
 mail reader.  Different MIME-compliant mail readers exhibit different
 behavior, especially when dealing with "multipart" MIME messages
 (i.e., documents which have been split up into multiple messages), so
 check your local documentation on how to manipulate these messages.

Houser, et al Informational [Page 5] RFC 1865 EDI Meets the Internet January 1996

2. General Information

2.1. What is the Internet ?

 It is the inter-working of existing corporate and government networks
 using commonly used telecommunications standards.  It is not a new
 physical network, although some new facilities may be needed.
 Rather, it is based on mutual interests of users to communicate more
 effectively via electronic message and file transfers.  Internet
 communications may be interpersonal (person-to-person) E-Mail or
 process-to-process like EDI.  Messages may be inquiries to shared
 databases and responses. Messages may be entire files.

2.2. Is there a difference between EDI and electronic commerce (EC) ?

 Electronic Data Interchange (EDI) is defined as the inter-process
 (computer application to computer application) communication of
 business information in a standardized electronic form.  Electronic
 Commerce includes EDI, but recognizes the need for inter-personal
 (human to human) communications, the transfer of moneys, and the
 sharing of common data bases as additional activities that aid in the
 efficient conduct of business.  By incorporating a wide range of
 technologies, EC is much broader than EDI.  However, the focus of
 this document in on EDI, not electronic commerce.

2.3. What makes the Internet useful for EDI ?

 The greatest benefits will derive from:
    o  Adoption of common standards and proven inter-operable systems,
    o  Adoption and deployment of a distributed Directory Service
       capability, so that one can readily contact electronically any
       other organization in the world.
    o  Explicit commitment by participating organizations to
       cooperatively route traffic, work to resolve addresses, and
       meet required standards.
    o  Ubiquitous network coverage from many service providers. This
       allows the customer to choose the level of service needed.
    o  Layering of applications (such as EDI) over existing, proven,
       applications.
    o  A standards process with reference implementations which
       all vendors have equal access.  (a.k.a. a level playing field).

Houser, et al Informational [Page 6] RFC 1865 EDI Meets the Internet January 1996

    o  Widely available public domain software including but not
       limited to applications, protocol/transports and multiple
       platform development tools.

2.4. Does this means we will now have to coordinate our EC/EDI

    activities with the Internet?
 The Internet is not an organization or government agency.  You use
 the Internet to do business like you would use the telephone.  The
 same Internet connection your organization uses to send electronic
 mail would be the one you use to send EDI transactions.  Software
 developers write EDI translators, packages or templates for your e-
 mail system so that you can handle your own EDI transactions.  Your
 EDI activities do not need to be coordinated, but your connection to
 the Internet does.

2.5. How do I find the addresses of other Trading partners on the

    Internet if I don't have to coordinate my EDI activities with
    a central organization or VAN?
 The Internet works by assigning names or "domains" to
 networks/companies/machines.  This is called the Domain Name Service
 (DNS). It works from a distributed tree structure.  The Internet
 requires registration of your Internet Protocol (IP) address and
 Domain Name in the Domain Name Service (DNS).  Your internet service
 provider can do this for you or assist you in contacting the right
 people to get your assigned addresses and domain names.

2.6. How fast is the Internet?

 For a modest amount of data with a dedicated connection, a message
 transmission would occur in a matter of seconds, unless the ISP
 selected one of the trading partners is overloaded.  The maximum
 delay over the internet backbones is at most a few seconds.  Like the
 interstate highway system, speed depends on how close you and your
 trading partner are to Internet backbones.  Unfortunately, some areas
 may lack the capacity or "bandwidth" to handle the workload your
 organization requires.  Contact your local Internet Service Provider
 for details on service in your area.  Also, the more you are willing
 to spend, the better the service.  The Internet is inexpensive, but
 (contrary to popular mythology) it is not free.

2.7. What about reliability of the Internet?

 For high reliability mission critical applications, redundant ISPs
 may be used (with separate backbones), and redundant mail servers at
 separate locations can be used. A single internet email or server
 address can be used to transparently route to any of the redundant

Houser, et al Informational [Page 7] RFC 1865 EDI Meets the Internet January 1996

 servers or network connections.
 If a dedicated Internet connection is used to transmit information,
 e.g., via SMTP (see questions 3.2 and 3.5), then the message is
 delivered directly to the trading partner's system and delivery is
 assured. If a part time store and forward connection is used, then
 the integrity of the message depends on the ISP or other computers
 used in the forwarding of a message.

2.8. What are RFCs and where can I get them ?

 RFC stands for Request For Comments.  The RFC series of notes covers
 a broad range of topics related to computer communications.  The core
 topics are the Internet and the TCP/IP protocol suite.  There are
 three categories of RFCs today, Standards Track, Informational, or
 Experimental.  Many of the RFCs describe de-facto standards in the
 Internet Community.  Copies of RFCs are often posted to the USENET
 newsgroup comp.doc and obtainable from archive sites such as
 ds.internic.net.
                      ftp://ds.internic.net/rfc/

2.9. Where can I get general information about the Internet?

 Your local bookstore probably has one of the many recent introductory
 publications on the Internet.  In addition, look for (or have someone
 get you) the following bibliographies for free:
       RFC 1175
           Bowers, K., LaQuey, T., Reynolds, J., Roubicek, K.,
           Stahl, M., and A. Yuan, "FYI on Where to Start -
           A Bibliography of Internetworking Information",
           08/16/1990 (FYI 3)
                  ftp://ds.internic.net/rfc/rfc1175.txt
       RFC 1463
           Hoffman, E., and L. Jackson, "FYI on Introducing the
           Internet -- A Short Bibliography of Introductory
           Internetworking Readings for the Network Novice",
           05/27/93 (FYI 19)
                  ftp://ds.internic.net/rfc/rfc1463.txt
 The reader may want to look at the Frequently Asked Questions (FAQ)
 document for the newsgroup alt.internet.services.  This FAQ, as well
 as all Usenet FAQs, can be retrieved via ftp from rtfm.mit.edu in the
 directory /pub/usenet/news.answers.  These FAQs are also available

Houser, et al Informational [Page 8] RFC 1865 EDI Meets the Internet January 1996

 from ftp.sterling.com in the directory /usenet/news.answers.

3. Getting Connected To The Internet

3.1. What do I need to get to use the Internet?

 You need to know your existing telecommunications connectivity,
 address resolution, and routing capabilities.  Then you need to
 establish and operate an Electronic Mail gateway and/or other
 application gateway, e.g., for the file transfer protocol (FTP).
 Larger organizations may supply their trading partners with the
 TCP/IP software and X12 translator interfaced to E-mail or FTP.

3.2. What software is used to support electronic mail?

 a) Simple Mail Transfer Protocol (SMTP) Servers
    A dedicated internet connection usually uses SMTP software to send
    and receive messages. The SMTP server may transfer messages to the
    "spool" area for incoming email in the file system, may queue the
    messages for transmission via UUCP, may hold mail in a POP server,
    or may transfer the message to a proprietary email system.
 b) Unix-to-Unix Copy (UUCP) Servers
    A UUCP server is used to transfer messages when a store and
    forward is used, either between machines within a WAN, or to
    another machine with a dialup link.
 c) Post Office Protocol (POP) mail Servers
    A POP server holds email which can later be retrieved by a client
    application run by the user, typically on a PC which might not be
    running 24 hours a day.  The TCP/IP protocol is used either over a
    LAN or dialup SLIP connection to retrieve messages.
 d) Mail User Agents (Mail Readers)
    Uses or applications employ client programs to retrieve and
    display email messages from the file system mail spool area, or
    from another server computer using POP or some other proprietary
    protocol (e.g. Microsoft-Mail). This mail user agent (UA) software
    is also used to compose and send email via a POP server or system
    email.
    The mail user agent may also process attached files using a
    proprietary format within a mail message, using one of the common
    de-facto standards, or using the Multipurpose Internet Mail

Houser, et al Informational [Page 9] RFC 1865 EDI Meets the Internet January 1996

    Extensions (MIME) internet standard.  Among other things, MIME
    permits the identification and concatenation of message parts
    (called "body parts") into a single message that can traverse the
    Internet using the SMTP protocol.  The Work in Progress, "EDI in
    MIME"  provides the necessary standards for MIME compliant user
    agents to identify EDI body parts.  A MIME compliant mail reader
    can process the contents of the messages and dispatch data to
    external software. For example, files can be dragged to file
    system directories, images can be displayed, and audio data can be
    played.  In the case of EDI, a message formatted according to the
    MIME-EDI specification could be automatically transferred to an
    EDI processing program.
 e) Automated Mail Processing
    A typical Mail User Agents is an interactive application. However
    there are automated email message processing programs which can
    sort incoming mail, process forms returned by others, or in the
    case of EDI data, transfer the message contents to the EDI system.
    Messages formatted according to the MIME EDI specification can be
    properly recognized by any MIME compliant mail processing program.

3.3. What types of client-server or server-server protocols exist on

    the Internet?
 Internet email is typically used for two party messaging. The FTP,
 gopher, and HTTP protocols allow many users, possibly anonymous, to
 retrieve data from a central source. For example, corporate catalogs
 can be restricted by potential customers.
 a) File Transfer Protocol (FTP)
    Companies with existing connectivity to the Internet may use FTP
    to transfer files to one-another or to their VAN.  This solution
    employs the same TCP/IP used for SMTP.  Furthermore, Internet
    documents such as EDI in MIME Work in Progress are available via
    FTP on the FTP server "ds.internic.net."
 b) gopher service protocol.
    Gopher service is a way of organizing selected documents and files
    on an Internet server in a simple tree menu, so that users on
    other Internet computers can find them easily.  Most gopher menus
    are also linked to other gopher menus elsewhere, so that users can
    easily jump from one Internet server to another.  There are
    thousands of gopher servers in operation worldwide.

Houser, et al Informational [Page 10] RFC 1865 EDI Meets the Internet January 1996

 c) The Hypertext Transfer Protocol (HTTP)
    HTTP defines http-server and http-clients that comprise the World
    Wide Web (WWW).  WWW was developed by the European Laboratory for
    Particle Physics (CERN) as a tool for exchanging multimedia data
    between researchers.  Although there is also no specification for
    graphics in HTTP, most web browsers are graphical in nature.
    Mosaic, available free from the National Center for Supercomputer
    Applications (NCSA), provides a Graphical User Interface (GUI)
    that facilitates user access to information on the Internet.
    Mosaic interprets hypertext based information on the WWW, as well
    as to other linked Index/Directory services such as Archie, FTP,
    Gopher, and X.500 Directory information.  Mosaic also supports on
    line Graphic Interchange Format (GIF), Joint Photographic Experts
    Group (JPEG), Motion Picture Experts Group (MPEG), QuickTime, and
    other document, image, and audio types.  Vendors have developed
    product catalogues using Mosaic servers.
 d) WHOIS
    WHOIS servers generally offer information about the organization
    to which they belong.  There are many WHOIS servers scattered
    throughout the Internet.  To obtain a list of registered WHOIS
    servers, anonymous FTP to rtfm.mit.edu and get the file
    /pub/whois/whois-servers.list.  You can:
     o   run a client program on your own machine to access the
         WHOIS server,
     o   telnet to a site which hosts the server, eg: telnet to
         whois.internic.net and type help to access the full online
         help
     o   send an email message to retrieve information from the
         database.  eg: send email to mailserv@internic.net with
         a command in the Subject field.  Any information in the
         body part of message will be ignored.  ie.
              Subject:  whois <search string>
         Therefore, to find information on the Internic Registration
         Service, the subject should contain: whois internic
         Moreover, to obtain help information on this service you can
         send two separate email with the following in their subject
         line, respectively:

Houser, et al Informational [Page 11] RFC 1865 EDI Meets the Internet January 1996

                           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

Houser, et al Informational [Page 12] RFC 1865 EDI Meets the Internet January 1996

    list would more than offset the cost to support the mailing list
    server. Thus service might be available for free.

3.5. What are the ways to connect to the Internet ?

 The following provides a general overview of connectivity options now
 available:
 a) Dedicated Connection
    Typically a leased telephone line is used to connect a gateway
    computer or Typically a leased telephone line is used to connect a
    gateway computer or bridge/router of a corporate LAN/WAN to the
    router of the Internet Service Provider's (ISP) Point-Of-Presence
    (POP, not to be confused with the Post Office Protocol). The
    connection may be of various types and speeds, e.g.  modem, ISDN,
    DS0, or DS1 line.
    With a dedicated connection, the SMTP protocol is typically used
    to deliver email directly to a trading partners system. Also,
    real-time client server applications can be run directly with a
    trading partners system, including information transferred using
    the FTP and HTTP protocols.
    Some ISPs provide optional services even with dedicated
    connections.  For example, store and forward email on an ISP
    server can be used as a backup for a direct SMTP server operated
    by a trading partner.  The ISP may offer disk space on their FTP
    and HTTP servers with a high speed connection to the Internet.
    For example, a trading partner might use a 14.4Kb modem for
    dedicated email transfers and use a 1.5Mb connection operated by
    the ISP to distribute FTP and HTTP information.
 b) On-demand Connection
    An on-demand connection operates like a dedicated connection,
    except a dialup ISDN or modem connection is used. If the link
    remains idle for a certain period of time, the connection is
    dropped.  Some ISPs offer dial-out capability so any inbound or
    outbound traffic can reestablish the link. However, many ISPs
    require their customers to dial-in, so only outbound traffic and
    regular polling will establish the link. In the latter case, store
    and forward would likely be used for email, and the ISP servers
    would be used for FTP and HTTP information.

Houser, et al Informational [Page 13] RFC 1865 EDI Meets the Internet January 1996

 c) Part-time Polled Connection
    The Unix-to-Unix Copy (UUCP) protocol is typically used for email,
    news, and (rarely) file transfers.  A client organization
    periodically dials the ISP and transfers email and Usenet news for
    the organization, then disconnects.  Typically, the client polls
    the ISP at regular intervals, e.g. every 20 minutes, though some
    ISPs dial out when a message is to be delivered.  Outgoing email
    can be sent immediately, or queued for transmission with a
    specified maximum delay.
    A UUCP connection may be used to transfer messages to an arbitrary
    number of people or automated mail processing programs.  A single
    UUCP connection may also route messages to other systems, e.g.
    divisions within a corporation.  UUCP and store-and-forward are
    synonymous.
    Since UUCP is only used to transfer mail and news messages,
    interactive internet client-server applications like FTP and HTTP
    are not available, except using a server provided by an ISP. Thus
    a separate dialup account might be needed to retrieve information
    from other FTP or HTTP servers. UUCP might be used for automated
    email transfer, and a on-demand dialup connection would be used
    for interactive internet client applications.
    Though UUCP accounts imply a delay (up to the polling interval) in
    processing a message, many ISPs allow a customer supplied script
    to process messages immediately on the ISP's machine.  Though UUCP
    can be used to transfer files directly, usually files are
    transferred by encoding them within an email message.
    Transmission within internet email messages is much more widely
    supported and can be gatewayed into proprietary systems.
 d) Dial-up Shell Account
    With a dial-up account, a single user with a personal computer
    running a terminal emulator connects to the ISP's computer.  Mail
    readers, news readers, HTTP browsers, etc. can be run on the ISP
    machine. Data on the ISP machine can be transferred to the
    personal computer manually using a protocol like X-Modem, Z-Modem,
    or Kermit.
    The ISP's host computer may run one of the usual UNIX command line
    (shell) programs, or may use a custom BBS or other menu driven
    user interface. A proprietary client-server program may be used in
    lieu of a terminal emulator to provide a graphic user interface.
    Some of the proprietary GUI clients provide access to selected
    internet applications, e.g. gopher.

Houser, et al Informational [Page 14] RFC 1865 EDI Meets the Internet January 1996

    A dialup ISP typically has a direct internet connection, however
    very low cost providers might only have a UUCP connection to the
    Internet. Some large proprietary networks such as CompuServe do
    not offer a direct internet connection, and only support UUCP
    email and, sometimes, Usenet news gateways to the Internet.
 d) Personal Serial Line Internet Protocol (SLIP) or Point to Point
    Protocol (PPP) Account
    A SLIP/PPP account is also available as a cross between the on
    demand and dial- up. Like the on-demand account, a single user can
    connect to an ISP and run mail reader, news reader, FTP, HTTP
    browser, etc. client applications directly from a personal
    computer.  Unlike the on-demand account, the dial-out computer
    functions as a client only and not a server, and would be used by
    a single user rather than as a gateway to a LAN.
    With a SLIP/PPP account, the POP (Post-Office-Protocol) protocol
    is used for a user's mail reader client to retrieve messages
    stored in the ISP's server.  Unlike, UUCP, the POP servers hold
    mail for a single user (i.e. individual email address).
    With a SLIP/PPP connection any standard TCP/IP application is tied
    directly into the internet.  Thus unlike the proprietary GUI
    software supplied by the ISP, any TCP/IP client application can be
    used.
    A program such as TIA (The Internet Adapter) can be run on a shell
    account which allows a standard UNIX shell account to function as
    a SLIP/PPP account.  However, some ISPs do not support TIA as they
    charge extra for SLIP.

4. Organizational Issues

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

 There is a tendency for each organization to establish is own rules
 and administrative policies, leading to rising costs of dealing with
 multiple trading partners, each in turn with its own requirements and
 procedures.  However, new technologies and business practices are
 necessary if EDI is to move beyond the 30 to 40,000 organizations
 presently using EDI.  According to Department of Labor and Internal
 Revenue Service statistics, there are about 6.2 million entities with
 employees and about 14 million other "business" entities.  A business
 that wants to sell chairs, for example, would have to check with many
 different customers to see if they had any requirements.  By making
 it possible for a business to use a common method to look for
 customers, the barriers entering to the electronic marketplace are

Houser, et al Informational [Page 15] RFC 1865 EDI Meets the Internet January 1996

 greatly eased.  This does not mean that there is only one source that
 everyone goes to for a list of current business opportunities.
 Rather, a prospective supplier only needs to go to a single
 electronic marketplace.  To communicate with each other, the various
 participants in electronic commerce need to harmonize their
 procedures and processes.  Examples include common trading partner
 registration and the adoption of standard implementation conventions
 for EDI messages.

4.2. My organization has an internal automated system for processing

    requisitions and issuing purchase orders, but it does not create
    the X12 formatted EDI transactions; what should we do ?
 You could enhance your existing system, for example, by adding EDI
 translation software.  VANs often offer EDI "translation"
 capabilities that convert flat text files into EDI X12 or EDIFACT
 format.  This translation software may be designed with a particular
 technical solution in mind; carefully consider how the software would
 be used and what applications and telecommunications software would
 need to interact with it.  You don't want to inadvertently lock
 yourself into using only one supplier.

4.3. My organization already has a dial-in bulletin board service

    (BBS) where we post transactions; should we keep it?
 Yes, but that puts you in the role of being your own VAN.  By acting
 independently, organizations have established their own dial-up
 electronic bulletin board system with their own unique, but
 functionally equivalent, operating rules.  Your BBS will be a little
 different that the next organization's, making it difficult for
 suppliers to access.  By getting transactions from the VANs who
 specialize in moving information, your organization will get the
 widest circulation possible.  You will be able to reach trading
 partners you may not even know existed, resulting in more competitive
 bids.  Because of their idiosyncratic nature, BBS are not consistent
 with the idea of a "single face to industry" espoused by the Federal
 Government.

4.4. My organization currently has a Trading Partner Agreement

    with each trading partner we're currently doing business with.
    Can we keep them ?
 In the short run you may want to keep some Agreements in place to
 cover unique circumstances.  But be careful not to create conflicting
 agreements and directions for your trading partners.  Follow the
 procedures common to your particular line of business.  In the long
 run, less is better.  Hopefully, the introduction of EDI into common
 commercial practice will eliminate the need for EDI-specific

Houser, et al Informational [Page 16] RFC 1865 EDI Meets the Internet January 1996

 agreements.

4.5. It would be nice to get more trading partners and/or more

    competition, but I'm worried about getting too many transactions
    to be able to handle them.  Has this been a problem ?
 The answers to this and related questions presupposes a willingness
 to participate in the open bidding process.  While this process is a
 legal requirement for government agencies, many private organizations
 choose not to adopt the practice.  The technology of the Internet
 facilitates competition, but the cost of putting these practices in
 place limit their value.  This is a business decision, not a
 technical one.  Will companies competitively procure critical
 supplies absent a long term relationship with the supplier? For
 essential inputs that will make or break customer satisfaction and
 productivity, the benefits of competition may not be worth the risks.
 Many organizations experience some increase in the number of
 transactions; for competitive procurements, the winning bid should be
 significantly better than those received prior to using the
 electronic system.  The impact of an increase in volume needs to be
 evaluated on a situation by situation basis.  For example, your
 acquisition support system may need to be re-engineered to quickly
 handle bids by ranking and presenting them to your buyers in low to
 high order.  Your new or enhanced system should make it easy to
 receive and reply to any inter-personal messages that are sent and
 linked to a bid (that is, an SMTP/MIME message or the EDI X12.864
 text message transaction set).

4.6. Does this mean that I'll receive more messages ?

 There is a strong likelihood the number of messages will increase as
 There is a strong likelihood the number of messages will increase as
 you reach more and more trading partners.  After a reasonable trial
 period, your EDI trading partners should be relying on EDI and
 disinclined to use alternative forms of communication that don't fit
 EDI/EC.  Once you use EDI/EC to communicate with a trading partner,
 you should consider discouraging the use of telephone calls or fax
 messages or other non-EDI/EC messages by pointing out the fact that
 telephone or fax messages are processed more slowly.  By using
 electronic messaging, you can establish a written and dated audit
 trail.  Your application system can route the message to the buyer
 and "attach" it to a "case file".  However, if your organization does
 not use automated systems, you will want to adjust your approach to
 dealing with non-EDI messages.

Houser, et al Informational [Page 17] RFC 1865 EDI Meets the Internet January 1996

4.7. If we see a transaction posted on VAN, how do we respond in

    electronic format ?
 This function is typically handled by applications software, not by
 the Internet.  For example, a vendor that wishes to bid on a
 particular Request For Quotation (RFQ) would prepare a bid (X12-843)
 and send it via their VAN of choice.  The identification information
 in the interchange control header (ISA) and functional group header
 (GS) will be interpreted by your VAN and forwarded to the buyer's VAN
 or to the buyer directly, depending on the reply address.  VANs may
 reject messages from unregistered sources; otherwise they are
 forwarded to (or otherwise made available to) the buyer.  If a buyer
 is using dial-up access to a VAN, then they will have to call-in for
 their messages.

4.8. My organization has an established bilateral relationship

    (such as an existing contract.  Can we send these transaction
    via the Internet ?
 Yes, the Internet can be used to send transaction sets to existing
 trading partners via SMTP or FTP messages.  VANs were typically used
 for bilateral relationships between companies, whereas the Internet
 is useful for establishing multilateral relationships.  These
 bilateral relationships are usually quite stable, but both parties
 had to agree to share the same VAN or get their VANs to interconnect.
 Multilateral relationships are between organizations that don't
 necessarily have existing relationships and may be rather ephemeral.
 The Internet is suited to dynamic multilateral relationships that may
 later evolve into static bilateral relationships between companies
 using VANs.  Therefore, the issues concerning the Internet (security,
 availability, etc.) are manageable in the early stages of forming a
 relationship.  If your current VAN is not capable of using the
 Internet, you may need an alternative route for those messages.
 Later, as the business relationship matures, the use of VANs may be
 appropriate as the level of communication becomes more important.
 For example, unless your system has a directory of all registered
 trading partners, you lack the capabilities to screen and validate
 transactions that arrive at your site.

5. The Role Of Value Added Networks

5.1. What is a VAN?

 The use of EDI over the Internet is in the early stages, although the
 technology and services are developing remarkably rapidly.  In the
 past, organizations doing EDI typically have relied on specialized
 firms called Value Added Networks (VANs) for technical assistance.
 Many of these organizations will look to their VAN for assistance in

Houser, et al Informational [Page 18] RFC 1865 EDI Meets the Internet January 1996

 using the Internet.  VANs specializing in EDI applications provide
 technical support, help desk and troubleshooting for EDI and
 telecommunications problems.  They assist in configuration of
 software, upgrades to telecommunications connectivity, data and
 computer security, auditing and tracing of transactions, recovery of
 lost data, service reliability and availability.  Some EDI specific
 services can include broadcasting an RFQ to a collection of vendors,
 or storage of EDI information for later search and retrieval.

5.2. What is an Internet Service Provider (ISP)?

 VAN services have typically used proprietary network or a network
 gatewayed with a specific set of other proprietary networks.  In
 contrast an Internet Service Provider (ISP) offers generic network
 access (i.e. not specific to EDI) for all computers connected to the
 internet. A direct internet connection permits real time computer-
 computer communication for client-server applications.
 Alternatively, a part time internet connection can be used to access
 internet servers using an on-demand basis, or access another system
 via email which includes a store and forward method.  Internet email
 may be used as a gateway to proprietary networks if the proprietary
 network has an email gateway.

5.3. How might an ISP be used for EDI?

 Internet email can be configured for a dedicated connection with
 real-time transfers, or a store and forward method (like traditional
 VANs), or a combination of the two, e.g. where a direct delivery to a
 trading partners system is used when a link is operational, and a
 store and forward from an ISP is used as a backup.
 A large organization can connect their network to the Internet at an
 internet exchange point, however, most use a commercial ISP, either a
 major backbone provider, or local resellers of service off one or
 more backbones. The ISP provides technical assistance and access to
 local telecommunications links.

5.4. Doesn't EDI presume the services of companies called

    Value Added Networks (VANs)?
 EDI only specifies a format for business information; the
 transmission of the information is covered under other standards. A
 real world analog is sending a business form from one company to
 another. The "form" could be sent via US mail, US Registered mail,
 via private carrier (UPS/FEDEX) or simply faxed between the
 companies.  EDI only requires that the trading partners follow the
 content standards.

Houser, et al Informational [Page 19] RFC 1865 EDI Meets the Internet January 1996

5.5. If I can use X12 protocol and my VAN to send transactions,

    what is the benefit of using the Internet?
 The Internet E-mail standards have hierarchical address spaces that
 are defined and updated in what the Internet calls "domain name
 servers."  Unfortunately, X12 has a flat address space.  So, when you
 send an interchange (not via the Internet) to a partner who is on a
 different VAN, your VAN must do a table look up to figure out what
 VAN the receiving party is on.  If you use only X12 without the
 Internet, before you can send a message to this partner, you must
 first contact the recipient's VAN and have them add you as an entry
 to his VAN's table.  If the ISA contained the VAN ID of the
 recipient, then you could (in theory) send interchanges to partners
 via the VAN interconnects without having to notify the recipient's
 VAN first.  However, this theory needs to be worked out in practice.
 In contrast, thanks to the domain name service, Internet e-mail users
 (and Postal users) don't have to call up their service provider
 before sending a message across an "interconnect" to another service
 provider.

5.6. Can we expect VANs to offer connections to other VANs via the

    Internet?
 All VANs connected to the Internet are connected to one another, thus
 avoiding most of the problems of interconnecting proprietary
 networks.  VANs can then focus on services to their customers such as
 automatic bid submission, market and business opportunity analysis,
 and translation software.

5.7. How can I use the Internet directly for exchanging EDI messages

    without going through a VAN?
 You and your trading partner must agree on one of the Internet
 protocols for exchanging messages and then agree upon some details
 with the exchange.
 a) Email based messaging
    The simplest and most widely supported means of exchanging
    messages is via internet email. Typically, the IETF-MIME
    encapsulation specification would be used to enclose the EDI
    data within the email message, and the trading partners would
    need to agree upon an encryption method for secure email,
    typically PEM or PGP (see question 8.4).
    The trading partners would then exchange:
        1. The internet email address for EDI messages
        2. An internet email address for personal communications

Houser, et al Informational [Page 20] RFC 1865 EDI Meets the Internet January 1996

           related to EDI
        3. Agreement on the encryption and digital signature
           protocols, including email acknowledgment, e.g.
           support for the "Return-Receipt-To:" email header,
           or X.400 extended email header fields.
        4. Public Keys for PEM or PGP encryption and digital
           signatures.  (or private keys for DES encryption)
        5. Agreement on the format of the message, e.g. IETF MIME/EDI.
    A convention for naming email addresses might be
    established, e.g. edi@edi.xyzcorp.com for messages,
    ediinfo@xyzcorp.com for an automated response for human readable
    information on establishing internet EDI, and
    edisupport@xyzcorp.com for a personal contact.
 b) FTP based messaging
    To exchange EDI messages via FTP, some setup information must be
    included in the trading partner agreement. Typically, an account
    would be created for each trading partner for a FTP login,
    including a password. Typically, each X12 or EDIFACT message
    would be stored in a file, and the trading partner agreement would
    define the conventions for naming files and directories for
    the messages.
    The trading partner agreement would include:
        1. FTP login name and password
        2. Machine(s) from which the login will be accepted
        3. Additional security protocols, e.g. Kerberos[?]
        4. Directory and file naming conventions
        5. File encryption protocols and keys
        6. Wrappers around EDI data, e.g. MIME/EDI headers,
           PEM/PGP wrappers, etc.
 There are several compression routines and utilities available for
 virtually any computer system that uses the Internet.  Many of these
 utilities will convert across platforms (say UNIX to Mac, UNIX to PC,
 and vise versa) and are available for free from one of several ftp
 archive servers.  Use of these compression routines should be used
 with care when one is employing an encryption technique such as PEM
 or PGP.

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

Houser, et al Informational [Page 21] RFC 1865 EDI Meets the Internet January 1996

 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 ?
 There was an X12 DM (data maintenance) request proposed to the X12
 standards committee for a change to the ISA segment (X12 header
 information) that would allow users to specify the recipient's VAN,
 in addition to the recipient's ID.  The intent was to provide a
 hierarchical address in the ISA.  The top level would be the VAN ID,
 and the next level would be the recipient ID.  To date, this DM has
 not been approved.

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

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

Houser, et al Informational [Page 22] RFC 1865 EDI Meets the Internet January 1996

 (ECTF), chaired by the Administrator, Office of Federal Procurement
 Policy (OFPP), chartered the Federal Electronic Commerce Acquisition
 Team (ECAT) memorandum.  The PMC gave ECAT the task of defining the
 architecture for the government-wide electronic commerce acquisition
 system and identifying the executive departments or agencies
 responsible for developing, implementing, operating, and maintaining
 the Federal electronic system.
 ECAT has become the Federal Electronic Commerce Program Management
 Office (ECA-PMO).  The National Institute or Science and Technology
 (NIST) maintains an HTML home page for the ECA-PMO:
            http://snad.ncsl.nist.gov/dartg/edi/fededi.html

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:

Houser, et al Informational [Page 23] RFC 1865 EDI Meets the Internet January 1996

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

Houser, et al Informational [Page 24] RFC 1865 EDI Meets the Internet January 1996

 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;
 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

Houser, et al Informational [Page 25] RFC 1865 EDI Meets the Internet January 1996

 fraction of the cost of typical EDI VANs.
 The impact of an organization's moving EDI onto the Internet,
 independent of a VAN, is more difficult to assess.  In the view of
 some, the introduction of the Internet in the near term (1-5 years)
 adds additional interfaces and complexity to the organization's
 existing EDI environment.  This may in the short term increase costs
 and raise new costs.  But a corporate commitment to an open systems
 environment through the use of Internet Protocols offers the
 potential for a greater interoperability, integration of application
 systems, and therefore the promise of higher performance and lower
 costs.  Some organizations will be able to get to these benefits
 others will pay for a set of largely incompatible services.  The
 return on investment largely depends on one's ability to consider EDI
 on the Internet as a part of the organization's overall information
 systems strategy and the organization's plans for a presence on the
 Internet.

7. EDI Resources On The Internet

7.1. Are EDI Standards available on the Internet ?

 The Data Interchange Standards Association (DISA)  has a World Wide
 Web server at "http://www.disa.org/"  This Web server has
 considerable information, including a list of new standards, a list
 of all the X12 transaction sets, meeting minutes, calendar of events,
 and lists of courses.  Unfortunately, as of this date, the X12
 standards are not available electronically.  [soap ...] Hopefully
 that will be added soon.  [...soap].  DISA has also set up a gopher
 server (gopher.disa.org) and an FTP server (ftp.disa.org).
 The principle documents regarding ANSI ASC X12's planned alignment
 with EDIFACT are available on the World Wide Web.  The alignment plan
 adopted by a mail ballot of X12 in December 1994/January 1995 is at
                 http:/www.disa.org/info/alinplan.html
 The "floor motion" adopted at the X12 meeting in February 1995 is at:
               http:/www.disa.org/meetings/alinmotn.html
 The following mail lists and exploders support X12 and EDIFACT
 standards development work.

Houser, et al Informational [Page 26] RFC 1865 EDI Meets the Internet January 1996

  1. —————–

X12G Mailing list:

  1. —————–
    This is a fully open exploder set up to support X12G.
    To subscribe send an e-mail message to:
                     x12g-request@snad.ncsl.nist.gov
    The text of the message should only contain the following:
                              subscribe x12g
    After you subscribe, you can broadcast your messages to the
    participants (who have subscribed) via the address
                         x12g@snad.ncsl.nist.gov.
  1. ——————–

FED-REG Mailing list:

  1. ——————–
    This new exploder is concerned with the federal EDI Registry and
    the implementation of IMPDEF within the registry, the  EDI Viewers
    and Editors, and the use of IMPDEF to upgrade EDI products.  The
    nature of this mailist calls for informal discussion focusing on
    pragmatic issues.
    To subscribe send an e-mail message to:
                    fed-reg-request@snad.ncsl.nist.gov
    The text of the message should only contain the following:
                            subscribe fed-reg
    Messages intended for the fed-reg list should be sent to:
                        fed-reg@snad.ncsl.nist.gov
  1. ————————

X12C-IMPDEF Mailing list:

  1. ————————
    This exploder deals with formal discussion in the context of X12
    regarding the evolution of IMPDEF. If would expect that
    discussions in the context of the "fed-reg" exploder result in

Houser, et al Informational [Page 27] RFC 1865 EDI Meets the Internet January 1996

    formal DMRs submitted to "x12c-impdef" and X12C.  Anyway, the
    process will be defined and controlled by the appropriate X12C
    authority.
    To subscribe send an e-mail message to:
                  x12c-impdef-request@snad.ncsl.nist.gov
    The text of the message should only contain the following:
                          subscribe x12c-impdef
    Messages intended for the fed-reg list should be sent to:
                      x12c-impdef@snad.ncsl.nist.gov
    See section 7.7 for additional EDI related mailing lists.

7.2. Are EDIFACT Standards available on the Internet ?

 You can access the EDIFACT standards via GOPHER from the
 International Telecommunications Union (gopher://info.itu.ch).  Here
 are the general directions in getting to the standards.
        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 will get
         D93A (which becomes the standard S94a)
         D94A (which will be next year's standard).
 If you want the UNTDED, select 2.  If you want the UNTDID, select 3.
 When you get to the lowest level directory in which ever path you
 choose, press D (i.e.  upper case D) to download. Choose the protocol
 that suits and you are the proud owner of an EDIFACT Standards
 Directory.
 For electronic mail retrieval, send your message to itudoc@itu.ch
 with no subject and the following message body:
 START
 GET ITU-1900
 END

Houser, et al Informational [Page 28] RFC 1865 EDI Meets the Internet January 1996

7.3. The EDI X12 standards are quite complex. How do we decide what

    X12 transactions to implement and how ?
 There are a number of generic implementation conventions (ICs) or
 guidelines; most ICs are prepared on an industry-by-industry basis.
 Be sure that both you and your current trading partners are working
 from the same set.  The Federal Electronic Commerce for Acquisition
 Program Management Office has been promoting the 3040 version
 throughout the government and the private sector.  Older versions may
 be used in accordance with the ASC X12 rules.  Certain ICs are
 published by the Data Interchange Standards Association (DISA);
 contact DISA at the address above for information about ICs for your
 applications.  Certain ICs as well as the X12 standards may be
 obtained through:
                 Washington Publishing Company
                 c/o EDI Support Services
                 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 via FTP at ds.internic.net.  These
 cover X12 transaction sets 810, 820, 824, 836, 838, 840, 843, 850,
 855, 864, and 997.  The path is pub/ecat.library/fed.ic/xxx where xxx
 can be acrobat.pdf, postscript or ascii file formats.
            ftp://ds.internic.net/pub/ecat.library/fed.ic/
 The SPEEDE/ExPRESS Project, funded by the National Center for
 Education Statistics of the U.S. Dept. of Ed., publishes an
 Implementation Guide for X12 transaction sets 130, 131, 146, 147, and
 997.  The July 1994 versions (each in WordPerfect and in Postscript)
 may be retrieved by anonymous FTP at admissions.carleton.ca.  The
 WordPerfect 5.1 files are found in /pub/wp_speede_2 while the
 Postscript files are found in /pub/ps_guide_2.
             ftp://admissions.carleton.ca/pub/wp_speede_2/
              ftp://admissions.carleton.ca/pub/psguide_2/
 Complete directions for retrieving these files can be found in the
 AACRAO gopher at AACRAO-DEC.NCHE.EDU.  Choose the SPEEDE/ ExPRESS

Houser, et al Informational [Page 29] RFC 1865 EDI Meets the Internet January 1996

 menu item, then Publications, and then select a version of the
 Implementation Guide.  Note that guidelines are sometimes referred to
 by the release/version designation (currently 3040).
 The Defense Information Systems Agency (DISA) Center for Standards is
 the designated configuration manager for DoD Electronic
 Commerce/Electronic Data Interchange (EC/EDI) standards.  The DoD
 EC/EDI Standards repository system, available via anonymous FTP from
 ftp.sterling.com in the /edi/DoD-edi/ directory, contains DoD EDI ICs
 separated into two categories, User and Test.
                  ftp://ftp.sterling.com/edi/DoD-edi/
 Test conventions are identical to User, except that the condition
 designator for all applicable transaction sets, data segments and
 data elements used by that convention are designated as Mandatory for
 test purposes.  Implementation convention files, both user and test
 versions, can be downloaded either individually or all together in
 compressed self-extracting files.  All the implementation files are
 available, when decompressed, in both WordPerfect 5.1/5.2 (.WP) file
 format and Standard Exchange Format (SEF) test files which are for
 use with EDISIM software or any other EDI software that conforms with
 the EDISIM .SEF file format.
 The /DoD-edi/2003_User & _Test directories contain draft DoD
 Implementation Conventions based on ANSI X12 Version 2 Release 3
 (2003):
      840  Request for Quotation
      843  Response to Request for Quotation
      850  Purchase Order
      997  Functional Acknowledgement
 The /DoD-edi/3010_User & _Test directories contain draft DoD
 Implementation Conventions based on ANSI X12 Version 3 Release 1
 (3010):
      810  Invoice:
      810  Commercial
      810  Progress Payment
      810  Public Voucher
      840  Request for Quotation
      843  Response to Request for Quotation
      850  Purchase Order
      997  Functional Acknowledgement
 Additional 2003 and 3010 based conventions may be added in the near
 future.  3010 based conventions will never progress to approved

Houser, et al Informational [Page 30] RFC 1865 EDI Meets the Internet January 1996

 status but will be used temporarily by various DoD agencies to
 implement phase I of the DoD Electronic Commerce (EC)/Electronic Data
 Interchange (EDI) in Contracting Report.
 The /DoD-edi/3050_User directory contains draft DoD Implementation
 Conventions based on ANSI X12 Version 3 Release 5 (3050):
      840  Request for Quotation
      843  Response to Request for Quotation
      850  Purchase Order
      855  Purchase Order Acknowledgement
      860  Purchase Order Change Request - Buyer Initiated
      865  Purchase Order Change Acknowledgement/Request - Seller
           Initiated
 Note that the ICs in the /DoD-edi/3050_USER directory were developed
 as a means to express DOD requirements for an ANSI X12 3050 based
 transaction set.  They are not approved for implementation.  They
 have been submitted to the Federal IC configuration management
 process for adoption throughout the federal government.  Since they
 are subject to Federal review and are based upon a standard not yet
 released, changes can be anticipated.  (See ECA PMO above)

7.5 How can a trading partner keep up with all these implementation

   conventions (ICs) and revisions in X12 and EDIFACT?
 The US government is trying to standardize electronic communications
 internally and with it's 300,000 plus suppliers.  This requires
 standardization of the standards process and cross communication
 between programs.  The IMPDEF message and the NIST Federal IC
 Registry will place electronic versions of all its ICs on the
 Registry - both full federal ICs and individual agency ICs - so that
 any trading partner can download and use them.  In combination with
 message data compliance checking as well, smaller firms should be
 able to get into EDI and start benefitting both themselves and the
 government.

7.6. Where can I get information on EDI translation software ?

 Several commercial trade magazines publish periodic guides to EDI
 translation software.  Under commission by the US Government, the
 Logistics Management Institute (LMI) of McLean, Va. published "A
 Guide to EDI Translation Software, 1994 Edition."  The guide
 describes the features and characteristics of EDI software offered by
 more than 60 vendors.  Commercial organizations can get copies for
 $20 each by sending a check made out to the Logistics Management
 nstitute.  Federal agencies may have up to five free copies by
 sending requests to

Houser, et al Informational [Page 31] RFC 1865 EDI Meets the Internet January 1996

                 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.  Information on subscription follows below.
  1. ———————

IETF-EDI Mailing list:

  1. ———————
    The IETF-EDI list has been established as a forum for discussing
    methods of operating EDI transactions over the Internet, and for
    discussing specifications which permit such operation.  This list
    is therefore focused on the technology of Internet usage of EDI,
    rather than on more general aspects of EDI technology or use.
    To subscribe, send an e-mail message to:
                           LISTSERV@BYU.EDU.
    The text of the message should only contain the following:
                         sub ietf-edi <your-name>
    Messages intended for the ietf-edi list should be sent to:
                            IETF-EDI@BYU.EDU.

Houser, et al Informational [Page 32] RFC 1865 EDI Meets the Internet January 1996

  1. ——————

EDI-L Mailing list:

  1. ——————
    The EDI-L list is target towards more general EDI discussions.
    The edi-l mailing list is also gatewayed to the USENET newsgroup
    bit.listserv.edi-l.
    To subscribe, send an e-mail message to:
                         listserv@uccvma.ucop.edu
    The text of the message should only contain the following:
                       subscribe edi-l <your-name>
    Messages intended for the edi-l list should be sent to:
                          EDI-l@uccvma.ucop.edu
  1. ——————–

EDI-NEW Mailing list:

  1. ——————–
    This list complements ietf-edi in the sense that it promotes
    discussion of new approaches to edi and the extension of edi
    beyond its traditional domains.
    To subscribe, send an e-mail message to:
                    edi-new-request@tegsun.harvard.edu
    The text of the message should only contain the following:
                      subscribe edi-new <your-name>
    Messages intended for the edi-new list should be sent to:
                        edi-new@tegsun.harvard.edu

Houser, et al Informational [Page 33] RFC 1865 EDI Meets the Internet January 1996

  1. ———————

SPEEDE-L Mailing list:

  1. ———————
    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
  1. ———————

OPEN-EDI Mailing list:

  1. ———————
    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
  1. —————–

ECAT Mailing list:

  1. —————–
    The Federal Electronic Commerce for Acquisition Team (ECAT) has
    established an open mail list for those interested in ECAT
    activities.

Houser, et al Informational [Page 34] RFC 1865 EDI Meets the Internet January 1996

    Information sent to the forum address is automatically distributed
    to all forum members. This forum is available 24 hours a day, 7
    days a week. Currently, only ASCII text messages up to 250kb are
    supported.  For best results when sending messages to this forum,
    each line should be limited 70 characters followed by a carriage
    return.  Also, your name and email address should be included in
    the body of messages sent.
    To subscribe, send an e-mail message to:
                         listserv@forums.fed.gov
    The text of the message should only contain the following:
                    subscribe ecat firstname lastname
    Messages intended for the ECAT list should be sent to:
                           ECAT@forums.fed.gov.

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 list are available via FTP from
                   ftp://ftp.sterling.com/edi/lists/

7.9. I have EDI related material I'd like to make available to the

    Internet community.  How do I do that ?
 If you have an existing Internet connected site, you can make the
 information available via FTP or WWW.  If you do not wish to go to
 the effort, send mail to Kent Landfield at
                       edi-archive@sterling.com
 Sterling Software is making the archive publicly available to the
 community.  Anyone who wants to distribute EDI related documents may
 contact Sterling to make your documents publicly available on
 ftp.sterling.com.  For example, the Department of Veterans Affairs
 has posted numerous studies and training materials on EDI which are
 available to the public at ftp.sterling.com/edi/va/.

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

Houser, et al Informational [Page 35] RFC 1865 EDI Meets the Internet January 1996

 make that information publicly available.
        o  ftp://admissions.carleton.ca/pub/
        o  ftp://ds.internic.net/ietf/edi/
        o  ftp://ds.internic.net/pub/ecat.library/
        o  ftp://ftp.sterling.com/edi/
        o  ftp://ftp.swin.edu.au/pub/edi/
        o  ftp://prospero.isi.edu/pub/papers/security/
        o  ftp://turiel.cs.mu.oz.au/pub/edi/
        o  http://snad.ncsl.nist.gov/dartg/edi/fededi.html
        o  http://waltz.ncsl.nist.gov/ECIF/ecif.html
        o  http://www.disa.org/
        o  http://www.acq.osd.mil/ec/
        o  http://www.ietf.cnri.reston.va.us/
        o  http://www.premenos.com/standards/EDIStandards.html

8. Security Considerations

8.1. What security measures are needed to connect to the Internet ?

 Internet security measures can be placed in two broad categories:
 protecting your system from intruders and protecting the content and
 integrity of your messages.  With respect to the latter, EC/EDI
 transactions of nominal value and sensitivity do not require special
 security requirements.  However, if the information has any sensitive
 aspects, you will need to take measures discussed below.  Competitors
 might intercept your bids and undercut your proposal.  Or they could
 monitor your purchases and shipping notices to determine your firm's
 production capacity.  To ensure confidentiality of the message, your
 e-mail system should offer some means of encrypting the message in a
 manner only the intended recipient can read.  Trading partners are
 responsible for satisfying existing rules and regulations relating to
 computer security and privacy.  For example, bid data received by
 government systems is subject to the appropriate controls.  Trading
 partner financial account data is likewise subject to disclosure
 restrictions.  To thwart those who might tamper with a message to
 divert delivery by changing the "ship-to" address, digital signatures
 can attest to the integrity of the message.  Digital signatures can
 also authenticate messages, preventing pranksters or rivals from
 submitting false orders.

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:

Houser, et al Informational [Page 36] RFC 1865 EDI Meets the Internet January 1996

    o  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.
    o  Conduct a risk assessment as described in Appendix M of the
       Federal Electronic Commerce for Acquisition Team report
       Streamlining Procurement Through Electronic Commerce.  This
       documents is available via ftp at ds.internic.net in the
       directory /pub/ecat.library.
    o  Apply the recommendations from NIST Special Publication 800-9,
       Good Security Practices for Electronic Commerce, Including
       Electronic Data Interchange as appropriate.
    o  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.
    o  Review RFC 1281[4] Guidelines for the Secure Operation of
       the Internet and RFC 1244 Holbrook and Reynolds "Site Security
       Handbook"
    o  Review Cheswick and Bellovin's "Firewalls and Internet
       Security - Repelling the Wily Hacker," Addison-Wesley [5]
    o  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?

 These are several free, publicly available, security tools one can
 obtain via ftp from one of many good archives.  If your company uses
 UNIX systems to connect to the Internet or has UNIX systems connected
 to the Internet get and use the following tools:
   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-know problems and holes in UNIX systems and how to fix
 them.

Houser, et al Informational [Page 37] RFC 1865 EDI Meets the Internet January 1996

 The Computer Emergency Response Team (CERT) at Carnegie Mellon
 University can assist with computer break-ins as well as provide
 notices of security activity on the Internet.  The US Department of
 Energy's Computer Incident Advisory Capability (CIAC), located at
 Lawrence Livermore National Laboratory, can provide assistance at
 ciac@llnl.gov or at 510-422-8193.  CIAC offers software and documents
 on their anonymous ftp server at ciac.llnl.gov.  Both CERT and CIAC
 are members of the Forum of Incident Response and Security Teams
 (FIRST), a global organization to foster cooperation and coordination
 among computer security teams worldwide.

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 will find
 a clear and concise description of how these signatures work in Gary
 Ratterree's RIPEM Beginner's Guide; contact Ratterree at
 grayr@cs.tamu.edu.   Other references include:
              ftp://ftp.tis.com/pub/PEM/    for Privacy Enhanced Mail
              ftp://ftp.rsa.com/            for PEM
              ftp net-dist.mit.edu:/pub/PGP for Pretty Good Privacy
                                            (PGP)
 An "infrastructure" for public keys is not required to use public key
 encryption or digital signatures. In the absence of such an
 infrastructure, the encryption protocol and the public keys would
 need to be exchanged bilaterally, such as part of the trading partner
 agreement.  A public key infrastructure would provide a secure means
 to obtain a public key without a need for a manual key exchange.
 But digital techniques will become more convenient with the arrival
 of additional infrastructure and support systems.  The US government
 is taking steps to ensure the admissibility in court of such systems.
 We anticipate that the necessary regulatory and legal infrastructure
 will be in place about the same time as the necessary directory and
 certificate services and other supporting systems come on-line.  We
 expect to see expansion of several government pilot programs in the
 later half of 1994.  NIST recently published a report on the Public
 Key Infrastructure (PKI) and related policy issues; for information
 contact the NIST Computer Security Division at 301-975-2934.

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.

Houser, et al Informational [Page 38] RFC 1865 EDI Meets the Internet January 1996

    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

Houser, et al Informational [Page 39] RFC 1865 EDI Meets the Internet January 1996

 [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 as he prepared the ECAT FAQ which I used (or perhaps
 abused) as the base document.  Artch was judicious and patient as he
 watched his original text being rewritten over and over.
 Carl Hage contributed detailed explanations and clarifications of the
 various Internet protocols and services and how EDI can employ them.
 I would like to thank the following people for their comments and
 specific contributions: Kent Landfield, Mike Bauer, Kit Lueder, Eric
 Christ, Betsy Bainbridge, Bob Lyons, Kirby Spencer, Sally Hambridge,
 Ed Levinson, Warren Smith, Steve Bass, Jerry Johnson, Randy
 VandenBrink, John Pillay, Jim W.C.  Smith, Mark Charles, Jean-
 Philippe Favreau.  I apologize if I omitted any one of the many folks
 who responded to my many calls for comments.
 I greatly appreciate Kent Landfield for his editorial assistance
 during final preparation of this document.  Sterling Software
 graciously hosted the work in progress for ftp access and review,
 saving many bits of Internet SMTP traffic.
 Finally, I am grateful for the patient cooperation of the IETF
 Working Group and the participants of the IETF-EDI and EDI-L lists.
 It's a nice cyberplace to work!
    WRH, Washington, DC.

Houser, et al Informational [Page 40] RFC 1865 EDI Meets the Internet January 1996

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/

Houser, et al Informational [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1865.txt · Last modified: 1996/01/03 00:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki