[whatwg] Reserving XRI and URN in registerProtocolHandler

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 <a/> could be accepted 
> as well: 
> http://www.mail-archive.com/whatwg at 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.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 1 March 2011 14:34:52 UTC