Re: draft-nottingham-site-meta: registration too slow, opaque

[Mark Nottingham <mnot at mnot.net>]

I think the key question here is whether the contents of a registered  
well-known URL need to have an interoperable specification available.

If so, the current registration policy (Specification Required, which  
implies Designated Expert) is appropriate.

If we're willing to allow anything to be registered (e.g., FooCorp  
wants to place a completely opaque file on Web servers, and reserve  
URI space for it; likewise for a developer who wants to try something  
out, only to decide next week that it's not a good idea, or that they  
got it slightly wrong), First Come First Served may be more appropriate.

Getting an entry in this registry effectively dictates the format of a  
URL on every Web server on the planet. Do we really want to  
accommodate developers with such short attention spans?

Regardless of that, I agree that the registration process explanation  
in the draft needs to be tightened up, and that more visible feedback  
would be helpful. I think this could be addressed by creating a  
dedicated mailing list for review (assuming we keep the current  
policy) and having the initial submission and discussion take place on  
it; it would be the job of the expert reviewer to forward approved  
registrations to IANA for publication.

Cheers,


On 23/10/2009, at 3:38 AM, Dan Connolly wrote:

> Sorry I didn't review and comment when the draft first
> became available...
>
> Regarding:
>
> "Before a period of 30 days has passed, the Designated
>   Expert will either approve or deny the registration request,
>   communicating this decision both to the review list and to IANA."
> -- http://www.ietf.org/id/draft-nottingham-site-meta-03.txt
>
> My experience is that this sort of latency results in developers
> working around the IANA and IETF. Please set up a form so
> that with latency of a few seconds, somebody can have their
> token provisionally registered. (Perhaps an email callback
> will have to precede the form.)
>
> By way of example, consider the W3C XPointer Scheme Name Registry form
>   http://www.w3.org/2005/04/xpointer-schemes/0register
> (though it's perhaps not completely shiny either...
> I see one example of "Status: Being reviewed
> Last updated on 2006-10-11" on
> http://www.w3.org/2005/04/xpointer-schemes/ )
>
> I have tried to keep W3C out of the registry business all together,
> but IANA is widely reputed to be slow and opaque, and my own
> personal experience bears that out to some extent, so I can't
> completely stop people who are willing to set up registries in W3C
> (not to mention elsewhere...). If IANA has in fact gotten a lot better
> lately, perhaps we just need to address the perception part.
>
> As it is, section 5 doesn't even give an exact email
> address of where to send registration requests. That sends
> people on a scavenger hunt right from step 1.
>
> Perhaps a/the "datatracker" addresses my concern about latency
> and transparency... if mail to iana at iana.org results in an
> automated "ticket" response, with a pointer to a status page that  
> always
> has a clear bound on the latency for the next step, that
> would suffice (if it's actually documented in section 5).
>
> Hmm... it's entitled "IETF I-D Tracker", which suggests
> its scope doesn't include IANA registration requests.
> https://datatracker.ietf.org/idtracker/
>
>
>
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E


--
Mark Nottingham     http://www.mnot.net/