RE: Proposed Status Categories for URI Scheme registry

My proposal for three active categories of URI Schemes is based on (1)
the insistence by others that duplicate names have a home in the
registry, and (2) what I believe to be an uncontestable Good Thing -
that no future duplicate scheme names be permitted.

Previous arguments on this list assert the need to reflect the reality
of past *and* future wild-type URI schemes (roughly: people will do what
they want to do, and we have no means to prevent them from doing so, and
the registry is more useful if it acknowledges the existence of such).

To permit the possibility of duplication of future URI scheme tokens
based on a small number of existing inadvertant duplications is ill
advised in the extreme.  It needlessly exposes future innovations to the
vulnerability of inadvertant or malicious duplication.

The proposal aside, can we be clear about these two requirements?  My
proposal meets them both.
Charles's suggestion below meets them also, in a simpler way (always a
feature), with the one caveat that there will be no accomodation for
duplicate wild-type registrations in the future (except perhaps as x-

To summarize:

Keep the high entry bar for the Permanent category

Allow a lower entry bar for the Provisional category, and either
   a.) require unique tokens for ALL new entries, or 
   b.) provide for a third category without protection from 
       duplication (vernacular... x-... whatever).


Charles Lindsey wrote, in part:

Surely the essence of the proposal should be to prevent duplication of
scheme-names in the future, even though we know that a few of them have
slipped through in the past (it would be helpful for someone to provide
examples of these).

So if there was a requirement for uniqueness in the Registry, then there
could be exceptional provision for the existing duplicates of the form
"This scheme-name is currently used for schemes A and B (provide
pointers to details of both). It will not be possible for this
scheme-name to proceed to permanent registration until this anomaly has
been resolved".

And you would not allow registration of new duplicates in the future.


Received on Tuesday, 25 January 2005 13:55:45 UTC