rfc1767.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 396 行 · 第 1/2 页

Network Working Group                                         D. Crocker
Request for Comments: 1767                        Brandenburg Consulting
Category: Standards Track                                     March 1995


                   MIME Encapsulation of EDI Objects

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Introduction...........................................  1
   2. Application/EDIFACT specification......................  2
   3. Application/EDI-X12 specification......................  3
   4. Application/EDI-Consent specification..................  4
   5. Sample edi usage in MIME-based email...................  5
   6. References.............................................  5
   7. Security Considerations................................  6
   8. Acknowledgments........................................  6
   9. Author's Address.......................................  6
   10. Appendix - MIME for EDI users.........................  7

1.  Introduction

   Electronic Data Interchange (EDI) provides a means of conducting
   structured transactions between trading partners.  The delivery
   mechanism for these types of transactions in a paper world has been
   the postal system, so it is to be expected that electronic mail would
   serve as a natural delivery mechanism for electronic transactions.
   This specification permits formatted electronic business interchanges
   to be encapsulated within MIME messages [Bore92].  For the
   specification effort, the basic building block from EDI is an
   interchange.

   This specification pertains only to the encapsulation of EDI objects
   within the MIME environment.  It intends no changes in those objects
   from the primary specifications that define the syntax and semantics
   of them.  EDI transactions take place through a variety of carriage
   and exchange mechanisms.  This specification adds to that repertoire,
   by permitting convenient carriage through Internet email.





Crocker                                                         [Page 1]

RFC 1767                      EDI in MIME                     March 1995


   Since there are many different EDI specifications, the current
   document defines three distinct categories as three different MIME
   content-types.  One is Application/EDI-X12, indicating that the
   contents conform to the range of specifications developed through the
   X12 standards organization [X125, X126, X12V].  Another is
   Application/EDIFACT, indicating that the contents conform to the
   range of specifications developed by the United Nations Working Party
   4 Group of Experts 1 EDIFACT boards [FACT, FACV].  The last category
   covers all other specifications; it is Application/EDI-consent.

2.     APPLICATION/EDIFACT SPECIFICATION

   The Application/EDIFACT MIME body-part contains data as specified for
   electronic data interchange by [FACT, FACV].

   Within EDIFACT, information is specified by:

   MIME type name:               Application

   MIME subtype name:            EDIFACT

   Required parameters:          none

   Optional parameters:          CHARSET, as defined for MIME

   Encoding considerations:      May need BASE64 or QUOTED-PRINTABLE
                                 transfer encoding

   Security considerations:      See separate section in the
                                 document.

   Published specification:      Contained in the following section.

   Rationale:                    The EDIFACT specifications are
                                 accepted standards for a class of
                                 inter-organization transactions;
                                 this permits their transmission
                                 over the Internet, via email.

   Contact-info:                 See Contact section, below.

   Detail specific to MIME-based usage:

        This is a generic mechanism for sending any EDIFACT
        interchange.  The object is self-defining, in terms of
        indicating which specific EDI objects are included.  Most
        EDI data is textual, but special characters such as some
        delimiters may be non-printable ASCII or some data may be



Crocker                                                         [Page 2]

RFC 1767                      EDI in MIME                     March 1995


        pure binary.  For EDI objects containing such data, the MIME
        transfer mechanism may need to encode the object in Content-
        Transfer-Encoding:quoted-printable or base64.

3.     APPLICATION/EDI-X12 SPECIFICATION

   The Application/EDI-X12 MIME body-part contains data as specified for
   electronic data interchange by  [X125, X12.6, EDIV].

   Within MIME, EDI-X12 information is specified by:

   MIME type name:               Application

   MIME subtype name:            EDI-X12

   Required parameters:          none

   Optional parameters:          CHARSET, as defined for MIME

   Encoding considerations:      May need BASE64 or QUOTED-PRINTABLE
                                 transfer encoding

   Security considerations:      See separate section in the
                                 document.

   Published specification:      Contained in the following section.

   Rationale:                    The ASC X12 EDI specifications are
                                 accepted standards for a class of
                                 inter-organization transactions;
                                 this permits their transmission
                                 over the Internet, via email.

   Contact-info:                 See Contact section, below.

   Detail specific to MIME-based usage:

        This is a generic mechanism for sending any ASC X12
        interchange.  The object is self-defining, in terms of
        indicating which specific EDI objects are included.  Most
        EDI data is textual, but special characters such as some
        delimiters may be non-printable ASCII or some data may be
        pure binary.  For EDI objects containing such data, the MIME
        transfer mechanism may need to encode the object in Content-
        Transfer-Encoding:quoted-printable or base64.






Crocker                                                         [Page 3]

RFC 1767                      EDI in MIME                     March 1995


4.     APPLICATION/EDI-CONSENT SPECIFICATION

   The Application/EDI-consent MIME body-part contains data as specified
   for electronic data interchange with the consent of explicit,
   bilateral trading partner agreement exchanging the EDI-consent
   traffic.  As such, use of EDI-consent only provides a standard
   mechanism for "wrapping" the EDI objects but does not specify any of
   the details about those objects.

   Within MIME, EDI-consent information is specified by:

   MIME type name:               Application

   MIME subtype name:            EDI-consent

   Required parameters:          none

   Optional parameters:          CHARSET, as defined for MIME

   Encoding considerations:      May need BASE64 or QUOTED-PRINTABLE
                                 transfer encoding

   Security considerations:      See separate section in the
                                 document.