Re: [apps-discuss] Provisional URI registrations

[Graham Klyne <[e-mail]>]

John C Klensin wrote:
> 
> --On Monday, November 22, 2010 09:48 +0900 "\"Martin J.
> Dürst\"" <[e-mail]> wrote:
> 
>> On 2010/11/22 7:25, Graham Klyne wrote:
>>
>>> We have "permanent", "provisional" and "historical"
>>> registration classes for URI schemes. For practical purposes,
>>> I think the "provisional" registry serves the same role as
>>> the "reserved" one you suggest [1]. I think the additional
>>> bureaucracy incurred to create a new registry class is not
>>> justified by practical benefit.
>> +1.
> 
> I would agree, except that:
> 
> (1) We now have proposals to remove things from Provisional that
> have well-defined protocol specs and evidence of use because
> they have been Provisional too long.  Fighting battles of that
> sort is lots more painful than setting up a new registry
> category, especially since...

Having made a very quick review of that discussion (w.r.t. tn3270), I feel there 
is a consensus that the appropriate response to to say "that's fine, it has a 
definition, let's leave it there".  There is no explicit provision for time-out 
of provisional registrations - the general idea (at least in the formulation of 
the header registry, from which I believe this registry was derived) was to 
provide a place where schemes could be documented for the community without 
having to meet the properly high standards of IETF consensus.

One option in this case would be to move the tn3270 scheme to historic - I'm not 
sure if that's been suggested.  That's something I would support in this case.

You say "Fighting battles of that sort is lots more painful...".  My sense is 
that the more choices there are, the more painful the battles may be.  My 
reference to "bureaucracy" was intended to allude as much to the choices to be 
made on an ongoing basis as to the setting up of a new registry.  As scheme 
reviewer, I would find it harder to make a reasonable decisions if "reserved" 
were also an option, since that would require more detailed knowledge of the 
protocol's history than I can generally bring to bear.

> (2) Not having a Reserved category from the beginning appears to
> be an error on IANA's part, not something the IETF specified in
> any way.   If that is correct, it should be possible to deal
> with it as correcting an error, which is (or should be) an
> extremely lightweight procedure.

Well, as Martin says, if it's an error it's not one on IANA's part.  In this 
case, they follow what we (the IETF) asked of them.  So I suppose we should be 
careful what we ask for :)

#g