- From: Mykyta Yevstifeyev <evnikita2@gmail.com>
- Date: Thu, 10 Feb 2011 17:23:15 +0200
- To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
- CC: Tony Hansen <tony@att.com>, public-iri@w3.org
10.02.2011 9:37, "Martin J. Dürst" wrote: > Hello Mykyta, Tony, > > On 2011/02/10 0:48, Tony Hansen wrote: >> On 2/9/2011 9:23 AM, Mykyta Yevstifeyev wrote: >>> Hello all, >>> >>> Since I have initiated this issue, I'd like to stateit more detailed >>> and propose some ways to resolve it. >>> >>> Firstly, what is the problem? RFC 4395 mentions that there is a >>> separate category 'Provisional' URI schemes. However there are no >>> explicit definition of its purpose. Therefore, the community members >>> have great misunderstandings with this status and this makes some sort >>> of problem. >>> >>> So I'd like to propose the following solution. Firstly, set the clear >>> criteria for Provisional URI schemes - that URI schemes are placed in >>> the Provisional category to indicate the intention to define it more >>> carefully later and perhaps set the time it would be deleted from this >>> category if no acceptable specification appeared (maybe 6 to 9 >>> months). This novelty will allow to revise the Provisional >>> registrations if no specification of it are available. >> >> I can think of a number of reasons that an "acceptable spec" never winds >> up appearing, yet the scheme continues to be used. Such notices should >> not disappear "automagically". >> >> Sometimes provisional is a means to give people notice that a scheme is >> being used "in the wild" -- there *is* no public and/or acceptable >> specification, but there is a sufficient user population that someone >> trying to create an "official" spec using the same name may run into >> difficulties. Such notices should not disappear "automagically". >> >> Sometimes schemes are defined by proprietary entities, and there really >> is a full specification for the scheme, *but* it's not publicly >> available, so it can never be registered in the Permanent registry. But >> it can be put into the Provisional registry. Such notices should not >> disappear "automagically". >> >> I think of the Provisional registry as more of a "caveat emptor" >> registry -- the schema listed there are not well defined and may never >> be well defined, so be wary of the names listed there. > > I propose to make this explicit. One way to do this would be as follows: > > Add a paragraph to Section 4, > http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-00#section-4, > reading as follows: > > >>>> > The main purpose of provisional registration is as an intermediate > step on the way to permanent registration before the scheme > specification is finalized. However, there is no time limit on how > long a scheme can stay provisionally registered, and provisional > registration is also appropriate for schemes that are known to be used > in the wild, but where a definitive specification is not available. > >>>> > > Comments welcome. Here should be the mentioning of the issue with those cases when some scheme is intended to be registered as Permanent, but the provisional before-RFC registration is also deemed suitable (e.g. http://tools.ietf.org/html/draft-ietf-core-coap-04#section-11.4 where the scheme will be registered as permanent but now Provisional registration is requested). I'd also like to bring your attention on the low bar that should be set for Provisional registration. I'd like to propose to remain the Expert Review for Provisional registration while set the IETF Consensus for Permanent ones. This will bring more community review for permanent registrations. What do you think as for this? Mykyta Yevstifeyev > > >>> Moreover, I'd like to ask to make a notice in your document regarding >>> 'afs' URI scheme. I'd like to propose to mention its classification as >>> Historic directly in the document to resolve all the issues concerned >>> to 'reserved' RFC 1738 schemes. >> >> I would leave that to the IRI working group to decide by consensus. > > Please discuss this (issue #55) in a separate thread. > > > Regards, Martin. >
Received on Thursday, 10 February 2011 15:30:40 UTC