INTERNET-DRAFT                                             RohitNetwork Working Group                                           R. Khare
<draft-ietf-tls-http-upgrade-00.txt>
Internet-Draft                                 4K Associates / UC Irvine
Expires May
Expires: December 21, 1999                                   S. Lawrence
                                                   Agranat Systems, Inc.
                                                           June 22, 1999                                     November 16, 1998

                    Upgrading to TLS Within HTTP/1.1
                     draft-ietf-tls-http-upgrade-01.txt

Status of this Memo

   This document is an Internet-Draft. Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work "work in progress.''

   To learn the progress."

   The list of current status Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet Drafts Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). December 21, 1999.

Abstract

   This memo proposes a applies the Upgrade mechanism to upgrade in HTTP/1.1 connections to use employ
   Transport Layer Security (TLS). Using (TLS) over an Upgrade: TLS/x.y request
   header would allow existing TCP connection. This
   allows unsecured and secured traffic to share the same well known
   port (in this case, 80). A companion document describes the current
   practice of using http: at 80 rather than https: at 443). This
   also enables "virtual hosting," by allowing a separate port for single HTTP over TLS,
   <draft-ietf-tls-https-01.txt>.

  0. Motivation

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors indicated they would like + TLS
   server to see a mechanism disambiguate traffic intended for
   applying Transport Layer Security [TLS] within an HTTP connection, several hostnames at
   the same port, instead of only being able to recommend a distinct port
   (443) and scheme (https). IANA has already issued ten
   single IP address.

   This memo also clarifies how to exploit the HTTP/1.1 Upgrade
   mechanism in general. It creates new ports IANA registries for
   application X over TLS/SSL public HTTP
   status codes, and public or private Upgrade product tokens.

   This memo also argues that 'https' is insufficient to date.

   The TLS working group has moved forward with an extensive draft on
   properly implementing https (draft-ietf-tls-https-00), but there discriminate
   between secure and non-secure URIs, and henceforth http: alone
   should be used. That is
   alternate precedent for "securing" a regularly opened connection for
   SMTP to say, both https: and other applications (draft-hoffman-smtp-ssl,
   draft-newman-tls-imappop-03, murray-auth-ftp-ssl-00,
   draft-ietf-ldap-ext-ldapv3-TLS-00.txt ).

   There port 443 could be
   safely deprecated upon deployment of this mechanism.

Status Notes

   This memo is intended to proceed directly to Proposed Standard,
   since its functionality has already been extensive debate on the http-wg , ietf-tls and
   ietf-apps-tls mailing lists about extensively debated, but not
   implemented, over the advisability last two years. It is expected to update RFC
   2616.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Table of permitting
   optional 'upgrades' Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Client Requested Upgrade to secure connections within the same channel,
   primarily focusing on the thread HTTP over TLS  . . . . . . . . . .  4
   3.1 Requesting Upgrade When Unsecured Is Not Acceptable  . . . . .  4
   3.2 Requesting Upgrade When Unsecured Is Acceptable  . . . . . . .  4
   3.3 Server Acceptance of man-in-the-middle attacks. Our
   intent here is not Upgrade Request . . . . . . . . . . . . .  5
   4.  Server Requested Upgrade to engage in this debate, but merely HTTP over TLS  . . . . . . . . . .  5
   4.1 Server Required Upgrade to document a
   proposed mechanism for doing either with HTTP. Several applications
   being built upon HTTP might use this mechanism, such as over TLS . . . . . . . . . . .  5
   4.2 Server Advertised HTTP over TLS  . . . . . . . . . . . . . . .  6
   5.  HTTP Upgrade Usage Considerations  . . . . . . . . . . . . . .  6
   5.1 Upgrading across HTTP Proxies  . . . . . . . . . . . . . . . .  6
   6.  Rationale for the Internet
   Printing Protocol; we look to them use of a 4xx (client error) response code  .  7
   7.  Rationale for the HTTP+TLS/1.0 Upgrade token . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
   8.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.1 Implications for implementation guidance. the https: URI Scheme . . . . . . . . . . . .  9
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11

1. Motivation

   The historical practice for deploying HTTP over SSL3[2] has
   distinguished the combination from HTTP alone by a unique URI scheme
   and the TCP port number. The scheme 'http' meant the HTTP protocol
   alone on port 80, while 'https' meant the HTTP protocol over SSL on
   port 443.  Other protocols have similarly requested (and in some
   cases were issued) a second well known port so that they can
   distinguish the secured and unsecured modes of operation in this way
   as well.  Taken to its extreme, this approach in effect cuts in half
   the number of available well known ports.

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors, and the IESG broadly, reaffirmed that the practice
   of issuing parallel "secure" port numbers should be deprecated. The
   HTTP/1.1 Upgrade mechanism can indeed apply Transport Layer
   Security[5] to an HTTP connection, over the same port.

   In the nearly two years since, there has been broad acceptance of
   the concept behind this proposal, but little interest in
   implementing alternatives to port 443 for generic Web browsing.
   However, the Internet Printing Protocol[6], one of the first new
   application protocols built atop HTTP, has called for just such a
   mechanism in order to move forward in the IETF standards process.

   The Upgrade mechanism also solves the "virtual hosting" problem.
   Rather than allocating multiple IP addresses to a single host, an
   HTTP/1.1 server will use the Host: header to disambiguate the
   intended web service. As HTTP/1.1 usage has grown more prevalent,
   more ISPs are offering name-based virtual hosting, thus delaying IP
   address space exhaustion.

   TLS (and SSL) have been hobbled by the same limitation as earlier
   versions of HTTP: the initial handshake does not specify the
   intended hostname, relying exclusively on the IP address. Using a
   cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake --
   choosing the certificates based on the initial Host: header -- will
   allow ISPs to provide secure name-based virtual hosting as well.

2. Introduction

   Either the client or server can use the HTTP/1.1[1] Upgrade
   mechanism (Section 14.42) to indicate that a TLS-secured connection
   is desired or necessary. This draft defines the "HTTP+TLS/1.0"
   Upgrade token and a new HTTP Reply Code, "426 Upgrade Required".

   TLS, a/k/a SSL (Secure Sockets Layer) establishes a private
   end-to-end connection, optionally including strong mutual
   authentication, using a variety of cryptosystems. Initially, a
   handshake phase uses three subprotocols to set up a record layer,
   authenticate endpoints, set parameters, as well as report errors.
   Then, there is an ongoing layered record protocol that handles
   encryption, compression, and reassembly for the remainder of the
   connection. The latter is intended to be completely transparent. For
   example, there is no dependency between TLS's record markers and or
   certificates and HTTP/1.1's chunked encoding or authentication.

   The need
   This specification provides a procedure for either a client or
   server to request that this TLS handshake phase begin on an existing
   HTTP/1.1 connection.

3. Client Requested Upgrade to HTTP over TLS

   The client sends an HTTP/1.1 request with an Upgrade header field
   containing the token "HTTP+TLS/1.0".

3.1 Requesting Upgrade When Unsecured Is Not Acceptable

   To complete the switch to secured operation before sending any clear
   HTTP traffic, the client MAY use a method such as "OPTIONS*".

         OPTIONS * HTTP/1.1
         Host: bank.example.com
         Upgrade: HTTP+TLS/1.0
         Connection: Upgrade

   The client MUST use the OPTIONS method if unsecured operation is
   unacceptable.

3.2 Requesting Upgrade When Unsecured Is Acceptable

   The client MAY offer to switch to secured operation during a clear
   HTTP operation:

        GET http://bank.example.com/acct_stat.html?749394889300 HTTP/1.1
        Host: bank.example.com
        Upgrade: HTTP+TLS/1.0
        Connection: Upgrade

   In this case, the server MAY respond to the clear HTTP operation
   normally, OR switch to secured operation (as detailed in the next
   section).

3.3 Server Acceptance of Upgrade Request

   As specified in HTTP/1.1[1], if the server is prepared to initiate
   the TLS handshake, it MUST send the intermediate "101 Switching
   Protocol" response specifying the upgrade tokens it is switching to:

       HTTP/1.1 101 Switching Protocols
       Upgrade: HTTP+TLS/1.0

   The TLS handshake bytes begin after the final CRNL of the HTTP
   response.

   If the TLS handshake completes, the server MUST continue with the
   response to the original request. Any TLS handshake failure MUST
   lead to disconnection, per the TLS error alert specification.

   In the 'required upgrade' case described in Section 3.1, the client
   will send the real request after the OPTIONS ("no-op") request has
   completed.

4. Server Requested Upgrade to HTTP over TLS

   The Upgrade header field can be used in HTTP responses to advertise
   server policy.

4.1 Server Required Upgrade to HTTP over TLS

   A server can indicate that a request can not be fulfilled without
   TLS secured operation using the "426 Upgrade Required" status code
   [see Section 6 for the rationale for why this is not a 3xx redirect
   response].  The 426 response MUST include an Upgrade header field
   specifying the token for the required TLS version.

       HTTP/1.1 426 Upgrade Required
       Upgrade: HTTP+TLS/1.0
       ...

   The server cannot know whether or not the client is willing or able
   to Upgrade. The use of 426 means that the request has failed, as any
   4xx code would.  This has two important implications:
   1.  The server SHOULD include a message body in the 426 response
       which indicates in human readable form the reason for the error
       and describes any alternative courses which may be available to
       the user.
   2.  Neither the server nor the client can immediately begin the TLS
       handshake -- a new request must be made, whether over the same
       TCP connection or not.

   If the client is capable of the protocol set specified by the server
   in the Upgrade header of a 426 response, it MAY begin a
   client-initiated sequence as specified in Section 3 to repeat the
   request.

   [Since the original request was presumably sent in the clear, the
   Section 3.2 method reduce the number of round-trips in this case]

4.2 Server Advertised HTTP over TLS

   As specified in [HTTP], the server MAY include an Upgrade header in
   any response to indicate a willingness to switch to any
   (combination) of the protocols listed.  Only a 101 or 426 response
   lists Upgrade tokens that MUST be used to successfully complete the
   request.

5. HTTP Upgrade Usage Considerations

   In the course of formalizing this mechanism, several principles of
   HTTP Upgrade usage have been clarified for future users.

   o  Servers MUST select at most one of the offered Upgrade tokens in
      the 101 Switching Protocols response.
   o  This implies that Upgrade tokens represent "bundles" of
      functionality. Skipping a sequential upgrade to X/1.0 then to
      Y/1.0 would require defining a joint XY/1.0 token, for example.
   o  This implies public Upgrade tokens should be managed by IANA,
      according to the process in [8].
   o  Reliable deployment of new protocol extensions requires a
      definitive failure error, "426 Upgrade Required" in this case.
      This is broadly useful for any Upgrade usage.

   Note that since Upgrade was only defined in HTTP/1.1 (and above),
   upgraded protocols can assume persistent-connections by default.

5.1 Upgrading across HTTP Proxies

   As a hop-by-hop header, Upgrade must be negotiated between each pair
   of HTTP counterparties. As an end-to-end protocol, HTTP+TLS/1.0 is
   only applicable across tunnels. The HTTP CONNECT method explicitly
   constructed a tunnel, but it requires unique port numbers to
   disambiguate services.

   The following rules apply to relaying Upgrade requests:

   1.  Upon receipt of an Upgrade header field, a proxy server MUST
       either discard all the offers, or choose to forward only those
       it agrees to become a tunnel for.
   2.  Upon receipt of a "101 Switching Protocols" response, a proxy
       server MUST become a tunnel, or report a more detailed proxy
       server error.

   Furthermore a caching proxy SHOULD not reply to a request with
   Upgrade tokens from its cache. Clients are still advised to 'secure' running connections is not merely 'running SSL
   over port 80', an early challenge for firewall developers answered by
   Ari Luotonen's ssl-tunneling-02 draft
   explicitly include "Cache-control: no-cache" in 1995 -- this case.

   Note that scheme still
   requires these scenarios slightly complicate diagnosis of a distinct port number
   426-status response. Since Upgrade: is a hop-by-hop header, a proxy
   may have removed the client's original Upgrade request, while the
   origin server continues to activate TLS.

   The HTTP/1.1 spec reserves CONNECT insist no offer was received.

6. Rationale for future use, deferring the use of a 4xx (client error) response code

   Reliable, interoperable negotiation of Upgrade features requires an
   unambiguous failure signal. The 426 Upgrade Required status code
   allows a server to definitively state the
   more recent draft-luotonen-web-proxy-tunneling-00 proposal. This
   technique perpetuates precise protocol
   extensions a given resource must be served with. Otherwise, there
   would be no solution in the concept Section 4.1 case.

   It might at first appear that security is indicated the response should have been some
   form of redirection (a 3xx code), by analogy to an old-style
   redirection to an https: URI.  User agents that do not understand
   Upgrade: preclude this:

   Suppose that the code 3YZ had been assigned for "Upgrade Required";
   a
   magic port number -- CONNECT establishes user agent that did not recognize it would treat it as 300.  It
   would then properly look for a generic "Location" header in the response and
   attempt to repeat the request at the URL in that header field.
   Since it did not know to Upgrade to HTTP+TLS/1.0, it would at best
   fail again at the new URL.

7. Rationale for the HTTP+TLS/1.0 Upgrade token

   While TLS (and SSL) are properly ignorant of the syntax and
   semantics of encapsulated, encrypted traffic, it remains
   inappropriate to infer the protocol being secured by TCP tunnel, so port
   number. To reinforce the point that the upgraded protocol is now the
   composition of HTTP and TLS/1.0, we explicitly named the Upgrade
   token HTTP+TLS/1.0.

   Note that the version number in the product token refers to the
   version of TLS employed;  the version of HTTP to be used over TLS
   following the switch is calculated normally, viz. per the version
   compatibility rules of HTTP. [Note that while TLS is compatible with
   previous versions of SSL, they do not have TLS version numbers. If
   there were a backwards-compatible Upgrade, it might have specified
   HTTP+SSL/3.0 instead.]
   Purely HTTP-compliant extensions such as IPP will reuse
   HTTP+TLS/1.0, while derivative works such as the Session Initiation
   Protocol are encouraged to define their own Upgrade mechanism and
   their own tokens.

8. IANA Considerations

   IANA shall create registries for two name spaces, as described in
   BCP 26[8]:
   o  HTTP Status Codes
   o  HTTP Upgrade Tokens

8.1 HTTP Status Code Registry

   The HTTP Status Code Registry defines the only way to specify name space for the
   Status-Code token in the layering Status line of TLS with an HTTP
   (https) or with NTTP (snews).

   Instead, the preferred mechanism to initiate response.  The
   initial values for this name space are those specified by
   1.  Draft Standard for HTTP/1.1[1]
   2.  Web Distributed Authoring and insert TLS in an
   HTTP/1.1 session should be the Upgrade: header, as defined Versioning[3] [defines 420-424]
   3.  WebDAV Advanced Collections[4] (Work in Progress) [defines 425]
   4.  section
   14.42 Section 6 of rev-03. Ideally, TLS-capable clients should add "Upgrade:
   TLS/1.0" this specification.[defines 426]

   Values to their initial request, and TLS-capable servers may reply
   with "101 Switching Protocol", complete be added to this name space SHOULD be subject to review in
   the handshake, and continue
   with form of a standards track document within the "normal" response IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the original request. However, the
   specification quoth:

     "The Draft Standard for
   HTTP/1.1[1].

8.2 HTTP Upgrade header field only applies Token Registry

   The HTTP Upgrade Token Registry defines the name space for product
   tokens used to switching
     application-layer identify protocols upon the existing transport-layer
     connection."

   Aside from this minor semantic difference -- invoking TLS indeed
   changes in the existing transport-layer connection -- this is an ideal
   application of Upgrade. This technique overlays the TLS-request on an Upgrade HTTP method; requires client-initiation, and allows servers to choose
   whether header
   field.  Each registered token should be associated with one or a set
   of specifications, and with contact information.

   The Draft Standard for HTTP/1.1[1] specifies that these tokens obey
   the production for 'product':

       product         = token ["/" product-version]
       product-version = token

   Registrations should be allowed on a First Come First Served basis
   as described in BCP 26[8]. These specifications need not be IETF
   documents or be subject to make IESG review, but should obey the
   following rules:

   1.  The registration for a given token MUST NOT be changed once
       registered.
   2.  The registry MUST NOT register a token whose 'product' component
       is the switch. Like same as that of an already registered token, unless the other examples
       source of
   TLS-enabled application protocols, the original session authority for the registration is preserved
   across the TLS handshake; secured communications resumes with a
   servers' reply. same as the
       previous registry (if company XYZ, Inc. registered "XYZ/1.0",
       then no other entity should be allowed to register any token
       whose product component is "XYZ" without the consent of XYZ, Inc.

   An initial value in this namespace is defined in Section Section 7
   of this specification.

   It is NOT required that specifications for upgrade tokens be made
   publically available, but the contact information for the
   registration SHOULD be.

9. Security Considerations

   The potential for a man-in-the-middle attack (wherein (deleting the "TLS/1.0"
   HTTP+TLS/1.0 upgrade token is stripped out) is precisely token) remains the same as for current, mixed
   http/https use:

    1. practice:
   o  Removing the Upgrade token is similar to rewriting web pages to
      change https:// links to http:// links.
    2.
   o  The risk is only present if the server is willing to vend that
      information over both a secure and an insecure channel in the
      first place
    3. place.
   o  If the client knows for a fact that a server is TLS-compliant, it
      can insist on it by only connecting as https:// https: (currently) or by
      only sending an upgrade Upgrade request on with a no-op method like OPTIONS.
   o  Finally, as the https: specification warns, "users should
      carefully examine the certificate presented by the server to
      determine if it meets their expectations." -- there is no
      substitute for vigilance.

   Furthermore, for clients which do not actively try to invoke TLS,
   servers can use Upgrade: to advertise TLS compliance, too. Since
   TLS-compliance should be considered a feature of the server and not
   the resource at hand, it should be sufficient to send it once, and
   let clients cache that fact.

  2. Potential Solution

   Define "TLS/x.y" as a reference to the TLS specification
   (draft-ietf-tls-protocol-03), with x and y bound to its major and
   minor version numbers. Section 6.2.1 of the current draft explains why
   the TLS version would currently be defined as 1.0, not the actual
   parameters on the wire (which is "3.1"

9.1 Implications for backwards compatibility
   with SSL3).

   An HTTP client may initiate an upgrade by sending "TLS/x.y" as one of the field-values of the Upgrade: header. The origin-server MAY respond
   with "101 Switching Protocols"; if so it MUST include https: URI Scheme

   This mechanism does not use the header
   "Upgrade: TLS/x.y" URI scheme name to indicate what it is switching to.

   Servers which can upgrade to TLS MAY include the header "TLS/x.y" in
   an Upgrade response header to inform the client; servers SHOULD
   include such indication in response to any OPTIONS request.

   Similarly, servers MAY require clients to switch to TLS first by
   responding with a new error code "418: Upgrade Required", which MUST
   specify the
   protocol to be supported. @@ This is a change to 'core'
   HTTP; if, processwise, it's too difficult to slip in a general-purpose
   error code, we may have to fall-back to "418: TLS Required".

   Upgrade is a hop-by-hop header (Section 13.5.1), so each intervening
   proxy which supports TLS MUST also request the same version of TLS/x.y
   on its subsequent request. Furthermore, used. That is, any caching proxy which
   supports TLS MUST NOT reply from its cache when TLS/x.y has been
   requested (although clients are still recommended to explicitly
   include "Cache-control: no-cache").

   Note: proxy servers may http: URI could be able to request or initiate a TLS-secured
   connection, e.g. upgraded; and that
   https: URIs are no guarantee the outgoing or incoming firewall server will upgrade.

   Instead, the choice of a trusted
   subnetwork.

  3. Next Steps

   While there is formal interest in promulgating a scheme for HTTP/TLS
   without allocating a new port number, implementations have been
   scarce. We cannot predict what might trigger adoption of this
   proposal.

   Note: The Mandatory extension scheme for HTTP security characteristics are required on
   the connection is another mechanism,
   though arguably less aprropriate, since TLS does not modify left to the client and server.  This allows either
   party to use any information available in making this determination.
   For example, user agents may rely on user preference settings or
   information about the
   semantics security of HTTP itself. TLS would the network such as 'TLS required
   on all POST operations not on my local net or VPN', and servers may
   resource access rules such as 'the form on this page must be served
   and submitted using Upgrade for its stated
   purpose -- to switch to an entirely different protocol. TLS'.

   This document is available at http://www.ics.uci.edu/~rohit/http-tls.

    3.1 Open Issues

   There also implies both parties have been some questions about how to continue to resolve https:
   URLs with the scheme postulated here. There is a default assumption in
   many products that https and http:443 are equivalent.

   Similarly, when resolving option of fallback to a mixture less
   secure mode of secured operation if either party cannot shift to TLS and
   such unsecured URLs from
   the same site, some might postulate the need operation is acceptable to both and to "downgrade" the
   connection. We suggest simply reopening human
   user; this is not possible with the HTTP connection without
   TLS.

  4. 'https' scheme.

References

   [1]  Fielding, R.T., et. al, , "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [2]  Rescorla, E.K., "HTTP Over TLS", Internet-Draft (Work In
        Progress), September 1998.

   [3]  Goland, Y.Y., Whitehead, E.J., et. al, , "Web Distributed
        Authoring and Versioning", RFC 2518, February 1999.

   [4]  Slein, J., Whitehead, E.J., et. al, , "WebDAV Advanced
        Collections Protocol", Internet-Draft (Work in Progress), June
        1999.

   [5]  Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January
        1999.

   [6]  Herriot, R., Butler, S., Moore, P., Turner, R., "Internet
        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
        1999.

   [7]  Rose, M.T., "Writing I-Ds and RFCs using XML", April 1999.

   [8]  Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, October 1998.

Authors' Addresses

   Rohit Khare
   4K Associates / UC Irvine
   3207 Palo Verde
   Irvine, CA  92612
   US

   Phone: +1 626 806 7574
   EMail: rohit@4K-associates.com
   URI:   http://www.4K-associates.com/
   Scott Lawrence
   Agranat Systems, Inc.
   5 Clocktower Place
   Suite 400
   Maynard, MA  01754
   US

   Phone: +1 978 461 0888
   EMail: lawrence@agranat.com
   URI:   http://www.agranat.com/

Appendix A. Acknowledgments

   Thanks to to:
   o  Paul Hoffman for his work on the STARTTLS command extension for
      ESMTP. Thanks to
   o  Roy Fielding for assistance with the rationale behind Upgrade:
      and its interaction with OPTIONS.

  5. References

  1. http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0495.html
   2. http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt
   3. http://www.ietf.org/internet-drafts/draft-ietf-tls-https-00.txt
   4. http://www.imc.org/ietf-apps-tls/draft-hoffman-smtp-ssl
   5. http://www.ietf.org/internet-drafts/draft-newman-tls-imappop-03.txt
   6. http://www.consensus.com/ietf-tls/murray-auth-ftp-ssl-00.txt
   7. http://www.ics.uci.edu/pub/ietf/http/
   8. http://www.consensus.com/ietf-tls/
   9. http://www.imc.org/ietf-apps-tls/
  10. http://www.pwg.org/ipp/index.html
  11. http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt
  12. http://www.ietf.org/internet-drafts/draft-luotonen-web-proxy-tunneling-00
.txt
  13. http://www.consensus.com/ietf-tls/tls-protocol-03.txt
  14. http://www.ics.uci.edu/~rohit/http-tls
   o  Eric Rescorla for his work on standardizing the existing https:
      practice to compare with.
   o  Marshall Rose, for the xml2rfc document type description and
      tools.
   o  Jim Whitehead, for sorting out the current range of available
      HTTP status codes.

Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.