RE: [XRI] ARK comparison

Hello John,
 
I think that the nub of the question that you and other comes down to:
 
"How can I look at some arbitary URI/IRI and know just by looking at it,
that it is an XRI (or an ARK or whatever...)" ie. you are looking for a
syntact marker or a pattern match that will assure you that the a given
identifier string is intentionally of a particular category rather that just
one that looks like it is. A world of certainty rather than possibility
(from inspection of the identifier alone).
 
1) A URI scheme definition can give that certainty.
2) In some limited way, on the basis of policy published by a domain
authority - eg for xri.net, matching something like ^http://xri.net/[=@$(]
could give certainty.
3) For an existing scheme, matching lower down (further left) in the
authority field or somewhere down the path lead only to possibility, not
certainty.
 
So... can we find a way of living with possibility rather than certainty? 
 
eg. if an identifier looked and smelled like an XRI would an attempt to use
it as an XRI yield a determination one way or the other (at least at the
time of asking) - ie making an http request with an accept:
application/xrds+xml  would yield either  an XRDS (or maybe XRD - haven't
really grokked the difference yet) representation, a 404, a redirection or
something else. Only in the first case (I think) has it been demonstrated
that the URI can be used as an XRI.
 
Regards
 
Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12
1HN
Registered No: 690597 England



  _____  

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
John Bradley
Sent: 18 July 2008 03:03
To: Erik Hetzner
Cc: www-tag@w3.org
Subject: [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