draft-ietf-tls-http-upgrade-02.txt   draft-ietf-tls-http-upgrade-03.txt 
Network Working Group R. Khare Network Working Group R. Khare
Internet-Draft 4K Associates / UC Irvine Internet-Draft 4K Associates / UC Irvine
Expires: February 15, 2000 S. Lawrence Expires: February 15, 2000 S. Lawrence
Agranat Systems, Inc. Agranat Systems, Inc.
August 17, 1999 August 17, 1999
Upgrading to TLS Within HTTP/1.1 Upgrading to TLS Within HTTP/1.1
draft-ietf-tls-http-upgrade-02.txt draft-ietf-tls-http-upgrade-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 9, line 16 skipping to change at page 9, line 16
the production for 'product': the production for 'product':
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
Registrations should be allowed on a First Come First Served basis Registrations should be allowed on a First Come First Served basis
as described in BCP 26[10]. These specifications need not be IETF as described in BCP 26[10]. These specifications need not be IETF
documents or be subject to IESG review, but should obey the documents or be subject to IESG review, but should obey the
following rules: following rules:
1. The registration for a given token MUST NOT be changed once 1. A token, once registered, stays registered forever.
registered. 2. The registration MUST name a responsible party for the
2. The registry MUST NOT register a token whose 'product' component registration.
is the same as that of an already registered token, unless the 3. The registration MUST name a point of contact.
source of the authority for the registration is the same as the 4. The registration MAY name the documentation required for the
previous registry (if company XYZ, Inc. registered "XYZ/1.0", token.
then no other entity should be allowed to register any token 5. The responsible party MAY change the registration at any time.
whose product component is "XYZ" without the consent of XYZ, Inc. 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 This specification defines the protocol token "TLS/1.0" as the
identifier for the protocol specified by The TLS Protocol[6]. identifier for the protocol specified by The TLS Protocol[6].
It is NOT required that specifications for upgrade tokens be made It is NOT required that specifications for upgrade tokens be made
publicly available, but the contact information for the registration publicly available, but the contact information for the registration
SHOULD be. SHOULD be.
8. Security Considerations 8. Security Considerations
skipping to change at page 13, line 4 skipping to change at page 12, line 23
and its interaction with OPTIONS. and its interaction with OPTIONS.
o Eric Rescorla for his work on standardizing the existing https: o Eric Rescorla for his work on standardizing the existing https:
practice to compare with. practice to compare with.
o Marshall Rose, for the xml2rfc document type description and o Marshall Rose, for the xml2rfc document type description and
tools[9]. tools[9].
o Jim Whitehead, for sorting out the current range of available o Jim Whitehead, for sorting out the current range of available
HTTP status codes. HTTP status codes.
o Henrik Frystyk Nielsen, whose work on the Mandatory extension o Henrik Frystyk Nielsen, whose work on the Mandatory extension
mechanism pointed out a hop-by-hop Upgrade still requires mechanism pointed out a hop-by-hop Upgrade still requires
tunneling. tunneling.
o Harald Alvestrand for improvements to the token registration
rules.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/