idnits 2.17.1 draft-ietf-ediint-as2-00.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-04-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. == 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 1) being 537 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 3 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 173: '...ransfer encoding MUST not be used. A ...' RFC 2119 keyword, line 174: '... field MUST be provided....' RFC 2119 keyword, line 211: '... and 14.23) MUST be included....' RFC 2119 keyword, line 299: '... The HTTP reply SHOULD omit the third...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '... as descri...' == Line 296 has weird spacing: '...rt part will ...' == Line 309 has weird spacing: '...t Draft draft...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An EDI data file or stream is first structured into one of the message templates described in [12], sections 4.2.1 to 4.2.4 or 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. If TLS is to be used, the typical packaging will be that provided in 4.2.2 or 4.3.2; that is, a multipart/signed message will be created with no encryption in the message. Otherwise, if privacy is desired, message templates 4.2.4 or 4.3.4 are used. Content transfer encoding MUST not be used. A content-length field MUST be provided. -- 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 (14 November 1997) is 9659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 468, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 481, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) == Outdated reference: A later version (-07) exists of draft-ietf-receipt-mdn-04 ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) -- Possible downref: Normative reference to a draft: ref. '8' -- No information found for draft-ietf-ediint-req03 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1892 (ref. '10') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 2068 (ref. '11') (Obsoleted by RFC 2616) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-04 == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-04 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. '13') Summary: 17 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EDIINT Working Group Chuck Shih 3 draft-ietf-ediint-as2-00.txt Dale Moberg 4 Expires in six months Rik Drummond 5 14 November 1997 7 HTTP Transport for Secure EDI 9 draft-ietf-ediint-as2-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 27 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This document describes how to exchange EDI documents securely 33 using http transport for EDI data that is packaged in MIME messages 34 that use public key security body parts. 36 Feedback Instructions: 38 If you want to provide feedback on this draft, follow these guidelines: 40 -Send feedback via e-mail to the ietf-ediint list for discussion, with 41 "AS#2" in the Subject field. To enter/follow the discussion, you 42 need to subscribe at ietf-ediint@imc.org. 44 -Be specific as to what section you are referring to, preferably 45 quoting the portion that needs modification, after which you state 46 your comments. 48 -If you are recommending some text to be replaced with your suggested 49 text, again, quote the section to be replaced, and be clear on the 50 section in question. 52 Table of Contents 54 1. Introduction 55 1.1 Purpose and relation to previous work 56 1.2 Overall operation 58 2. Stages of an HTTP EDI exchange transaction 59 2.1 EDI sending using POST 60 2.1.1 Response and Error Codes for POST requests 61 2.1.2 Using Transport Layer Security 62 2.2 Receipt Reply 64 3. Referenced RFCs and their contribution 65 3.1 RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1 [11] 66 3.2 Internet draft (dierks): Transport Layer Security [11] 67 3.3 RFC 1847 MIME Security Multiparts [6] 68 3.4 RFC 1892 Multipart/report [9] 69 3.5 RFC 1767 EDI Content [2] 70 3.6 RFC 2015 PGP/MIME [4] 71 3.7 RFC 2045, 2046, and 2049 MIME [1] 72 3.8 Internet draft (fajman): Message Disposition Notification [5] 73 3.9 Internet draft (dusse): - S/MIME Specification [8] 75 4. Differences between HTTP and SMTP based transport 76 4.1 Unused MIME headers and operations 77 4.1.1 Content-Transfer-Encoding not used 78 4.1.2 Epilogue must be empty 79 4.1.3 Lengthy message bodies and Message/partial 80 4.2 Differences in MIME or other headers or parameters used 81 4.2.1 Content-Length needed. 82 4.2.2 Disposition-notification-to 83 4.2.3 To, Final-Recipient, and Original Recipient 84 4.2.4 Message-Id and Original-Message-Id 85 4.2.5 Host 87 5. Acknowledgments 89 6. References 91 7. Authors' Addresses 93 1. Introduction 95 1.1 Purpose and relation to previous work 97 Early work on Internet EDI focused on specifying MIME content 98 types for EDI data ([2] RFC 1767). The functional requirements 99 document [9], "Requirements for Interoperable Internet EDI," 100 provides extensive information on EDI security 101 and the business and user processes surrounding the need for and 102 use of EDI security. In addition, MIME structures 103 appropriate for SMTP transport of the packaged EDI data have 104 been specified ([12] "MIME-based Secure EDI" draft ). 105 That specification also describes comprehensive security features, 106 specifically data privacy, data integrity/authenticity, 107 non-repudiation of origin and non-repudiation of receipt. 109 In this document, it is assumed that the reader is familiar 110 with the SMTP/MIME transport document, the requirements document, 111 and the RFCs applied or referenced in those documents. 113 This draft, like the SMTP/MIME transport document, builds on 114 previous RFCs and is attempting to "re-invent" as little 115 as possible. The goal here is to specify how previously specified 116 MIME messaging structures and operations can be adapted for use with 117 HTTP servers and clients to obtain secure, reliable, 118 and acknowledged transport for EDI data. 120 The applicability statement, [12] "MIME-based Secure EDI," 121 explained the basic EDI transaction using the concept of a 122 "secure transmission loop" for EDI. This loop involves 123 one organization sending a signed and encrypted EDI 124 interchange to another organization, 125 requesting a signed receipt, followed later by the 126 receiving organization sending this signed receipt back to the 127 sending organization. In other words, the following transpires: 129 i. The organization sending EDI/EC data encrypts the data and 130 provides a digital signature, using either PGP/MIME or S/MIME. 131 In addition, they request a signed receipt. 133 ii. The receiving organization decrypts the message and verifies 134 the signature, resulting in verified integrity of the data and 135 authenticity of the sender. 137 iii. The receiving organization then sends a signed receipt in the 138 form of a signature over the hash of a message disposition 139 notification, which contains a hash of the received message. 141 The above describes functionality which if implemented would 142 satisfy all security requirements. Other restricted subsets of 143 functionality have also been characterized. In this document, the 144 goal is to make use of HTTP instead of SMTP as a transport protocol, 145 and make changes needed to adapt to protocol packaging differences. 146 An option to make use of Transport Layer Security [13] to provide 147 privacy is also added. 149 Note that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 150 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 151 "MAY", and "OPTIONAL" in this document are to be interpreted 152 as described in RFC 2119. 154 1.2 Overall operation 156 A HTTP POST operation [11] is used to send appropriately packaged 157 EDI or other business data. The Request-URI ([11] section 9.5) 158 identifies a process to unpack and handle the message data 159 and to generate a reply for the client that contains a message 160 disposition acknowledgement. This request/reply transaction 161 provides secure, reliable, and authenticated transport for EDI 162 or other business data using HTTP. 164 2. Stages of an HTTP EDI exchange transaction 166 An EDI data file or stream is first structured into one of the 167 message templates described in [12], sections 4.2.1 to 4.2.4 or 168 4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. If TLS is to be used, 169 the typical packaging will be that provided in 4.2.2 or 4.3.2; 170 that is, a multipart/signed message will be created with no 171 encryption in the message. Otherwise, if privacy 172 is desired, message templates 4.2.4 or 4.3.4 are used. 173 Content transfer encoding MUST not be used. A content-length 174 field MUST be provided. 176 To request an unsigned message disposition notification, 177 additional extension headers should be added to the content-type 178 and content-length headers in the entity header section preceding 179 the message body. 181 A Disposition-Notification-To [5] header is added to indicate 182 that a message disposition notification is requested 183 in the reply to the POST request. The value for this header 184 plays no real role in the reply mechanism, unlike in the 185 SMTP transport reply. A Message-ID header may be added to support 186 message reconciliation, although the role of this value is not 187 crucial in a connection-oriented (the HTTP/1.1 default) transaction. 189 A Disposition-Notification-Options header is used to request 190 a signed message disposition notification. The parameters 191 used to select protocols for signed message disposition 192 notification are found in [12]. 194 2.1 EDI sending using POST 196 For sending EDI, the following protocol elements are typically 197 present: a request line [11], section 5.1, entity headers, a 198 CRLF pair to mark the end of the entity headers, followed by the 199 message-body. 201 The request line will have the form: "POST Request-URI HTTP/1.1". 202 The spaces must be present. (The Request-URI is normally exchanged 203 out of band, as part of setting up a trading partner agreement. 204 Automation of this process is outside this specification.) 205 The request line must be followed by a CRLF. 207 The request line may be followed by general headers and 208 request headers, but must be followed by entity headers 209 specifying content length ([11] section 14.14) and content type 210 [11] section 14.18. The Host request header ([11] sections 9 211 and 14.23) MUST be included. 213 The entity headers used for requesting a message disposition 214 notification (unsigned or signed) have previously been mentioned. 216 2.1.1 Response and Error Codes for POST requests 218 The status line for response to errors in the POST request line 219 will be provided by a status line with the following protocol 220 elements present ( [11], section 6.1 ) : HTTP version (normally, 221 HTTP/1.1), a status code, reason phrase, and CRLF. 223 The suggested status code should be a 204 ("No Content") 224 in case the request-URI process does not produce 225 an entity to return. Other explicit error codes are 226 documented in [11], sections 6.1.1 and throughout section 10. 227 For errors in the request-URI, 400 ("Bad Request"), 228 404 ("Not Found") and similar codes are appropriate status codes. 229 Successful responses will be discussed in section 2.2 below, 230 where the inclusion of an entity containing the message 231 disposition notification is also discussed. 233 2.1.2 Using Transport Layer Security 235 To use Transport Layer Security, the request-URI should indicate 236 the appropriate scheme value, https. Usually only a multipart/signed 237 message body would be sent using TLS, as encrypted message bodies 238 would be redundant. Encrypted message bodies may be sent, however. 240 2.2 Receipt Reply 242 The response to the POST command varies depending upon whether 243 a receipt has been requested and upon what kind of receipt 244 has been requested. 246 With no extended header requesting a receipt, and no errors 247 accessing the request-URI specified processing, the status 248 line in the Response to the POST request should be 200, 249 201 or 202. Status code 200 ("OK") should be used when 250 an entity is returned (a signed receipt in a multipart/signed 251 content type or an unsigned receipt in a multipart/report). 252 Status 201 ("Created") should be used if a URI pointing to a receipt 253 is returned; this may be preferable to returning an unsolicited 254 receipt. The code 202 ("Accepted") should be used to indicate 255 processing unable to generate acknowledgements; this status 256 is non-committal on the disposition of the message. 258 An application may include an unsolicited multipart/report 259 as a message body. Extended headers for content-type 260 and content-length must be provided. 262 When a message disposition notice extended header is present 263 in the POST request extended headers, then entity headers for 264 the message disposition notice should be included and a message 265 body containing the multipart/report [10] or multipart/signed [6] 266 should be included in the Response entity headers as appropriate. 267 The basic responsibilities of responding to requests are discussed 268 at length in [12] section 5, and in detail within section 5.2.1. 270 Message Disposition Notifications, when used in the HTTP reply 271 context, will normally contain a restricted set of features 272 of a MDN. 274 The disposition field is a required element in the machine 275 readable second part of a multipart/report. 276 The final-recipient-field([5] section 3.1) value need not 277 be derived from the entity headers of the request, 278 because the "To" field may be absent in the entity 279 headers. In the case of a signed report, 280 the value may be the email address field from 281 the signer's X.509 attribute for email addresses. 282 For unsigned reports, a technical or administrative 283 contact's email address may be included. However, 284 if a "To" field is present in the request headers, 285 then that value should be used for the value of the 286 "Final-Recipient" field in the message/disposition-notification 287 body part. 289 An application should report the Message-ID of a request 290 if it was included in the request using the original-message- 291 id-field in the message/disposition-notification body part. 293 The human readable part (the first part of the multipart/report) 294 may omit items such as the subject, date and other information 295 not generally present in header fields in the POST request. 296 Generally the first report part will consist of some text 297 reflecting the disposition status. 299 The HTTP reply SHOULD omit the third part of the report (which 300 can includes the original message or its headers in the SMTP 301 context). 303 3. Referenced RFCs and their contribution 305 3.1 RFC 2068 [11] : The HyperText Transfer Protocol, HTTP, 306 provides an application level protocol for distributed hypermedia 307 information systems. This standard specifies the protocol HTTP/1.1. 309 3.2 Internet Draft draft-ietf-tls-protocol-04.txt: Transport Layer 310 Security specifies a protocol similar to SSL version 3 that provides 311 communications privacy over the Internet. Applications can 312 communicate without eavesdropping, tampering, or message forgery. 314 3.3 RFC 1847 MIME Security Multiparts [6] 316 This document defines security multiparts for MIME: 317 multipart/encrypted and multipart/signed. 319 3.4 RFC 1892 Multipart/report [10] 321 This RFC defines the use of the multipart/report content type, 322 something that the MDN draft (fajman) builds upon. 324 3.5 RFC 1767 EDI Content [2] 326 This RFC defines the use of content type "application" for ANSI 327 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 328 mutually defined EDI (application/EDI-Consent). 330 3.6 RFC 2015 PGP/MIME [4] 332 This RFC defines the use of content types 333 "multipart/encrypted", "multipart/signed", "application/pgp 334 encrypted" and "application/pgp-signature" for defining MIME PGP 335 content. 337 3.7 RFC 2045, 2046, and 2049 MIME [1] 339 These are the basic MIME standards, upon which all MIME related RFCs 340 build, including this one. Key contributions include definition of 341 "content type", "sub-type" and "multipart", as well as encoding 342 guidelines, which establishes 7-bit US-ASCII as the canonical 343 character set to be used in Internet messaging. 345 3.8 Internet draft (fajman): Message Disposition Notification [5] 347 This Internet draft defines how a message disposition notification 348 (MDN) is requested, and the format and syntax of the MDN. The MDN 349 is the basis upon which receipts and signed receipts are defined 350 in this and the "Requirements" specification. 352 3.9 Internet draft (dusse): S/MIME Message Specification [8] 353 This specification describes how MIME shall carry PKCS7 354 envelopes. 356 3.10 Internet draft (shih): MIME-based Secure EDI [12] 357 This applicability statement describes security patterns, 358 MIME content types, and acknowledgement policies and 359 mechanisms for EDI or business data transport. 361 4. Comparison of HTTP and SMTP based transport 363 The major difference between HTTP and SMTP transport for secure 364 EDI is found in the persistence of the connection over the send 365 and reply transaction. SMTP may involve mail relays; HTTP 366 may involve intermediate proxies. Likewise, SMTP MTAs must invoke 367 user agents to handle messages, and HTTP servers handle 368 the POST request via a cooperating thread or process. For HTTP 369 version 1.1, TCP persistent connections are the default, ( [11] 370 sections 8.1.2, 8.2, and 19.7.1). 372 A number of other differences exist because HTTP does not 373 conform to MIME [1] as used in SMTP transport. Relevant 374 differences are summarized below. 376 4.1 Unused MIME headers and operations 378 4.1.1 Content-Transfer-Encoding not used in HTTP transport 380 Because HTTP, unlike SMTP, does not have an early history 381 involving 7-bit restriction, there is no need to use 382 the Content Transfer Encodings of MIME [1]. This difference 383 is discussed in [11] section 19.4.4. 385 4.1.2 Epilogue must be empty 387 The EBNF for a multipart [1] RFC 2046, section 5.1.1 allows 388 a multipart to have trailing octets after the close delimiter. 389 In [11] section 3.7.2, it is explicitly noted that multiparts 390 must have null epilogues. 392 4.1.3 Lengthy message bodies 394 In [12], section 5.4.1, options for large file processing are 395 discussed for SMTP transport. For HTTP, large files should 396 be handled correctly by the TCP layer. However, [11] sections 397 3.5 and 3.6 discuss some options for compressing or chunking 398 entities to be transferred. Section 8.1.2.2 discusses a 399 pipelining option that may be useful for segmenting large 400 amounts of data. 402 4.2 Differences in MIME or other headers or parameters used 404 4.2.1 Content-Length 406 Because connections are persistent, closing a connection 407 cannot be used to indicate the end of an entity. Therefore, 408 [11] sections 4.4 and 14.14 indicate the need for a 409 Content-Length entity header in a request. In MIME, 410 Content-Length is not normally used. 412 4.2.2 Disposition-notification-to 414 In MIME, a value is needed in order to mail the 415 message disposition notification to an address. 417 In HTTP, a value is not needed because the reply 418 goes back as an "immediate" response, using the 419 existing TCP connection. A good value to use would 420 be a technical or administrative contact email address. 421 The header itself must be present. 423 4.2.3 To, Final Recipient, and Original Recipient 425 The "To" is optional in the POST request. 427 If present, it should be used as the Final-Recipient value 428 if request generated. If absent, Final-Recipient value may 429 be the signer email address for unsigned receipts or 430 a technical or administrative contact email address. 432 The final and original recipient distinction should not 433 arise for HTTP transport. 435 4.2.4 Message-Id and Original-Message-Id 437 In SMTP, required and useful for reconciliation of MDN receipt 438 with original message. 440 In HTTP, not required but could be useful for reconciliation 442 4.2.5 Host header 444 The host request header field must be included in the 445 POST request made when sending business data. This field 446 is to allow one server IP address to service multiple 447 hostnames, and potentially conserve IP addresses. 448 See [11], sections 14.23 and 19.5.1. 450 5. Acknowledgments 452 6. References 454 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 455 Part One: Format of Internet Message Bodies", RFC 2045, 456 December 02, 1996. 458 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 459 Part Two: Media Types", RFC 2046, December 02, 1996. 461 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 462 Part Five: Conformance Criteria and Examples", RFC 2049 , December 02, 463 1996. 465 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 466 2, 1995. 468 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 469 Messages", STD 11, RFC 822, August 13, 1982. 471 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 472 2015, Sept. 1996. 474 [5] R. Fajman, "An Extensible Message Format for Message Disposition 475 Notifications", draft-ietf-receipt-mdn-04.txt, June 14, 1997. 477 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts 478 for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 479 3, 1995 481 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 482 August 1, 1982. 484 [8] S. Dusse, "S/MIME Message Specification; PKCS Security 485 Services for MIME", Internet draft: draft-dusse-mime-msg-spec 486 00.txt 488 [9] C. Shih, "Requirements for Interoperable Internet EDI", 489 Internet draft: draft-ietf-ediint-req03.txt July 1997. 491 [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting 492 of Mail System Administrative Messages", RFC 1892, 493 January 15, 1996. 495 [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 496 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, 497 January 1997. 499 [12] C. Shih, "MIME-based Secure EDI", Internet draft: 500 draft-ietf-ediint-as1-04.txt, 502 [13] T. Dierks, "The TLS Protocol, Version 1.0," Internet draft: 503 draft-ietf-tls-protocol-04.txt, April 28, 1997. 505 7. Authors' Addresses 507 Chuck Shih 508 chucks@actracorp.com 509 Actra Corp. 510 610 East Caribbean Drive 511 Sunnyvale, CA 94089 USA 513 Dale Moberg 514 dale_moberg@stercomm.com 515 Sterling Commerce 516 4600 Lakehurst Ct. 517 Dublin, OH 43016 USA 519 Rik Drummond 520 drummond@onramp.com 521 The Drummond Group 522 5008 Bentwood Ct. 523 Ft. Worth, TX 76132 USA