- From: Drummond Reed <drummond.reed@cordance.net>
- Date: Wed, 15 Oct 2008 23:23:45 -0700
- To: "'Williams, Stuart (HP Labs, Bristol)'" <skw@hp.com>
- Cc: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'John Bradley'" <john.bradley@wingaa.com>, <www-archive@w3.org>, "'Peter Davis'" <peter.davis@neustar.biz>
> -----Original Message----- > From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com] > Sent: Wednesday, October 15, 2008 2:40 AM > To: Drummond Reed > Cc: Henry S. Thompson; John Bradley; www-archive@w3.org > Subject: XRI: Implication following from ' proxy' equivalence. > > Hello Drummond, > > [archiving in www-archive@w3.org (a public archive) for ease of future > reference] > > Following our recent meeting I have just realised something about the > direction we were coming round to that may need some thought. > > I believed that a strong principle for Tim and the TAG remains > decentralisation and that the fewer points of centralisation the better. > In that regard, DNS a centralised naming system that is pivotal to the > internet and hence the web. Once folks have their own domain name they can > (roughly speaking) mint sub-domain names to their hearts content. > > By and large anyone that has a DNS domain name can mint and deploy http: > scheme URIs without reference to another party. > > From a TAG pov, I believe that that would be seen as a desirable > characteristic of XRIs... that there are no (signifcant) commercial > barriers to anyone being able to mint an XRI of their own - eg. so (to > pick an example) Boeing could decide that XRI were for then create them to > their hearts content. > > So... during our meeting you explained that the following are intented to > be synonym: > > http://xrt.net/=jbradley > http://boeing.com.xri.net/=jbradley > > > Infact: > > http://{anySubdomain}.xri.net/<specificXRIShortName> are all > synonyms for http://xri.net/<specificXRIShortName> Correct. > What did not occur to me at the time of our discussion was that this > induces a need for a centralised registry of <specificXRIShortNames> > > eg. so it is not the case that http://boeing.com.xri.net/=jsmith could be > some person at Boeing where Boeing handled the registration of that name > and that the person referenced might be different from the person > referenced by http://xri.net/=jsmith. Correct - both of these http: URIs carry the same XRI and thus represent the same abstract resource. > At the time of our meeting, I missed the significance of this distinction. > The .xri.net subdomains (or .xri or whatever) give the syntactic marker > that indicates an identifier as an XRI, however, I think that it had been > my perception then that some organisation, say boeing, would then be able > to administer XRI issued under their own subdomain (say > http://boeing.com.xri.net). > > However, I now think that that is not what is intended. What is intended > that, say, John Smith at boeing might be assigned a short XRI identifier > of @boeing*People*JohnSmith (forgive any clumsyness with the syntax - but > I think the intent is clear) You have the syntax completely correct (except that, being the authority component of the XRI, all characters should follow the URI recommendation of being normalized to lowercase). > such that all > http://{anySubdomain}.xri.net/@boeing*People*JohnSmith are synonyms for > http://xri.net/@boeing*People*JohnSmith. Maybe that's ok. The indirecetion > throug @boeing may be perceived as giving boeing (or anyone else) > sufficient freedom to create names within their own authority, but I think > it is a point worth bringing out in the discussion when it surfaces. > > The question really is about the implications that follow from all XRI > proxies (if that how we think of the http: URI authority part) being > equivalent. > > I hope I've made some sense above. Yes, it makes complete sense, and your point is very valid, which is why during John's and my visit with you I took the time to explain how important I believe the issue of XRI registry governance is. More on that below. First, a few clarifying points: 1) You are completely correct that all XRI proxy resolution services SHOULD produce the same resolution result given the same XRI. From section 11.8 of XRI Resolution 2.0 (http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html): ******************************* 11.8 Differences Between Proxy Resolution Servers An XRI proxy resolution request MAY be sent to any proxy resolver that will accept it. All XRI proxy resolvers SHOULD deliver uniform responses given the same QXRI and other input parameters. However, because proxy resolvers may potentially need to make decisions about network errors, Redirect and Ref processing, and trust policies on behalf of the client they are proxying, and these decisions may be based on local policy, in some cases different proxy resolvers may return different results. ******************************* 2) XRI authority segments form a hierarchical delegation tree exactly like DNS domain names except from left-to-right instead of right-to-left. In other words, the XRI @boeing*People*JohnSmith and the DNS name johnsmith.people.boeing.com are very similar. So this aspect of XRI architecture is very much like DNS architecture, and has the same centralized registry issues (with one difference - DNS has just one root - the abstract "." concluding any FQDN, whereas XRI has four abstract roots - the global context symbols =, @, +, and $). 3) A little-understood but critically important facet of XRI architecture is the cross-reference capability that, to our knowledge, does not have any precedent at the DNS layer. Using cross-references, any authority for an existing URI can turn it into an XRI root authority. In XRI 2.0 syntax, this is done just by enclosing the cross-reference in parentheses. For example, Boeing could define their own XRI root as follows (in XRI-normal form): (http://boeing.com)*people*johnsmith This same pure XRI bound to a Boeing XRI proxy server (again, using XRI 2.0 syntax) would look like: http://boeing.com.xri.net/(http://boeing.com)*people*johnsmith To be clear, this is Boeing's own private XRI root, so there is no expectation that (http://boeing.com)*people*johnsmith represents the same resource as @boeing*people*johnsmith (any more than the expectation that boeing.com and boeing.net represent the same resource). However, for the reasons explained above, the following two http: bound XRIs DO represent the same abstract resource: http://boeing.com.xri.net/(http://boeing.com)*people*johnsmith http://cordance.net.xri.net/(http://boeing.com)*people*johnsmith The reason I emphasize this cross-reference capability is that it means that unlike DNS, XRI registries are not limited to the four abstract roots. There can be an infinite number of private roots (several have already been implemented). Currently in XRI 2.0 architecture, the XRI resolver clients in an XRI community using a private root must be preconfigured to recognize that private root (that is, they must be given the http: and/or https: URI(s) of the starting XRI authority server for resolution). However in the next revision there is growing consensus that we should support dynamic resolution for root cross-references to http: and https: URIs by simply specifying that the URI inside the cross-reference represents the starting location for the XRI resolution chain. This would mean that every http: and https: server in existence could immediately begin serving as an XRI authority server, and that everyone with a domain name today can immediately turn it into an XRI authority root and begin minting their own XRIs without reference to any other authority or registry. This capability would allow a decentralized world of p2p, self-managed XRIs to live alongside and fully interoperate with the world of XRIs rooted on GCS registries - a different picture than DNS where interoperability is only achieved through centralized registries. Of course that has implications when it comes to trust between XRI authorities, persistent XRIs, and many other issues, but it does free up reliance on centralized registries. As a final note, the private root capability of XRI does not IMHO lessen the importance of open community governance of centralized XRI registry services. This is the work that the current XDI.org trustees (http://www.xdi.org/trustees.html) have been engaged in since 2003 (and their predecessors since 2000). Although there is a "church-and-state" separation between the work of the OASIS XRI TC on the technical protocols and XDI.org on the operational infrastructure (similar to that between IETF and ICANN), many people do not understand this relationship or the importance of XDI.org's role. Also, as you know, several of us on the XRI TC are employees of direct or indirect contractors to XDI.org (myself at Cordance and also employees at NeuStar), so we serve as liaisons between both organizations. As it happens the XDI.org trustees met today and one of their main topics was harmonization of XDI.org governance with that of ICANN and other community-based Internet governance authorities. I attended the meeting and briefed them on the progress of the W3C TAG discussions and know that they would welcome input from TAG members on the subject individually or collectively. I hope this has been useful. On our main front, the XDI TC has developed a summary of the "XRI-as-relative-URI" proposal that we are reviewing on our telecon tomorrow; we should be ready to start posting to the www-TAG list about it by Friday. Best, =Drummond
Received on Thursday, 16 October 2008 06:33:13 UTC