A URI identifies a Resource, an abstraction for which there is a
conceptual mapping to a (possibly empty) set of representations.
The representations of a resource may vary as a function of
factors including time, place,
and the identity of the agent accessing the resource.
For example, at the time this document was drafted, the URI
Yahoo's weather forecast for Oaxaca, Mexico.
The representations of this resource depend on
(at least) time, the expressed preference of the user for Fahrenheit
or Celsius, and the identity of the user-agent software receiving the
Consistent Representations: There is a strong expectation of consistency between the representations of a resource; to the extent possible, representations SHOULD be equivalent.
There are strong social expectations that once a URI identifies a particular resource, it should continue indefinitely to refer to that resource. Persistence is always a matter of policy and commitment on the part of authorities assigning URIs rather than a constraint imposed by technological means.
Persistent URIs: Those who create and manage resources and their identifiers SHOULD design the identifiers in such a way as to ensure their persistence.
For example, each W3C technical report (e.g., "the SVG specification") is in fact a series of documents that represent the maturation of the technical report (Working Drafts, Candidate Recommendations, Proposed Recommendations, and a Recommendation). W3C assigns a URI to the "latest version" in the specification series (e.g., http://www.w3.org/TR/SVG). W3C also assigns a URI for each specification in the series (called the "this version URI", as in http://www.w3.org/TR/2001/PR-SVG-20010719/). W3C policy is that representations of the "latest version" resource will change over time (with each new publication of an SVG specification). W3C policy is also that representations of a specification designed by a "this version" URI will not change over time (to the best of W3C's ability to maintain its archives intact).
A primary characteristic of a URI is its scheme, which is given by
colon-delimited prefix. For example,
scheme is "http", and
ftp://ftp.example.com's is "ftp". It is
common to refer to URIs by scheme, calling the two preceding examples
respectively an "HTTP URI" and an "FTP URI".
Many of the properties of URIs are scheme-dependent.
New Schemes: Since correct processing of URIs is often scheme-dependent, and since a huge range of software is expected to be able to process URIs, the cost of introduction of new URI schemes is very high. The introduction of new URI schemes SHOULD be avoided.
Some URI schemes are used for identifying specific classes of resources. For example, TELNET URIs represent telnet services and MAILTO URIs electronic mailboxes.
The procedure for dereferencing a URI may vary from scheme to scheme. For example, HTTP URIs are dereferencable using the protocol of the same name, and the scheme is actually defined in section 3.2.2 of the HTTP specification [RFC 2616].
On the other hand, the URN scheme [RFC 2141] does not guarantee that a dereference procedure is defined for any given URN.
The deployment and use of URI different URI schemes may require varying degrees of central co-ordination and administration. For example, HTTP URIs depend (in practice at least) on the use of the DNS infrastructure. Also, there is a central registry of URN subclasses.
It is not in general possible to determine by inspection whether two different URIs refer to the same resource. Certain URI schemes, however, provide syntactic rules for determining equivalence in URIs, and these rules vary from scheme to scheme.
For example, URNs begin with two colon-delimited fields, the first of which
urn and the second identifies the subclass of URN, for
In URNs, these two fields are to be compared in a case-insensitive
The remainder of the URN following the second colon is subject to rules
dependent on the content of the second field (following the first colon) -
thus the equivalence rules may vary within subclasses of URNs.