- From: John Bradley <john.bradley@wingaa.com>
- Date: Wed, 16 Jul 2008 21:37:58 -0700
- To: "Drummond Reed" <drummond.reed@cordance.net>
- Cc: "'Paul Prescod'" <paul@prescod.net>, <www-tag@w3.org>
- Message-Id: <EEA589DD-B3FA-49A2-85D3-48410AADE29C@wingaa.com>
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 >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 17 July 2008 04:38:39 UTC