This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Uniform Resource Identifier
Uniform Resource Identifier

Version management

Difference between version and

At line 1 added 75 lines
!!! 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-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop