Requirements and assumptions for a managed URI namespace

I have explicated a set of requirements and assumptions that I think
underly a managed URI namespace and appended (with some modifications)
the proposed categories of URI schemes from a previous post.  As I have
indicated in previous posts, recognition of a Vernacular category
depends on how important people think it is that the Registry make note
of unreviewed schemes.

Assumptions and Requirements for :

1. Stability of existing broadly-deployed schemes is important

2. Assuring unique tokens for URI Schemes throughout their development
life cycle is essential 

3. Categorization of URI Schemes will allow different levels of review
and approval, which introduces several desireable characteristics into
the URI namespace environment:
    a. reduces burden on review agencies and personnel
    b. allows learning curve to develop and refine scheme
characteristics while reserving tokens
    c. recognizes 

4. Management of URI namespace should be supported by explicit
requirements and clear processes
    a. Unambiguous documentation of the process supporting URI approval
is essential
    b. A means of guarding against URI-Token land-grab pre-emption is
important
   
5. Arbitrary proliferation of URI schemes that serve branding without
affording additional functionaility is undesirable

Proposed categories of URI Schemes: (slightly modified from a previous
post)

Permanent 

Documented by Standards Track RFC
Full Technical Review
Unique token assured
Revision authority rests with IETF
New candidate schemes must have demonstrated usefulness as a Provisional
scheme prior to technical review

Rationale: Full review and wrangling is costly and should only be
undertaken when there is demonstrated usefulness (history of successful
deployment as a provisional scheme)

Provisional

Documented by an Informational RFC or a standards track RFC
Provisional technical review required (details and scope open to
discussion)
Revision authority rests with author or designated maintenance agency 
Unique token assured 
Tokens may be recycled after a period of dormancy (ala renewal of domain
name?) or at the expiration of the supporting doccumention

Rationale: 
   - Some schemes will be registered as provisional with the idea of
being promoted later on as deployment can be demonstrated and
specifications tightened to reflect experience.  Tokens would not be
recycled
   - Other schemes may never go beyond provisional because, while the
may be important within a restricted domain, they are not of
sufficiently broad use to justify review at the level of a permanent
scheme.  Tokens should not be recycled
   - Still others will be tried, and their proponents will lose interest
or fail to deploy.  Tokens may be recycled after a suitable period of
dormancy

Vernacular (wild-type)  

Rationale: whether there is a category in the registry for these, or
they are simply recognized as 'wild-type' schemes is open to discussion.


Documentation unspecified (none | author-managed | community-managed...)
Technical review may be limited to only suitability of proposed token
Registration record may be created by author or third party
No assurance of unique token, though if they are to have registration
records, perhaps tokens could be reserved for one year to allow  authors
to pull together an informational RFC sufficient to accord them
provisional status
Tokens may be recycled after a period of dormancy

Historic

Deprecated or superceded schemes, as designated by the IETF
recyclability of token an open question [would one ever want to allow,
gopher: to re-emerge?]

[unregistered]

There are always likely to be schemes in development or use that no one
has registered. Such schemes may be registered as Vernacular schemes by
anyone as they emerge.

Received on Friday, 4 February 2005 20:29:50 UTC