RE: non-IETF tree URI scheme draft

+4.

The whole alternative tree scenario IMO would only lead to a fractured
federation of URI namespaces with the faceted namespaces being marked out as
having junk status. Perhaps we need to return to the real question of why
anybody would want to deploy identifiers under the URI naming architecture.
What are the reasons/benefits for wanting to join? That seems to me to be
key.

Tony

-----Original Message-----
From: edmckinsey@cox.net [mailto:edmckinsey@cox.net]
Sent: 13 November 2003 18:06
To: uri@w3.org
Subject: Re: non-IETF tree URI scheme draft



A couple of issues and observations:
 
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". 

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. 
 
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.
 
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 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. 
 
 
regards,
Ed
 



----- Original Message ----- 
From: <hardie@qualcomm.com>
To: <uri@w3.org>
Sent: Tuesday, November 11, 2003 6:17 PM
Subject: non-IETF tree URI scheme draft


> 
> Larry Masinter and I had a chance to grab some time in the hallways
> of this IETF meeting, to discuss the future of the draft on non-IETF
> URI schemes.  One of the sticking points all along has been how to avoid
> name collisions in these, and we discussed this around a couple
> of straw proposals that he and I generated out of cookies and hot tea.
> None of them were really satisfying, though, and we eventually
> came to the conclusion that the collision problem in other
> IANA registries were simply a not big enough problem to put
> people through any syntactic hoops for this.  I'd like to suggest,
> therefore that we revise the doc to say essentially:
> 
> Non-IETF tree URI schemes are registered by the IANA
> by providing the IANA a template document that shows
> who has change control, gives a name for that change
> controller, the proposed scheme name, and a precis of
> the URI scheme's syntax. 
> 
>  The IANA would then construct and assign a URI scheme of the form:  
> orgname-schemename.
> 
> The IANA will allow only single orgname per organization, will
> generally choose the one associated with the MIME registry
> if it is available, and may refuse a suggested organization name
> and propose another at its discretion (chiefly to avoid collision,
> but at its discretion).  
> 
> The IANA will use the "expert reviewer" mechanism for assignment,
> and that reviewer will assure that the proposed scheme is
> a syntactically correct URI, but will not review its proposed
> operation or semantics.
> 
> Does this make sense to folks as the right balance of achieving
> uniqueness, ensuring syntactic correctness, and avoiding a
> heavyweight, slow process?
> regards, 
> Ted Hardie
>

Received on Friday, 14 November 2003 15:09:26 UTC