- From: Brett Zamir <brettz9@yahoo.com>
- Date: Fri, 26 Nov 2010 12:33:25 +0800
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 at 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 > >
Received on Thursday, 25 November 2010 20:33:25 UTC