rfc1865.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,393 行 · 第 1/5 页

          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. [e-mail] for messages,
      [e-mail] for an automated response for human readable
      information on establishing internet EDI, and
      [e-mail] 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 c