On 2/10/2010 3:55 PM, Martin Atkins wrote:

Brett Zamir wrote:

Internet Explorer has an attribute on anchor elements for URNs: http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx

This has not caught on in other browsers, though I believe it could be a very powerful feature once the feature was supported with a UI that handled URNs (as with adding support for custom protocols).

Imagine, for example, to take a link like:

<a href="http://www.amazon.com/...(shortened)...." urn="isbn:9210020251">United Nations charter</a>

[snip details]

I like what this proposal achieves, but I'm not sure it's the right solution.

Here's an attempt at stating what problem you're trying to solve without any specific implementation: (please correct me if I misunderstood)

* Provide a means to link to or operate on a particular artifact without necessarily requiring that the artifact be retrieved from a specific location.

* Provide graceful fallback to user-agents which do not have any specialized handling for a particular artifact.

Yes, exactly.
This is different to simply linking to a different URL scheme (for example, linking a mailto: URL in order to begin an email message without knowing the user's preferred email provider) because it provides a fallback behavior for situations where there is no handler available for a particular artifact.

Yes. But note also that it would be possible to have the @protocol attribute be, for example, be used for already frequent protocols like mailto:, and the @href be http: . Or, to use a URN, the protocol could be urn:isbn:... and the @href could be http, etc.

Since 'href' also links to a protocol, it might be more clear for the proposed attribute to be called something like @defaultProtocol.

== Example Use-cases ==

* View a particular book, movie or other such product without favoring a particular vendor.

* View a map of the location for particular address or directions to that address without favoring a particular maps provider.

* View a Spanish translation of some web document without favoring a particular translation provider.

* Share a link/photo/etc with friends without favoring a particular publishing platform. (i.e. generalizing the "Tweet This", "Share on Facebook", class of links)

Yes. This would of course depend on the protocols existing. For example, XMPP as an open protocol, might work for your last examples if those services were actually using XMPP. And your other examples would also be excellent use cases.

== Prior Art ==

=== Android OS Intents ===

The Android OS has a mechanism called Intents[1] which allow one application to describe an operation it needs have performed without nominating a particular other application to perform it.

Intents are described in detail here:

An intent that does not identify a particular application consists of the following properties:

* Action: a verb describing what needs to be done. For example, "view", "edit", "choose", "share", "call". * Object: the URI of a particular thing that the action is to be done to. This is not specified for actions that apply only to a class of object, such as "choose". * Object Type: the MIME type of the Object, or if no particular Object is selected a concrete MIME type or wildcard MIME type (e.g. image/*) describing the class of object that the action relates to.

A process called "Intent Resolution" is used to translate an abstract intent like the above into an explicit intent which nominates a particular handler.

Often when applications use intents a UI is displayed which allows a user to choose one of several available applications that can perform the action. For example, the built-in photo gallery application provides a "Share" command on a photo. By default, this can be handled by application such as the email client and the MMS application, but other applications can declare their support for intents of this type thus allowing plug-in functionality such as sharing a photo on Facebook.

That's an interesting consideration.

I think some behaviors should be necessarily limited with links (as they are in HTTP disallowing a link to make a POST or PUT request or upload a form (without JavaScript at least))--so that, e.g., spam links don't cause users to accidentally do things they didn't want to do. So side-effects should probably not occur (like "share" at least), unless it was merely, as in your use cases with Twitter/Facebook to lead to a UI control confirming that you wanted to share.

Unlike URNs, a regular protocol could already handle the use cases you mention, and perhaps the Intents mechanism could itself be made into a protocol: e.g.,:


Being that experimentation here is fairly early on, and being that there may be too many types of fundamental actions/data/etc. to agree would be useful for the whole web (at least at this stage), I'd think that allowing protocol innovation should be enough for now. As HTML5 is now doing in co-opting various existing practices, HTML6 could also consider specializing support for particular protocols down the line if they were found to be worthy of being obligatorily supported.

=== Internet Explorer "urn" Attribute ===

Internet Explorer supports a non-standard attribute on the "A" element called "urn", which accepts an URN identifying some resource.

It is described in detail here:

It is not apparent that this attribute causes any behavior in the browser itself. It is possible that this is exposed to browser extensions in some way to allow them to overload the behavior of a link which identifies a particular class of resource.

It does not seem that this attribute has achieved wide author adoption nor wide application support.

Yes, that is correct on all counts. But like perhaps Esperanto (or international English, etc.) not catching on, I think the fault does not lie in the utility of the idea, but in its inadequate standardization and implementation. If the browser doesn't do anything special with the attribute, then there is little incentive for website creators to make use of it. It seems that the "urn" attribute documentation doesn't even make explicit the idea that it could be used for default processing, so I'd at least like to see this documented as a potential use, or rather, see the more comprehensive @defaultProtocol document it. It'd be great if there could be default handling behavior specified (akin to using a new protocol inside "href"), but if it is too late in the game, it'd be nice to at least have the attribute with a suggested behavior, letting the browsers add support if they wished.


Please reply with any other use cases and prior art you have.

I don't know of any other prior art, except that protocol handling is already in http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler .

I think there are any number of use cases--some of which may crop up in the future; your list I think already gave a good overview of some possibilities. There is the one I already mentioned for a Wikipedia or Wikipedia-like protocol to reference concepts, people, or things in a generic way, with other encylopedias or resources being potentially registerable to handle such resources. I chose Wikipedia because of its popularity, openness, and flexibility--no need for waiting around for IANA to approve a new concept. That adds some challenges with names being in flux as pages are deleted, redirected, merged, etc., but I think could still be very useful. Other encyclopedias could use their own protocol, or be made to work with Wikipedia as a base, letting their users (and Wikipedia users) view an article where they please. (Of course, it'd be nice if there were an open API so that one could easily query to find out whether the handler turn up any results; see my suggested JavaScript below.)

Maybe another similar use case could be a protocol which looked for commentary or information on a given webpage--e.g.,:



    urn:commentary:http://yahoo.com (escaped as needed by URN syntax)

...could find out info about what users had to say about Yahoo.

As yet another example, I just recently proposed to the Unicode mailing list that a protocol be adopted to specify a particular Unicode character, range of characters, or searched subset. While this might not be something the average user would clamor for, I was hoping to get standardization on the custom protocol I designed to work with my Unicode browsing Firefox extension, (at https://addons.mozilla.org/en-US/firefox/addon/5235 )--a protocol which would let you choose how you wanted to view a particular Unicode character--e.g., to get description info, meta-data, equivalent entities, etc.

While it may seem desirable to be more specific--and indeed it often is--sometimes there is benefit in being able to be vague. For example, when clicking on such a Unicode "link", it may be desired to leave ambiguous what the user should do with the content. For example, one registered handler might simply display the character's authoritative name. Another use might be to display the character in a chart along with other characters in that range. As in language, sometimes ambiguity can be a good thing, letting your user come to their own conclusion/take their own path.

If I understand URNs correctly, this ambiguity seems to be closer to what a URN represents. It doesn't seem to imply an action, just a name. While that might not always be clear, if the particular terminology implied an action, it would seem to me that this is more generic than a protocol which can have say a query string with variables including actions, objects, etc.

That being said, I'd really like to see any protocol work here (and urn: seems it can also be used in protocol form anyways).

Actually, maybe it should even be @defaultProtocols with say white-space separated protocols occurring in order, to allow, say, one to check for support for "tel:", and if none, then "mailto:";, and if none, then href to a contact form.

I'm particularly interested to see whether Android's (verb, object) tuple is actually required or whether the single object as afforded by your proposal -- and by the existing design of registering handlers for particular URL schemes and MIME types -- is sufficient for the use-cases at hand.

As far as the existing design of registering handlers, while I think that should be all right (e.g., as already at http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler and also described at https://developer.mozilla.org/en/Web-based_protocol_handlers ), I think it'd be nice to be able to see additions to say the navigator object or <a/> (if not onclick events):

<a href="http://amazon.com..."; defaultProtocol="urn:isbn:..." onclick="check(event);">Some book</a>
// We must rely on "onclick" since older browsers wouldn't support a handler like "onDefaultProtocol" anyways. // The following demonstrates some potentially useful properties for the event:
function  check (e) {
    if (!*navigator.defaultProtocol*) {
if (!confirm("Your browser doesn't support generic protocols; would you like to be redirected to "+this.href+"?") {
            e.preventDefault(); // Here we can prevent the regular 'href'
else if (!*navigator.defaultProtocol.handlers*) { // or requiring a key to a specific scheme? alert("Although your browser supports generic protocols, you do not have any handlers registered for"+*this.defaultProtocol.scheme*); // "for urn". if (!confirm("Would you like to be redirected to the default URL?") { e.preventDefault(); // Here we prevent the defaultProtocol (and href) from proposing a dialog to find a protocol; there could either be // special syntax added to allow jumping over the defaultProtocol to the default 'href', or the JavaScript could simply set
            // window.location. The latter would probably be enough.
        else { window.location.href = this.href; }
    else {
// Since some handlers might need to make a network connection to figure out whether they can not only handle the scheme, but also // the particular content (like for a specialized bookstore which only recognized certain ISBNs), maybe it should also be possible to have // a selection hierarchy order, such that one could activate checking: if (!*navigator.defaultProtocol.handlers.supports*(this.defaultProtocol)) {* * alert("Unfortunately your registered protocol handlers cannot support this particular protocol instance.");
// We might allow script access to the names of the protocol handlers, but not allow invoking of a particular handler since it might violate the user's wishes; however "selected.name" could be advanced to the first capable handler found by the supports() check above alert("We will now open "+*navigator.defaultProtocol.handlers.selected.name*)+" with "+*this.defaultProtocol*; // e.g., "...will now open UsedBooks with urn:isbn:..."

While the above might be very useful, I don't think it would be critical--and no doubt others may find better ways of implementing.... The main thing I'd like to see is at least some attribute that justifies giving default behavior to a protocol for handling generic data and which could override 'href' if the user agrees.


Reply via email to