idnits 2.17.1 draft-ietf-ediint-as2-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** There are 38 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 203 has weird spacing: '...dresses as de...' == Line 231 has weird spacing: '...nt-type heade...' == Line 277 has weird spacing: '...usiness data ...' == Line 325 has weird spacing: '...cations for e...' == Line 340 has weird spacing: '...ined in secti...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1, 2001) is 8425 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MIMEEDI' on line 1364 looks like a reference -- Missing reference section? 'EDIINT' on line 1424 looks like a reference -- Missing reference section? 'AS1' on line 1405 looks like a reference -- Missing reference section? 'SMTPMSG' on line 1371 looks like a reference -- Missing reference section? 'HTTP' on line 1401 looks like a reference -- Missing reference section? 'GISB' on line 1418 looks like a reference -- Missing reference section? 'HTML' on line 1414 looks like a reference -- Missing reference section? 'FORMDATA' on line 1411 looks like a reference -- Missing reference section? 'MDN' on line 1379 looks like a reference -- Missing reference section? 'REPORT' on line 1397 looks like a reference -- Missing reference section? 'TLS' on line 1408 looks like a reference -- Missing reference section? 'MIME-TYPES' on line 1421 looks like a reference -- Missing reference section? 'XMLTYPES' on line 1369 looks like a reference -- Missing reference section? 'SMIMEV2' on line 1389 looks like a reference -- Missing reference section? 'MIMEPGP' on line 1376 looks like a reference -- Missing reference section? 'RFC2440' on line 344 looks like a reference -- Missing reference section? 'REPORTS' on line 422 looks like a reference -- Missing reference section? 'DUNS' on line 592 looks like a reference -- Missing reference section? 'HTTTP' on line 599 looks like a reference -- Missing reference section? 'SECURITY' on line 1382 looks like a reference -- Missing reference section? 'MIME' on line 1353 looks like a reference -- Missing reference section? 'SMTP' on line 1386 looks like a reference -- Missing reference section? 'SMIMEV3' on line 1392 looks like a reference -- Missing reference section? 'CMS' on line 1395 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EDIINT Working Group Dale Moberg 3 Internet draft Dick Brooks 4 Expires: October 2001 Rik Drummond 5 April 1, 2001 7 HTTP Transport for Secure EDI 8 draft-ietf-ediint-as2-08.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To view the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in an Internet- 29 Drafts Shadow Directory, see http://www.ietf.org/shadow.html. 31 Any questions, comments, and reports of defects or ambiguities in 32 this specification may be sent to the mailing list for the EDIINT 33 working group of the IETF, using the address 34 . Requests to subscribe to the mailing list 35 should be addressed to . 37 Abstract 39 This document describes how to exchange structured business data 40 securely using HTTP transport for EDIFACT, X12, XML or other 41 used for business to business data interchange. The data is packaged 42 using standard MIME content-types. Authentication and privacy are 43 obtained by using CMS (S/MIME) or OpenPGP security body 44 parts. Authenticated acknowledgements make use of multipart/signed 45 replies to the HTTP POST requests. 47 This document extends the procedures and payload packaging options of 48 AS1 in the following ways: HTTPS may be used to obtain data privacy, 49 both synchronous and asynchronous reply procedures are described, 50 multipart/form-data packaging may be used, a generalized 51 multipart/report format is added to the MDN format of AS1, 52 replies may include a multipart/mixed payload that contains 53 both the acknowledgement and an additional EDI payload. 55 This document is intended to be read in conjunction with AS1 and 56 the referenced RFCs defining the MIME and cryptographic 57 packaging that are used to obtain secure, authenticated, and 58 acknowledged transport. 60 HTTP Transport for Secure EDI April 1, 2001 62 Feedback Instructions: 64 If you want to provide feedback on this draft, follow these guidelines: 66 -Send feedback via e-mail to the ietf-ediint list for discussion, with 67 "AS#2" in the Subject field. To enter/follow the discussion, you 68 need to subscribe at ietf-ediint@imc.org. 70 -Be specific as to what section you are referring to, preferably 71 quoting the portion that needs modification, after which you state 72 your comments. 74 -If you are recommending some text to be replaced with your suggested 75 text, again, quote the section to be replaced, and be clear on the 76 section in question. 78 Table of Contents 80 1. Introduction 81 1.1 Purpose and relation to previous work 82 1.2 Overall operation 83 2. Stages and Details of HTTP EDI Transmission and Acknowledgment 84 2.1 Requesting receipts in the POSTED request 85 2.1.1 Requesting MDN-based receipts 86 2.1.2 Requesting Generalized receipts 87 2.1.3 Summary Remarks on Receipt request options 88 2.2 Additional Commonly Used Headers 89 2.3 Sending EDI in HTTP POST Requests 90 2.4 Using Transport Layer Security for Transmission 91 2.5 Response Status Codes in Replies 92 2.6 Receipt Reply 93 2.6.1 MDN Receipts and Signed MDN Receipts 94 2.6.2 Generalized Receipts and Signed Generalized Receipts 95 2.7 Additional Reply Content 96 2.8 Non-Repudiation of the POST Reply 97 2.9 Error Recovery 98 3. Other differences between HTTP and SMTP based transport 99 3.1 Unused MIME headers and operations 100 3.1.1 Content-Transfer-Encoding not used 101 3.1.2 Epilogue must be empty 102 3.1.3 Lengthy message bodies and Message/partial 103 3.2 Differences in MIME or other headers or parameters used 104 3.2.1 Content-Length needed 105 3.2.2 Final Recipient and Original Recipient 106 3.2.3 Message-Id and Original-Message-Id 107 3.2.3 Host header 108 3.3 New Options for HTTP transport 110 A. AS 2 MIME templates. 111 B. Using AS2 Extensions in the GISB Protocol 112 C. Samples of AS 2 Protocol Data Units 113 D. Acknowledgments 114 E. References 115 F. Security Considerations 116 G. Authors' Addresses 118 HTTP Transport for Secure EDI April 1, 2001 120 1. Introduction 122 1.1 Purpose and relation to previous work 124 Early work on Internet EDI focused on specifying MIME content 125 types for EDI data [MIMEEDI] The functional requirements 126 document , "Requirements for Interoperable Internet EDI," 127 [EDIINT] provides extensive information on EDI security 128 and the business and user processes that can benefit 129 from the use of EDI security. In addition, MIME structures 130 appropriate for SMTP transport of the packaged EDI data are 131 specified in ([AS1] "MIME-based Secure EDI" ) as well 132 as the details needed to support signed receipts as acknowledgments. 133 The framework of [AS1] shows how to implement the security features-- 134 specifically data privacy, data integrity/authenticity, 135 non-repudiation of origin and non-repudiation of receipt -- 136 found to be requirements for secure EDI. 138 In this document, it is assumed that the reader is familiar 139 with the SMTP/MIME transport document, the requirements document, 140 and the RFCs applied or referenced in those documents. 142 This draft, like the SMTP/MIME transport document, builds on 143 previous RFCs and is attempting to "re-invent" as little 144 as possible. The goal here is to specify how previously specified 145 MIME messaging structures and operations can be adapted for use with 146 HTTP servers and clients to obtain secure, reliable, 147 and acknowledged transport for EDI and other business data. 149 The applicability statement, [AS1] "MIME-based Secure EDI," 150 explained the basic EDI transaction using the concept of a 151 "secure transmission loop" for EDI. This loop involves 152 one organization sending a signed and encrypted EDI 153 interchange to another organization, requesting a signed receipt, 154 followed by the receiving organization sending this 155 signed receipt back to the sending organization. The transmission, 156 therefore, involves the following stages: 158 1. The organization sending business data encrypts the data and 159 provides a digital signature, using either PGP/MIME or S/MIME. 160 In addition, they request a signed receipt. 162 2. The receiving organization decrypts the message and verifies 163 the signature, resulting in verified integrity of the data and 164 authenticity of the sender. 166 3. The receiving organization then sends a signed receipt 167 using a signature over the hash of a message disposition 168 notification, which contains a hash of the received message. 170 The above stages describe the functionality that would 171 satisfy all security requirements. Applications are expected 172 to be able to provide full functionality, though users may 173 agree to exchange data using only a restricted subset of 175 HTTP Transport for Secure EDI April 1, 2001 177 functionality. For example, businesses may agree to send signed data 178 using TLS, and only request a simple, unsigned receipt. 179 Implementations are expected to be configurable so that they may 180 support business community agreements that use subsets 181 of the full functionality. 183 In this document, the goal is to make use of HTTP instead of SMTP 184 as a transport protocol, and make the changes that are needed to 185 adapt to protocol packaging differences. 187 In either transport case, the body of the message is a MIME 188 structure, using MIME headers ("content-type" and other 189 "content-X" tags) to convey information about the data 190 being transported. 192 Also, one primary use of SMTP RFC 822 headers within SMTP based 193 transport of secure EDI has been to enable requests for 194 acknowledgements and to specify options for signatures over 195 acknowledgements (asymmetric encryption and cryptographic 196 hash algorithm preferences). 198 One way to convey this information within the HTTP transport 199 context is to use either HTTP entity-headers or extension-headers 200 [11, section 7.1] that have the syntax of SMTP headers. Only the 201 "From" header is overloaded by possibly different usages in the 202 SMTP and HTTP contexts. The "From" header normally contains 203 machine-usable email addresses as defined in [SMTPMSG]. The 204 usage of the "From" header in [HTTP] section14.22 is to provide 205 the email address of an administrative contact for the HTTP 206 client. The function of the "From" header in the SMTP context of 207 secure EDI transport has been to supply a value used in 208 constructing the MDN style receipt. But the MDN receipt has been 209 found to be too restrictive for some commercial EDI transport 210 scenarios [GISB]. So alternative receipt mechanisms will be 211 provided that, among other things, will remove any conflicts 212 arising from trying to reuse the SMTP-MDN roles of 213 "From" within the context of HTTP reserved usage of "FROM". 215 Also, it is currently difficult to make use of HTML [HTML] 216 and simple scripting to send HTTP entity-headers as part of the 217 HTML FORM tag construct. For HTML-based POST situations [GISB], 218 it is useful to specify ways to convey 'metadata' needed for the 219 secure transmission loop that do not make use of HTTP headers. 220 One way to specify this data is by using the MIME 221 multipart/form-data packaging specified in [FORMDATA]. 223 For SMTP transport, the receipt and signed receipt functions are 224 implemented using Message Disposition Notifications [MDN] 225 and Multipart/signed Message Disposition Notifications [AS1]. 226 For HTTP transport, generalization of the Message Disposition 227 Notification is useful. 229 The MDN is a special kind of multipart/report [REPORT]. For 230 MDNS, specialization is achieved by assigning the "report-type" 231 parameter in the content-type header the special value, 232 "disposition-notification" and by having the second body part 234 HTTP Transport for Secure EDI April 1, 2001 236 (the "machine-readable" body part) have the MIME content-type, 237 "message/disposition-notification". 239 To generalize a MDN, all that is needed is to remove the 240 restrictions that make the underlying multipart/report into a MDN. 241 In other words, the "report-type" parameter [REPORT, section 1] 242 is given a new value and the second body part is changed to a 243 content-type other than "message/disposition-notification". 244 Acknowledgements defined by these changes will be referred 245 to as "generalized receipts. Each receipt of this kind will have its 246 own specific report-type parameter and its own specifications 247 for the syntax and semantics of the automated response body part. 248 Implementations are encouraged to be able to register new 249 report-type handlers using only configuration changes (not 250 recompiling) that specify how to process new report-type values. 252 Nothing else needs to be changed to construct reply acknowledgements 253 that are not restricted by the semantics of MDNs. Specifically, 254 a signed reply will still be constructed by using a multipart/signed 255 package to wrap up generalized receipts with their signatures. 257 Finally, within the HTTP transport context, it is useful 258 to make use of Transport Layer Security [TLS] to provide 259 privacy. Compression can be provided using HTTP content-codings 260 [HTTP], sections 3.5, 14.3, 14.12]. (Content codings are not be be 261 confused with the MIME concept of content transfer encodings.) 263 A variety of other minor differences (for example, 264 absence of content-transfer-encoding) 265 are noted below and summarized in the concluding section. 267 1.2 Overall operation 269 A HTTP POST operation [HTTP] is used to send appropriately packaged 270 EDI, XML, or other business data. The Request-URI ([HTTP], 271 section 9.5) identifies a process to unpack and handle the 272 message data and to generate a reply for the client that 273 contains a message disposition acknowledgement or a 274 multipart/report, signed or unsigned, and possibly other 275 turnaround transactions. This request/reply transactional 276 interchange provides secure, reliable, and authenticated 277 transport for EDI or other business data using HTTP; 278 the security protocols and structures used also 279 support auditable records of these transmissions, 280 acknowledgements, and authentication. 282 2. Stages and Details of HTTP EDI Transmission and Acknowledgment 284 A data file or stream is first structured into one of the 285 message templates described in [AS1], sections 4.2.1 to 4.2.4 or 286 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. In addition 287 to the content-types of [MIMEEDI], applications should be 288 prepared for handling other content-types used in business to 289 business transactions, such as those for XML [MIME-TYPES]. 290 For convenience, these message templates, adapted for the 291 HTTP transport context, are provided in Appendix A below. 293 HTTP Transport for Secure EDI April 1, 2001 295 If TLS is to be used, the typical packaging will 296 be that described in sections 4.2.2 or 4.3.2; 297 that is, a multipart/signed message will be created with no 298 encryption in the message. Otherwise, if privacy 299 is desired, message templates 4.2.4 or 4.3.4 are used. 300 Content transfer encoding is not used and a content-length 301 field is to be provided. 303 If HTML-based POST is used (using the METHOD=POST attribute 304 within the "FORM" tag) [HTML, 17 Forms], then the message payload 305 will be packaged in the input-data element of a multipart/form-data. 306 The metadata needed for application layer routing, identification, 307 requesting a reply and other transaction operations 308 can be packaged in message body parts in the multipart/form-data. 309 The labels for the metadata values are found in the "name" 310 parameter of the Content-Disposition header in each form-data 311 part as discussed in [FORMDATA, section 3]. 313 In general, both HTTP servers and HTTP clients handling the message 314 templates of [AS1] should be prepared to process these basic EDIINT 315 data formats when they are embedded within MIME multiparts. 317 In addition to the enveloping and MIME media type options defined in 318 sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this 319 specification enables the transport of payload objects containing 320 other MIME media types. Implementors are to follow the 321 appropriate specifications identified under "References" 322 in [MIME-TYPES], for the type of object being transmitted. 323 For example, to send an XML object, the MIME media type 324 of application/xml is used in the Content-type MIME header 325 and the specifications for enveloping the object are contained in 326 [XMLTYPES]; for example: 328 Content-type: application/xml; charset="utf-8" 330 Many of the specifications referenced by [MIME-TYPES] were designed 331 for SMTP transports. Implementors are advised to make appropriate 332 adjustments for HTTP transport as indicated in section 4 of this 333 document. 335 Finally, several industry groups currently make use of 336 "encapsulated"(or opaque) signatures within encrypted or 337 signed objects. Encapsulated signatures should be supported 338 in order to accommodate these existing practices. Objects 339 containing encapsulated signatures must be prepared according 340 to the specifications contained in section 3.4.2 of [SMIMEV2] 341 or, in the case of PGP, according to the 342 specifications contained in section 6.2 of "MIME Security 343 with Pretty Good Privacy (PGP)" [MIMEPGP] and 344 "OpenPGP Message Format" [RFC2440]. 346 2.1 Requesting Receipts 348 2.1.1 Requesting MDN-based receipts 350 For requesting MDN based receipts, the originator supplies 351 metadata using the syntax of extension headers 352 (the [SMTPMSG] header syntax) that precede the message body. 354 HTTP Transport for Secure EDI April 1, 2001 356 The header "tags" are as follows: 358 A Disposition-Notification-To header is added to indicate 359 that a message disposition notification is requested 360 in the reply to the POST request. This header is 361 specified in [MDN]. It may have values 362 other than email addresses, such as a D-U-N-S number, 363 when it is found as a name parameter in a form-data body part 364 When this tag is used in HTTP extension headers, 365 it follows the MDN usage. 367 A Message-ID header is added to support message reconciliation, 368 so that an Original-Message-Id value can be returned in the MDN 369 body part of the receipt. (The term "Receipts" is here used 370 to refer to the signed or unsigned multipart/report content.) 372 Both "From" and "To" extension headers are to be supplied. The "From" 373 value needs to have an email address as specified in [SMTPMSG] and 374 [HTTP]. If other uses of "From" are needed, the generalized receipts 375 to be next discussed should be used. There the role of "From" is 376 replaced by symbols not having a reserved HTTP or SMTP usage. 378 Other headers, especially "Subject" and "Date", should be supplied; 379 the values of these headers are often mentioned in the 380 human-readable section of a MDN to aid in identifying the original 381 message. 383 A Disposition-Notification-Options header is used to request 384 a signed message disposition notification. The parameters 385 used to select protocols for signed message disposition 386 notification are found in [AS1]. 388 Disposition-Notification-To is a name that, if present, indicates 389 that the MDN style of receipt is to be used. 391 Disposition-notification-options identifies characteristics of 392 message disposition notification in accordance with [AS1] and [MDN]. 394 A Receipt-delivery-option is a header whose value is a URL 395 that indicates how the receipt is to be delivered. 396 This header is only used within AS2. 397 The default mode of operation is synchronous 398 within HTTP transport, which means that the receipt 399 (be it MDN, signed MDN, generalized report receipt, 400 or signed report receipt) is returned in the reply body. 401 By using the "receipt-delivery-option," an asynchronous reply mode 402 can be requested. The values for this option are URLs that indicate 403 the destination for the reply, and may use any appropriate 404 protocol ("mailto", "http", and "https" will 405 be the more common types) for this information. 406 If this header/metadata is absent, then the mode of operation 407 is synchronous, which means that the receipt is returned 408 in the reply to the current HTTP request. 410 2.1.2 Requesting Generalized Receipts 412 In this section, the ways to request generalized receipts 413 are specified. Generalized receipts are multipart/reports 415 HTTP Transport for Secure EDI April 1, 2001 417 with a report-type other than "disposition-notification," and 418 a second automated response with a content type other 419 than "message/disposition-notification". 421 For requesting generalized receipts using the MIME template for 422 multipart/reports [REPORTS], the following metadata 423 elements will be useful. A specific example of a 424 generalized receipt with report-type "GISB-Acknowledgement-Receipt" 425 will be presented in appendix B. 427 When the term "metadata" is used in the following, 428 the term indicates that the 429 information may be supplied in one of 430 two ways: 432 First, the metadata information may be supplied using the 433 syntax of HTTP headers. That is, the symbol 434 name is followed by a colon and its value follows; 435 the header is subject to processing of structured 436 field bodies [SMTPMSG, section 3.1.4], also including 437 parameters. 439 Second, the metadata information may be 440 supplied by using the syntax of the "name" parameter within the 441 "Content-Disposition" header of the multipart/form-data structure, 442 when that MIME packaging [FORMDATA] is used. For example, 444 --boundaryformdata 445 Content-Disposition: form-data; name="Receipt-Report-Type" 447 GISB-Acknowledgement-Receipt 448 --boundaryformdata 450 Within HTML, the symbols used for these 451 names correspond to the value of the name attribute within 452 the INPUT element, where the "type" attribute has a "text" value. 453 [HTML], section 18; for example, 455
456 457 458
460 To indicate the various options for generalized receipts, the 461 basic metadata that the POSTing client needs to convey to the 462 replying server are: "Receipt-Disposition-To", 463 "Receipt-report-type", "Receipt-Security-Selection", 464 and "Receipt-Delivery-Option". 466 The presence of the metadata value "Receipt-Disposition-To", 467 using the extension header syntax, indicates a request 468 for a generalized receipt. 470 Because HTTP already has a role for the "From" header, the 471 "Receipt-Disposition-To" header is used to avoid conflicts 472 with [HTTP], when using the header syntax for metadata. 473 (Within a multipart/form-data package, the "From" value 474 can be used to identify the sending party without any 476 HTTP Transport for Secure EDI April 1, 2001 478 conflict with HTTP headers.) Notice that the value for 479 this identifier need not be an email address or a URL. 480 In this way, other systems of identification (such 481 as a DUNS number) may be used, if needed. Notice that 482 the information needed for delivery of the receipt 483 is found in the receipt-delivery-option element 484 described below; delivery information is not 485 generally needed if the default mode of operation 486 occurs. In that case, the receipt just goes back 487 in the reply to the current HTTP request. 489 "Receipt-Report-Type" indicates the desired value of 490 the "report-type" parameter in the multipart/report 491 content type of a specific version of the generalized 492 receipt. This parameter must be supplied when 493 "Receipt-Disposition-To" is used to indicate a request 494 for a generalized receipt because this indicates what 495 specific type of receipt is desired. An example 496 for this value (discussed in appendix A) is 497 "GISB-Acknowledgement-Receipt". 499 "Receipt-Security-Selection" is a name that indicates the 500 protocol and algorithm choices for a digital signature 501 over the receipt. Signatures are always in multipart/signed 502 packages. The format for protocol and algorithm choices is 503 that used in [AS1] and [MDN]; for example, 505 Receipt-Security-Selection: 506 signed-receipt-protocol=optional,pkcs7-signature; 507 signed-receipt-micalg=optional,rsa-sha1 509 "Receipt-Delivery-Option" is used to indicate the 510 URL for asynchronous delivery of the receipt. 511 While the default mode of operation within HTTP 512 transport is to return the receipt(be it MDN, signed 513 MDN, generalized receipt, or signed generalized receipt) 514 in the reply body, asynchronous reply is allowed through 515 use of this symbol. The URLs will typically use the 516 "MAILTO", "HTTP", and "HTTPS" schemes. For the HTTP and 517 HTTPS schemes, the POST method is to be used. 519 2.1.3 Summary Remarks on Receipt request options 521 Applications are encouraged to support handling all metadata 522 values whether they make use of the name parameter syntax 523 within a multipart/form-data or whether they use the message 524 header syntax used in SMTP or HTTP headers [SMTPMSG]. If 525 metadata items are repeated in extension headers and in 526 form-data parts, but the values are not the same, the 527 extension header values will be selected for use. 529 Because the value in Receipt-Disposition-To 530 may have no significance for how the receipt is transported, 531 the extension header "Receipt-delivery-option" 532 is to be used to provide that information. 534 HTTP Transport for Secure EDI April 1, 2001 536 The receipt-delivery-option's value should be a URL 537 indicating the delivery transport destination for the 538 receipt. 540 The Receipt-delivery-option field is used when 541 asynchronous delivery is desired. It should not 542 be present if the intention is to deliver 543 the reply synchronously; synchonous delivery of 544 the reply is the default mode of delivery. 546 For signed generalized receipts, 547 an extension header of "Receipt-security-selection" should 548 be added to indicate the desired security protocol for the 549 multipart/signed over the multipart/report. 551 In summary, the receipt request and construction processes now 552 have the following options: 554 1. Receipt requests are made by conveying metadata 555 values using a syntax of either the name parameter in a 556 multipart/form-data's Content-Disposition headers or by 557 using a syntax of HTTP extension headers. 559 2. Both MDN and generalized receipts can be requested using 560 either syntax. However, using an extension header syntax 561 and requesting a MDN receipt means restricting the "From" 562 values to email addresses. 564 3. Either type of receipt comes in signed or unsigned versions. 566 4. Finally, receipts may be delivered synchronously (delivered 567 in the HTTP reply) or asynchronously by using 568 the "Receipt-delivery-option" header. 570 2.2 Additional Commonly Used Headers 572 The following set of header data elements are also available for 573 use. Organizations wishing to use this specification for the 574 secure and reliable transport of business documents are not required 575 to utilize all of these headers and are free to use whatever subset 576 they deem appropriate for their business needs. 578 TO: 579 The To name contains an identifier identifying the 580 intended recipient of a data exchange and may be 581 D&B D-U-N-S number [DUNS] or other agreed upon 582 identifier system. Applications should allow users to 583 configure these elements in the automated HTTP agents 584 processing these values. For example, the body 585 part MIME header line looks like the following line: 587 Content-Disposition: form-data; name="To" 589 FROM: 590 The From name contains a textual value identifying 591 the sender of a data exchange, such as the a D&B D-U-N-S number 592 [DUNS] as in [GISB]. Because "From" has a specified use within 593 [HTTP], the From name parameter is not to be considered equivalent 595 HTTP Transport for Secure EDI April 1, 2001 597 to the extension header. If an extension header "From" is to be 598 used it should within HTTP, it should conform to the usage, syntax, 599 and semantics of [HTTTP] section 14.22. The extension header 600 counterpart of the sender of a data exchange is the extension 601 header version of "Receipt-disposition-to". 603 INPUT-FORMAT: 604 The Input-format name identifies the type of data contained in a 605 data file. 607 AGENT: 608 The Agent name parameter indicates the network or agent where the 609 data exchange originated. 611 APPLICATION: 612 The Application name identifies the application used to process 613 the data next(after the URI-request process has finished with the 614 stream). 616 DATETIME: 617 The DateTime name provides the date and time the data was created 618 and uses the format specified in [SMTPMSG] as updated by 619 RFC 1123. 621 REFNUM: 622 The RefNum is an integer value used to uniquely identify the 623 communication exchange and is in a textual format. The RefNum is 624 similar to the Message-ID and Content-Id headers of SMTP that 625 are used in constructing values in receipts based on MDNs. 627 USERPARAM: 628 The UserParam is a user defined parameter. 630 Version: 631 Version is a protocol version number [GISB]. 633 TRANSACTION-SET: 634 Transaction-set is an optional data element identifying the 635 EDI transaction. 637 INPUT-DATA: 638 Input-data is the sending side's local file system name 639 for the file being sent. The payload is contained as the body 640 part of this header element. 642 PRIORITY: 643 The "Priority" name is used to indicate the processing priority of 644 each message relative to other messages sent by a given party. 645 The value "1" indicates highest priority and a value of "5" 646 indicates the lowest priority. 648 EXPIRATION: 649 The "Expiration" name is used to indicate the date and time at 650 which a message is no longer transportable. No message delivery 651 should be attempted beyond the date and time specified in 652 this value. The date/time format must follow the specifications 653 contained in section 5 of RFC822. 655 HTTP Transport for Secure EDI April 1, 2001 657 2.3 Sending EDI in HTTP Client Requests using POST 659 For sending EDI, the following protocol elements are typically 660 present: a request line ([HTTP], section 5.1), entity headers, a 661 CRLF pair to mark the end of the entity headers, followed by the 662 message-body. 664 The request line will have the form: "POST Request-URI HTTP/1.1", 665 with spaces and followed by a CRLF. The Request-URI is typically 666 exchanged out of band, as part of setting up a bilateral 667 trading partner agreement. Applications should be prepared 668 to deal with an initial reply containing a status indicating a need 669 for authentication of the usual types used for authorizing access 670 to the Request-URI ([HTTP], section 10.4.2 and elsewhere). 672 Automation of this process is not discussed in this document 673 but might involve obtaining a session URL from a page requesting 674 authentication and possibly other information about proposed 675 EDI standard versions and other trading conventions to be used. 677 The request line is followed by entity headers specifying content 678 length ([HTTP] section 14.14) and content type [HTTP], 679 section 14.18. The Host request header ([HTTP] sections 9 and 680 14.23) is also included. 682 The entity or extension headers used for requesting a MDN 683 (unsigned or signed) have previously been mentioned, 684 as have those ("To" "From" "Message-Id") that are needed as 685 values for MDN fields or for other receipt requests. 687 For generalized receipts based on the multipart/report content type, 688 the metadata can be the values found in extension headers, 689 but can also be placed in body parts of a multipart/form-data 690 using "name" parameters in the content-disposition header. 692 Finally, the payload is found in any of the message patterns 693 of [AS1] sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME 694 or S/MIME security. These payloads may arrive as the "input-data" 695 part of the multipart/form-data or may even be enclosed in some 696 other multipart. 698 2.4 Using Transport Layer Security 700 To use Transport Layer Security [TLS], the request-URI should 701 indicate the appropriate scheme value, HTTPS. Usually only a 702 multipart/signed message body would be sent using TLS, as encrypted 703 message bodies would be redundant. Encrypted message bodies are not 704 prohibited, however. For asynchronous receipt delivery requests, 705 use the "Receipt-delivery-option" header with a URL value making 706 use of the HTTPS scheme to obtain security privacy. 708 2.5 Response Status Codes in Replies 710 The status line for response to errors in the POST request line 711 will be provided by a status line with the following protocol 712 elements present ( [HTTP], section 6.1 ) : HTTP version (normally, 713 HTTP/1.1), a status code, reason phrase, and CRLF. 715 HTTP Transport for Secure EDI April 1, 2001 717 The status codes return status concerning HTTP operations. For 718 example, the status code 401, together with the WWW-Authenticate 719 header, is used to challenge the client to repeat the request 720 with an Authorization header. Other explicit status codes are 721 documented in [HTTP], sections 6.1.1 and throughout section 10. 722 For errors in the request-URI, 400 ("Bad Request"), 404 723 ("Not Found") and similar codes are appropriate status codes. 724 These codes and their semantics are specified by [HTTP]. 725 A careful examination of these codes and their semantics 726 should be made before implementing any retry functionality 727 that is described below; specifically, retries should not 728 be made if the error is not transient or if retries are 729 explicitly discouraged (for real authentication failures, 730 for example.) 732 2.6 Receipt Reply 734 The details of the response to the POST command vary depending 735 upon whether a receipt has been requested and upon what kind 736 of receipt has been requested. 738 With no extended header requesting a receipt, and no errors 739 accessing the request-URI specified processing, the status 740 line in the Response to the POST request should be in the 200 741 range. Status codes in the 200 range should also be used when an 742 entity is returned (a signed receipt in a multipart/signed 743 content type or an unsigned receipt in a multipart/report). 744 Even when the disposition of the data was an error condition 745 at the authentication, decryption or other higher level, the 746 HTTP status code should indicate success at the HTTP level. 748 The HTTP server-side application may respond with an unsolicited 749 multipart/report as a message body that the HTTP client 750 might not have solicited, but this may be discarded by the 751 client. Applications should avoid emitting unsolicited receipt 752 replies because bandwidth or processing limitations might 753 have led administators to suspend asking for acknowledgements. 755 When a Disposition-Notification-To extension header is present 756 in the POST request entity headers, then entity headers for 757 the MDN should be included. The content type for the MDN receipt 758 ( multipart/report [REPORT] or multipart/signed [SECURITY]) 759 should be included in the Response entity headers. The 761 The basic responsibilities of responding to requests are discussed 762 in [AS1] section 5, and in detail within section 5.2.1. 764 2.6.1 MDN based Receipts and Signed MDN Receipts 766 Message Disposition Notifications, when used in the HTTP reply 767 context, will closely parallel a SMTP MDN. For example, 768 the disposition field is a required element in the machine 769 readable second part of a multipart/report for a MDN. 770 The final-recipient-field([MDN] section 3.1) value should 771 be derived from the entity headers of the request 773 HTTP Transport for Secure EDI April 1, 2001 775 If the "To" field is missing, for signed messages, 776 the value for Original-recipient may be the email 777 address field from the signer's X.509 attribute for 778 email addresses, if that value is available. 779 For a MDN, an application must report the Message-ID 780 of the request. The human readable part (the first 781 part of the multipart/report) should include items 782 such as the subject, date and other information 783 when those fields are present in entity header fields 784 following the POST request 786 The HTTP reply should normally omit the third optional part 787 of the multipart/report (used to return the original message 788 or its headers in the SMTP context). 790 2.6.2 Generalized Receipts and Signed Receipts 792 For generalized receipts, the multipart/report [REPORT] 793 or a multipart/signed containing a multipart/report 794 as the signed data is the basic MIME packaging. Each 795 generalized receipt needs a value for the multipart/report 796 parameter, "report-type," a selection of a content-type 797 for its second body part, when signed, a hash value over 798 a defined portion of the original message and, 799 when asynchronously delivered, information allowing the 800 identification of the original POSTed message. 802 The basic structure of the multipart/report is used so that 803 the first part is a "human-readable" message concerning the received 804 message. The second part should be for automated process utilization. 805 It should at least possess some common Internet syntax for 806 expressing names and values, such as the [SMTPMSG] header syntax, 807 XML, or some MIME content type correlated with automated 808 processing. 810 The MDN requirements, therefore, are removed for this second part, 811 but information used in MDNs may be used here. 812 The third part of the multipart report is 813 usually omitted in the HTTP context, but could include 814 the extension headers, or even the entire payload, 815 to provide diagnostic information. 817 A multipart/signed over a multipart/report is constructed 818 precisely in the same way as a multipart/signed over a MDN [AS1]. 820 One metadata element should be within the automated part. 821 This is the Received-Content-MIC (also allowing 822 X-Received-Content-MIC). This value is constructed and formatted 823 as described in [AS1] and the syntax should be either RFC822: 825 Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==,rsa-md5 827 or simple XML 829 830 w7AguNJEmhF/qIjJw6LnnA== 831 833 HTTP Transport for Secure EDI April 1, 2001 835 Any original metadata thought useful to include in the automated 836 part may be reflected back using "Original-X", as in 838 Original-Message-ID: <43141asfioufasd@somewhere.com> 840 Otherwise the automated acknowledgement semantics are left open 841 to further semantic specification by specific electronic commerce 842 communities, such as in [GISB]. Each specialization of the 843 generalized receipt should make use of a specific identifying 844 value to be placed in the parameter "report-type," 846 Content-Type: multipart/report; 847 report-type="identifying-value"; 848 boundary="=-Trfds88fd99" 850 Implementations should attempt to be configurable to allow 851 for new report-type values to be added; communities can then agree 852 to the specific extensions they need to support application 853 level routing, transaction identification, timestamps, and 854 other specialized information about the data they have exchanged. 856 2.7 Additional Reply Content 858 In general, both HTTP servers and HTTP clients should be prepared 859 to process the basic EDIINT data formats when they are embedded 860 within MIME multiparts. This is true for HTTP request payloads 861 as well as HTTP reply payloads. 863 So, as previously mentioned, for HTML-based POSTS, 864 any of the EDIINT templates described in [AS1], 865 sections 4.2.1 to 4.2.4 or 866 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security, 867 may be found as parts of a multipart/form-data. 868 [Consult Appendix A for the templates adapted for this document.] 870 In addition, the response to the POST operation may include other 871 MIME wrapped content besides an MDN Receipt, Signed MDN, 872 Generalized Receipt or Signed Generalized Receipt. If a receipt was 873 requested within the POST data, and additional content is to be 874 returned, the receipt multipart/report must be combined with the 875 other data using some MIME multipart pattern. 876 Real-time EDI processing systems may use MIME 877 multipart content-types to include a response EDI message, 878 for example, a Quote in response to a Request-For-Quote transaction. 880 Also, if requested, the sender may request an asynchronous mode 881 for return of receipt. This mode is indicated by including the 882 metadata for Receipt-delivery-option as explained above. 884 2.8 Non-Repudiation of the POST Reply 886 If the reply to a POST operation needs a MDN receipt for non- 887 repudiation (for example, the reply includes content other than 888 a receipt), the top-level headers in the response include 889 the same headers required for POST data described above: 890 Disposition-Notification-To, Message-ID, From, and To. Other 891 headers described above used in a MDN should be included, 892 for example, Date and Subject. 894 HTTP Transport for Secure EDI April 1, 2001 896 The MDN receipt of the response data is returned using 897 a subsequent POST operation. A POST operation used only 898 to transmit an MDN should not include the Disposition- 899 Notification-To receipt request, and only a 200 ("OK") response 900 would be expected. 902 An MDN in response to a reply may be combined with a 903 subsequent EDI message sent with a POST operation, for example 904 a Purchase-Order transaction in response to a Quote. The MIME 905 multipart/mixed form is used to combine the MDN with the other 906 data, the same as for a POST reply. 908 2.9 Error Recovery 910 If the HTTP client fails to read the HTTP server 911 response data, the POST operation with identical content (including 912 Message-ID, RefNum, and other header elements) should be repeated, 913 if the error condition is transient. 915 The Message-ID or RefNum on a POST operation can be reused if and only 916 if all of the content (including the original Date) is identical. 918 Details of the retry process -- including time intervals to pause, number of 919 retries to attempt, timeouts for retrying -- are implementation dependent. 921 Servers should be prepared to receive a POST with a repeated Message-ID. 922 The MIME reply body previously sent should be resent, including the MDN 923 and other MIME parts. 925 3. Other differences to notice in HTTP and SMTP based transport 927 For HTTP version 1.1, TCP persistent connections are the default, 928 ([HTTP] sections 8.1.2, 8.2, and 19.7.1). 930 A number of other differences exist because HTTP does not 931 conform to MIME [MIME] as used in SMTP transport. Relevant 932 differences are summarized below. 934 3.1 Unused MIME headers and operations 936 3.1.1 Content-Transfer-Encoding not used in HTTP transport 938 HTTP can handle binary data and so there is no need to use 939 the Content transfer encodings of MIME [MIME]. This difference 940 is discussed in [HTTP] section 19.4.4. 942 3.1.2 Epilogue must be empty 944 The EBNF for a multipart [MIME] RFC 2046, section 5.1.1 allows 945 a multipart to have trailing octets after the close delimiter. 946 In [HTTP] section 3.7.2, it is explicitly noted that multiparts 947 must have null epilogues. 949 3.1.3 Lengthy message bodies 951 In [AS1], section 5.4.1, options for large file processing are 952 discussed for SMTP transport. For HTTP, large files should 953 be handled correctly by the TCP layer. However, [HTTP] sections 955 HTTP Transport for Secure EDI April 1, 2001 957 3.5 and 3.6 discuss some options for compressing or chunking 958 entities to be transferred. Section 8.1.2.2 discusses a 959 pipelining option that is useful for segmenting large 960 amounts of data. 962 3.2 Differences in MIME or other headers or parameters used 964 3.2.1 Content-Length 966 Because connections are persistent, closing a connection 967 cannot be used to indicate the end of an entity. Therefore, 968 [HTTP] sections 4.4 and 14.14 indicate the need for a 969 Content-Length entity header in a request. 971 3.2.2 Final and Original Recipient 973 The final and original recipient distinction should not 974 arise for HTTP transport because SMTP aliases and mailing 975 lists should not be used. 977 3.2.3 Message-Id and Original-Message-Id 979 The Message-Id and Original-Message-Id distinction should not 980 arise for HTTP transport because SMTP MTA alterations should 981 not occur. 983 3.2.4 Host header 985 The host request header field must be included in the 986 POST request made when sending business data. This field 987 is to allow one server IP address to service multiple 988 hostnames, and potentially conserve IP addresses. 989 See [HTTP], sections 14.23 and 19.5.1. 991 Appendices 993 A. AS 2 MIME templates 995 Structure of an AS2 MIME message - PGP/MIME 997 No encryption, no signature (analog of 4.2.1) 999 -RFC2068/2045 1000 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) 1002 No encryption, signature (analog of 4.2.2) 1004 -RFC2068/2045 1005 -RFC1847 (multipart/signed) 1006 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) 1007 -RFC2015 (application/pgp-signature) 1009 HTTP Transport for Secure EDI April 1, 2001 1011 Encryption, no signature (analog of 4.2.3) 1013 -RFC2068/2045 1014 -RFC1847 (multipart/encrypted) 1015 -RFC2015 (application/pgp-encrypted) 1016 -"Version: 1" 1017 -RFC2015 (application/octet-stream) 1018 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted) 1020 Encryption, signature (analog of 4.2.4) 1022 -RFC2068/2045 1023 -RFC1847 (multipart/encrypted) 1024 -RFC2015 (application/pgp-encrypted) 1025 -"Version: 1" 1026 -RFC2015 (application/octet-stream) 1027 -RFC1847 (multipart/signed)(encrypted) 1028 -RFC1767/RFC2376 (application/EDIxxxx or application/xml)(encrypted) 1029 -RFC2015 (application/pgp-signature)(encrypted) 1031 Structure of an AS2 MIME message - S/MIME 1033 No encryption, no signature (analog of 4.3.1) 1035 -RFC2068/2045 1036 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) 1038 No encryption, signature (analog of 4.3.2) 1040 -RFC2068/2045 1041 -RFC1847 (multipart/signed) 1042 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) 1043 -RFC2633 (application/pkcs7-signature) 1045 Encryption, no signature (analog of 4.3.3) 1047 -RFC2068/2045 1048 -RFC2633 (application/pkcs7-mime) 1049 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted) 1051 Encryption, signature (analog of 4.3.4) 1053 -RFC2068/2045 1054 -RFC2633 (application/pkcs7-mime) 1055 -RFC1847 (multipart/signed) (encrypted) 1056 -RFC1767/RFC2376 (application/EDIxxxx or application/xml) (encrypted) 1057 -RFC2633 (application/pkcs7-signature) (encrypted) 1059 B.AS2 Extensions for the GISB Protocol and Report-type 1061 GISB AS2 Profile 1063 The United States based Gas Industry Standards Board (GISB) is a 1064 consortium of companies and individuals that operate in the Gas 1065 Industry. The membership is divided into 5 sectors, Producers, 1066 Pipelines, Services, End Users, Local Distribution Companies, 1068 HTTP Transport for Secure EDI April 1, 2001 1070 representing the various type of organizations within the industry. 1071 In 1996 GISB initiated a program to move from the expensive Value 1072 Added Networks they were using, to the Internet. By October of 1996 1073 GISB had developed and tested a protocol, called GISB Electronic 1074 Delivery Mechanism (EDM), which uses HTTP and is based on RFC1867 1075 (Form-based File Upload in HTML). By April 1997 this protocol was 1076 being used by Enron and others to send/receive live, mission 1077 critical business transactions over the Internet. Additional 1078 companies followed suit and a large percentage of today's 1079 business transactions in the Gas Industry are transmitted over the 1080 Internet using the GISB EDM protocol. In 1998 the Automobile 1081 Industry Action Group (AIAG) adopted the GISB EDM protocol and in 1082 1999 the local electric companies serving the state of Pennsylvania 1083 declared the GISB protocol as their standard for transmitting 1084 business transactions via the Internet. 1086 In May of 1999 the AIAG, GISB and members of the IETF EDIINT 1087 workgroup initiated an effort to converge their independent 1088 specifications, the result of which is this specification. In order 1089 to bring the GISB EDM into compliance with this specification GISB 1090 initiated a formal change to the EDM specification. The following 1091 information, referred to as the "GISB AS2Profile", reflects the 1092 planned utilization of this specification by the GISB membership. 1094 The GISB membership will utilize PGP to meet all P.A.I.N. requirements. 1095 All data exchanges will utilize the multipart/form-data enveloping 1096 method and two generalized receipts, GISB-Acknowledgement-Receipt and 1097 GISB-Error-Notification. All original business transactions must be 1098 digitally signed (using encapsulated signatures) and encrypted using 1099 RSA algorithms. Upon successful transfer of an original business transaction 1100 the receiver is required to send a GISB-Acknowledgement-Receipt indicating 1101 that the transfer has completed successfully. If, upon further processing 1102 of the business document an error is encountered a GISB-Error-Notification 1103 is sent to the original sender using the multipart/form-data enveloping. 1105 It is expected that companies following the GISB AS2 profile will protect 1106 their web sites from unauthorized access through the use of basic 1107 authentication (username/passwords), as defined in the HTTP specification. 1109 GISB is not "requiring" the use of signed receipts; however, signed 1110 receipts are allowed between consenting trading partners. 1112 GISB has decided to use the following core headers: 1114 FROM: 1115 Contains the DUNS number of the sending party 1117 TO: 1118 Contains the DUNS number of the intended recipient 1120 INPUT-FORMAT: 1121 Type of data being sent (only x12 and error currently 1122 supported) other options can easily be added to this list. 1124 INPUT-DATA: 1125 The actual payload containing the business transaction or 1126 GISB-Error-Notification. If the payload contains a business 1127 transaction it is signed and encrypted using PGP. 1129 HTTP Transport for Secure EDI April 1, 2001 1131 Version: 1132 The GISB version number (currently 1.3) 1134 RECEIPT-DISPOSITION-TO: 1135 The DUNS number of the party to receive the 1136 GISB-Acknowledgement-Receipt (typically the 1137 same DUNS number associated with the From header.) 1138 Presence of this field also serves as a 1139 flag indicating that an acknowledgement 1140 receipt is requested by the sender. The receipt is 1141 returned synchronously (on the same session used 1142 to send the input-data payload). 1144 RECEIPT-REPORT-TYPE: 1145 Contains the value GISB-Acknowledgement-Receipt. 1147 Optional headers also available: 1149 TRANSACTION-SET: 1150 Identifies the type of transaction contained in the 1151 input-data payload. 1153 RECEIPT-SECURITY-SELECTION: 1154 This field serves as a flag indicating that a 1155 signed receipt is being requested. The contents 1156 of this field indicate the algorithm and 1157 signature type to use in constructing the signature. 1159 Example of a GISB data exchange: 1161 The sending party creates an X12 business transaction and concatenates with 1162 an RFC 1767 compliant header. The entire package is then encrypted and 1163 signed using PGP. The encrypted package is then enveloped with the 1164 appropriate headers/values and sent to the trading partner using HTTP POST, 1165 the contents of this post appear as follows: 1167 POST c:\execute HTTP/1.0 1168 Referer: http://www.get.a.life/upl.htm 1169 Connection: Keep-Alive 1170 User-Agent: brow v0.1 XYZ Corp. 1171 Host: localhost 1172 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* 1173 Content-type: multipart/form-data; 1174 boundary=---------------------------87453838942833 1175 Content-Length: 5379 1177 -----------------------------87453838942833 1178 Content-Disposition: form-data; name="from" 1180 123456789 1181 -----------------------------87453838942833 1182 Content-Disposition: form-data; name="to" 1184 234567890 1185 -----------------------------87453838942833 1187 HTTP Transport for Secure EDI April 1, 2001 1189 Content-Disposition: form-data; name="Version" 1191 1.3 1192 -----------------------------87453838942833 1193 Content-Disposition: form-data; name="receipt-disposition-to" 1195 123456789 1196 -----------------------------87453838942833 1197 Content-Disposition: form-data; name="receipt-report-type" 1199 GISB-Acknowledgement-Receipt 1200 -----------------------------87453838942833 1201 Content-Disposition: form-data; name="input-format" 1203 x12 1204 -----------------------------87453838942833 1205 Content-Disposition: form-data; name="input-data"; 1206 filename=c:\temp\smallnom.bin 1207 Content-Type: multipart/encrypted; boundary=8760; 1208 protocol="application/pgp-encrypted" 1210 --8760 1211 Content-Type: application/pgp-encrypted 1213 Version: 1 1215 --8760 1216 Content-Type: application/octet-stream 1218 -----BEGIN PGP MESSAGE----- 1219 Version: PGP 6.5 1221 hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs 1222 z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG 1223 lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al 1224 ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E 1225 h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O 1226 cp2IWClxKOGUbxpVNOnNTqWHS/GntegvDE/7/ewCxDxsnmQS95pOl141QZ1RQbeN 1227 aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV 1228 zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9 1229 UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+ 1230 4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4= 1231 =Oiuo 1232 -----END PGP MESSAGE----- 1234 --8760- 1236 -----------------------------87453838942833 1238 Upon receiving the above stream of data the receiving host parses the 1239 headers and returns an unsigned 1240 GISB-Acknowledgement-Receipt, appearing as follows: 1242 Content-Type: multipart/report; 1243 report-type="GISB-Acknowledgement-Receipt"; boundary="GISB7867" 1245 --GISB7867 1247 HTTP Transport for Secure EDI April 1, 2001 1249 Content-type: text/html 1251 Acknowledgement Receipt Success 1252

1253 time-c=19960619082855* 1254 request-status=ok* 1255 server-id=coolhost* 1256 trans-id=234423897* 1257

1259 --GISB7867 1260 Content-type: text/plain 1262 time-c=19960619082855* 1263 request-status=ok* 1264 server-id=coolhost* 1265 trans-id=234423897* 1267 --GISB7867-- 1269 C. Samples of AS 2 Protocol Data Units 1271 C.1 The following example illustrates the full HTTP request that sends 1272 X12 EDI data from company1 to company2. A signed receipt is requested; 1273 the receipt is to be a MDN report-type, with the pkcs7 signature option, 1274 using a signature algorithm of rsa-md5. 1276 The receipt is to be sent synchronously (that is, in the reply to 1277 this HTTP request), because no special delivery options are indicated. 1279 POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1 1280 Host: tp2server.company2.com 1281 To: tp2@company2.com 1282 Date: Tue, 06 Nov 2001 12:53:01 UT 1283 Subject: Purchase orders for 6 November 2001 1284 Message-Id: <20011106@company1.com> 1285 Disposition-Notification-To: tp1@company1.com 1286 Disposition-Notification-Options: signed-receipt-protocol=optional, 1287 pkcs7-signature; signed-receipt-micalg=optional,rsa-md5 1288 Content-Type: multipart/signed; boundary="20011106RsXgYlvCNW"; 1289 protocol=application/pkcs7-signature; micalg=rsa-md5 1290 Content-Length: 3056 1292 --20011106RsXgYlvCNW 1293 Content-Type: application/edi-x12 1294 Content-Disposition: Attachment; filename=rfc1767.dat 1295 Content-Length: 2605 1297 [ISA ...EDI transaction data...IEA...] 1298 --20011106RsXgYlvCNW 1299 Content-Type: application/pkcs7-signature 1300 Content-Length: 804 1302 [omitted binary pkcs7 signature data] 1303 --20011106RsXgYlvCNW-- 1305 C.2 This second example illustrates returning a signed MDN 1306 that corresponds to the request for a MDN found in C.1. 1308 HTTP Transport for Secure EDI April 1, 2001 1310 HTTP/1.0 200 OK 1311 Server: HTTPEDI/1.1 1312 Content-type: multipart/signed; boundary="boundary1" 1313 Content-Length: 1200 1315 --boundary1 1316 Content-type: multipart/report; boundary="boundary2" 1317 Content-length: 1133 1319 --boundary2 1320 Content-type: text/plain 1321 Content-length: 85 1323 Message <20011106@company1.com> was authenticated; 1324 EDI processing was initiated. 1326 --boundary2 1327 Content-type: message/disposition-notification 1328 Content-length: 213 1330 Reporting-UA: Company2UA 1331 Final-Recipient: rfc822; tp2@company2.com 1332 Original-Message-Id: <20011106@company1.com> 1333 Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==,rsa-md5 1334 Disposition: MDN-sent-automatically/processed 1336 --boundary2-- 1338 --boundary1 1339 Content-Type: application/pkcs7-signature 1340 Content-Length: 560 1342 [ Signature data omitted] 1343 --boundary1-- 1345 D. Acknowledgments 1347 Carl Hage, Karen Rosenfeld, Chuck Fenton 1348 and many others have provided valuable suggestions 1349 improving this applicability statement. 1351 E. References 1353 [MIME] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1354 Part One: Format of Internet Message Bodies", RFC 2045, 1355 December 02, 1996. 1357 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1358 Part Two: Media Types", RFC 2046, December 02, 1996. 1360 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1361 Part Five: Conformance Criteria and Examples", RFC 2049 , December 02, 1362 1996. 1364 [MIMEEDI] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 1365 2, 1995. 1367 HTTP Transport for Secure EDI April 1, 2001 1369 [XMLTYPES] E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998. 1371 [SMTPMSG] D. Crocker, "Standard for the Format of ARPA Internet Text 1372 Messages", STD 11, RFC 822, August 13, 1982. 1373 (Also RFC 1123 provides important updates on date and time formats 1374 as well as email addresses.) 1376 [MIMEPGP] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 1377 2015, Sept. 1996. 1379 [MDN] R. Fajman, "An Extensible Message Format for Message Disposition 1380 Notifications", RFC 2298, March 1998. 1382 [SECURITY] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts 1383 for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, 1384 Oct. 3, 1995 1386 [SMTP] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 1387 August 1, 1982. 1389 [SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, 1390 "S/MIME Version 2 Message Specification", RFC 2311. 1392 [SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification", 1393 RFC 2633, June 1999. 1395 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 1397 [REPORT] G. Vaudreuil, "The Multipart/Report Content Type for the 1398 Reporting of Mail System Administrative Messages", RFC 1892, 1399 January 15, 1996. 1401 [HTTP] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 1402 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, 1403 January 1997. 1405 [AS1] T. Harding, R. Drummond, "MIME-based Secure EDI", Internet draft: 1406 draft-ietf-ediint-as1-10.txt. 1408 [TLS] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246, 1409 January 1999. 1411 [FORMDATA] L. Masinter, "Returning Values from Forms: multipart/form-data", 1412 RFC 2388, August, 1998. 1414 [HTML] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0 1415 Specification", World Wide Web Consortium Technical Report 1416 "REC-html40", December, 1997. 1418 [GISB] Gas Industry Standards Board, "Electronic Delivery 1419 Mechanism Related Standards", Version 1.3 July 31, 1998 1421 [MIME-TYPES] "Media Types," http://www.isi.edu/in-notes/iana/assignments/ 1422 media-types/media-types. 1424 [EDIINT] T. Harding, R. Drummond , "Requirements for Interoperable Internet 1425 EDI",Internet draft: draft-ietf-ediint-req.txt. 1427 HTTP Transport for Secure EDI April 1, 2001 1429 F. Security Considerations 1431 This entire document is concerned with secure transport of business to 1432 business data, and considers both privacy and authentication issues. 1434 G. Authors' Addresses 1436 Dale Moberg 1437 dale_moberg@stercomm.com 1438 Sterling Commerce 1439 4600 Lakehurst Ct. 1440 Dublin, OH 43016 USA 1442 Dick Brooks 1443 dick@8760.com 1444 Group 8760 1445 110 12th Street North 1446 Suite F103 1447 Birmingham, Alabama 35203 1448 Tel: 205-250-8053 1450 Rik Drummond 1451 rik@drummondgroup.com 1452 Drummond Group 1453 5008 Bentwood Ct. 1454 Ft. Worth, TX 76132 USA