W3C home > Mailing lists > Public > www-tag@w3.org > August 2006

RE: URNs, Namespaces and Registries

From: Schleiff, Marty <marty.schleiff@boeing.com>
Date: Tue, 8 Aug 2006 14:41:11 -0700
Message-ID: <2C1C6A07EEDCB14ABBACAC793BF8BE9E02E9694E@XCH-NW-6V2.nw.nos.boeing.com>
To: <www-tag@w3.org>

Comments on section 2.2 (Standardized) of URNs, Namespaces and Registries [1].

I'm not sure I understand what you mean by "... guaranteeing certain invariants, for example with respect to the structure of identifiers and the availability of the resources they identify." I think it means that the various myRI approaches wish to have consistent rules for parsing/interpretting identifiers, and the rest of this message is based on that assumption. If that's not what's meant, then maybe the rest of this message is of questionable worth. In either case, it would be good for the document [1] to provide a little more clarification.

One reason I'm not confident about my "parsing" assumption above, is because I don't see how it leads to a conclusion that "This means they should not be creatable in a distributed or unsupervised fashion".

Your employer may "... constrain the mechanisms by which web pages are accepted for serving from certain parts of their domain so as to enforce invariants both of path structure and content markup"; however, my employer uses different mechanisms to enforce path structure and content markup. A minter of URIs can certaiinly enforce namespace-pertinent conventions on the URIs it mints; however, such namespace-pertinent conventions don't seem very "invariant", because they are likely to vary from minter to minter.

I agree that "Domain names are as good, or as bad, at conveying _ownership_ of a particular form of URI as URN namespaces or URI schemes"; however, What about aspects other than "ownership" of a particular form? 
Authority Aspects:
I think that instead of "xri://example.com/stuff", you are suggesting that something like "http://xri.net/example.com/stuff" would be better. Or maybe you're suggesting something like "http://example.com.xri.net/stuff" would be better. In either case, the higher levels of the DNS name (xri.net) would be an indicator to applications that the rest of the URI should be interpretted using XRI rules. Again, I'm not sure I'm correct about what you might be suggesting, so the next few paragraphs are based on my guess. If you could provide clarifying examples, it would be appreciated.
I think an approach like "http://example.com.xri.net/stuff" would require "example.com.xri.net" to be registered in DNS in addition to the "example.com" that the company has already registered. Plus it looks kind of awkward to me.
With the other approach ("http://xri.net/example.com/stuff"), the "example.com" would no longer be the authority segment of the URI; it makes "xri.net" the authority for the resulting URI, which I'm pretty sure it does not want to be. In addition to issuing, naming, and resolution responsibilities, I think an authority also has a responsibility in the area of integrity -- the authority needs to maintain its reputation for integrity of the stuff at lower levels. I don't think "xri.net" as an authority can/should vouch for the integrity of the rest of the XRI -- if an organization like example.com started issuing bad XRIs (e.g., re-issuing persistent identifiers to different subjects), then it's probably the authority's reputation that would suffer. 
Syntax Aspects:
Without an xri: scheme, how would we reserve characters for special XRI use ("(" ")" "@" "!" "=" "$" "*" etc.)? Although domain names can convey the ownership of the form of URI, it doesn't convey the actual form and rules/constraints of the form.
Operations Aspects:
XRIs don't have all the same allowed operations as http. The single allowed operation on an XRI is something "XRI RESOLVE" (which happens to be based on a recursive series of HTTP GETs - but it's not just a simple/single HTTP GET). 

[1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml 

Received on Tuesday, 8 August 2006 21:41:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:13 UTC