W3C home > Mailing lists > Public > www-archive@w3.org > October 2008

RE: Implication following from ' proxy' equivalence.

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>
Message-ID: <2BB00D7977F3423B87395DEB68AB436C@ELROND>

> -----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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:19 GMT