RFC 1767 (rfc1767) - Page 2 of 7
MIME Encapsulation of EDI Objects
Alternative Format: Original Text Document
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