Last modified: 2013-11-25 21:25:49 UTC
The gradual transition from http:// links to https:// links is a reminder that Wikipedia and its sister projects will (we hope) live longer than the current set of protocols we use to access it. Currently, all article URLs couple a reference with some implementation details, leaving no single implementation-independent way of addressing articles. You have, as I noted, http:// and https://, /w/index.php?title=X and /wiki/X, and ways of retrieving articles via the API. RFC 4395, "Guidelines and Registration Procedures for New URI Schemes", explains the criteria for URI schemes and the process for registering a new one (http://tools.ietf.org/html/rfc4395). You can see the current set of registered schemes here: http://en.wikipedia.org/wiki/URI_scheme I propose we adopt interwiki links (http://en.wikipedia.org/wiki/Wikipedia:InterWikimedia_links) as a basis for a hierarchical identifier scheme. In other words, the current short names used for interwiki links would form the basis of an initial directory of canonical wiki names, to be used for a wiki:// URI scheme. URIs belonging to this scheme would look like this: wiki://w/en/529238017 The above URI references revision 529238017, belong to the article "Barack Obama" on the English Wikipedia. This URI scheme is agnostic about the means of retrieving the article. Just as repositories specified using git:// URIs may be retrieved, at the agent's discretion, via https or SSH, wiki:// URIs could be retrieved using the API, or by being loaded from a dump, or what have you. The important thing is that the reference is stable and permanent and not tied down to the state of networking technology, circa 2012 (as the http:// -> https:// transition ably demonstrates). I don't think this is any crazier than a bitcoin:// or a secondlife:// URI scheme, both of which officially exist and are recognized by the IETF.
I don't think your comparisons are very good. BitCoin and SecondLife have their own custom protocols. Hence they have a custom scheme to point to the location of the resource. Without the scheme there is no other way to address anything via URI. And as for git. git:// is only used when git's custom protocol is being used. When GIT uses ssh it uses ssh:// urls, and when it uses HTTP or HTTPS http:// and https:// are used. The use of interwiki prefixes as hosts is also not a sound idea. Interwiki prefixes are non-global. An absolute url is not supposed to be relative to where you use it.
Tbh what you want sounds more like a request for urn support.
(In reply to comment #1) > I don't think your comparisons are very good. BitCoin and SecondLife have > their own custom protocols. Hence they have a custom scheme to point to the > location of the resource. Without the scheme there is no other way to > address anything via URI. RFC 3495 specifically allows for schemes that do not act as locators; cf section 2.3: "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme." (http://tools.ietf.org/html/rfc4395) The description in this case would take the form of a mapping of wiki:// URIs to the set of URLs currently usable for retrieving or editing the article. The expectation is not that wiki:// URIs would replace URLs in browsers, but that the scheme would specify a stable, permanent, protocol-independent way of addressing wiki content, irrespective of the means of its retrieval. > The use of interwiki prefixes as hosts is also not a sound idea. Interwiki > prefixes are non-global. An absolute url is not supposed to be relative to > where you use it. Right; for that reason, the current set of interwiki link short forms would serve as the starting point for the top-level naming authority for wikis, as described in section 2.2.
(In reply to comment #0) > wiki://w/en/529238017 I gave this a bit of further thought last evening, and I think you'd have to use wiki://en.wikipedia.org/529238017 syntax here, at which point it becomes unclear (again) what the value of such a URI scheme is. I'd recommend an RFC for this idea, either on Meta-Wiki or on mediawiki.org. The implementation details are less important than explicitly defining the use-cases and virtues of this proposed URI scheme, in my opinion.
(In reply to comment #4) > (In reply to comment #0) > > wiki://w/en/529238017 > > I gave this a bit of further thought last evening, and I think you'd have to > use wiki://en.wikipedia.org/529238017 syntax here, at which point it becomes > unclear (again) what the value of such a URI scheme is. > > I'd recommend an RFC for this idea, either on Meta-Wiki or on mediawiki.org. > The implementation details are less important than explicitly defining the > use-cases and virtues of this proposed URI scheme, in my opinion. If we were going to do this, we'd want to seriously think about how open we'd want this to be, how we'd achieve time-invariance with regard not only to references to revisions / page IDs / etc. but also to projects. Maybe an RFC, some way down the track once we have a proper idea of how this might work in a few edge cases?
I would also like to see bank:// flattr://links supported, as a lot of projects that use Mediawiki also ask for donations and that should be IMHO as easy as possible.
digi_c: Please file different feature requests as separate reports (one request per report only). See https://www.mediawiki.org/wiki/How_to_report_a_bug
