Re: Boeing XRI Use Cases

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:  
URLS.

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
OASIS IDTRUST-SC
http://xri.net/



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
>