!!! Overview
[{$pagename}] ([URI]) is a string of characters used to identify a name of a resource. 

Such identification enables interaction with representations of the resource over a network, typically the [World Wide Web], using specific [protocols]. 

Schemes specifying a concrete syntax and associated protocols define each [URI]. The most common form of [URI] is the [Uniform Resource Locator] ([URL]), frequently referred to informally as a web address. More rarely seen in usage is the [Uniform Resource Name] or ([URN]), which was designed to complement URLs by providing a mechanism for the identification of resources in particular namespaces.

!! Syntax
The [{$pagename}] syntax consists of a [{$pagename}] scheme name (such as "http", "ftp", "mailto", "crid" or "file") followed by a colon character, and then by a scheme-specific part. 

The specifications that govern the schemes determine the syntax and semantics of the scheme-specific part. 

However, URI syntax does require all schemes to adhere to a general syntax that (among other things) reserves certain characters for special purposes (without always identifying those purposes). 

The URI syntax also enforces restrictions on the scheme-specific part in order to (for example) provide for a degree of consistency when the part has a hierarchical structure.

Internet standard STD 66 (also [RFC 3986], [RFC 6874] and [RFC 7320]) defines the generic syntax to be used in all [URI Schemes]. 

Every [{$pagename}] is defined as consisting of several parts, as follows:
%%prettify 
{{{
                    hierarchical part
        ┌───────────────────┴─────────────────────┐
                    authority               path
        ┌───────────────┴───────────────┐┌───┴────┐
  abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
  └┬┘   └───────┬───────┘ └────┬────┘ └┬┘           └─────────┬─────────┘ └──┬──┘
scheme  user information     host     port                  query         fragment

  urn:example:mammal:monotreme:echidna
  └┬┘ └──────────────┬───────────────┘
scheme              path
}}} /%

A typical [{$pagename}] might look like:
%%prettify 
{{{
URI = <scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
}}} /%

For the particular case of the [HTTP] (and [HTTPS]) scheme, defined on [RFC 7230], the syntax becomes:
%%prettify 
{{{
http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ]
}}} /%! [{$pagename}] Components
* [URI Scheme]
* Hierarchical - The hierarchical part of the [URI] is intended to hold identification information hierarchical in nature. If this part begins with a double forward slash ("//"), it is followed by an authority part and a path. If the hierarchical part doesn't begin with ("//") it contains only a path.
* [URI Authorities]
* [URI Path]
* [URI Query]
* [URI Fragment Identifiers]

!! Alternatives to Specifying Structure in [URIs] (From [RFC 7320])
Given the issues described in [RFC 7320] Section 1, the most successful strategy for applications and extensions that wish to use [URIs] is to use them in the fashion they were designed: as links that are exchanged as part of the [protocol], rather than statically specified syntax.

Several existing specifications can aid in this.
* [RFC 5988] specifies relation types for [Web Linking].  By providing a framework for linking on the [Web], where every link has a relation type, context and target, it allows applications to define a link's semantics and connectivity.
* [RFC 6570] provides a standard syntax for [URI Templates] that can be used to dynamically insert application-specific variables into a [URI] to enable such [applications] while avoiding impinging upon [URI] owners' control of them.
* [RFC 5785] allows specific paths to be 'reserved' for standard use on [URI Schemes] that opt into that mechanism ('[http|HTTP]' and '[https|HTTPS]' by default).  Note, however, that this is not a general "escape valve" for applications that need structured [URIs]; see that specification for more information.

Specifying more elaborate structures in an attempt to avoid collisions is not an acceptable solution, and does not address the issues in [RFC 7320] Section 1.  For example, prefixing query parameters with "myapp_" does not help, because the prefix itself is subject to the risk of collision (since it is not "reserved").

!! [URIs, URLs, and URNs]
What is the difference between [URIs, URLs, and URNs]?

!! [{$pagename}] [URI] Opacity ([Best Practices])
In general, [URIs] [SHOULD NOT] attempt to infer properties of the referenced resource or include [metadata].[1]

On the other hand, the [URI] "mailto:joe@example.com" indicates that the URI refers to a mailbox. The "mailto" [URI Scheme] specification authorizes agents to infer that [URIs] of this form identify Internet mailboxes.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Should metadata (e.g., versioning information) be encoded in URIs?|https://www.w3.org/2001/tag/issues.html#metadataInURI-31|target='_blank'] - based on information obtained 2018-01-24-