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
