[XRI] ARK part 2 (XRDS Simple)

Despite the length of Part 1 there are some things I need to add.

Sorry it was late yesterday when I wrote Part 1 of this.

In XRI 2.0 Resolution, Sec 9.2 (IRI Authority Resolution)

There is a third less often used but perfectly valid form of XRI/HXRI  
that Marty is using in his examples.

A IRI authority is ether a host or a domain name.  Rather than  
retrieving multiple subsegments of XRI authorities,  a IRI Authority  
allows for exactly one subsegment resolution.   This has gone on to be  
further refined in XRDS Simple,  Though for political reasons it isn't  
referred to directly in the XRDS Simple spec.  Some mention of the  
provenance is made of it in Eran's surrounding documentation http://www.hueniverse.com/hueniverse/2008/03/announcing-xrds.html 
.

I will point out that XRDS-Simple is building a limited subset of XRI  
resolution into that spec.
The main difference between the XRDS-Simple version and IRI Authority  
resolution is that XRDS simple leaves out Service Selection,  so would  
not be appropriate for the ARK example.

In the current XRI spec we are using xri:// to distinguish http scheme  
identifiers from xri scheme identifiers.   So lets consider some IRI- 
Normal form XRI identifyers

xri://@boeing      This is a two subsegment identifyer using the root  
registry
xri://(http://boeing.com)   This is a one subsegment cross reference  
indicating that the XRD for the first subsegment can be retrieved from http://boeing.com
xri://boeing.com                This is a one subsegment IRI authority  
indicating that the complete XRDS can be retrieved from boeing.com

Now lets look at how the ARK example below fits this.
I will stick with the current 2.0 spec in my example.

In IRI-Normal form it would be:
xri://boeing.com/($ark*12345%2Fabcdefg)

In HXRI form using the public proxy:
http://xri.net/boeing.com/($ark*12345%2Fabcdefg)

The XRDS will be retrieved from boeing.com and the selection rules for  
the path will be used by the XRI resolver to return XRDS metadata or a  
http redirect to some resource that has something boeing.com believes  
relates to ($ark*12345%2Fabcdefg)

Using XRI especially with cross references allows for the  
encapsulation of arbitrary addressing schemes and resolution protocols  
within XRI.

Another example of ARK encapsulation would be if ARK or someone  
registered the global name @ark you could say:

xri://@ark*($ark*12345%2Fabcdefg) or the equivalent http://xri.net/@ark*($ark*12345%2Fabcdefg)

This treats the ($ark*12345%2Fabcdefg) part as a sub-segmet cross reff.

The community authority server run by @ark could resolve that in in  
any way they see fit as long as they return a valid XRD in response.

ARK has been drawn into this discussion as an example.
In no way do I want suggest that any changes are required for ARK or  
that it should be encapsulated in XRI.

I think ARK is fine, good and suites it design goals.
I use it as a an example of the pattern encoding a sub scheme in the  
path of a URI only.
I apologize to the ARK people for dissecting there work in this forum.

Getting back to the main topic of XRI the scheme,  there are a number  
of perhaps unintended consequences of not using xri://

When a client processing application is presented with boeing.com or http://someproxy.com/boeing.com 
   how is the application going to detect that it is a xri?

In the current spec IRI authorities MUST always be represented with  
the xri: scheme to prevent confusion.   This is one of the places that  
the inability to use a URI scheme will have a significant impact.

I wish for your sakes I was a better author
Unfortunately you are stuck with me until our issues are resolved:)

Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中










On 16-Jul-08, at 11:14 PM, Schleiff, Marty wrote:

> I've been informed that a couple things in my prior message (below)  
> were confusing. I'll try to clear them up.
>
> First, my example had a slight syntax error (the first asterisk  
> should have been a slash).
>
> Second, I reused the authority segment ("ark.example.org") from  
> Erik's example, and some people though the "ark" was significant to  
> the discussion. I'll just use "example.org" in the new example.
>
> Third, I mentioned ARK's acronym "NAAN" without defining it. It  
> stands for Name Assigning Authority Number. It's the part before the  
> slash ("12345" in the example).
>
> Here's the corrected example of an ARK expressed in HXRI:
>
>     http://xri.net/example.org/($ark*12345%2Fabcdefg)
>
> A fourth possible point of confusion is that I took liberty to drop  
> parts of the ARK syntax that I thought could be better served by XRI  
> syntax. In fact the complete ARK syntax (see http://www.cdlib.org/inside/diglib/ark/) 
>  could be retained when expressing an ARK in an HXRI, something like  
> the following (it gets pretty ugly having to percent encode all the  
> slashes):
>
>     http://xri.net/$ark*(http:%2F%2Fexample.org%2Fark:%2F12345%2Fabcdefg)
>
> ARK proponents could pick their preferred format (there are probably  
> other options as well) and specify the definition of "$ark" so that  
> everyone understands the intended meaning and syntax constraints.
>
> I hope ARK proponents will be interested enough to explore use of  
> XRI to represent ARKs.
>
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Information Security - Technical Controls
> (206) 679-5933
>
>
> From: Schleiff, Marty
> Sent: Wednesday, July 16, 2008 6:08 PM
> To: John Bradley; Erik Hetzner
> Cc: Paul Prescod; Henry S. Thompson; Mark Baker; Booth, David (HP  
> Software - Boston); www-tag@w3.org
> Subject: RE: Boeing XRI Use Cases
>
> Hi John & Erik (& All),
>
> I don't like the pattern ARK uses (for reasons already mentioned),  
> and I'm not in favor of using the same pattern for XRI (for the same  
> reasons already mentioned). But I do think it would be interesting  
> to look at expressing ARKs within XRI.
>
> I think the problems Erik mentioned align very well with one of the  
> Boeing XRI Use Cases (see http://wiki.oasis-open.org/xri/BoeingXriUseCases) 
> . Look at the fifth one: "Multiple Identity Providers (for the same  
> entity)".
>
> Henry said the metadata for a particular object is intended to be  
> the same no matter which sponsoring organization is asked. Although  
> the Boeing use case describes different metadata being returned by  
> each identity provider, certain metadata items could be intended to  
> carry the same information about a resource no matter which identity  
> provider is asked.
>
> An ARK expressed in HXRI that is resolvable now might look like this  
> (unfortunately the delimiter between the NAAN and the name is a  
> slash, which would have to be percent encoded as %2F in an XRI cross  
> reference):
>
>      http://xri.net/ark.example.org*($ark*12345%2Fabcdefg)
>
> This example assumes that "$ark" gets defined in the XRI "$"  
> dictionary. This is an unambiguous way for the minter to declare  
> (and for the relying party to know) that "12345/abcdefg" is an ARK.  
> It would look a little cleaner if the delimiter between the NAAN and  
> the name were some other character that wouldn't require percent  
> encoding. The power of using XRI for this is that it can work for  
> nearly(?) any type of identifier.
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Information Security - Technical Controls
> (206) 679-5933
>
>