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

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 24 Jul 2009 16:43:49 +0200

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.

With the current strategy I suppose I'd rather have HTML5 follow its current strategy over draft-nottingham-http-link-header. We can then always change things in the future if it does not work out, but so far it seems to be doing fine.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Jul 2009 23:53:27 +0200

Anne van Kesteren wrote:
> ...

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.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Jul 2009 21:44:32 +0200

Anne van Kesteren wrote:
> On Fri, 24 Jul 2009 23:53:27 +0200, Julian Reschke <[email-masked]> 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 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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sun, 26 Jul 2009 20:56:19 +0200

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sun, 26 Jul 2009 23:58:34 +0200

> easier to go through that one than to meet the requirements in the link  

Whether your extension gets endorsed or not I do not particularly care about. I just care about it being easy to register it somewhere to start with. So people can find it and see if it makes sense. If it does I'm sure that in the long run it will go from "Proposal" to "Accepted".

And if it's not "Accepted" at least it's still registered making it clear it might be in use somewhere which in turn makes it easier for people to pick a name that does not clash with existing practice. The proposed registry horribly fails at this, much like the IANA registry for URI schemes.