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  <> 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):*($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.; CISSP 
Associate Technical Fellow - Cyber Identity Specialist 
Information Security - Technical Controls 
(206) 679-5933 



From: John Bradley [] 
Sent: Wednesday, July 16, 2008 5:04 PM
To: Erik Hetzner
Cc: Paul Prescod; Henry S. Thompson; Mark Baker; Booth, David (HP Software -
Subject: Re: Boeing XRI Use Cases

Hi Erik, 

I think the specific's of ARK  are a bit of a diversion from the main topic.

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.

I don't think the proposal went as far as using ARK itself though I could be
wrong about that.

There seems to be a diversity of opinions regarding the idea of encoding a
special identifier at the start of the http: path segment to indicate that a
http: URL is something other than a "plain" http: URL.

In the ARK case we seem to be encoding a sub scheme in the URL path.

So to use the ARK pattern to encode a XRI it would look like:*jbradley/+home/+phone

Persistent identifiers in XRI would use the ! symbol in the XRI part to
indicate persistence,  as per the XRI 2.0 spec.

I don't personally want to pass any judgement on ARK itself.  I think it is
a valid pattern for us to consider.
It remains to be seen if it is the best of the proposals under

John Bradley

On 16-Jul-08, at 4:40 PM, Erik Hetzner wrote:

At Wed, 16 Jul 2008 14:12:43 -0700,
"Paul Prescod" <> wrote:

I don't think that your analogy is quite right. The problem is not

that two different URIs address the same resource. The problem is

that third-parties are encouraged to make general-purpose software

that pulls apart *any* URI and infers something about it on the

basis of whether it matches that pattern or not. That software will

make the wrong inference if it encounters a legacy URI that just

happens to match the pattern.


Will this objection hold if third parties do not pull apart any URL,
but only the URLs of organizations that have agreed to be part of ARK?
In other words, if we know that & have agreed
to be a part of ARK, is there a problem with pulling apart and pointing at, knowing that,
which no longer exists, was part of the ARK system, and not to pull
apart, a site devoted to

If this does not address the objection, then I am at a loss for a
solution to the problem of:

| objects that last longer than the organizations that provide
| services for them, so when the provider changes it should not affect
| the object's identity. [2]

that: a) provides HTTP URLs which are resolvable now, b) allows for
some simple mechanism to make them resolvable at some point in the
future when the sponsoring organization no longer exists, and c) does
not have a single point of failure (for instance, PURLs).

Erik Hetzner

(Here of course speaking only for myself, and not for the California
Digital Library)

;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3

Received on Thursday, 17 July 2008 01:10:13 UTC