Just to add another specific use case besides ISBNs. If a URN were to come into effect for say verses of the Bible, you could make these neutral links which could be interpreted by browsers (though perhaps defaulting (if not preferring) say a WikiSource copy). With wider, but neutral linking, people could also confirm authenticity more readily and improve the experience for users, without forcing them to give priority to a specific site over others (except perhaps as a convenient default if none already existed at a Wikimedia site).

I wouldn't mind this on irc:// urls either. There's potential there for cases where you do have a web based interface as well for fallback.

Yes, absolutely for IRC URLs too.

Two more cases, though I'm sure the list could keep going on, especially for such a vast site as Wikipedia...

1. In one of my Firefox extensions, Unicode Input Tool/Converter (at https://addons.mozilla.org/en-US/firefox/addon/5235 ), I've implemented support for my custom protocol which allows linking to display Unicode characters, e.g., in context with their code point, definition, etc. I think this could be useful for language pages. See http://brett-zamir.me/tests/unicodeProtocolExamples.html for example links.

2. While I'm not sure whether Wikimedia would be open to the idea of encouraging links which could be redirected to other encyclopedias, given Wikimedia's support of choice and standards, perhaps it would be willing to work with other encyclopedias (whether wiki-based or not) to create a generic protocol for referencing an encyclopedic article, allowing browser redirects via use of this protocol (as my Open URIs extension already supports) from a site which did not wish to favor any particular encyclopedia but did wish to provide links for the convenience of its users.

Of course, there would need to be a means of deciding which article names were canonical, but if nothing else, such links could use Wikipedia names as a base. For example, there might be a protocol, "pedia:" in a link like "pedia:?show=Love" and it would open the article "Love" in the user's favorite encyclopedic site (or local program). Or "pedia:?edit=Love" could bring one to the edit page (or alternatively, perhaps another protocol could specify editability: edit:?uri=pedia:?show=Love). The protocol could also be designed to allow the user to configure whether they wished to be brought to an edit page if the page's HEAD request did not turn up a Last-Modified, or to search another encyclopedia.

ayg wrote:

We should not add attributes that aren't supported by real-world implementations. It's a waste of effort and bytes, even if it maintained validity, which it wouldn't. Please reopen when at least one widely-used browser supports this feature.

I'm sure you understand the catch-22 here. The WhatWG editor told me that this needed to be tried out and demonstrate traction before it can be standardized. I'll probably be told by the browsers that this needs to be first standardized (if I get an answer at all: still waiting at https://bugzilla.mozilla.org/show_bug.cgi?id=539889 ). Meanwhile, this obviously useful functionality has no way of getting implemented if no one of significant standing will experiment with it either.

I should add that IE did specify a URN attribute already, but it defines no specific behavior. At least using this attribute could be utilized by the likes of my extension to offer alternative processing for the attribute.

ayg wrote:

The normal procedure to get features added to the standard web platform is:

1. At least one browser implementer expresses interest in implementing it. (If none are interested, there's no point in proceeding.)

2. It is written it up in a vendor-neutral draft specification published by a recognized body such as the W3C.

3. At least one browser implements it.

4. Sites start using it.

Browser implementers routinely deploy experimental extensions and then ask sites to use them. They do their own internal testing by writing simple web pages that use the feature, and leave the extension experimental until they've gotten enough author feedback to standardize and finalize the API. This is the normal way things are done. Your Mozilla bug might be closed because they're not interested, but not because sites aren't using the feature, so there's no catch-22.

https://github.com/w3c/html linked from http://www.w3.org/TR/2012/CR-html5-20121217/ does not define any "@alternateURIs".
Closing as WONTFIX as per comment 7.