Graduate School of Business
University of Texas at Austin

D. Crocker
Network Working Group D. Crocker
Internet-Draft: DRAFT-CROCKER-EDI-02.{txt,ps}
Expiration <6/95>

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

3. Application/EDIFACT Specification

4. Application/EDI-Consent Specification

5. Sample EDI Usage in MIME-based email

6. References

7. Security Considerations

8. Acknowledgments

9. Contact

A. APPENDIX - MIME FOR EDI USERS

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.

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

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

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.

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-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 X12-EDI interchange:

To: <>
Subject:
From: <>
Date:
Mime-Version: 1.0
Content-Type: Application/EDI-X12
Content-Transfer-Encoding: QUOTED-PRINTABLE
<>

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.

[Brad89] Braden, R.T., "Requirements for Internet hosts - application and support". October, 1989, Network Information Center, RFC 1321.

[Croc82] Crocker, D., "Standard for the Format of Internet Text Messages". September, 1982, Network Information Center, RFC 822.

[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". October, 1982, Network Information Center, RFC 821.

[X12V] Data Interchange Standards Association; sets of specific EDI standards are ordered by their version number; Washington D.C.

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

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.

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

David H. Crocker

Brandenburg Consulting, 675 Spruce Dr., Sunnyvale, CA 94086 USA
Phone: +1 408 246 8253; Fax: +1 408 249 6205

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 by RFC822 and RFC1123 [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.