RE: Implication following from ' proxy' equivalence.

Hello Drummond,

Thanks for the detailed explaination... it certainly helped me.

I think that there is some punning of the term XRI going on in that:

        http://xri.net/=jbradley

may be thought of as either:

        a) An XRI.
        b) An http: URI which is known (by virtue of a syntactic marker xri.net in the authority field) to carry an XRI (=jbradley).

It is not always clear whether the term XRI is *now* being used to refer to the full URI above (and its synonyms) or the short form (=jbradley) or both. I think that there is evidence of all three usages - and some minor misunderstandings or failure to appreciate subtulties (at least on my part) arising from a failure to be clear quite what is (or will be being) spoken of as an XRI.

I think that it would be worth surfacing some brief discussion which name XRI name assignments require registration in centralised and/or distributed/delegated/private registries. In particular I believe that you need to be able to show a minimal presense of commercial barriers to the registration of names - that there are approaches where once 'rooted' in the system, a organisation can mint identifiers for all the entities that it wants to without recourse to a centralised registry. As you show below, given just an ordinary http URI it can be used as an authority for the creation of 'XRI' (being mindful of the pun noted above). I think that is likely important for public acceptance.

Regards

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: 16 October 2008 07:24
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: 'Henry S. Thompson'; 'John Bradley'; www-archive@w3.org;
> 'Peter Davis'
> Subject: RE: Implication following from ' proxy' equivalence.
>
> > -----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 09:50:30 UTC