W3C home > Mailing lists > Public > www-tag@w3.org > July 2008

Re: Boeing XRI Use Cases

From: John Bradley <john.bradley@wingaa.com>
Date: Wed, 16 Jul 2008 21:37:58 -0700
Cc: "'Paul Prescod'" <paul@prescod.net>, <www-tag@w3.org>
Message-Id: <EEA589DD-B3FA-49A2-85D3-48410AADE29C@wingaa.com>
To: "Drummond Reed" <drummond.reed@cordance.net>
Hi All,

There are a lot of options,  perhaps too many.

Encoding a sub scheme in the path like ARK.  Doing something special  
with the domain name.  Or even using a URI scheme.

Each as plusses an minuses.   Independent of the URI scheme issue,  I  
am coming to the conclusion that the HXRI form should adopt one or  
perhaps both strategies for  discriminating HXRI from "regular" http:  

I see merit in both approaches,  and I sincerely thank people for  
contributing there ideas.

We are starting again to venture into IPR issue territory.

Is it the TAGs intention to develop a universally acceptable encoding  
methodology for what I will call http:  sub schemes?

Should this work be undertaken by the W3C under its  IPR rules, or is  
it the desire of the TAG to have a OASIS TC undertake this work under  
OASIS RF-Limited.

I am happy to propose a new TC or have the XRI-TC undertake the work  
if that were mutually agreeable.

We at OASIS do not shy away from undertaking new spec work.

I think a clear desire has been expressed that someone needs to  
undertake it.

What ever Standards body and IPR regime undertakes the work I would  
encourage people from both OASIS and W3C to participate as possible.

We have some momentum established please lets not lose it.

I eagerly await the TAG's feedback from its call on this Thursday.

Best Regards
John Bradley

On 16-Jul-08, at 8:48 PM, Drummond Reed wrote:

> 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/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/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

Received on Thursday, 17 July 2008 04:38:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC