RE: Boeing XRI Use Cases

Paul,

 

>From my POV, this is an extremely interesting proposal. 2.5 years ago when
the XRI TC was trying to figure out how to best comply with the TAG's
feedback on an early draft of what's now XRI Resolution 2.0 (in which they
asked for this type of for HTTP(S) URI integration), we had to solve exactly
this same problem: how could we express an XRI inside an HTTP(S) URI (a
combination we call an HXRI) in a way that could be unambiguously understood
by all XRI-aware parsers/applications while still being a fully valid
HTTP(S) URI?

 

In the absence of such a recommendation, we had to struggle with it on our
own and finally ended out specifying a slight variant on what we recently
learned was the approach David Booth documented in his "Converting New URI
Schemes or URN Sub-Schemes to HTTP" [1]. The only difference of what we did
from what David specified was that in order to avoid specifying a single
centralized XRI proxy server, we specified a pattern HXRIs must follow
(essentially "xri.* in the domain name PLUS an XRI global context symbol as
the first char of the path).

 

Had a TAG recommendation for what you are proposing existed, it not only
would have saved us months of time, but it would have provided a
standardized solution vs us needing to specify our own special case.

 

The only suggestion I have to your proposal is to add a second forward slash
to the identifier so that you reduce the potential for false positives even
further. Thus the ABNF for "HTTP(S) subschemes" as the first segment of the
path of an HTTP(S) URI would be.

 

            subscheme-id    = reg-name "://"

 

.where reg-name is the rule of that name from the ABNF for RFC 3986. Then it
could be specified that the subscheme document SHOULD (or MUST) be specified
at http(s)://reg-name.

 

Best,

 

=Drummond 

 

[1] http://dbooth.org/2006/urn2http/

 

  _____  

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
Paul Prescod
Sent: Wednesday, July 16, 2008 6:19 PM
To: www-tag@w3.org
Subject: Re: Boeing XRI Use Cases

 

Let me make a concrete proposal.

 

Could the W3C (the TAG? Or someone else?) issue a recommendation to the
effect that URIs of the following form are special:

 

 <http://xri.example.org/xri:/@boeing*jbradley/+home/+phone>
http://xri.example.org/SOMETHING:/@boeing*jbradley/+home/+phone

 

It would be permissable for an application detecting a URI of that form to
interpret the URI *either* according to the HTTP specification *or*
according to some other specification attached to the word SOMETHING.

 

SOMETHING's should probably be managed in a registry but I don't know
whether to use the domain name registry or something else. For the sake of
continuing, let's presume the domain name registry:

 

 <http://xri.example.org/xri:/@boeing*jbradley/+home/+phone>
http://xri.example.org/uri.xri.org:/@boeing*jbradley/+home/+phone

 

It might be a best practice that "http://xri.org/" have a prominent link to
documentation of how the URI is used.

 

Once the W3C had issued such a recommendation, the chances of someone
minting these URIs by accident would drop (even below the really tiny
current chance).

 

I see a use-case that's been bugging me for years;

 

http://my.vital.service.com/failover_uri:/path/failover_uris=URI2+URI3

 

(I'd have to think more about how exactly the escaping works to get the
three URIs embedded)

 

Today's HTTP clients would contact me with the full URI and I'd discard URI2
and URI3. But a smart HTTP client might try URI2 if it couldn't contact
my.vital.service.com.

 

 Paul Prescod