[XRI] ARK comparison

Hi Erik,

I will take a stab at the differences between ARK and XRI,  as I  
understand them.

A simplified description of XRI:
XRI is a OASIS spec consisting of:
1  A IRI compatible syntax for addressing meta data.
2  A resolution protocol for retrieving XRDS representations of meta  
data.

The resolution process involves resolving XRI subsegments via  
retrieving a XRD document for each sub-segment.

The XRI resolver returns a XRDS containing the nested XRDs to the  
requester.

This is a fully extensible XML based protocol.

There are two basic sorts of XRI:
1 Those that start with a GCS (Global Context Symbol) The ones people  
care about are @, and  =
2 Those that start with a cross-reference.   If the cross-reference is  
a http: URI then the first XRD is retrieved via the URL cross  
references are denoted by parenthesis.

The GCS symbols indicate that the first subsegment is in a known  
registry @ is expanded to http://at.xri.net and = to http://equals.xri.net

Cross references and community registries allow for people to run  
there own registries rooted in a URI while still being globally  
resolvable.
(If people want me to dig into that I can do another post)

The GCS symbols themselves are a sub-segment so have an associated  
XRD.  The expansion is performed by the resolver in a manner similar  
to the way DNS resolvers are configured for a root zone.

I will pick a real example so you can try resolving it yourself.

@plaxo*jbradley/+contact

This is a XRI-Normal form XRI.
It has an authority segment @plaxo*jbradley.
It has a path +contact

The Authority segment has three sub segments  @  + plaxo + jbradley

Each subsegment resolves to a XDR document with a canonical address.
In this case @ has the canonical address of @, plaxo has the address ! 
2928.81E8.6160.C47D , and jbradley is !0000.0000.3B9A.CA01

That makes the Canonical ID (CID) for @plaxo*jbradley  == @! 
2928.81E8.6160.C47D!0000.0000.3B9A.CA01

You might ask what the ! is about,  that is the symbol for a  
persistent identifier.  One that by policy is not reassignable.

@!2928.81E8.6160.C47D!0000.0000.3B9A.CA01 can be resolved and will  
return the same meta data when queried with the same input parameters.

What input parameter?  Well the path is one of several Service  
Selection query parameters including mime_type and others.

In this case the path +contact matches a Service endpoint in the XRD.

There are a number of defined service endpoints including openID.

So if I type @plaxo*jbradley into a openID 2.0 site, Say Plaxo as an  
example it will use XRI resolution to find my openID metadata from my  
XRDS.

So what if you want to embed this in a HTML document for some reason,  
how do you do that since it is not a http url?

Well based on advice we received from the W3C a number of years ago we  
defined a HXRI format,  that encodes the XRI in a http: URL and can be  
resolved via a proxy resolver (openXRI its open source java).

So if I wanted to embed the above XRI in say an email I would put  http://xri.net/@plaxo*jbradley/+contact

You have probably clicked on ti and gone to my plaxo contact page.

The proxy server looks at the accept header and sees it is text/html  
so will do a http redirect to the URL in the SEP rather than returning  
not so useful XML  to the browser.

Anything you can do with native resolution you can do through a proxy  
resolver.

Any host running the proxy resolver can resolve any global XRI.

So  http://xri.boeing.com/@plaxo*jbradley and http://xri.net/@plaxo*jbradley 
  both resolve to the same CID @!2928.81E8.6160.C47D! 
0000.0000.3B9A.CA01 and return exactly the same meta data.

This is unlike ARK that probably will return the same metadata as I  
understand it.

This really is only scratching the XRI surface.  I feel like I am not  
doing it justice.

The issue we are trying to resolve is that we intended to register a  
URI scheme xri: so that we could pass XRI's between IRI aware  
applications in there native form.

The W3C is opposed to the registration of any new URI schemes. (my  
interpretation of there position)

So we have been asked to only use the HXRI form on the web and for  
passing between applications.

This presents a problem for XRI aware client applications.  How are  
they to recognize a HXRI from a regular URL?
Under the current scheme any host can be a HXRI proxy.

That is where the ARK discussion came in,  it was pointed out that ARK  
encodes effectively a sub scheme in the beginning of the path.

This gave rise to the idea of changing HXRI so that we would use  
something like:
http://proxy.boeing.com/xri:/@plaxo*jbradley

This would allow any host to be encoded in a HXRI bit still allow a  
XRI aware client to recognize that
http://proxy.boeing.com/xri:/@plaxo*jbradley and http://xri.net/xri:/@plaxo*jbradley 
  are equivalent XRI.

I hope this sheds some light on the discussion.

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley



On 17-Jul-08, at 4:59 PM, Erik Hetzner wrote:

> At Wed, 16 Jul 2008 17:04:18 -0700,
> John Bradley <john.bradley@wingaa.com> wrote:
>>
>> Hi Erik,
>>
>> I think the specific's of ARK are a bit of a diversion from the main
>> topic.
>
> True; apologies if I have take the discussion too far off track.
>
>> If I understood Henrys suggestion correctly he was proposing using a
>> mechanism similar to ARK for indicating to client applications that
>> they are processing an XRI rather than a http: URL.
>
> Having gone back over the discussion, though I still do not understand
> XRIs, I think I can follow a bit better. Reading metaDataInURI-31 did
> clarify one thing for me:
>
> | Assignment authorities may publish specifications detailing the
> | structure and semantics of the URIs they assign. Other users of
> | those URIs may use such specifications to infer information about
> | resources identified by URI assigned by that authority.
>
> In other words, it is quite legitimate that, should a client know that
> ark.example.ORG and ark.example.COM are part of ARK, for that client
> to interpret ARKs published by ark.example.ORG in the way specified in
> the ARK spec; namely, that http://ark.example.ORG/ark:/12345/abcdef
> can be considered equivalent to
> http://ark.example.COM/ark:/12345/abcdef, or, at least, should
> ark.example.ORG go away, ark.example.COM may be used instead.
>
> I would like also to make the further point that ARK-unaware clients
> that encounter http://ark.example.org/ark:/12345/abcdef lose nothing
> by not interpreting that URI as an special ARK; they simply do not
> gain the benefit that ARK provides (resolution of the identifier
> following the dissolution of example.org). I do not know if this is
> the case for XRI.
>
> Furthermore, I think that ARKs do perhaps differ from XRIs in that the
> number of organizations that are ever going to use ARK has a small
> upper-bound; let us say, generously, 10,000. It is a small enough
> number that a list of domains which, when used in URIs may be
> considered to be publishing ARKs is small enough that every
> ARK-enabled client could keep a copy. Again, I do not know if the same
> holds for XRIs.
>
>> […]
>
> best,
> Erik Hetzner
> ;; Erik Hetzner, California Digital Library
> ;; gnupg key id: 1024D/01DB07E3