idnits 2.17.1 draft-ietf-edi-mime-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 81 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 291: '...d appropriate, such mechanisms MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1341 (ref. 'Bore92') (Obsoleted by RFC 1521) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'Brad89') ** Obsolete normative reference: RFC 822 (ref. 'Croc82') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'Rose93' ** Obsolete normative reference: RFC 821 (ref. 'Post82') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'X12V' -- Possible downref: Non-RFC (?) normative reference: ref. 'X125' -- Possible downref: Non-RFC (?) normative reference: ref. 'X126' -- Possible downref: Non-RFC (?) normative reference: ref. 'FACT' -- Possible downref: Non-RFC (?) normative reference: ref. 'FACV' Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Crocker 2 Internet-Draft: DRAFT-IETF-EDI-MIME-01.{txt,ps} Brandenburg Consulting 3 Expiration <6/95> 5 MIME Encapsulation of EDI Objects 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as ``work 18 in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet- 22 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 23 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 24 Coast), or ftp.isi.edu (US West Coast). 26 TABLE OF CONTENTS 28 1. Introduction 29 2. Application/EDIFACT specification 30 3. Application/EDI-X12 specification 31 4. Application/EDI-Consent specification 32 5. Sample edi usage in MIME-based email 33 6. References 34 7. Security considerations 35 8. Acknowledgments 36 9. Contact 37 10. Appendix - MIME for EDI users 39 D. Crocker 1 40 Introduction 42 Electronic Data Interchange (EDI) provides a means of conducting 43 structured transactions between trading partners. The delivery 44 mechanism for these types of transactions in a paper world has 45 been the postal system, so it is to be expected that electronic 46 mail would serve as a natural delivery mechanism for electronic 47 transactions. This specification permits formatted electronic 48 business interchanges to be encapsulated within MIME messages 49 [Bore92]. For the specification effort, the basic building block 50 from EDI is an interchange. 52 This specification pertains only to the encapsulation of EDI 53 objects within the MIME environment. It intends no changes in 54 those objects from the primary specifications that define the 55 syntax and semantics of them. EDI transactions take place 56 through a variety of carriage and exchange mechanisms. This 57 specification adds to that repertoire, by permitting convenient 58 carriage through Internet email. 60 Since there are many different EDI specifications, the current 61 document defines three distinct categories as three different 62 MIME content-types. One is Application/EDI-X12, indicating that 63 the contents conform to the range of specifications developed 64 through the X12 standards organization [X125, X126, X12V]. 65 Another is Application/EDIFACT, indicating that the contents 66 conform to the range of specifications developed by the United 67 Nations Working Party 4 Group of Experts 1 EDIFACT boards [FACT, 68 FACV]. The last category covers all other specifications; it is 69 Application/EDI-consent. 71 2. APPLICATION/EDIFACT SPECIFICATION 73 The Application/EDIFACT MIME body-part contains data as specified 74 for electronic data interchange by [FACT, FACV]. 76 D. Crocker 2 77 Within EDIFACT, information is specified by: 79 MIME type name: Application 81 MIME subtype name: EDIFACT 83 Required parameters: none 85 Optional parameters: CHARSET, as defined for MIME 87 Encoding considerations: May need BASE64 or QUOTED-PRINTABLE 88 transfer encoding 90 Security considerations: See separate section in the 91 document. 93 Published specification: Contained in the following section. 95 Rationale: The EDIFACT specifications are 96 accepted standards for a class of 97 inter-organization transactions; 98 this permits their transmission 99 over the Internet, via email. 101 Contact-info: See Contact section, below. 103 Detail specific to MIME-based usage: 105 This is a generic mechanism for sending any EDIFACT 106 interchange. The object is self-defining, in terms of 107 indicating which specific EDI objects are included. Most 108 EDI data is textual, but special characters such as some 109 delimiters may be non-printable ASCII or some data may be 111 D. Crocker 3 112 pure binary. For EDI objects containing such data, the MIME 113 transfer mechanism may need to encode the object in Content- 114 Transfer-Encoding:quoted-printable or base64. 116 3. APPLICATION/EDI-X12 SPECIFICATION 118 The Application/EDI-X12 MIME body-part contains data as specified 119 for electronic data interchange by [X125, X12.6, EDIV]. 121 Within MIME, EDI-X12 information is specified by: 123 MIME type name: Application 125 MIME subtype name: EDI-X12 127 Required parameters: none 129 Optional parameters: CHARSET, as defined for MIME 131 Encoding considerations: May need BASE64 or QUOTED-PRINTABLE 132 transfer encoding 134 Security considerations: See separate section in the 135 document. 137 Published specification: Contained in the following section. 139 Rationale: The ASC X12 EDI specifications are 140 accepted standards for a class of 141 inter-organization transactions; 142 this permits their transmission 143 over the Internet, via email. 145 Contact-info: See Contact section, below. 147 D. Crocker 4 148 Detail specific to MIME-based usage: 150 This is a generic mechanism for sending any ASC X12 151 interchange. The object is self-defining, in terms of 152 indicating which specific EDI objects are included. Most 153 EDI data is textual, but special characters such as some 154 delimiters may be non-printable ASCII or some data may be 155 pure binary. For EDI objects containing such data, the MIME 156 transfer mechanism may need to encode the object in Content- 157 Transfer-Encoding:quoted-printable or base64. 159 4. APPLICATION/EDI-CONSENT SPECIFICATION 161 The Application/EDI-consent MIME body-part contains data as 162 specified for electronic data interchange with the consent of 163 explicit, bilateral trading partner agreement exchanging the EDI- 164 consent traffic. As such, use of EDI-consent only provides a 165 standard mechanism for "wrapping" the EDI objects but does not 166 specify any of the details about those objects. 168 Within MIME, EDI-consent information is specified by: 170 MIME type name: Application 172 MIME subtype name: EDI-consent 174 Required parameters: none 176 Optional parameters: CHARSET, as defined for MIME 178 Encoding considerations: May need BASE64 or QUOTED-PRINTABLE 179 transfer encoding 181 Security considerations: See separate section in the 182 document. 184 D. Crocker 5 185 Published specification: Contained in the following section. 187 Rationale: Existing practice for exchanging 188 EDI includes a very wide range of 189 specifications which are not part 190 of the usual, accredited standards 191 world. Nevertheless, this traffic 192 is substantial and well- 193 established. This content type 194 provides a means of delimiting such 195 content in a standard fashion. 197 Contact-info: See Contact section, below. 199 Detail specific to MIME-based usage: 201 This is a generic mechanism for sending any EDI object 202 explicitly agreed to by the trading partners. X12 and 203 EDIFACT object must be sent using their assigned MIME 204 content type. EDI-consent is for all other EDI objects, but 205 only according to trading partner agreements between the 206 originator and the recipient. Most EDI data is textual, 207 but special characters such as some delimiters may be non- 208 printable ASCII or some data may be pure binary. For EDI 209 objects containing such data, the MIME transfer mechanism 210 may need to encode the object in Content-Transfer- 211 Encoding:quoted-printable or base64. 213 5. SAMPLE EDI USAGE IN MIME-BASED EMAIL 215 Actual use of EDI within MIME-based mechanisms requires attention 216 to considerable detail. This section is intended as an example 217 of the gist of the formatting required to encapsulate EDI objects 219 D. Crocker 6 221 Internet Draft EDI in MIME (Expiration: 6/95) 223 within Internet mail, using MIME. To send a single EDIFACT 224 interchange: 226 To: <> 227 Subject: 228 From: <> 229 Date: 230 Mime-Version: 1.0 231 Content-Type: Application/EDIFACT 232 Content-Transfer-Encoding: QUOTED-PRINTABLE 234 <> 236 6. REFERENCES 238 [Bore92] Borenstein, N. & Freed, N., "Mime (Multipurpose 239 Internet Mail Extensions): Mechanisms for 240 Specifying and Describing The Format of Internet 241 Message Bodies". March, 1992, Network Information 242 Center, RFC 1341. 244 [Brad89] Braden, R.T., "Requirements for Internet hosts - 245 application and support". October, 1989, Network 246 Information Center, RFC 1321. 248 [Croc82] Crocker, D., "Standard for the Format of Internet 249 Text Messages". September, 1982, Network 250 Information Center, RFC 822. 252 [Rose93] Rose, M., "The Internet Message: Closing the Book 253 with Electronic Mail". PTR Prentice Hall, Englewood 254 Cliffs, N.J. (1993) 256 [Post82] Postel, J., "Simple Mail Transfer Protocol". 257 October, 1982, Network Information Center, RFC 821. 259 D. Crocker 7 260 [X12V] Data Interchange Standards Association; sets of 261 specific EDI standards are ordered by their version 262 number; Washington D.C. 264 [X125] ANSI X12.5 Interchange Control Structure for 265 Electronic Data Interchange, Washington D.C.: DISA 267 [X126] ANSI X12.6 Applications Control Structures for 268 Electronic Data Interchange, Washington D.C.: DISA 270 [FACT] United Nations Economic Commission (UN/EC) 271 Electronic Data Interchange For Administration, 272 Commerce and Transport (EDIFACT) - Application Level 273 Syntax Rules (ISO 9735), 1991. 275 [FACV] Version sets contains the specific syntax documents, 276 the element and segment dictionaries, and the 277 transaction/message specifications. 279 7. SECURITY CONSIDERATIONS 281 EDI transactions typically include sensitive data, so that 282 transmission often needs to attend to authentication, data 283 integrity, privacy, access control and non-repudiation concerns. 284 This specification permits transmission of such sensitive data 285 via Internet mail and other services which support MIME object 286 encapsulation. For transmission of sensitive data, it is 287 essential that appropriate security services, such as 288 authentication, privacy and/or non-repudiation be provided. 290 This specification does NOT, itself, provide any security-related 291 mechanisms. As needed and appropriate, such mechanisms MUST be 292 added, either via Internet MIME-based security services or any 294 D. Crocker 8 295 other services which are appropriate to the user requirements, 296 such as those provided by EDI-based standards. 298 8. ACKNOWLEDGMENTS 300 Tom Jones offered introductory text and descriptions of candidate 301 header options. Numerous working group participants provided 302 review and comment, especially Walt Houser, Gail Jackson, and Jim 303 Amster. 305 9. CONTACT 307 David H. Crocker 309 Brandenburg Consulting 310 675 Spruce Dr. 311 Sunnyvale, CA 94086 USA 313 315 Phone: +1 408 246 8253 316 Fax: +1 408 249 6205 318 10. APPENDIX - MIME FOR EDI USERS 320 To assist those familiar with EDI but not with Internet 321 electronic mail, this Appendix is provided as a very brief 322 introduction, primarily to give pointers to the relevant 323 specifications. This section is in no way intended to be a 324 thorough introduction. An excellent introductory text is 325 [Rose93]. 327 D. Crocker 9 328 Internet electronic mail follows the classic user agent/mail 329 transfer agent model. In this model, user software produces a 330 standardized object which is transferred via standard exchange 331 protocols. 333 An Internet electronic mail object comprises a collection of 334 headers, followed by a (possibly structured) body. The headers 335 specify such information as author and recipient addresses, 336 subject summary, creation date, handling node names, and so on, 337 and are defined by RFC822 and RFC1123 [Croc82, Brad89]. If the 338 body is structured, it conforms to the rules of the Multipurpose 339 Internet Message Exchange (MIME) [Bore92]. A structured body may 340 have parts encoded in different text character sets, or even of 341 entirely different types of data, such as voice or graphics. 343 The Simple Mail Transfer Protocol (SMTP) [Post82, Brad89] 344 performs the primary task of message transmission. User posting 345 and delivery interactions, between the user agent and the message 346 transfer agent, on the same machine, are not standardized and are 347 platform-specific. 349 An EDI-related use of Internet Mime email will have (at least) 350 the following components: 352 Business Program/Data base -> EDI Translator -> 353 -> MIME encapsulation -> RFC822 packaging -> mail 354 submission -> 355 -> SMTP relaying -> 356 -> mail delivery -> RFC822 & Mime stripping -> 357 -> EDI Translator -> Business processing 359 The first and last lines show components normal to all EDI 360 activities, so that it is only the EDI "transmission" components 361 that are replaced with Internet modules. 363 D. Crocker 10 365 -------------------- 366 Dave Crocker 367 Brandenburg Consulting +1 408 246 8253 368 675 Spruce Dr. fax: +1 408 249 6205 369 Sunnyvale, CA 94086 dcrocker@mordor.stanford.edu