Re: RE: non-IETF tree URI scheme draft

> >  
> > 1) I don't think that the basic division between ietf-tree 
> > and non-ietf tree is correct. IETF is just one standard 
> > organization among many others (e.g. oasis, itu, ieee, w3c, 
> > etc). Why should IANA treat IETF differently from other 
> > standard organizations? If uri-schemes proposed by other 
> > organizations has to use the "orgname-schemename", then 
> > uri-schems from IETF should also use "ietf-scheme". 
> 
> I think you've misunderstood. Any individual or organization
> may propose an IETF tree URI scheme, just as any individual
> or organization may propose an IETF tree MIME type. 
> 
> However, the IETF has a process for review and criteria for
> acceptance of URI schemes that are independent of their source.
> The process is documented in BCP 35 (RFC 2717) and the
> criteria are documented in RFC 2718. The "non-IETF" tree
> is only there for organizations that do not wish to participate
> in the documented process or for those proposals that have
> been judged as not meeting the criteria. This is similar
> to the division between IETF and non-IETF trees for MIME
> types.
>

Here is my observation of the current situation:

If "doi" and "info" are to register under "urn", then they are part of ietf and no questions will be asked. 

If "doi" and "info" insist to register under "uri", then they become non-ietf and has to go under "orgname-".


So it's more like:

"Any individual or organization may propose an ietf tree URI scheme, just as any individual or organization may propose an IETF tree MIME type". But if the scheme is about naming, it has to be under "urn". Otherwise it is "non-ietf" and is subject to special treatment.

It is important to realize that URN is just one of many ways of naming things on the Internet, just like http is just one of many ways to get contents on the web. IETF, particularly IESG, should not be acting as the policeman that enforces every naming scheme to be under URN, just as W3C never said we have to use nothing but http for web applications.

The fact that IESG (or the ones that take part in its decision making) favors one technology over any other ones makes it inappropriate to have IETF to take sole control of the URI root tree. 

 
> > 2) If the "orgname-" in the uri-scheme is primarily used to 
> > avoid namespace collision, then the same principle should 
> > also apply for urn namespace. Thus the "urn:publicid" should 
> > really be "urn:ietf-publicid". I haven't seen anyone bring this up. 
> 
> No, it is for distinguishing IETF vs non-IETF tree.
> 

But don't you need to consider how to control the URN namespace from being polluted? If the purpose of "orgname-..." is to regulate the URI namespace registration, don't they apply to URN namespace as well? If we don't have to worry about URN namespace getting polluted, why should we worry about URI namespace?


> > 3) The current "heavyweight, slow process" of uri 
> > registration is not because of the complexity of the proposed 
> > scheme itself, but due to the debate between URI or URN 
> > namespace. Because of some of our "URI experts" are URN 
> > advocates and they want their product to be successful, it 
> > complicates the whole process. Given that their opinions are 
> > heard, it would be better to have those people stay out of 
> > the decision making so that more objective decision can be made.
> 
> I think this kind of ad hominum argument (questioning the
> motivation of the speaker) is inappropriate. Certainly
> the same arguments could apply to "OpenURL experts" or
> "DOI advocates" who might "want their product to be
> successful". 
>

I think it's perfect fine for URN advocates to recommend their favorite technology. After all, that's what they believe will benefit the community and why they spent time and energy to develop it. 

But the IETF decision process has to be fare and open. It should allow different approaches of doing things, as long as they don't break existing practices. IESG should not be making decisions behind doors where only URN opinions are heard, and they shouldn't label people as non-IETF because they don't choose the URN technology.
 
> > 4) It seems that IETF is acting more and more towards a 
> > governing body on what is the right technology to use and how 
> > people should use it.
> 
> This is, as far as I can tell, the charter of IETF -- to
> make judgements and recommendations about technology.
> 

But what happens when IESG is faced with two or more competing technologies? Does the IESG always have to endorse one technology over any other ones? What if IESG only consists of people that favor one technology but the other? How can we ensure its decisions are unbiased, not to mention their correctness? 

If IETF is truly open, it should allow competing technologies to be proposed within the IETF scope and let the user community decides what is the right one to use. For URI/URN registration, IESG may recommend URN registration, but shouldn't forbid other choices selected by the user community. If "doi" people think URI namespace better fit their needs, then let them develop their application using it. 


> >         This only works if the ones that making 
> > the decision are not biased and can always make the right 
> > decision. I don't think we can trust anyone with such 
> > characteristics. A better approach is to have our experts 
> > advise users of pro's and con's of each of their choices, but 
> > leave the decision making to the users themselves. 
> 
> It is of course the responsibility of participants in the IETF
> to work toward the common good; it is the goal of the
> 'rough consensus' process in IETF to insure that decisions
> are not biased.
> 
> Users themselves are free to do whatever they want. You are
> free to use any URI scheme you would like to use, including doi:
> and info: and edmckinseyisgreat: if you like. The IETF
> police will not come after you.
> 
> The only question we're discussing on this list are what
> the recommendations from the IETF should be. And the IETF
> should make judgements following the IETF established
> processes, which have resulted in the URI process and
> criteria above. In this sequence of messages, we are discussing
> a proposal
> 
> http://www.ietf.org/internet-drafts/draft-king-vndurlscheme-03.txt
> 
> to change that process, and 'allow' some URIs which
> satisfy different criteria. We've recently discussed
> liberalizing the rules in that draft to allow 
> orgname-schemename instead of vnd-orgname-schemename.
> I think you're asking for an even more liberal interpretation
> of 'private' schemes, where they are intermixed, without
> facet or any syntactic distinction.
> 
> It sounds like you would prefer to follow the "expert review"
> with "no rules", i.e., independent of what the experts say,
> you would allow anyone to register any URI scheme, first come
> first served. Is that your position?
> 
> I'm not in favor of first-come-first-served, because it seems
> like it might lead to the same kind of mess we've seen with .COM.
> Unregulated namespaces tend to get polluted easily. Requiring
> "vnd-" or "prs-" or "org-" might at least discourage vanity
> registration and cybersquatting. However, if we allow IANA
> sufficient discression, we might be able to get away with just
> allowing the orgname-schemename version.
> 
> Secondly, it seems that there is some value in distinguishing
> between those URI schemes that have passed review vs. those
> that haven't. Using the URI syntax itself and the notion of
> "facets" seems like it's an effective way of accomplishing that.
> 
> In your "let the users decide" scenario, what would you do
> to avoid frivolous registrations of URI schemes?
> 

I agree with you that having some ad hoc review process will be a good thing. I think people on this board (especially you) have made great contributions. Personally I admire those efforts very much.

As for the criterias of the review process, my opinions are that 1) the review should concentrate more on the purpose of the URI namespace, and its intended service community. If the service behind a newly proposed URI scheme appears to be a bogus or it's only intended for some private community, then it should not be listed on the public listing. 2) The review process should not put too much emphasis on technical details as depicted in RFC2718. RFC2718 should be taken as (good) guidelines on how to make a URI scheme work, but not as the criteria for URI qualification. 3) People reviewing new URI scheme should allow time for the URI scheme to develop, to become mutual and functional. On the other hand, if a URI schemes failed to become functional for certain period of time (five years?), then it should be taken off from the public listing. 


Regards,
Ed

Received on Thursday, 20 November 2003 17:34:05 UTC