Internet Draft Application/EDI-X12 (Expiration: 11/94) D. Crocker Network Working Group D. Crocker Internet Draft: DRAFT-CROCKER-EDI-02.{txt,ps} Expiration <11/94> MIME Encapsulation of EDI Objects Status of This Memo This is a preliminary draft document, intended for eventual submission to the IETF working group process. At this stage, the document should be viewed strictly as a think-piece, with comments, corrections, etc. eagerly sought. Summary This document is an Internet Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress." IETF Information is available by anonymous FTP from several Internet sites. Please check the 1id-abstracts.txt listing to learn the current status of any Internet Draft. Table Of Contents 1. Introduction 2. APPLICATION/EDI-X12 Content-Subtype Usage in MIME 3. APPLICATION/EDIFACT Specification 4. APPLICATION/EDI-Consent Specification 5. EDI Usage in MIME 6. References 7. Security Considerations 8. Acknowledgments 9. Contact 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]. The basic building block from EDI is a functional group of transaction sets, as defined below. In most cases, these transaction sets are transmitted in formally packaged EDI enveloping structures, called interchanges. 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. 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. Another is Application/EDIFACT, indicating that the contents conform to the range of specifications developed by the United Nations <> organization. The last category covers all other specifications; it is Application/EDI-consent. 2. APPLICATION/EDI-X12 Content-Subtype Usage in 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 BINARY 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 transaction set. The interchange parameter at the beginning of the EDI object is used to specify the particular EDI transaction set that is included. 3. APPLICATION/EDIFACT Specification The APPLICATION/EDIFACT MIME body-part contains data as specified for electronic data interchange by ASC [EDIX12]. 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 BINARY 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 transaction set. The interchange parameter at the beginning of the EDI object used to specify the particular EDI transaction set that is included. 4. APPLICATION/EDI-Consent Specification The APPLICATION/EDI-other 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-other only provides a standard mechanism for "wrapping" the EDI objects but does not specify any of the details about those objects. EDI-other 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 BINARY 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. 5. EDI Usage in MIME To send a single bundle of one, or more, X12-EDI transaction units: To: <> Subject: From: <> Date: Mime-Version: 1.0 Content-Type: APPLICATION/EDI-X12 Content-Transfer-Encoding: BINARY <> 6. References [Bore92] Borenstein, N. & Freed, N., "Mime (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing The Format of Internet Message Bodies. March, 1992, Network Information Center, RFC 1341. [EDIX12] ASC X12.5 Interchange Control Structure, and other specifications. [EDIFACT] "UN/EDIFACT Syntax Rules," ISO 9735, 1991. 7. Security Considerations EDI transactions typically include sensitive data, so that transmission often needs to account for authentication, data integrity, privacy, access control and non-repudiation concerns. This specification permits transmission of such sensitive data via Internet mail. It does NOT provide any security-related mechanisms. As needed and appropriate, such mechanisms MUST be added to the Internet MIME-based service for this capability to provide sufficient protection of EDI records. 8. Acknowledgments Tom Jones offered introductory text and descriptions of candidate header options. 9. Contact David H. Crocker Phone: +1 408 246 8253; Fax: +1 408 249 6205