idnits 2.17.1 draft-ietf-tls-http-upgrade-05.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 486 has weird spacing: '....J. and et. a...' == Line 489 has weird spacing: '....J. and et. a...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 5, 2000) is 8872 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) ** Obsolete normative reference: RFC 2616 (ref. '1') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2396 (ref. '2') (Obsoleted by RFC 3986) == Outdated reference: A later version (-03) exists of draft-ietf-tls-https-02 ** Downref: Normative reference to an Informational draft: draft-ietf-tls-https (ref. '3') ** Obsolete normative reference: RFC 2518 (ref. '4') (Obsoleted by RFC 4918) -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2565 (ref. '7') (Obsoleted by RFC 2910) -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2629 (ref. '9') (Obsoleted by RFC 7749) -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Khare 2 Internet-Draft 4K Associates / UC Irvine 3 Expires: July 5, 2000 S. Lawrence 4 Agranat Systems, Inc. 5 January 5, 2000 7 Upgrading to TLS Within HTTP/1.1 8 draft-ietf-tls-http-upgrade-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 5, 2000. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Abstract 39 This memo explains how to use the Upgrade mechanism in HTTP/1.1 to 40 initiate Transport Layer Security (TLS) over an existing TCP 41 connection. This allows unsecured and secured HTTP traffic to share 42 the same well known port (in this case, http: at 80 rather than 43 https: at 443). It also enables "virtual hosting," so a single HTTP 44 + TLS server can disambiguate traffic intended for several hostnames 45 at a single IP address. 47 Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this 48 memo also documents the HTTP CONNECT method for establishing 49 end-to-end tunnels across HTTP proxies. Finally, this memo 50 establishes new IANA registries for public HTTP status codes, as 51 well as public or private Upgrade product tokens. 53 This memo does NOT affect the current definition of the 'https' URI 54 scheme, which already defines a separate namespace 55 (http://example.org/ and https://example.org/ are not equivalent). 57 Status Notes 59 This memo is intended to proceed directly to Proposed Standard, 60 since its functionality has been extensively debated, but not 61 implemented, over the last two years. It is expected to update RFC 62 2616. 64 Table of Contents 66 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 69 3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4 70 3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4 72 3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 5 73 4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5 74 4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5 75 4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5 76 5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6 77 5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6 78 5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 7 79 5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7 80 6. Rationale for the use of a 4xx (client error) Status Code . . 8 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8 83 7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 9 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10 86 8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10 87 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 89 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 92 1. Motivation 94 The historical practice of deploying HTTP over SSL3 [3] has 95 distinguished the combination from HTTP alone by a unique URI scheme 96 and the TCP port number. The scheme 'http' meant the HTTP protocol 97 alone on port 80, while 'https' meant the HTTP protocol over SSL on 98 port 443. Parallel well-known port numbers have similarly been 99 requested -- and in some cases, granted -- to distinguish between 100 secured and unsecured use of other application protocols (e.g. 101 snews, ftps). This approach effectively halves the number of 102 available well known ports. 104 At the Washington DC IETF meeting in December 1997, the Applications 105 Area Directors and the IESG reaffirmed that the practice of issuing 106 parallel "secure" port numbers should be deprecated. The HTTP/1.1 107 Upgrade mechanism can apply Transport Layer Security[6] to an open 108 HTTP connection. 110 In the nearly two years since, there has been broad acceptance of 111 the concept behind this proposal, but little interest in 112 implementing alternatives to port 443 for generic Web browsing. In 113 fact, nothing in this memo affects the current interpretation of 114 https: URIs. However, new application protocols built atop HTTP, 115 such as the Internet Printing Protocol[7], call for just such a 116 mechanism in order to move ahead in the IETF standards process. 118 The Upgrade mechanism also solves the "virtual hosting" problem. 119 Rather than allocating multiple IP addresses to a single host, an 120 HTTP/1.1 server will use the Host: header to disambiguate the 121 intended web service. As HTTP/1.1 usage has grown more prevalent, 122 more ISPs are offering name-based virtual hosting, thus delaying IP 123 address space exhaustion. 125 TLS (and SSL) have been hobbled by the same limitation as earlier 126 versions of HTTP: the initial handshake does not specify the 127 intended hostname, relying exclusively on the IP address. Using a 128 cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake -- 129 choosing the certificates based on the initial Host: header -- will 130 allow ISPs to provide secure name-based virtual hosting as well. 132 2. Introduction 134 TLS, a/k/a SSL (Secure Sockets Layer) establishes a private 135 end-to-end connection, optionally including strong mutual 136 authentication, using a variety of cryptosystems. Initially, a 137 handshake phase uses three subprotocols to set up a record layer, 138 authenticate endpoints, set parameters, as well as report errors. 139 Then, there is an ongoing layered record protocol that handles 140 encryption, compression, and reassembly for the remainder of the 141 connection. The latter is intended to be completely transparent. For 142 example, there is no dependency between TLS's record markers and or 143 certificates and HTTP/1.1's chunked encoding or authentication. 145 Either the client or server can use the HTTP/1.1[1] Upgrade 146 mechanism (Section 14.42) to indicate that a TLS-secured connection 147 is desired or necessary. This draft defines the "TLS/1.0" Upgrade 148 token, and a new HTTP Status Code, "426 Upgrade Required". 150 Section 3 and Section 4 describe the operation of a directly 151 connected client and server. Intermediate proxies must establish an 152 end-to-end tunnel before applying those operations, as explained in 153 Section 5. 155 2.1 Requirements Terminology 157 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 158 "MAY" that appear in this document are to be interpreted as 159 described in RFC 2119[11]. 161 3. Client Requested Upgrade to HTTP over TLS 163 When the client sends an HTTP/1.1 request with an Upgrade header 164 field containing the token "TLS/1.0", it is requesting the server to 165 complete the current HTTP/1.1 request after switching to TLS/1.0. 167 3.1 Optional Upgrade 169 A client MAY offer to switch to secured operation during any clear 170 HTTP request when an unsecured response would be acceptable: 172 GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 173 Host: example.bank.com 174 Upgrade: TLS/1.0 175 Connection: Upgrade 177 In this case, the server MAY respond to the clear HTTP operation 178 normally, OR switch to secured operation (as detailed in the next 179 section). 181 Note that HTTP/1.1[1] specifies "the upgrade keyword MUST be 182 supplied within a Connection header field (section 14.10) whenever 183 Upgrade is present in an HTTP/1.1 message." 185 3.2 Mandatory Upgrade 187 If an unsecured response would be unacceptable, a client MUST send 188 an OPTIONS request first to complete the switch to TLS/1.0 (if 189 possible). 191 OPTIONS * HTTP/1.1 192 Host: example.bank.com 193 Upgrade: TLS/1.0 194 Connection: Upgrade 196 3.3 Server Acceptance of Upgrade Request 198 As specified in HTTP/1.1[1], if the server is prepared to initiate 199 the TLS handshake, it MUST send the intermediate "101 Switching 200 Protocol" and MUST include an Upgrade response header specifying the 201 tokens of the protocol stack it is switching to: 203 HTTP/1.1 101 Switching Protocols 204 Upgrade: TLS/1.0, HTTP/1.1 205 Connection: Upgrade 207 Note that the protocol tokens listed in the Upgrade header of a 101 208 Switching Protocols response specify an ordered 'bottom-up' stack. 210 As specified in HTTP/1.1[1], Section 10.1.2: "The server will 211 switch protocols to those defined by the response's Upgrade header 212 field immediately after the empty line which terminates the 101 213 response." 215 Once the TLS handshake completes successfully, the server MUST 216 continue with the response to the original request. Any TLS 217 handshake failure MUST lead to disconnection, per the TLS error 218 alert specification. 220 4. Server Requested Upgrade to HTTP over TLS 222 The Upgrade response header field advertises possible protocol 223 upgrades a server MAY accept. In conjunction with the "426 Upgrade 224 Required" status code, a server can advertise the exact protocol 225 upgrade(s) that a client MUST accept to complete the request. 227 4.1 Optional Advertisement 229 As specified in HTTP/1.1[1], the server MAY include an Upgrade 230 header in any response other than 101 or 426 to indicate a 231 willingness to switch to any (combination) of the protocols listed. 233 4.2 Mandatory Advertisement 235 A server MAY indicate that a client request can not be completed 236 without TLS using the "426 Upgrade Required" status code, which MUST 237 include an an Upgrade header field specifying the token of the 238 required TLS version. 240 HTTP/1.1 426 Upgrade Required 241 Upgrade: TLS/1.0, HTTP/1.1 242 Connection: Upgrade 244 The server SHOULD include a message body in the 426 response which 245 indicates in human readable form the reason for the error and 246 describes any alternative courses which may be available to the 247 user. 249 Note that even if a client is willing to use TLS, it must use the 250 operations in Section 3 to proceed; the TLS handshake cannot begin 251 immediately after the 426 response. 253 5. Upgrade across Proxies 255 As a hop-by-hop header, Upgrade is negotiated between each pair of 256 HTTP counterparties. If a User Agent sends a request with an 257 Upgrade header to a proxy, it is requesting a change to the protocol 258 between itself and the proxy, not an end-to-end change. 260 Since TLS, in particular, requires end-to-end connectivity to 261 provide authentication and prevent man-in-the-middle attacks, this 262 memo specifies the CONNECT method to establish a tunnel across 263 proxies. 265 Once a tunnel is established, any of the operations in Section 3 can 266 be used to establish a TLS connection. 268 5.1 Implications of Hop By Hop Upgrade 270 If an origin server receives an Upgrade header from a proxy and 271 responds with a 101 Switching Protocols response, it is changing the 272 protocol only on the connection between the proxy and itself. 273 Similarly, a proxy might return a 101 response to its client to 274 change the protocol on that connection independently of the 275 protocols it is using to communicate toward the origin server. 277 These scenarios also complicate diagnosis of a 426 response. Since 278 Upgrade is a hop-by-hop header, a proxy that does not recognize 426 279 might remove the accompanying Upgrade header and prevent the client 280 from determining the required protocol switch. If a client receives 281 a 426 status without an accompanying Upgrade header, it will need to 282 request an end to end tunnel connection as described in Section 5.2 283 and repeat the request in order to obtain the required upgrade 284 information. 286 This hop-by-hop definition of Upgrade was a deliberate choice. It 287 allows for incremental deployment on either side of proxies, and for 288 optimized protocols between cascaded proxies without the knowledge 289 of the parties that are not a part of the change. 291 5.2 Requesting a Tunnel with CONNECT 293 A CONNECT method requests that a proxy establish a tunnel connection 294 on its behalf. The Request-URI portion of the Request-Line is always 295 an 'authority' as defined by URI Generic Syntax[2], which is to say 296 the host name and port number destination of the requested 297 connection separated by a colon: 299 CONNECT server.example.com:80 HTTP/1.1 300 Host: server.example.com:80 302 Other HTTP mechanisms can be used normally with the CONNECT method 303 -- except end-to-end protocol Upgrade requests, of course, since the 304 tunnel must be established first. 306 For example, proxy authentication might be used to establish the 307 authority to create a tunnel: 309 CONNECT server.example.com:80 HTTP/1.1 310 Host: server.example.com:80 311 Proxy-Authorization: basic aGVsbG86d29ybGQ= 313 Like any other pipelined HTTP/1.1 request, data to be tunneled may 314 be sent immediately after the blank line. The usual caveats also 315 apply: data may be discarded if the eventual response is negative, 316 and the connection may be reset with no response if more than one 317 TCP segment is outstanding. 319 5.3 Establishing a Tunnel with CONNECT 321 Any successful (2xx) response to a CONNECT request indicates that 322 the proxy has established a connection to the requested host and 323 port, and has switched to tunneling the current connection to that 324 server connection. 326 It may be the case that the proxy itself can only reach the 327 requested origin server through another proxy. In this case, the 328 first proxy SHOULD make a CONNECT request of that next proxy, 329 requesting a tunnel to the authority. A proxy MUST NOT respond with 330 any 2xx status code unless it has either a direct or tunnel 331 connection established to the authority. 333 An origin server which receives a CONNECT request for itself MAY 334 respond with a 2xx status code to indicate that a connection is 335 established. 337 If at any point either one of the peers gets disconnected, any 338 outstanding data that came from that peer will be passed to the 339 other one, and after that also the other connection will be 340 terminated by the proxy. If there is outstanding data to that peer 341 undelivered, that data will be discarded. 343 6. Rationale for the use of a 4xx (client error) Status Code 345 Reliable, interoperable negotiation of Upgrade features requires an 346 unambiguous failure signal. The 426 Upgrade Required status code 347 allows a server to definitively state the precise protocol 348 extensions a given resource must be served with. 350 It might at first appear that the response should have been some 351 form of redirection (a 3xx code), by analogy to an old-style 352 redirection to an https: URI. User agents that do not understand 353 Upgrade: preclude this. 355 Suppose that a 3xx code had been assigned for "Upgrade Required"; a 356 user agent that did not recognize it would treat it as 300. It 357 would then properly look for a "Location" header in the response and 358 attempt to repeat the request at the URL in that header field. Since 359 it did not know to Upgrade to incorporate the TLS layer, it would at 360 best fail again at the new URL. 362 7. IANA Considerations 364 IANA shall create registries for two name spaces, as described in 365 BCP 26[10]: 366 o HTTP Status Codes 367 o HTTP Upgrade Tokens 369 7.1 HTTP Status Code Registry 371 The HTTP Status Code Registry defines the name space for the 372 Status-Code token in the Status line of an HTTP response. The 373 initial values for this name space are those specified by 374 1. Draft Standard for HTTP/1.1[1] 375 2. Web Distributed Authoring and Versioning[4] [defines 420-424] 376 3. WebDAV Advanced Collections[5] (Work in Progress) [defines 425] 377 4. Section 6 [defines 426] 379 Values to be added to this name space SHOULD be subject to review in 380 the form of a standards track document within the IETF Applications 381 Area. Any such document SHOULD be traceable through statuses of 382 either 'Obsoletes' or 'Updates' to the Draft Standard for 383 HTTP/1.1[1]. 385 7.2 HTTP Upgrade Token Registry 387 The HTTP Upgrade Token Registry defines the name space for product 388 tokens used to identify protocols in the Upgrade HTTP header field. 389 Each registered token should be associated with one or a set of 390 specifications, and with contact information. 392 The Draft Standard for HTTP/1.1[1] specifies that these tokens obey 393 the production for 'product': 395 product = token ["/" product-version] 396 product-version = token 398 Registrations should be allowed on a First Come First Served basis 399 as described in BCP 26[10]. These specifications need not be IETF 400 documents or be subject to IESG review, but should obey the 401 following rules: 403 1. A token, once registered, stays registered forever. 404 2. The registration MUST name a responsible party for the 405 registration. 406 3. The registration MUST name a point of contact. 407 4. The registration MAY name the documentation required for the 408 token. 409 5. The responsible party MAY change the registration at any time. 410 The IANA will keep a record of all such changes, and make them 411 available upon request. 412 6. The responsible party for the first registration of a "product" 413 token MUST approve later registrations of a "version" token 414 together with that "product" token before they can be registered. 415 7. If absolutely required, the IESG MAY reassign the responsibility 416 for a token. This will normally only be used in the case when a 417 responsible party cannot be contacted. 419 This specification defines the protocol token "TLS/1.0" as the 420 identifier for the protocol specified by The TLS Protocol[6]. 422 It is NOT required that specifications for upgrade tokens be made 423 publicly available, but the contact information for the registration 424 SHOULD be. 426 8. Security Considerations 428 The potential for a man-in-the-middle attack (deleting the Upgrade 429 header) remains the same as current, mixed http/https practice: 430 o Removing the Upgrade header is similar to rewriting web pages to 431 change https:// links to http:// links. 432 o The risk is only present if the server is willing to vend such 433 information over both a secure and an insecure channel in the 434 first place. 435 o If the client knows for a fact that a server is TLS-compliant, it 436 can insist on it by only sending an Upgrade request with a no-op 437 method like OPTIONS. 438 o Finally, as the https: specification warns, "users should 439 carefully examine the certificate presented by the server to 440 determine if it meets their expectations." 442 Furthermore, for clients that do not explicitly try to invoke TLS, 443 servers can use the Upgrade header in any response other than 101 or 444 426 to advertise TLS compliance. Since TLS compliance should be 445 considered a feature of the server and not the resource at hand, it 446 should be sufficient to send it once, and let clients cache that 447 fact. 449 8.1 Implications for the https: URI Scheme 451 While nothing in this memo affects the definition of the 'https' URI 452 scheme, widespread adoption of this mechanism for HyperText content 453 could use 'http' to identify both secure and non-secure resources. 455 The choice of what security characteristics are required on the 456 connection is left to the client and server. This allows either 457 party to use any information available in making this determination. 458 For example, user agents may rely on user preference settings or 459 information about the security of the network such as 'TLS required 460 on all POST operations not on my local net', or servers may apply 461 resource access rules such as 'the FORM on this page must be served 462 and submitted using TLS'. 464 8.2 Security Considerations for CONNECT 466 A generic TCP tunnel is fraught with security risks. First, such 467 authorization should be limited to a small number of known ports. 468 The Upgrade: mechanism defined here only requires onward tunneling 469 at port 80. Second, since tunneled data is opaque to the proxy, 470 there are additional risks to tunneling to other well-known or 471 reserved ports. A putative HTTP client CONNECTing to port 25 could 472 relay spam via SMTP, for example. 474 References 476 [1] Fielding, R.T. and et. al, "Hypertext Transfer Protocol -- 477 HTTP/1.1", RFC 2616, June 1999. 479 [2] Berners-Lee, T., Fielding, R.T. and L. Masinter, "URI Generic 480 Syntax", RFC 2396, August 1998. 482 [3] Rescorla, E.K., "HTTP Over TLS", Internet-Draft (Work In 483 Progress) (Non-Normative Background Information) 484 draft-ietf-tls-https-02, September 1998. 486 [4] Goland, Y.Y., Whitehead, E.J. and et. al, "Web Distributed 487 Authoring and Versioning", RFC 2518, February 1999. 489 [5] Slein, J., Whitehead, E.J. and et. al, "WebDAV Advanced 490 Collections Protocol", Internet-Draft (Work In Progress) 491 (Non-Normative Background Information) 492 draft-ietf-webdav-collection-protocol-04, June 1999. 494 [6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 495 1999. 497 [7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet 498 Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 499 1999. 501 [8] Luotonen, A., "Tunneling TCP based protocols through Web proxy 502 servers", Internet-Draft (Work In Progress) (Non-Normative 503 Historical Information; Also available in: Luotonen, Ari. Web 504 Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120) 505 draft-luotonen-web-proxy-tunneling-01, August 1998. 507 [9] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 508 1999. 510 [10] Narten, T. and H.T. Alvestrand, "Guidelines for Writing an 511 IANA Considerations Section in RFCs", BCP 26, October 1998. 513 [11] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", RFC 2119, BCP 14, March 1997. 516 Authors' Addresses 518 Rohit Khare 519 4K Associates / UC Irvine 520 3207 Palo Verde 521 Irvine, CA 92612 522 US 524 Phone: +1 626 806 7574 525 EMail: rohit@4K-associates.com 526 URI: http://www.4K-associates.com/ 527 Scott Lawrence 528 Agranat Systems, Inc. 529 5 Clocktower Place 530 Suite 400 531 Maynard, MA 01754 532 US 534 Phone: +1 978 461 0888 535 EMail: lawrence@agranat.com 536 URI: http://www.agranat.com/ 538 Appendix A. Acknowledgments 540 The CONNECT method was originally described in an Internet-Draft 541 titled Tunneling TCP based protocols through Web proxy servers[8] by 542 Ari Luotonen of Netscape Communications Corporation. It was widely 543 implemented by HTTP proxies, but was never made a part of any IETF 544 Standards Track document. The method name CONNECT was reserved, but 545 not defined in [1]. 547 The definition provided here is derived directly from that earlier 548 draft, with some editorial changes and conformance to the stylistic 549 conventions since established in other HTTP specifications. 551 Additional Thanks to: 552 o Paul Hoffman for his work on the STARTTLS command extension for 553 ESMTP. 554 o Roy Fielding for assistance with the rationale behind Upgrade: 555 and its interaction with OPTIONS. 556 o Eric Rescorla for his work on standardizing the existing https: 557 practice to compare with. 558 o Marshall Rose, for the xml2rfc document type description and 559 tools[9]. 560 o Jim Whitehead, for sorting out the current range of available 561 HTTP status codes. 562 o Henrik Frystyk Nielsen, whose work on the Mandatory extension 563 mechanism pointed out a hop-by-hop Upgrade still requires 564 tunneling. 565 o Harald Alvestrand for improvements to the token registration 566 rules. 568 Full Copyright Statement 570 Copyright (C) The Internet Society (2000). All Rights Reserved. 572 This document and translations of it may be copied and furnished to 573 others, and derivative works that comment on or otherwise explain it 574 or assist in its implmentation may be prepared, copied, published 575 and distributed, in whole or in part, without restriction of any 576 kind, provided that the above copyright notice and this paragraph 577 are included on all such copies and derivative works. However, this 578 document itself may not be modified in any way, such as by removing 579 the copyright notice or references to the Internet Society or other 580 Internet organizations, except as needed for the purpose of 581 developing Internet standards in which case the procedures for 582 copyrights defined in the Internet Standards process must be 583 followed, or as required to translate it into languages other than 584 English. 586 The limited permissions granted above are perpetual and will not be 587 revoked by the Internet Society or its successors or assigns. 589 This document and the information contained herein is provided on an 590 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 591 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 592 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 593 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 594 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Acknowledgement 598 Funding for the RFC editor function is currently provided by the 599 Internet Society.