[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 <a/> 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
>
>