Re: [draft-nottingham-http-link-header-06] extension tokens

Anne van Kesteren wrote:
> On Fri, 24 Jul 2009 23:53:27 +0200, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Anne van Kesteren wrote:
>>> Since this is Last Call I thought I should mention that I much prefer  
>>> the WHATWG wiki approach to extensions over requiring people to use an  
>>> overly long URI. It both provides people with a short token and  
>>> provides other people with a clue as to what is happening in the world.
>>> ...
>> The draft does not require people to use URIs at all. There's a registry  
>> for tokens, just like in the HTML5 proposal. The only difference is that  
>> the registry lives somewhere else, and the registry procedure has  
>> different requirements.
> 
> The requirements will just lead to people using URIs I think (or rather, completely ignoring the registry as there was no registry practice so far) just like people use x-something all the time rather than vnd.something or register something more appropriate.
> 
> Barriers to registries need to be pretty low I think. E.g. due to high registry requirements for media types font files will be sniffed until eternity. JavaScript/ECMAScript has about six media types and were only registered due to a dedicated individual, not because the ECMAScript standardization comittee particuarly cared one way or another.
> 
> Same for URI schemes. You're better of on Wikipedia than at IANA. :/

The WHATWG WIKI currently states:

"For the "Status" section to be changed to "Accepted", the proposed 
keyword must either have been through the Microformats process, and been 
approved by the Microformats community; or must be defined by a W3C 
specification in the Candidate Recommendation or Recommendation state. 
If it fails to go through this process, it is "Rejected"."

A W3C Recommendation would be sufficient for the IANA registry proposed 
by the link header draft ("specification required").

Which leaves the "Microformats process", and I'm not convinced that it's 
easier to go through that one than to meet the requirements in the link 
header spec.

BR, Julian

Received on Sunday, 26 July 2009 19:45:18 UTC