MIME EDI: MIME Encapsulation of EDI Objects
Three MIME content types that let businesses send EDI interchanges as ordinary Internet email.
Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, DOI 10.17487/RFC1767, March 1995, <https://www.rfc-editor.org/info/rfc1767>.
@misc{rfc1767,
series = {Request for Comments},
number = 1767,
howpublished = {RFC 1767},
publisher = {RFC Editor},
doi = {10.17487/RFC1767},
url = {https://www.rfc-editor.org/info/rfc1767},
author = {D. Crocker},
title = {{MIME Encapsulation of EDI Objects}},
pagetotal = 7,
year = 1995,
month = mar,
} RFC text
Contents
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.
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
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.
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 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.
[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.edu
10. 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.
AI ELI5
On this page
§1EDI Meets MIME
Electronic Data Interchange (EDI) is a way of conducting structured transactions between trading partners. On paper the delivery mechanism was the postal system, so electronic mail is a natural fit for electronic transactions. RFC 1767 lets formatted business interchanges be encapsulated within MIME messages. The basic building block it works with is the interchange.
The scope is narrow. The RFC covers only the encapsulation of EDI objects in the MIME environment. It changes nothing in those objects, whose syntax and semantics stay as defined by their primary specifications. It simply adds Internet email to the many carriage and exchange mechanisms EDI already uses.
The memo only puts business forms into an email envelope. It does not change the forms at all.
§1Three Content Types
Since there are many different EDI specifications, the RFC sorts them into three categories, each with its own MIME content type.
Application/EDI-X12for contents that conform to the specifications developed through the X12 standards organization.Application/EDIFACTfor contents that conform to the specifications of the United Nations Working Party 4 Group of Experts 1 EDIFACT boards.Application/EDI-consentfor all other specifications.
Each is registered in the same template form. The type name is Application, there are no required parameters, and the only optional parameter is CHARSET, as defined for MIME.
There are three stickers for the envelope: one for the X12 kind of form, one for the EDIFACT kind, and one for everything else.
§2EDIFACT and X12 Body Parts
The Application/EDIFACT body part holds data exactly as specified for EDI by the EDIFACT documents. Application/EDI-X12 does the same for ASC X12 data. Both are described as a generic mechanism for sending any interchange of that family. The object is self-defining, meaning it indicates which specific EDI objects it contains, so the MIME type does not need to say.
Most EDI data is text, but some delimiters can be non-printable ASCII, and some data can be pure binary. For such objects the MIME transfer mechanism may need to use Content-Transfer-Encoding: quoted-printable or base64. The rationale given for both types is that these specifications are accepted standards for a class of inter-organization transactions, and this permits their transmission over the Internet by email.
The envelope holds the form untouched, and the form says what it is. If the form has odd symbols that email might mangle, it is first rewritten in a safe code.
§4The EDI-consent Type
Application/EDI-consent carries EDI data that two trading partners have explicitly agreed to exchange under a bilateral agreement. It only provides a standard way of wrapping the objects. It does not specify anything about what is inside.
The RFC says this traffic is substantial and well established, even though it falls outside the usual accredited standards world, and the type gives a standard way to delimit it. There is one firm rule: X12 and EDIFACT objects must be sent using their assigned MIME content types. EDI-consent is for all other EDI objects, and only according to trading partner agreements between the originator and the recipient.
This is the catch-all sticker. It only works if the sender and receiver have already agreed in advance what the forms look like.
§5A Sample Message
The RFC gives a short example of sending a single EDIFACT interchange. It stresses that real use needs attention to considerable detail and that the example only shows the gist. The message has the usual mail headers, a Mime-Version: 1.0 header, a Content-Type: Application/EDIFACT header and, here, Content-Transfer-Encoding: QUOTED-PRINTABLE, followed by the standard EDIFACT interchange as the body.
An appendix helps EDI users unfamiliar with email. It describes the user agent and mail transfer agent model and notes that the transmission steps replaced by Internet modules are the middle ones: MIME encapsulation, RFC 822 packaging, mail submission, SMTP relaying, delivery and stripping. The business program and EDI translator at both ends stay as they were.
It is a normal email with a different sticker on the envelope. The business form is in the letter part.
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>>§7Security Considerations
EDI transactions typically include sensitive data, so transmission often needs to attend to authentication, data integrity, privacy, access control and non-repudiation. This specification makes it possible to send such data over Internet mail and other MIME-capable services, and it says that appropriate security services are essential for sensitive data.
The specification does not itself provide any security mechanism. Where needed, such mechanisms MUST be added, either through Internet MIME-based security services or any other suitable service, such as those provided by EDI-based standards.
The envelope is not locked. If the form is private, you must add your own lock.