[XRI] RE: Boeing XRI Use Cases

Hello John,

> We have some momentum established please lets not lose it.
> 
> I eagerly await the TAG's feedback from its call on this Thursday.

Much as I would like to oblige, unfortunately the summer vacation period is
starting to kick-in, and after a cascade of regrets (6 out of 10) I
no-longer have critical mass for the TAG to meet this week. I am hopeful of
a meeting next week (24th) though I already have regrets on record from 3
members - we have also cancelled out regular meetings on 31/7, 7/8 and 14/8
and I expect us to resume a mostly normal meeting pattern on 21/8.

I know that is not what you want to hear... Drummond and I have exchanged a
few emails off-list, and I think that we think that the most/only way to
maintain some momentum through the summer is to email discussuion on this
list - it would be helpful to folks that either explicitly want to tune in
or out of this discussion if subject lines could contain a marker, say
"[XRI]" (hmmm... somewhat ironic) so that folks can filter their mail
accordingly.

I think that, given unsynchronised lapse of attention for periods ranging
from 1-4 weeks, finding someone that would be willing to provide balanced
summary of discussion over the summer might be useful around mid-Aug (that's
just me thinking aloud without particular expectations).

Best regards

Stuart Williams
co-chair W3C TAG
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12
1HN
Registered No: 690597 England

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of John Bradley
> Sent: 17 July 2008 05:38
> To: Drummond Reed
> Cc: 'Paul Prescod'; www-tag@w3.org
> Subject: 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/+phon
> e <http://xri.example.org/xri:/@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/+ph
> one <http://xri.example.org/xri:/@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
> 		
> 
>