- 1 Double slashes
- 2 steam:// URI
- 3 require cleanup??
- 4 Splitting the Table
- 5 info-URI
- 6 Official IANA-registered schemes
- 7 Use Backus–Naur formatting
- 8 icyx://, rtpx://, htpx://, uvxx://
- 9 Picasa?
- 10 URI not listed yet
- 11 res
- 12 Percent-encoding and character set
- 13 Split article
- 14 Why Why Why?? (redirection)
- 15 RFC 3969?
- 16 'im' scheme: irrelevant RFCs, @-sign not optional
- 17 market: scheme
- 18 sms:
- 19 chrome: and Google Chrome
- 20 Inofficial Remote Access Schemes rdp: and vnc:
- 21 Unofficial URIs
- 22 Mailto example
- 23 More UnOfficial URIs
- 24 URI Syntax Diagram
- 25 Path delimiter inconsistency
- 26 "Forward slash" (sic)
The double slash after the colon following the URI scheme name requires some explanation IMHO. Why is it used sometimes (e. g. in http) but not always (e. g. in mailto or news)? Why do Windows "file:" URIs for UNC paths have to use four slashes, like in "file:////myserver/myshare/myfile.htm"; couldn't they live with the UNC's two slashes as well? Also, the scheme list could need some examples. - wr 14-dec-2005
- For Unixy paths, I believe it is e.g. "file:///home/isaac/whatever" because it's "file://" + "/home/isaac/whatever". I don't know why they have the "//", but a bit of searching turns up this: "The scheme specific data start with a double slash "//" to indicate that it complies with the common Internet scheme syntax." (RFC 1738) —Isaac Dupree(talk) 23:31, 1 January 2006 (UTC)
- It seems like the revised standard in RFC 3986 takes a rather different approach than its predecessors to the generic-ness of URIs. In the previous versions, very little meaning was explicitly enforced on the structure of the "scheme-specific part", and those schemes which used the common hierarchical system were referred to as using a "generic URI" syntax. Part of this generic syntax was the leading "//", so a URI starting
http://) could be assumed to be using that syntax, while one that didn't was probably non-hierarchical (e.g.
mailto:). Excerpt from RFC 2396:
The URI syntax does not require that the scheme-specific-part have any general structure or set of semantics which is common among all URI. However, a subset of URI do share a common syntax for representing hierarchical relationships within the namespace. This "generic URI" syntax consists of a sequence of four main components: <scheme>://<authority><path>?<query> each of which, except <scheme>, may be absent from a particular URI. For example, some URI schemes do not allow an <authority> component, and others do not use a <query> component.
- How this all fits in with the different angle taken by the newer RFC, I've no idea; I'd have to read it first.
- As for
file://, Isaac's given most of the answer already: a UNIX path becomes
/path/file- that is, the
file:scheme with the marker that it's generic/hierarchical (
//), and then the path used on the local system. Similarly, a Windows UNC example like
//myserver/myshare/myfile.htm. - IMSoP 13:41, 29 August 2006 (UTC)
- perhaps it was to make it easier for parsers to differentiate between an authority and a relative path, when certain elements are missing. For instance,
//example.com/clearly refers to an authority, while
/example.html/clearly is a path. -Cowlinator —Preceding comment was added at 02:27, 27 October 2007 (UTC)
I could add it meself, but I'm lazy...Takua108 02:15, 26 April 2006 (UTC)
- Added as of 12 September 2006 -- Southen 17:49, 20 October 2006 (UTC)
"To meet Wikipedia's quality standards, this article or section may require cleanup".
Clean the Notes column is enough??
Splitting the Table
The List of URI schemes table is getting long and complex. Is there a rule that prevents us from splitting it into two sections, for "Official IANA-registered schemes" and "Unofficial but common schemes"?
This would have the benefit of having both tables appearing in the table of contents for easy access, as well as make it easier to edit the required table. Thoughts? -- Techtoucian 04:39, 19 October 2006 (UTC)
- I support splitting the IANA and unofficial schemes into two tables (that is, each with their own heading) on this same page. The unofficial schemes could probably do with alphanumeric sorting too. -- Southen 17:49, 20 October 2006 (UTC)
- Out of interest, is there any particular reason why no-one thought to sort the table of registered schemes while they were at it? Oh well, I'm going to do it now, anyway. - IMSoP 17:46, 6 January 2007 (UTC)
What about info: (RFC 4452)
Official IANA-registered schemes
I have some suggestions about Official IANA-registered schemes, but I would like to discuss them because they may imply substantial modifications:
- I think the "Notes" column is too narrow (because "General format" needs most of the width), may be there should not be a table but a list ...
- Purpose and Name are not filled with uniform criterium on the whole table (usually "purpose" is the "Name" of the protocol, or the "Meaning" of the schema identifier, but there are some exceptions). On some entries the "Notes" field is really the "Purpose" of that schema.
- How should the general format be stated? ABNF per specification? "simplified" ABNF? example or meta-example (such as
- "generic syntax" is ambiguous, and should be avoided when possible (e.g.
Rjgodoy 01:24, 4 April 2007 (UTC)
It seems a bit odd to include
uuid:<specificpart> as part of the Official IANA-registered schemes on any grounds whatsoever. Certainly it is absent from Uniform Resource Identifier (URI) Schemes which is the (appropriately) cited authority. --Ramorrismorris (talk) 03:18, 11 July 2013 (UTC)
Use Backus–Naur formatting
Authors are encurrage to use Backus–Naur formatting when describing the URI format. A generic example would be:
<example_uri> ::= "example://" <absolute_uri>
Good point (and well done too!). Rjgodoy 01:44, 7 August 2007 (UTC)
icyx://, rtpx://, htpx://, uvxx://
Would it be appropriate to add these unofficial URLs:
icyx://, rtpx://, htpx://, uvxx:// or aren't they yet common enough? They are used by Orban/Coding Technologies AAC/aacPlus plugin for any DirectShow compliant media player, such as Windows Media Player.
URI not listed yet
1. reg syntax : reg:[regpath]
ex : reg:HKEY_CURRENT_USER\Control Panel OR reg:HKCU\Control Panel
Percent-encoding and character set
I suggest splitting this article into two new articles: 1) Explaining URI scheme in general 2) List of URI schemes —Preceding unsigned comment added by 220.127.116.11 (talk) 22:01, 7 October 2009 (UTC)
Why Why Why?? (redirection)
... does everything on Wiki keep sliding into one pot? I want to find information on the Callto function but I am redirected here!!! WHY?!?!?!? Sure it's a higher leved classification in a certain taxonomy but SO WHAT?!?!? Hey, I've got an idea. Let's put everything to do with computers under the title Computers. That would simplify things wouldn't it? Come to think of it a computer is simply ane elctronic machine so we could just put it all under the heading Electonic Machines. Hey, this is great, because, electronic machnes are just a subset of ... yes, you've got it, this process makes the information not more useful but less usefull, in fact it steadily decays until it is almost completely useless. This is a cse in point. Common guys, the idea of a taxonomy is to make information more searchable not less. LookingGlass (talk) 11:15, 13 December 2009 (UTC)
- Generally speaking, things on Wikipedia are redirected to more general articles simply because nobody has - yet - written enough about them for them to deserve their own article. So in this case, all we have to say about "callto:" URIs can be summed up by one line of the table in this article. If there was genuinely enough to say about it that it warranted a page all of its own, one could be created in place of the redirect.
- Now, admittedly it can be somewhat confusing when you search for (or even follow a link to) a specific term, only to see an article whose relevance is not immediately obvious. Sometimes, this can be improved by targetting the redirect at a particular section of the page; at other times, a mention can be made in the summary of related terms also covered by the article.
- Obviously, neither of those would help in this case. One possibility would however be to split the article, creating an article about the concept and syntax of URI schemes in general, and a separate list article (or possibly 2 articles?) with the 2 tables of information about specific schemes. That way it would be more obvious that incoming redirects were simply a way of combining a set of related "stubs" into one more useful page. - IMSoP (talk) 19:01, 13 December 2009 (UTC)
'im' scheme: irrelevant RFCs, @-sign not optional
In the row about the 'im' scheme, the following RFCs are mentioned: RFC 3860, RFC 4622, and RFC 5122. The latter two seem XMPP-related, and unrelated to the 'im' scheme. These two RFCs should be left out.
The first RFC defers to RFC 2822's "mailbox" specification, which always contains an "addr-spec", which always contains an @-sign and a "domain". Therefore the example should be written im:<username>@<host> instead of im:<username>[@<host>].
It appears Google "invented" a new scheme to be used on Android devices addressing items in its application market: market: Example: market://search?q=pname:net.dinglisch.android.taskerm Somebody who knows more could add it to the article. --Xerces8 (talk) 13:41, 27 October 2010 (UTC)
The article states that sms: 'should be used as a subset to the tel: schema'. This suggests that any telephone would have SMS capabilities, which is untrue. Is the comment therefore misleading/incorrect? —Preceding unsigned comment added by 18.104.22.168 (talk) 19:14, 20 December 2010 (UTC)
chrome: and Google Chrome
The article mentions that chrome: is used in mozilla based browsers for XUL components, and shouldn't be confused with Google Chrome. Google Chrome also seems to use this scheme, but for a purpose more similar to about: in other browsers; eg. chrome://settings/cookiesView in Google Chrome brings up a list of your cookies. TheCycoONE (talk) 14:53, 11 March 2011 (UTC)
Inofficial Remote Access Schemes rdp: and vnc:
- The "chrome-extension" URI should be added to the unofficial URIs. It's purpose is a managements of extensions in Google Chrome browser - it's managed by HTML forms, for example: chrome-extension://edacconmaakjimmfgnblocblbcdcpbko/main.html
- There is a record about "chrome://" related to FireFox, but this URI is also used by Google Chrome. Here's an example: chrome://settings/browser
- "res" URI used by IE and Windows to view an HTML file stored in a DLL, or a CHM file. For example, the error pages of IE are stored at res://ieframe.dll/
- "hcp" (later renamed to "ms-help" in Vista) is a protocol for viewing the help files in Microsoft Windows Help and Support Center. Those are also HTML files. Examples for HCP avilable here. Here's an example for a "ms-help" link: ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vcedit/html/92ac4c84-65d1-4a4f-8faf-ffb158b9665b.htm
- I've recently saw another URI that isn't mentioned in this list:
- Is anyone knows what's it purpose? It showed up when Flash stucked in FireFox.
- Galzigler (talk) 22:19, 29 April 2012 (UTC)
The interpretation of the mailto example seems to be incorrect.
It states that username is the userinfo and example.com is the hostname, i.e. part of the authority rather than the path. But in fact, RFC 3986 states that
the URI <mailto:email@example.com> has a path of "firstname.lastname@example.org", whereas the URI <foo://info.example.com?fred> has an empty path.
- mailto is defined in RFC 6068. Please review that before making any changes. --Kvng (talk) 13:25, 11 May 2012 (UTC)
More UnOfficial URIs
I found a few more unofficial URIs, but I don't know what they are doing:
(The URIs mentioned on Unofficial URIs were added to the article.)
The format is: "android.resource://[package]/[res id]" [package] is your package name [res id] is value of the resource ID, e.g. R.drawable.sample_1 to stitch it together, use Uri path = Uri.parse("android.resource://your.package.name/" + R.drawable.sample_1);
- From 
- pack, application, siteoforigin - WPF
- From 
- GNOME's computer:///
- linkback - I couldn't find anything about it, so I didn't add it to the list.
URI Syntax Diagram
foo://username:email@example.com:8042/over/there/index.dtb?type=animal&name=narwhal#nose \_/ \_______________/ \_________/ \__/ \___/ \_/ \______________________/ \__/ | | | | | | | | | userinfo hostname port | | query fragment | \________________________________/\_____________|____|/ \__/ \__/ | | | | | | | scheme authority path | | interpretable as keys name \_______________________________________________|____|/ \____/ \_____/ | | | | | | | hierarchical part | | interpretable as values | | | | path interpretable as filename | | ___________|____________ | / \ / \ | urn:example:animal:ferret:nose interpretable as extension scheme name userinfo hostname query _|__ ___|__ ____|____ _____|_____ / \ / \ / \ / \ mailto:firstname.lastname@example.org?subject=Topic
Passwords and other access info
Seems like a sensible idea, Galzigler! Today, I looked into the source mentioned for this diagram, namely Chapter 3 of [RFC 3986], in order to establish just what exactly an explanatory diagram such as this should contain. There, in section 3.2.1. User Information, we find these statements:
The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource. ... Use of the format "user:password" in the userinfo field is deprecated.
So to anybody who plans to replace or update this diagram, please remove the ":password" after "username". Similarly, and at the same time, we need to lose the "password" appearing twice more in the article.
Still, it beats me what other useful "information about how to gain authorization to access the resource" one would want to place in cleartext in a URI! Basic security considerations imply that we should pass no access info unless it's absolutely necessary, and even then, we should first encrypt it. yoyo (talk) 10:50, 26 June 2014 (UTC)
Path delimiter inconsistency
The "Generic syntax" section states that if the hierarchical path doesn't begin with ("//") it contains only a path. It goes on saying that if the path is present, it must begin with a forward slash ("/"). It also states that the path is a sequence of segments separated by a forward slash.
The sub section "Examples" uses URI "urn:example:animal:ferret:nose" as an example, pointing out that the substring "example:animal:ferret:nose" is the path component of the URI.
Now, raise your hands those of you who can see the "//" prefix and the required "/" delimiter in that path, stated as required characters a few inches up in the article. The article states one thing only to go against itself later on. I don't feel qualified to correct this, but at least I can point out the inconsistency.
- I also noticed this. I updated that section to be more in line with the information listed at RFC 3986 Section 3.3. Bondsbw (talk) 16:51, 2 November 2013 (UTC)
"Forward slash" (sic)
The Generic syntax section repeatedly mentions a (sometimes double) "forward slash". I believe that this expression is an oxymoron, and that the correct name (in both ASCII and UTF-8 standards, among others) for the "/" character is simply "slash". I also understand that many people use the expression "forward slash" to make it clear to their audience that they don't mean the character "\", a "backslash". I'd like to promote the cause of accuracy, as it can contribute to clarity, but not at the expense of comprehension.
My question is this: Should we, in the interests of being technically (even pedantically) correct, replace all occurrences of "forward slash" by "slash", or would that make the article harder to understand?