Talk:URI scheme

message: I could add it meself, but I'm lazy...Takua108 02:15, 26 April 2006 (UTC)
replies: text: Added as of 12 September 2006 -- Southen 17:49, 20 October 2006 (UTC)
thread_title:  steam:// URI 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Splitting the Table 

message: 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)
thread_title:  Official IANA-registered schemes 

message: 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)
thread_title:  Use Backus–Naur formatting 

message: 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)
thread_title:  icyx://, rtpx://, htpx://, uvxx:// 

message: 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)
thread_title:  Picasa? 

message: 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)
thread_title:  URI not listed yet 

message: 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)
thread_title:  res 

message: 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)
thread_title:  Percent-encoding and character set 

message: 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)
thread_title:  Split article 

message: This article refers to RFC 3969, but that RFC doesn't seem relevant.  Perhaps RFC 3986 was intended?
149.65.130.57 (talk) 22:00, 3 February 2010 (UTC)
replies: text: Correct 129.142.143.67 (talk) 11:20, 7 February 2010 (UTC)
thread_title:  RFC 3969? 

message: 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)
thread_title:  'im' scheme: irrelevant RFCs, @-sign not optional 

message: 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)
thread_title:  market: scheme 

message: 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)
thread_title:  sms: 

message: 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)
thread_title:  chrome: and Google Chrome 

message: 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)
thread_title:  Inofficial Remote Access Schemes rdp: and vnc: 

message: 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)
replies: text: mailto is defined in RFC 6068. Please review that before making any changes. --Kvng (talk) 13:25, 11 May 2012 (UTC)
thread_title:  Mailto example 

message: 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 
* 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.
Galzigler (talk) 00:47, 17 July 2012 (UTC)
thread_title:  More UnOfficial URIs 

message: 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)
thread_title:  URI Syntax Diagram 

message: 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)
thread_title:  Passwords and other access info 

message: 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)
replies: text: 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)
thread_title:  Path delimiter inconsistency 

message: 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)
thread_title:  "Forward slash" (sic) 

message: 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)
thread_title:  List of schemes removed