Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Ian Hickson]

On Fri, 26 Nov 2010, Brett Zamir wrote:
>
> I'd like to propose reserving two protocols for use with 
> navigator.registerProtocolHandler: "urn" and "xri" (or possibly xriNN 
> where NN is a version number).
> 
> See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info 
> on XRI (basically allows the equivalents of URN but with a user-defined 
> namespace and without needing ICANN/IANA approval). Although it was 
> rejected earlier, I don't see that there is any other way for sites to 
> create their own categorization or other behavior mechanisms in a way 
> which is well-namespaced, does not rely on waiting for official 
> approval, and has the benefits of working with the HTML5 specification 
> as already designed.
> 
> URN is something which I think also deserves to be reserved, if not all 
> IANA protocols.
> 
> As I see it, the only way for a site to innovate safely in avoiding 
> conflicts for non-IANA protocols is to use XRI (assuming especially if 
> it can be officially reserved).
> 
> And all of this would be enhanced, in my view, if my earlier proposal 
> for defaultURIs and alternateURIs attributes on  could be accepted 
> as well: 
> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20066.html in 
> that it makes it much more likely that people would actually use any of 
> these protocols.

On Fri, 26 Nov 2010, Brett Zamir wrote:
>
> My apologies, I realized that there might be a modification needed to 
> the HTML5 design of registerProtocolHandler, in that URN and XRI are 
> better designed to work, in many cases, with registration to a specific 
> namespace. For example, one application might only wish to handle 
> urn:earthquakes or xri:http://example.com/myProtocols/someProtocol which 
> hopefully registerProtocolHandler could be expanded to allow such 
> specification without interfering with other URN/XRI protocol handlers 
> which attempted to handle a different namespace.

On Fri, 26 Nov 2010, Brett Zamir wrote:
>
> 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).

The definition of the protocol/scheme is what makes it non-conforming to 
do something else with that protocol/scheme, there's not really anything 
additional to do here as far as I can tell.


On Sat, 27 Nov 2010, Brett Zamir wrote:
> 
> 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").

Let's see if this gets any traction in the first place. If it does, then 
it might make sense to add new features.

Of course, an alternative would be to just register the top-level schemes 
for the features you want (like isbn:), instead of putting them inside a 
urn: bucket.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Brett Zamir]

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

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Julian Reschke]

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?



...


BR, Julian

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Brett Zamir]

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.
Finally, I'd recommend not to open the XRI can-of-worms (see 
).


Ok, looks like I misappropriated this based on an incomplete 
understanding. Still, at least the part about having a namespaced naming 
protocol makes sense to me. For example, if Wikipedia offered its own 
article names up for referencing using its own namespace to define which 
scheme was being used, but in a generic way so they could be 
dereferenced to articles on Britannica, Citizendium, etc., sites 
wouldn't need to be showing preference to only one encyclopedia when 
they added links (or at least give the choice to their users by using 
the attributes I proposed be added to  such as "alternateURIs" for 
the fallbacks after "href" or "defaultURIs" for the priority ones before 
"href").


Brett

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Julian Reschke]

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 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?


Finally, I'd recommend not to open the XRI can-of-worms (see 
).


Best regards, Julian

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Brett Zamir]

On 11/26/2010 6:18 PM, Julian Reschke wrote:

On 26.11.2010 05:20, Brett Zamir wrote:

I'd like to propose reserving two protocols for use with
navigator.registerProtocolHandler: "urn" and "xri" (or possibly xriNN
where NN is a version number).

See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info
on XRI (basically allows the equivalents of URN but with a user-defined
namespace and without needing ICANN/IANA approval). Although it was


You don't need ICANN/IANA approval.

You can use informal URN namespaces, use a URN scheme that allows just 
grabbing a name (such as URN:UUID) *or* write a small spec; for the 
latter, the approval is *IETF* consensus (write an Internet Draft, 
then ask the IESG for publication as RFC).


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.


thanks,
Brett

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Julian Reschke]

On 26.11.2010 05:20, Brett Zamir wrote:

I'd like to propose reserving two protocols for use with
navigator.registerProtocolHandler: "urn" and "xri" (or possibly xriNN
where NN is a version number).

See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info
on XRI (basically allows the equivalents of URN but with a user-defined
namespace and without needing ICANN/IANA approval). Although it was


You don't need ICANN/IANA approval.

You can use informal URN namespaces, use a URN scheme that allows just 
grabbing a name (such as URN:UUID) *or* write a small spec; for the 
latter, the approval is *IETF* consensus (write an Internet Draft, then 
ask the IESG for publication as RFC).


Best regards, Julian

Re: [whatwg] Reserving XRI and URN in registerProtocolHandler

[Brett Zamir]

My apologies, I realized that there might be a modification needed to 
the HTML5 design of registerProtocolHandler, in that URN and XRI are 
better designed to work, in many cases, with registration to a specific 
namespace. For example, one application might only wish to handle 
urn:earthquakes or xri:http://example.com/myProtocols/someProtocol which 
hopefully registerProtocolHandler could be expanded to allow such 
specification without interfering with other URN/XRI protocol handlers 
which attempted to handle a different namespace.


thanks,
Brett

On 11/26/2010 12:20 PM, Brett Zamir wrote:
I'd like to propose reserving two protocols for use with 
navigator.registerProtocolHandler: "urn" and "xri" (or possibly xriNN 
where NN is a version number).


See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for 
info on XRI (basically allows the equivalents of URN but with a 
user-defined namespace and without needing ICANN/IANA approval). 
Although it was rejected earlier, I don't see that there is any other 
way for sites to create their own categorization or other behavior 
mechanisms in a way which is well-namespaced, does not rely on waiting 
for official approval, and has the benefits of working with the HTML5 
specification as already designed.


URN is something which I think also deserves to be reserved, if not 
all IANA protocols.


As I see it, the only way for a site to innovate safely in avoiding 
conflicts for non-IANA protocols is to use XRI (assuming especially if 
it can be officially reserved).


And all of this would be enhanced, in my view, if my earlier proposal 
for defaultURIs and alternateURIs attributes on  could be accepted 
as well: 
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20066.html in 
that it makes it much more likely that people would actually use any 
of these protocols.


thank you,
Brett