- From: Brett Zamir <brettz9@yahoo.com>
- Date: Sat, 27 Nov 2010 00:14:40 +0800
On 11/26/2010 11:59 PM, Julian Reschke wrote: > On 26.11.2010 16:55, Brett Zamir wrote: >> On 11/26/2010 7:13 PM, Julian Reschke wrote: >>> On 26.11.2010 11:54, Brett Zamir wrote: >>>> ... >>>> My apologies for the lack of clarity on the approval process. I see >>>> all >>>> the protocols listed with them, so I wasn't clear. >>>> >>>> In any case, I still see the need for both types being reserved >>>> (and for >>>> their subnamespaces targeted by the protocol handler), in that >>>> namespacing is built into the XRI unlike for informal URNs which could >>>> potentially conflict. >>>> ... >>> >>> I'm still not sure what you mean by "reserve" and what that would mean >>> for the spec and for implementations. >>> >> I just mean that authors should not use already registered protocols >> except as intended, thinking that they can use any which protocol name >> they like (e.g., the Urn Manufacturers Company using "urn" for its >> categorization scheme). >>> I do agree that the current definition doesn't work well for the "urn" >>> URI scheme, as, as you observed, semantics depend on the first >>> component (the URN namespace). Do you have an example for an URN >>> namespace you actually want a protocol handler for? >>> >> ISBNs. > > Oh, that's a good point. In particular, if the URN WG at some day > makes progress with respect to retrieval. > > So, would it be possible to write a generic protocolHandler for URN > which itself delegates to more specific ones? If a site were interested in handling all of the cases, I would think so, but I doubt that would happen. I doubt the neighborhood bookstore site is going to try to deal with XMPP URNs or whatever else, even if the spec called for some (bandwidth-wasting) response by the server to indicate it was abdicating responsibility. The only optimal way I can really see this is if there were say a fourth argument added to registerProtocolHandler which allowed (or in the case of URNs or what I'll call "XRN" for now, required) specifying a namespace (perhaps also allowing URN subnamespace specificity via colons, e.g., "ietf:rfc"). Brett
Received on Friday, 26 November 2010 08:14:40 UTC