to an https: URI.  User agents that do not understand Upgrade:
   preclude this.

   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
   user agent that did not recognize it would treat it as 300.  It would
   then properly look for a "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 incorporate the TLS layer, it would at
   best fail again at the new URL.

7. IANA Considerations

   IANA shall create registries for two name spaces, as described in BCP
   26 [10]:

   o  HTTP Status Codes
   o  HTTP Upgrade Tokens

7.1 HTTP Status Code Registry

   The HTTP Status Code Registry defines the name space for the Status-
   Code token in the Status line of an HTTP 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 Versioning [4] [defines 420-424]
   3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
   4.  Section 6 [defines 426]

   Values to be added to this name space SHOULD be subject to review in
   the form of a standards track document within the IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the Draft Standard for
   HTTP/1.1 [1].

7.2 HTTP Upgrade Token Registry

   The HTTP Upgrade Token Registry defines the name space for product
   tokens used to identify protocols in the Upgrade HTTP 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':






 
RFC 2817                  HTTP Upgrade to TLS                   May 2000


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

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

   1.  A token, once registered, stays registered forever.
   2.  The registration MUST name a responsible party for the
       registration.
   3.  The registration MUST name a point of contact.
   4.  The registration MAY name the documentation required for the
       token.
   5.  The responsible party MAY change the registration at any time.
       The IANA will keep a record of all such changes, and make them
       available upon request.
   6.  The responsible party for the first registration of a "product"
       token MUST approve later registrations of a "version" token
       together with that "product" token before they can be registered.
   7.  If absolutely required, the IESG MAY reassign the responsibility
       for a token. This will normally only be used in the case when a
       responsible party cannot be contacted.

   This specification defines the protocol token "TLS/1.0" as the
   identifier for the protocol specified by The TLS Protocol [6].

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

8. Security Considerations

   The potential for a man-in-the-middle attack (deleting the Upgrade
   header) remains the same as current, mixed http/https practice:

   o  Removing the Upgrade header is similar to rewriting web pages to
      change https:// links to http:// links.
   o  The risk is only present if the server is willing to vend such
      information over both a secure and an insecure channel in the
      first place.
   o  If the client knows for a fact that a server is TLS-compliant, it
      can insist on it by only sending an Upgrade request 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