- From: Drummond Reed <drummond.reed@cordance.net>
- Date: Wed, 16 Jul 2008 20:48:22 -0700
- To: "'Paul Prescod'" <paul@prescod.net>, <www-tag@w3.org>
- Message-ID: <052801c8e7bf$f6db5c00$9bfec04b@ELROND>
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
Received on Thursday, 17 July 2008 03:49:20 UTC