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

From: Julian Reschke <[email-masked]>
Date: Sat, 15 Aug 2009 22:13:23 +0200

Mark Nottingham wrote:
> 
> 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.

OK, so let's leave things as they are for now.

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

RFC 2817 registers "TLS/1.0" (token + product-version), while RFC 2616 
reserves "HTTP" (just token).

So we need to decide how to populate the existing registry 
(<http://www.iana.org/assignments/http-upgrade-tokens/>) which currently 
  is empty -- actually it isn't anymore, it now has a broken entry for 
"WebSocket":

> Value  Description       Reference
> -----  ----------------  ---------
> 1      WebSocket         [draft-hixie-thewebsocketprotocol]

...broken in that the value to be registered isn't "1", right?

Citing the registration procedure:

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

...which licenses the registration of just a token.

So it seems the registry can take both.

My proposal thus is to instruct IANA to change the registry to:

Value      Description                  Reference

HTTP       Hypertext Transfer Protocol  [RFC2616]
TLS/1.0    Transport Layer Security     [RFC2817]
WebSocket  WebScocketProtocol           [draft-hixie-thewebsocketprotocol]

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 16 Aug 2009 04:45:16 +0200

> ...broken in that the value to be registered isn't "1", right?

Right.

> ...which licenses the registration of just a token.

Which is entirely in order here I think. But would probably be enforced
anyway if there was expert review requirements for registering
product/version pairs.

> So it seems the registry can take both.

Good.

> WebSocket  WebScocketProtocol           [draft-hixie-thewebsocketprotocol]

+1, with a little spellcheck 

WebSocket   The Web Socket protocol      [draft-hixie-thewebsocketprotocol]

Regarding TLS that protocol is already at revision 1.2, and by the time
someone actually tries to use HTTP Upgrade for the purpose it's probably
some revisions later... but I doubt the registry will be updated even if
people starts to use TLS/1.2.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Aug 2009 12:51:40 +0200

Julian Reschke wrote:
> ...
> ...

I have applied the proposed patch with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/684>.

It seems we can close issue 172 -- we can still change the registry 
requirements later on if we change our position on that.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Aug 2009 10:11:14 +1000

Closed.

On 16/08/2009, at 8:51 PM, Julian Reschke wrote:

> I have applied the proposed patch with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/684 
> >.
>

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Aug 2009 13:50:58 +0200

Hi,

so the proposal is to fix the Upgrade Token Registry contents 
(<http://www.iana.org/assignments/http-upgrade-tokens/>) to say:

-- snip --

HTTP      Hypertext Transfer Protocol [RFC2616]
TLS/1.0   Transport Layer Security    [RFC2817]
WebSocket The Web Socket Protocol     [draft-hixie-thewebsocketprotocol]
-- snip --

I will forward this proposal to IANA today.

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 20 Aug 2009 16:09:54 -0700

> WebSocket The Web Socket Protocol     [draft-hixie- 

No, that TLS/1.0 is not valid.  The token is TLS.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Aug 2009 08:14:38 +0200

> No, that TLS/1.0 is not valid.  The token is TLS.

Roy,

we just discussed this very issue and came to the conclusion that the 
registry can contain both simple tokens and token + version 
combinations. In particular, the registry procedure in RFC 2817 
(<http://tools.ietf.org/html/rfc2817#section-7.2>) says:

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

...which indicates that the registry can hold both. I imagine the 
purpose is that individual entries for different versions can point to 
different specifications.

As HTTPbis Part 1 now takes over the registry for Upgrade Tokens we can 
of course fix this, in which case we should re-open issue 172 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/172>).

With respect to TLS and the registration, RFC 2817 clearly is confused, 
as it says:

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

...although "TLS/1.0" is a token + version, not a simple token.

If we do agree that this should just have said "TLS", we of course can 
submit an erratum to RFC2817, and adjust the registry contents as well.

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 21 Aug 2009 12:25:47 -0700

On Aug 20, 2009, at 11:14 PM, Julian Reschke wrote:

> we just discussed this very issue and came to the conclusion that  
> the registry can contain both simple tokens and token + version  
> purpose is that individual entries for different versions can point  
> to different specifications.

I thought that it was obvious from the discussion -- "/" is not
part of a token.

> As HTTPbis Part 1 now takes over the registry for Upgrade Tokens we  
> can of course fix this, in which case we should re-open issue 172  
> With respect to TLS and the registration, RFC 2817 clearly is  
> confused, as it says:
>

Ignore 2817 -- it is obviously wrong.  In any case, Upgrade is an HTTP
header field and 2616 defines its syntax -- "/" is not allowed in a  
token.
It is also a complete waste of time to "register" version indicators.
There is no potential for misunderstanding what they mean, nor potential
for conflicting use.

> If we do agree that this should just have said "TLS", we of course  
> can submit an erratum to RFC2817, and adjust the registry contents  
> as well.

I thought the plan was to obsolete 2817.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Aug 2009 12:51:34 +0200

> I thought that it was obvious from the discussion -- "/" is not

Yes, that's clear, and this is where the text in RFC 2817 (and now in 
Part 1) is confusing.

So product is a token, version is a token, but product/version is not.

On the other hand, RFC 2817 is very clear that versions can be 
registered as well, so at least according to *that* registry procedure 
the registry can hold both.

> header field and 2616 defines its syntax -- "/" is not allowed in a token.

Yes, and I didn't suggest that.

> There is no potential for misunderstanding what they mean, nor potential

Then we need to change it. My understanding was that the original 
authors wanted the ability to register different versions so that the 
registry could point to different documents for them.

> I thought the plan was to obsolete 2817.

That part of RFC 2817, yes.

But in the meantime we should tell IANA what to put into the registry, 
because right now it is broken (see 
<http://www.iana.org/assignments/http-upgrade-tokens/>, it contains no 
entries for HTTP and TLS, and a single broken entry for Websocket).

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 22 Aug 2009 12:08:50 -0700

On Aug 22, 2009, at 3:51 AM, Julian Reschke wrote:
> authors wanted the ability to register different versions so that  
> the registry could point to different documents for them.

Most registries allow multiple references after the token.

>>> If we do agree that this should just have said "TLS", we of  
>>> course can submit an erratum to RFC2817, and adjust the registry  
>>> contents as well.
> But in the meantime we should tell IANA what to put into the  
> registry, because right now it is broken (see <http://www.iana.org/ 
> assignments/http-upgrade-tokens/>, it contains no entries for HTTP  
> and TLS, and a single broken entry for Websocket).

Yes, we should tell them to put "TLS", "HTTP", "Websocket", and "waka"
in the registry.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Aug 2009 14:27:29 +0200

Ho Roy,

> Most registries allow multiple references after the token.

Yes, we could do that.

> Yes, we should tell them to put "TLS", "HTTP", "Websocket", and "waka"

I'd really like to fix things carefully. Right now, it appears we have 
three action items:

1) fixing the current contents of 
<http://www.iana.org/assignments/http-upgrade-tokens/>

2) changing/clarifying the registry format in HTTPbis

3) registering Waka

I'd like to treat those as separate, thus

1) fix the registry contents as proposed,

2) open a new issue for tracking the change in HTTPbis, and

3) let you register Waka yourself (I think all it'll take is email to IANA).

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 24 Aug 2009 13:14:35 -0700

On Aug 24, 2009, at 5:27 AM, Julian Reschke wrote:

>>>>> course can submit an erratum to RFC2817, and adjust the  
>>>>> registry contents as well.
>>> registry, because right now it is broken (see <http:// 
>>> www.iana.org/assignments/http-upgrade-tokens/>, it contains no  
> I'd really like to fix things carefully. Right now, it appears we  
> have three action items:
>
> 1) fixing the current contents of <http://www.iana.org/assignments/ 
> http-upgrade-tokens/>
>

Yep, fine, I just don't want to see any precedent for registering
specific versions.  I don't know how 2817 passed review.

> 3) let you register Waka yourself (I think all it'll take is email  

Yes, that was just a joke (for Mark's benefit).

....Roy