URLs, URIs, and URNs

Uniform Resource Locators (URL - rfc1738), also informally called "web addresses", are able to describe the name and location of a resource. A URL scheme, such as http, identifies the method used to access the resource. A URL host, such as www.boost.org, is used to identify where the resource is located. The interpretation of a URL might depend on scheme-specific requirements.

Table 1.1. Example: URLs

URL	Scheme	Host	Resource
`https://www.boost.org/index.html`	`https`	`www.boost.org`	`index.html`
`ftp://host.dom/etc/motd`	`ftp`	`host.dom`	`etc/motd`

Classical View

URLs are often compared to Uniform Resource Names (URN - rfc1738), a scheme whose primary purpose is labeling resources with location-independent identifiers. URNs, as other schemes, have their own syntax. The scheme urn: is reserved to URNs, which do not specify how to locate a resource:

Table 1.2. Example: URN

URN	Resource	Namespace	Identifier
`urn:isbn:045145052`	`isbn:045145052`	`isbn`	`045145052`

Uniform Resource Identifiers (URI - rfc3986) define a general scheme-independent syntax for references to abstract or physical resources. The initial URI specification (rfc2396) described them as either URLs and URNs (rfc2396 section 1.2). The current specifications (rfc3986) refer to this hierarchy as the Classical View (rfc3305, Section 2.1) of URI partitioning:

Table 1.3. URIs: Classical View

URI	Category
`https://www.boost.org`	URL
`mailto:person@example.com`	URL
`telnet://melvyl.ucop.edu/`	URL
`urn:isbn:0-486-27557-4`	URN

The following are examples of invalid URIs:

Table 1.4. Invalid URIs

Component	Example	Note
Protocol-Relative Link (PRL)	`www.boost.org` ^[a]	Missing scheme.
`URI-reference`	`index.html`	Missing scheme. Missing `urn:` scheme and requirements.
^[a] Formally, `www.boost.org` is either a `URI-reference` with path `www.boost.org` (rfc3986 Section 4.1) or a Protocol-Relative Link (PRL). It is not a `URI` according to rfc3986, although often described as such in some sources.

Contemporary View

The Classical View of URI partitioning, where a URI is either a URI or a URL, caused enough confusion to justify a specification about URI partitioning (rfc3305).

Common sources of confusion in the Classical View were:

Most possible URIs were also URLs.
URLs and Relative references are not required to locate a resource, while they are still not URNs.
Scheme-independent URLs and URIs have the same grammar. A single algorithm is used for parsing both.
URNs have scheme-specific requirements beyond the URI specification.

Thus, the URL/URN hierarchy became less relevant and the Contemporary View of URI partitioning (rfc3305, Section 2.2) is now that:

URLs don't refer to a formal partition of the URI space.
A scheme does not have to be classified into the discrete URL/URN categories.
The uri: scheme is one of many possible URI schemes.
All schemes can define subspaces and urn: namespaces are URN subspaces.
Any URI can be a locator, a name, or both.

In this view, the terms URLs and URIs have the same grammar and are used interchangeably in that regard.

Table 1.5. URLs (or URIs): Contemporary View

Example	Scheme	Host (Locator Component)	Path (Name Component)
`https://www.boost.org/index.html`	`https`	`www.boost.org`	`index.html`
`telnet://melvyl.ucop.edu/`	`telnet`	`melvyl.ucop.edu`
`mailto:person@example.com`	`mailto`		`person@example.com`
`urn:isbn:0-486-27557-4`	`urn`		`isbn:0-486-27557-4`

The Contemporary View has been endorsed by rfc3305 (Section 5), and has been in use in all other specifications since then, including the current URI grammar (rfc3986, Section 1.1.3).

Although URIs and URLs have the same grammar, it's often useful to standardize on one of these terms. Recent RFC documents standardize on the term URI rather than the most restrictive term URL. However, the term URL is almost omnipresent in any other contexts for being more specific, which provides more communication clarity.

This library also adheres to this Contemporary View of URI partitioning and standardizes on the term "URL".