Re: #172 (take over HTTP Upgrade Token Registry) – httpbis

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