diff options
Diffstat (limited to 'doc/rfc/rfc1767.txt')
| -rw-r--r-- | doc/rfc/rfc1767.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1767.txt b/doc/rfc/rfc1767.txt new file mode 100644 index 0000000..a10d356 --- /dev/null +++ b/doc/rfc/rfc1767.txt @@ -0,0 +1,395 @@ + + + + + + +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 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. + + + + + + +Crocker [Page 3] + +RFC 1767 EDI in MIME March 1995 + + +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- + + + +Crocker [Page 4] + +RFC 1767 EDI in MIME March 1995 + + + 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. + + + + +Crocker [Page 5] + +RFC 1767 EDI in MIME March 1995 + + + [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 + + + + +Crocker [Page 6] + +RFC 1767 EDI in MIME March 1995 + + +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. + + + + + + + + + + + +Crocker [Page 7] + |