Re: Fixing the IANA HTTP upgrade token registry, Re: #172 (take over HTTP Upgrade Token Registry) – httpbis

Roy T. Fielding wrote:
>> 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.
> 
> I thought that it was obvious from the discussion -- "/" is not
> part of a token.

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.

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

Yes, and I didn't suggest that.

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

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.

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

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

Received on Saturday, 22 August 2009 10:52:22 UTC