W3C home > Mailing lists > Public > www-archive@w3.org > March 2011

feedback on ISSUE-27 survey feedback, Re: ISSUE-27: rel-ownership - Straw Poll for Objections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 22 Mar 2011 11:37:01 +0100
Message-ID: <4D887BCD.3010007@gmx.de>
To: Paul Cotton <Paul.Cotton@microsoft.com>
CC: "public-html@w3.org" <public-html@w3.org>, Jonas Sicking <jonas@sicking.cc>, www-archive <www-archive@w3.org>
On 17.03.2011 17:36, Paul Cotton wrote:
>...

In 
<http://www.w3.org/2002/09/wbs/40318/issue-27-objection-poll/results>, 
Jonas writes:

> IANA does not have a good track record of operating registries that affect formats higher up in the protocol stack. For example the HTTP header registry is notoriously out of date and so far IANA seems to have made no effort to fix this. Instead blame is being pushed around and no change occurs. For example, IANA appears to be completely unwilling to go out and look at what is out there and add it to the registry, and instead insist that other people add things to the appropriate registry, leading to absurd situations where headers are known by everyone except the actual registry.

This is a (common) misunderstanding.

The IANA function is *purely* administrative.

What get's into the registry and how it gets there only depends on the 
specification that defines the registry, and the rules it sets up.

It is *not* IANA's role to go out and add entries just because somebody 
uses them. Consider them as a web site, nothing more, if this helps.

Most IANA registries depend on *people* submitting registry entries to a 
review mailing list. That is, either those who mint the new values, or 
others who try to clean up behind them.

Looking at HTTP header fields... the registration process is defined in 
<http://tools.ietf.org/html/rfc3864#section-4>. There's both a permanent 
and a provisional registry, where the latter only requires a citeable 
spec, registration template, and an email to the review mailing list 
(specified in RFC 3864).


> To make this worse, despite claims to the contrary, IANAs registration process is so heavy weight that many people give up. See the experiences documented here for an example:
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0161.html

But make sure you read the subsequent thread, plus consider the current 
registry's contents (hint: all HTML5 link relations without open bugs in 
*this* WG should be in the registry, and have been for quite some time).

> While IANA has claimed that changes can be made to improve the situation, so far it doesn't appear that these changes have been made giving me little reason to believe that they will in the future. And no reason to believe that they'll be made in a satisfactory way.

I think you're mixing up IANA with various people active in the IETF. Do 
not. And also keep in mind that IANA runs many registries, with 
different requirements, and different levels of transparency and 
responsiveness.

If you want to argue against the IANA Link Relations registry, please 
use *that* one as example.

Furthermore, going back to message headers: if you are unhappy about 
unregistered values in wide use then please consider writing up a small 
specification and submit it for provisional registration. I'll be happy 
to help, and suspect the Mozilla Wiki might already contain relevant 
information.

> If IANA want to be responsible for running the rel registry I think they need to prove themselves first. Let them show that they are running a rel registry which is up to date. Either by asking people who register in whatever official registry we come up with to also register with IANA (that should give them incentive to keep the bar for registering low), or by manually adding the entries themselves. Something that they undoubtedly will need to do even if they were the official registry as no matter how low we make the bar, some people won't know or care enough to register.

See above. IANA does none of this. People need to.

Best regards, Julian

PS: chairs, please consider this feedback when deciding on ISSUE-27.
Received on Tuesday, 22 March 2011 10:37:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT