Talk:URI scheme

This redirect was nominated at Wikipedia:Redirects for discussion on 14 November 2017. The result of the discussion was no consensus.

This is the talk page of a redirect that has been merged and now targets the page:
• Uniform Resource Identifier
Because this page is not frequently watched, present and future discussions, edit requests and requested moves should take place at:
• Talk:Uniform Resource Identifier
Merged page edit history is maintained in order to preserve attributions.

Double slashes

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)[reply]

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 <scheme>:// (e.g. 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 file:///path/file from file:// + /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 file:////myserver/myshare/myfile.htm is simply file:// + //myserver/myshare/myfile.htm. - IMSoP 13:41, 29 August 2006 (UTC)[reply]

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)[reply]

steam:// URI

I could add it meself, but I'm lazy...Takua108 02:15, 26 April 2006 (UTC)[reply]

Added as of 12 September 2006 -- Southen 17:49, 20 October 2006 (UTC)[reply]

require cleanup??

"To meet Wikipedia's quality standards, this article or section may require cleanup".

Clean the Notes column is enough??

I think we nedd information, other articles like URI does not offer information about schemas. Other sugestion is to split into a lot of schema articles. -- krauss 31/jul/2006.

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)[reply]

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)[reply]

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)[reply]

info-URI

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 dns://dnsauthority/dnsname?dnsquery).
"generic syntax" is ambiguous, and should be avoided when possible (e.g. http:, ftp:, etc).

Rjgodoy 01:24, 4 April 2007 (UTC)[reply]

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)[reply]

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>

— Preceding unsigned comment added by 80.202.179.68 (talk)

Good point (and well done too!). Rjgodoy 01:44, 7 August 2007 (UTC)[reply]

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.

More information.

24.80.185.126 (talk) 12:06, 3 September 2008 (UTC)[reply]

Picasa?

Doesn't Picasa use picasa: as a URI scheme? It isn't listed in the "unofficial" table, or in the template at the bottom of the article. B7T (talk) 15:28, 17 March 2009 (UTC)[reply]

URI not listed yet

1. reg syntax : reg:[regpath]

    ex : reg:HKEY_CURRENT_USER\Control Panel OR reg:HKCU\Control Panel

Logiphile (talk) 15:04, 22 March 2009 (UTC)[reply]

res

Outlook seems to embed images as res://ietag.dll/#34/#1001 - but that scheme isn't listed on this page? 80.177.58.134 (talk) 09:20, 5 May 2009 (UTC)[reply]

Percent-encoding and character set

The article misses to describe Percent-encoding and the allowed character set. What characters is an URI allowed to be build of at which parts? -- 195.37.139.208 (talk) 10:18, 18 June 2009 (UTC)[reply]

Split article

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 193.167.107.251 (talk) 22:01, 7 October 2009 (UTC)[reply]

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)[reply]

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)[reply]

RFC 3969?

This article refers to RFC 3969[1], but that RFC doesn't seem relevant. Perhaps RFC 3986[2] was intended? 149.65.130.57 (talk) 22:00, 3 February 2010 (UTC)[reply]

Correct 129.142.143.67 (talk) 11:20, 7 February 2010 (UTC)[reply]

'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>].

Marnix.klooster (talk) 08:39, 27 July 2010 (UTC)[reply]

market: scheme

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)[reply]

sms:

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 193.129.220.105 (talk) 19:14, 20 December 2010 (UTC)[reply]

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)[reply]

Inofficial Remote Access Schemes rdp: and vnc:

The inofficial schemes rdp: and vnc: seem to be used often, shouldn't they be included? — Preceding unsigned comment added by 93.82.35.167 (talk) 14:53, 29 October 2011 (UTC)[reply]

Unofficial URIs

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

Galzigler (talk) 23:06, 26 April 2012 (UTC)[reply]

I've recently saw another URI that isn't mentioned in this list:

resource://gre/modules/XPCOMUtils.jsm:357

Is anyone knows what's it purpose? It showed up when Flash stucked in FireFox.

Galzigler (talk) 22:19, 29 April 2012 (UTC)[reply]

I've seen a strange URI which appear in a few search results in Google of Wikipedia's articles. Here is an example: linkback://en.wikipedia.org/wiki/Leon_Uris Galzigler (talk) 06:16, 16 July 2012 (UTC)[reply]

Mailto example

The interpretation of the mailto example seems to be incorrect.

mailto:username@example.com?subject=Topic

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:fred@example.com> has a path of "fred@example.com", whereas
  the URI <foo://info.example.com?fred> has an empty path.

This is verifiable by passing that mailto URI through an RFC 3986 compliant parser. Unless there is disagreement, I will correct this. -- CYD (talk) 09:16, 9 May 2012 (UTC)[reply]

mailto is defined in RFC 6068. Please review that before making any changes. --Kvng (talk) 13:25, 11 May 2012 (UTC)[reply]

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.)

android.resource

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 [3]

pack, application, siteoforigin - WPF

From [4]

GNOME's computer:///

linkback - I couldn't find anything about it, so I didn't add it to the list.

Galzigler (talk) 00:47, 17 July 2012 (UTC)[reply]

URI Syntax Diagram

  foo://username:password@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:username@example.com?subject=Topic

I think it would be better to recreate it as an SVG diagram. I don't know SVG, so I can't make it myself. Galzigler (talk) —Preceding undated comment added 21:30, 20 November 2012 (UTC)[reply]

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)[reply]

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.

84.210.19.1 (talk) 11:32, 28 April 2013 (UTC)[reply]

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)[reply]

"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?

yoyo (talk) 02:58, 26 June 2014 (UTC)[reply]

List of schemes removed

I've just removed the gigantic table listing IANA-registered schemes and the smaller one of unofficial schemes. They were atrocious to look at, ruined the page's layout, and did little but awkwardly duplicate content on IANA's website in an inconsistent manner that's guaranteed to go out of date. In other words, they were cruft. This article was proposed for a merger with Uniform resource identifier, and for good reason, but it's never going to happen if that ghastly mess remains. If anyone is desperate to retain them, move them to List of URI schemes, don't put them back here. — Scott • talk 22:36, 23 August 2015 (UTC)[reply]