RE: Proposed Status Categories for URI Scheme registry

Thanks to Etan Wexler, Charles Lindsey, and Larry Masinter for their
thoughtful comments on my proposal regarding status categories for URI
Schemes.

I have no profound commitment to many of the details I elaborated under
each category;  They were included to give distinguishing
characteristics of the levels, and I'm happy to acknowledge they may not
be exactly what is necessary.

The essence of the proposal is to accurately reflect the reality of the
URI Scheme landscape as Larry and some others have insisted in order for
the registry to serve its purpose, while meeting the requirement of
protecting the process from inadvertant or malicious duplication of
tokens.

If I may categorize the categories them from a slightly different point
of view:

W-Permanent 

The set of URI schemes that can be expected to be widely supported by
general-purpose Web applications. Strongest level of technical review
required. The incentive for making the substantial effort of a standards
track RFC is to increase the probability of deployment in a broad array
of global applications.  Application developers may not support all such
schemes in a given application, but can be confident that the ones they
support have been subject to the highest standard of technical review
and change control.  Uniqueness of token is agreed by all to be
essential.

W-Provisional

Schemes registered as provisional may or may not ever reach the
Permanent category, and hence may not become commonly deployed in
general purpose Web software.   Nonetheless, they may be very important
schemes in certain contexts or in certain communities.  Assuring unique
tokens for such schemes is desirable to promote good network practice
and is essential to protect the business practices which motivate scheme
innovation from inadvertant or malicious damage.

The idea of promotion from W-provisional to W-Permanent is not essential
to my arguments, but rather affords a mechanism to increase efficiency
of review and discourage large numbers of applications to permanent
status.

My own view is that technical review of W-provisional schemes can be
simpler, more straightforward, lower cost, but this is not essential to
the idea either. 

Vernacular 

The motivation for this status category is largely to make it possible
for the registry to reflect the existence of wild-type URI schemes that
have evolved outside of the normal review channels or which evolved in
parallel without benefit of a registry to guide decisions on the
selection of a suitable token.

Thus, there are two candidates for Vernacular registration:

1. A team has developed a URI scheme for local purposes, and as an
afterthought recognizes that it may have broader community importance as
an addressing namespace, and raises its visibility by registering it by
completing an IANA template.  It may be sensible to allow a third party
to register it as well?  The purpose of registration is to raise
visibility and make it easier for people to do the right thing (choose a
unique token).

2. A small number of existing schemes share their token with unrelated
protocols because they developed in parallel without knowledge of one
another.  It seems to be true that such protocols can never become
permanent unless one of the twins is withdrawn (historicalized?) or
accepts the pain of a change in token.

Etan's objection to my ambiguously-articulated documentation requirement
for vernacular schemes is well taken and exposes my own uncertainty
about what the requirement should be.

Charles Lindsay correctly exposes the problem that the
uniqueness-of-token problem still lurks, but has been pushed down a
level.  This may or may not be a problem.  It is my unsubstantiated
belief that any serious information architect in today's world will
consult a registry early in their design process if it is easy enough to
do so... that is, there is a well known registry with easily understood
registration requirements.

It is true that two Vernacular schemes might have the same token, and
therefore promotion to the next level (W-provisional) would require a
new (unique) token.  I don't know how to prevent this short of requiring
uniqueness from the start.  But how important will a scheme ever be
PRIOR to its registration of a w-provisional status?  *IF* there is a
registration process in place, then broad deployment of such a scheme
probably says more about the competence of the developers than the
sufficiency of the process.

Thus, we would hope that as time goes on, there will be few additions to
the Vernacular category -- every designer will see that their fame as a
promulgator of protocols, and the business processes that motivate them,
are well served by registering their protocol token early.  This is an
important part of the Hansen draft objective, is it not?

stu
 








Historical - 

> _____________________________________________ 
> From: 	Weibel,Stu  
> Sent:	Friday, January 21, 2005 9:33 AM
> To:	uri@w3.org
> Subject:	Proposed Status Categories for URI Scheme registry
> 
> I am convinced by the argument of Larry and others that it is
> important that a URI registry reflect the real & messy world as far as
> possible.  I remain convinced as well that there must be provisions
> for orderly promotion of demonstrably-useful schemes, and that the
> business cases for such schemes, as well as good network practices,
> require assured unique tokens.
> 
> I believe that both of these requirements can be met by adding an
> additional status category to the three described in 2717/18-bis.  A
> high level summary of these categories follows:
> 
> Proposed status categories for a URI Scheme registry
> 
> 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
> 
> Provisional
> 
>    Documented by at least an Informational RFC
>    Provisional technical review required (details and scope open to
> discussion)
>    Revision authority rests with author or designated organization 
>    Registration records openly annotatable (wiki-like public comment)
>    Unique token assured
>    Tokens may be recycled after a period of dormancy
>    
> Vernacular (wild-type)
> 
>   Documentation unspecified (none | author-managed |
> community-managed...)
>   Registration record may be created by author or third party
>   Registration records openly annotatable (wiki-like public comment)
>   No assurance of unique token
>   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 Monday, 24 January 2005 16:05:37 UTC