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
