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

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Jun 2009 14:45:20 +0200

Hi,

while looking at IANA issues I noticed the issue below:

Currently the registry prodecure for HTTP Upgrade Tokens is defined in 
RFC 2817 ("Upgrading to TLS Within HTTP/1.1"), Section 7.2 
(<http://tools.ietf.org/html/rfc2817#section-7.2>). This probably should 
be taken over by Part 1, just as we did with the HTTP status code registry.

I have opened <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/172> to 
track this.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Jun 2009 10:28:10 +1000

I think this is editorial -- any objection to that?

On 04/06/2009, at 10:45 PM, Julian Reschke wrote:

> Currently the registry prodecure for HTTP Upgrade Tokens is defined  
> in RFC 2817 ("Upgrading to TLS Within HTTP/1.1"), Section 7.2 (<http://tools.ietf.org/html/rfc2817#section-7.2 
> >). This probably should be taken over by Part 1, just as we did  
> with the HTTP status code registry.
>
> I have opened <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/ 
> 172> to track this.
>
> BR, Julian
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Jun 2009 16:35:49 +0200

Looking a bit closer at RFC 2817 and the IANA registry resulted in the 
mail below being sent to IANA :-)

-- snip --

<http://www.iana.org/assignments/http-upgrade-tokens/>, as of today 
(June 05 2009) says:

 > Registry:
 > Value  Description       Reference
 > -----  ----------------  ---------
 > There are no registrations at this time

As a matter of fact, RFC 2817, the document that created that registry, 
registered the value below:

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

(<http://tools.ietf.org/html/rfc2817#section-7.2>)

Furthermore, RFC 2616 has:

 >    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. Any token can be used as a protocol name; however, it
 >    will only be useful if both the client and server associate the name
 >    with the same protocol.

(<http://tools.ietf.org/html/rfc2616#section-14.42>), so essentially it 
reserves all tokens starting with "HTTP" for use by HTTP specifications.

-- snip --

NR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Jun 2009 21:49:32 +0200

Mark Nottingham wrote:
> ...

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 08:36:50 +1000

On 06/06/2009, at 5:49 AM, Julian Reschke wrote:
> Open Questions:
>
> - are we happy with the details of the registration procedure (if  
> not, we should treat that as separate issue)?, and

My first impulse upon reading this was to suggest it be changed to a  
designated expert procedure (which IMO is good policy, as it allows a  
sanity check on registrations without raising the bar too high).  
However, AFAICT there aren't as many risks in registering a new  
upgrade token as there would be for a new header (for example), and  
the considerable effort required to deploy a new upgrade token  
successfully suggests that the registry won't be inundated.

So, I'm not fussed either way.

> - 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.

My reading of the text is that the term "token" was an unfortunate  
choice, and the intent was to register both.