- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 05 Jun 2009 21:49:32 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > I think this is editorial -- any objection to that? > ... I have attached a proposed change to the ticket, see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/172/172.diff>. For archival over here, I'm including the changed parts of the section on the upgrade header, and the added subsection of the IANA Considerations Section: 8.8. Upgrade ... This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 3.1 and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined below. 8.8.1. Upgrade Token Registry The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header field. Each registered token should be associated with one or a set of specifications, and with contact information. Registrations should be allowed on a First Come First Served basis as described in Section 4.1 of [RFC5226]. 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. It is not required that specifications for upgrade tokens be made publicly available, but the contact information for the registration should be. 9.1. Upgrade Token Registration The registration procedure for HTTP Upgrade Tokens -- previously defined in Section 7.2 of [RFC2817] -- is now defined by Section 8.8.1 of this document. The HTTP Status Code Registry located at <http://www.iana.org/assignments/http-upgrade-tokens/> should be updated with the registrations below: +-------+---------------------------+-------------------------------+ | Value | Description | Reference | +-------+---------------------------+-------------------------------+ | HTTP | Hypertext Transfer | Section 3.1 of this | | | Protocol | specification | +-------+---------------------------+-------------------------------+ -- snip -- Note I have copied over the text from RFC2817, Section 7.1 almost without changes, and tuned the last paragraph of 8.8 to point to the registration procedure. Open Questions: - are we happy with the details of the registration procedure (if not, we should treat that as separate issue)?, and - is the registry supposed to take just product tokens, or product/version pairs? The text in RFC 2817 is unclear, and the one value it registers contains both. BR, Julian
Received on Friday, 5 June 2009 19:50:17 UTC