MIME Encapsulation of EDI Objects
RFC 1767
Document | Type |
RFC - Proposed Standard
(March 1995; No errata)
Was draft-ietf-edi-mime (edi WG)
|
|
---|---|---|---|
Author | Dave Crocker | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1767 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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. Crocker [Page 1] 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 [Page 2] RFC 1767 EDI in MIME March 1995 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 forShow full document text