Movatterモバイル変換

Network Working Group                                         D. CrockerRequest for Comments: 1767                        Brandenburg ConsultingCategory: Standards Track                                     March 1995MIME Encapsulation of EDI ObjectsStatus 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 Contents1. Introduction...........................................12. Application/EDIFACT specification......................23. Application/EDI-X12 specification......................34. Application/EDI-Consent specification..................45. Sample edi usage in MIME-based email...................56. References.............................................57. Security Considerations................................68. Acknowledgments........................................69. Author's Address.......................................610. Appendix - MIME for EDI users.........................71.  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 beCrocker                                                         [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 19954.     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.   Published specification:      Contained in the following section.   Rationale:                    Existing practice for exchanging                                 EDI includes a very wide range of                                 specifications which are not part                                 of the usual, accredited standards                                 world.  Nevertheless, this traffic                                 is substantial and well-                                 established.  This content type                                 provides a means of delimiting such                                 content in a standard fashion.   Contact-info:                 See Contact section, below.   Detail specific to MIME-based usage:        This is a generic mechanism for sending any EDI object        explicitly agreed to by the trading partners.  X12 and        EDIFACT object must be sent using their assigned MIME        content type.  EDI-consent is for all other EDI objects, but        only according to trading partner agreements between the        originator and the recipient.   Most EDI data is textual,        but special characters such as some delimiters may be non-Crocker                                                         [Page 4]

RFC 1767                      EDI in MIME                     March 1995        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.5.     SAMPLE EDI USAGE IN MIME-BASED EMAIL   Actual use of EDI within MIME-based mechanisms requires attention to   considerable detail.  This section is intended as an example of the   gist of the formatting required to encapsulate EDI objects within   Internet mail, using MIME.  To send a single EDIFACT interchange:   To:  <<recipient organization EDI email address>>   Subject:   From: <<sending organization EDI email address>>   Date:   Mime-Version: 1.0   Content-Type: Application/EDIFACT   Content-Transfer-Encoding:  QUOTED-PRINTABLE   <<standard EDIFACT Interchange goes here>>6.     REFERENCES   [Bore92]    Borenstein, N., and N. Freed, "MIME (Multipurpose               Internet Mail Extensions) Part One: Mechanisms for               Specifying and Describing the Format of Internet Message               Bodies",RFC 1521, Bellcore, Innosoft, September 1993.   [Brad89]    Braden, R., Editor, "Requirements for Internet Hosts -               Application and Support", STD 3,RFC 1123, Internet               Engineering Task Force, October 1989.   [Croc82]    Crocker, D.,  "Standard for the Format of Internet               Text Messages", STD 11,RFC 822, UDEL, August 1982.   [Rose93]    Rose, M., "The Internet Message: Closing the Book               with Electronic Mail", PTR Prentice Hall, Englewood               Cliffs, N.J., 1993.   [Post82]    Postel, J.,  "Simple Mail Transfer Protocol".               STD 10,RFC 821, USC/Information Sciences Institute,               August 1982.   [X12V]      Data Interchange Standards Association; sets of               specific EDI standards are ordered by their version               number; Washington D.C.Crocker                                                         [Page 5]

RFC 1767                      EDI in MIME                     March 1995   [X125]      ANSI X12.5 Interchange Control Structure for               Electronic Data Interchange, Washington D.C.: DISA   [X126]      ANSI X12.6 Applications Control Structures for               Electronic Data Interchange, Washington D.C.: DISA   [FACT]      United Nations Economic Commission (UN/EC)               Electronic Data Interchange For Administration,               Commerce and Transport (EDIFACT) - Application Level               Syntax Rules (ISO 9735), 1991.   [FACV]      Version sets contains the specific syntax documents,               the element and segment dictionaries, and the               transaction/message specifications.7.     SECURITY CONSIDERATIONS   EDI transactions typically include sensitive data, so that   transmission often needs to attend to authentication, data integrity,   privacy, access control and non-repudiation concerns.  This   specification permits transmission of such sensitive data via   Internet mail and other services which support MIME object   encapsulation.  For transmission of sensitive data, it is essential   that appropriate security services, such as authentication, privacy   and/or non-repudiation be provided.   This specification does NOT, itself, provide any security-related   mechanisms.  As needed and appropriate, such mechanisms MUST be   added, either via Internet MIME-based security services or any other   services which are appropriate to the user requirements, such as   those provided by EDI-based standards.8.     ACKNOWLEDGMENTS   Tom Jones offered introductory text and descriptions of candidate   header options.  Numerous working group participants provided review   and comment, especially Walt Houser, Gail Jackson, and Jim Amster.9.     AUTHOR'S ADDRESS   David H. Crocker   Brandenburg Consulting   675 Spruce Dr.   Sunnyvale, CA 94086 USA   Phone:  +1 408 246 8253   Fax:  +1 408 249 6205   EMail: dcrocker@mordor.stanford.eduCrocker                                                         [Page 6]

RFC 1767                      EDI in MIME                     March 199510.    APPENDIX - MIME FOR EDI USERS   To assist those familiar with EDI but not with Internet electronic   mail, this Appendix is provided as a very brief introduction,   primarily to give pointers to the relevant specifications.  This   section is in no way intended to be a thorough introduction.  An   excellent introductory text is [Rose93].   Internet electronic mail follows the classic user agent/mail transfer   agent model.  In this model, user software produces a standardized   object which is transferred via standard exchange protocols.   An Internet electronic mail object comprises a collection of headers,   followed by a (possibly structured) body.  The headers specify such   information as author and recipient addresses, subject summary,   creation date, handling node names, and so on, and are defined byRFC822 andRFC1123 [Croc82,Brad89].  If the body is structured, it   conforms to the rules of the Multipurpose Internet Message Exchange   (MIME) [Bore92].  A structured body may have parts encoded in   different text character sets, or even of entirely different types of   data, such as voice or graphics.   The Simple Mail Transfer Protocol (SMTP) [Post82,Brad89] performs   the primary task of message transmission.  User posting and delivery   interactions, between the user agent and the message transfer agent,   on the same machine, are not standardized and are platform-specific.   An EDI-related use of Internet Mime email will have (at least) the   following components:       Business Program/Data base -> EDI Translator ->       -> MIME encapsulation ->RFC822 packaging -> mail       submission ->       -> SMTP relaying ->       -> mail delivery ->RFC822 & Mime stripping ->       -> EDI Translator -> Business processing   The first and last lines show components normal to all EDI activities,   so that it is only the EDI "transmission" components that are replaced   with Internet modules.Crocker                                                         [Page 7]