RE: Boeing XRI Use Cases

Hi David (& All),

You stated that introducing a URI scheme for XRI "... is harmful to the
web." How would it be harmful to the web? Is this an objection to any
new scheme, or just XRI? Does your objection apply to existing schemes
other than http:?

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Information Security - Technical Controls
(206) 679-5933

-----Original Message-----
From: Booth, David (HP Software - Boston) [mailto:dbooth@hp.com] 
Sent: Saturday, July 12, 2008 10:15 PM
To: John Bradley
Cc: Schleiff, Marty; Ray Denenberg, Library ofCongress; www-tag@w3.org
Subject: RE: Boeing XRI Use Cases


Hi John,

> From: John Bradley [mailto:john.bradley@wingaa.com] [ . . . ] There 
> are actually separate specs for XRI syntax and resolution.
> This is common with OASIS specs.
>
> http://www.oasis-open.org/committees/download.php/15376/xri-sy
> ntax-V2.0-cs.html
> http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/x
> ri-resolution-V2.0-cs-01.html
>
> I suspect that you may not have read the resolution spec.

Correct.  Thanks for telling me about it.

>
> I would point you to Section 11 of the resolution spec that in large 
> measure deals with your suggestion.

I skimmed through it (though not in great detail), and it looks like an
effort has been made toward making it implementable over HTTP.  And
although that sounds like it would benefit your users, it does not
address my key concern: the creation of a new URI scheme.

Also, I note in section 11.2, that an HXRI is intended to be
recognizable by starting with "http://xri." (or "https://xri.").
Wouldn't this potentially cause a regular (non-HXRI) URI that happens to
start with that sequence to be erroneously interpreted as an HXRI?

> [ . . . ]
> I don't know if there is something special about [purl.org] that makes

> it more likely to continue running a proxy resolver than the current 
> operators of the XRI Global Registry Service.

Purl.org (not perl.org) is run by OCLC, "a nonprofit membership
organization serving more than 69,000 libraries and cultural heritage
institutions in 112 countries".  From their site: "OCLC has fiduciary
responsibilities of the highest order. We assist our members in
organizing and preserving the human record, providing access to it, and
passing it on to future generations."

I suggested purl.org (not perl.org) as an example, only because: (a) I
know it has credibility in its commitment to maintain persistent URLs;
(b) it is widely regarded as a neutral party; and (c) it is the most
well-known way to create persistent URLs.  However, the XRI TC could
just as well choose something else.

> [ . . . ]
> If there is some other arrangement for the proxy resolvers operation 
> that would make people more comfortable then we should open that 
> discussion, . . . .

Purl.org only does URL forwarding -- it would not act as an XRI proxy
resolver -- but it could *forward* HTTP requests to an XRI proxy
resolver.

>
> If we:
> 1.  Use http://xri.net/=some-xri  as the scheme for URLs through a 
> proxy resolver.
> 2.  Use =some-xri as the normal form for native resolution 3.  Stop 
> using xri://=some-xri as a IRI
>
> Would this be satisfactory to remove the TAGs objections?

I am not on the TAG, but from my perspective, #3 alone would remove my
objections.  My sole objection is the creation of a new URI scheme.  It
is not necessary for obtaining the benefits of XRIs, it creates a higher
barrier to use that http URI, and it is harmful to the web.

I want to stress that the point of my suggestion to piggyback XRIs on
top of http URIs was *not* to suggest that all XRI resolution should go
through an HTTP proxy or even use the HTTP protocol.  My points are:

1. An http URI can still act as an XRI identifier even if the HTTP
protocol is not used in resolving it.  XRI-aware software could
recognize a http://xri.net/ or http://purl.org/xri/ prefix and use XRI's
special resolution rules without using HTTP at all, thus obtaining all
of the benefits of XRIs that you value.

2. An http URI will work better in *other* circumstances, for software
that is *not* yet XRI aware or only partially XRI aware, because it can
potentially be dereferenced using good old HTTP.  Think of http URIs as
offering graceful degradation: for software that is not (or only
partially) XRI aware, it can *still* get some potentially useful
information by dereferencing the URI, wherease with the xri: scheme, the
software is *totally* stuck.

> [ . . . ]
> I believe, and please correct me if I am wrong in my belief from last 
> weeks call that the TAG position is, (I am paraphrasing now):
> 1. There should be no new URI schemes registered.
> 2. The http scheme should be the only namespace, to prevent 
> fragmentation.
>
> I ask simply is this the bar we must meet?

(Again, speaking for myself -- I am not on the TAG)  Yes.  It is as
simple as that.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not
necessarily represent the official views of HP unless explicitly so
stated.

Received on Monday, 14 July 2008 14:49:35 UTC