MIME Encapsulation of EDI Objects
Extracted elements (13)
EDI-consent exists because '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.' It provides a standard delimiting mechanism without endorsing any specific non-standard EDI format.
Internet email is identified as the natural electronic delivery mechanism for EDI transactions because EDI historically replaced paper-based postal interchange. MIME encapsulation adds to the EDI repertoire without changing the primary EDI syntax/semantics specifications.
Three distinct MIME content-types are defined rather than one because EDIFACT and X12 are separately accredited standards organizations with distinct specifications, while EDI-consent covers the wide range of existing bilateral EDI practice that does not fit into either accredited standard.
Application/EDI-consent may only be used by trading partners with explicit bilateral agreement; it cannot substitute for Application/EDI-X12 or Application/EDIFACT when those content types are appropriate.
EDI data may contain non-printable ASCII characters (e.g., delimiters) or pure binary data. For such objects, MIME Content-Transfer-Encoding of quoted-printable or base64 must be used to ensure safe transport through Internet mail infrastructure.
For transmission of sensitive EDI data, appropriate security services such as authentication, privacy, and/or non-repudiation MUST be added, either via Internet MIME-based security services or EDI-based standards. This specification itself provides no security mechanisms.
X12 and EDIFACT objects MUST be sent using their assigned MIME content types (Application/EDI-X12 and Application/EDIFACT respectively). EDI-consent is reserved exclusively for all other EDI objects under trading partner agreement.
Application/EDI-consent is a MIME content-type for EDI data exchanged under explicit bilateral trading partner agreement. It does not specify details of the EDI objects themselves, only provides a standard wrapping mechanism for non-X12, non-EDIFACT EDI traffic.
Application/EDI-X12 is a MIME content-type for EDI data conforming to ASC X12 specifications (ANSI X12.5, X12.6, EDIV). It requires no mandatory parameters; CHARSET is optional. The object is self-defining as to which specific EDI objects are included.
Application/EDIFACT is a MIME content-type for EDI data conforming to UN/EC EDIFACT specifications (ISO 9735). It requires no mandatory parameters; CHARSET is optional. The object is self-defining as to which specific EDI objects are included.
This document registers three new MIME subtypes under the Application type: EDIFACT, EDI-X12, and EDI-consent. Each registration follows the MIME type registration template with type name, subtype name, required/optional parameters, encoding considerations, security considerations, and rationale.
EDI transactions typically include sensitive data requiring authentication, data integrity, privacy, access control, and non-repudiation. This specification permits transmission of such data via Internet mail and MIME but does not itself provide any of these security services; they must be added externally.
A MIME-encapsulated EDIFACT interchange requires at minimum: MIME-Version header (1.0), Content-Type header (Application/EDIFACT), and Content-Transfer-Encoding header (e.g., QUOTED-PRINTABLE), followed by the standard EDIFACT interchange body.