Re: [apps-discuss] Provisional URI registrations

[Graham Klyne <[e-mail]>]

Alfred ? wrote:
> John said:
> 
>>>   (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.
> 
> and you responded:
> 
>> 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 :)
> 
> I disagree on the first two statements.
> 
> Actually, before the change of the URI Scheme registry triggered
> by RFC 4395, 'afs', 'mailserver', and 'tn3270' had been listed
> as "reserved".  I could not find instructions in RFC 4395 telling
> IANA to convert these entries to "provisional" URI schemes,
> and I observe that neither of these previously "reserved" keywords
> would have qualified under the criteria for such registration in
> RFC 4395.
> So, since there apparently haven't been conversion rules; arguably,
> something went wrong; achieving at consensus *now* that it likely
> was a clerical error would allow us to perform a very lightweight
> procedure to restore the 'status quo ante' (with three reserved
> keywords), before Alexey's draft is published, or during that
> process (but logically before 'mailserver' is made Historic).

Ah, I wasn't of the prior "reserved" status (sorry if I skimmed over the prior 
discussion too quickly).  I think these 3 are an exceptional case.

In the circumstances described, as reviewer, my inclination would probably have 
been to recommend provisional registration (I don't recall being asked about 
these - I suspect they were grandfathered in when the registry was initially 
created, by some ad-hoc means; after all, provisional is very similar in its 
effect to reserved).  If the general consensus is that the provisional status is 
unlikely to be further developed, then moving to historic seems a reasonable 
course, allowing that in this case the precise requirements may not be perfectly 
satisfied.

#g
--