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

Julian, are you commenting in an official IANA capacity here? If so,
I'd like to cite this email as evidence that IANA has no intention of
changing.

/ Jonas

On Tue, Mar 22, 2011 at 3:37 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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 18:32:44 UTC