<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <title>Architectural Principles of the World Wide Web</title>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/base" />
  <link rel="stylesheet" type="text/css" href="style/default.css" />
  <meta name="generator" content="amaya 5.3, see http://www.w3.org/Amaya/" />
</head>

<body>
<p><a href="http://www.w3.org/"><img height="48" width="72" alt="W3C"
src="http://www.w3.org/Icons/w3c_home" /></a></p>

<h1>DRAFT: Architectural Principles of the World Wide Web</h1>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/2001/tag/2002/0826-archdoc">http://www.w3.org/2001/tag/2002/0826-archdoc</a></dd>
  <dt>Superseded by:</dt>
    <dd><a
      href="http://www.w3.org/2001/tag/2002/0828-archdoc">http://www.w3.org/2001/tag/2002/0828-archdoc</a>
    </dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/2001/tag/2002/0813-archdoc">http://www.w3.org/2001/tag/2002/0813-archdoc</a></dd>
  <dt>Editor:</dt>
    <dd>Ian Jacobs, W3C</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
© 2002 <a href="http://www.w3.org/">W3C</a> <sup>®</sup> (<a
href="http://www.lcs.mit.edu/">MIT</a>, <a
href="http://www.inria.fr/">INRIA</a>, <a
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
<a
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
use</a>, and <a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
licensing</a> rules apply.</p>
<hr />

<h2 class="notoc">Abstract</h2>

<p>The World Wide Web is a networked information system. Web
Architecture is the set of principles that all agents in the system
follow that result in the large-scale effect of a shared information
space. Identification, data formats, and protocols are the main
technical components of Web Architecture, but the large-scale effect
depends on social behavior as well.</p>

<p>This document strives to establish a reference set of principles
for Web architecture. Some of these principles may conflict with
current practice, and so education and outreach will be required to
improve on that practice. Other principles may fill in gaps in
published specifications or may call attention to known weaknesses in
those specifications.</p>

<h2 class="notoc">Status of this document</h2>

<p><strong>This document has been superseded</strong>. See <a
href="0828-archdoc">next version</a>.</p>

<p>This document has been developed for discussion by the W3C <a
href="http://www.w3.org/2001/tag/">Technical Architecture Group</a>.</p>

<p>This draft is highly unstable. This draft represents substantial input
from TAG participants, but does not yet represent consensus. It is a draft
with no official standing. Once this document has undergone substantial
revision, the TAG expects to develop it on the W3C Recommendation track.</p>

<p>Please send comments on this document to the public W3C TAG mailing list
<a href="mailto:www-tag@w3.org">www-tag@w3.org</a> (<a
href="http://lists.w3.org/Archives/Public/www-tag/">archive</a>).</p>

<p>Publication of this document by W3C indicates no endorsement by W3C.</p>

<h2 class="notoc"><a id="contents" name="contents">Table of Contents</a></h2>
<!-- Insert generated TOC here using addtoc.xsl -->

<h2><a id="intro" name="intro">Introduction</a></h2>

<p>The World Wide Web ("Web" from here on) is a networked information system
consisting of <span id="glossary-agents" title="Agents" class="glossary-entry">agents</span>
(<span id="desc-glossary-agents" class="glossary-desc">programs acting on behalf of another person, entity, or process</span>) that
exchange information. <span class="open">Open:</span> Web Architecture is the
set of principles that all agents in the system follow that result in the
large-scale effect of a shared information space that scales well and behaves
predictably.</p>

<p>This architecture consists of:</p>
<ol>
  <li><strong>Identifiers</strong>. A single specification of the way in
    which objects in the system are identified: the Uniform Resource
    Identifier (<acronym>URI</acronym>) [<a href="#RFC2396">RFC2396</a>].</li>
  <li><strong>Formats</strong>. Specifications of a nonexclusive set of data
    formats designed for interchange between agents in the system. This
    includes several formats used in isolation or in combinations (e.g.,
    XHTML, CSS, PNG, XLink, RDF, SMIL animation), as well as technologies for
    designing new formats (XML, XML namespaces).</li>
  <li><strong>Protocols</strong>. Specifications of a small and nonexclusive
    set of protocols for interchanging information between agents, including
    HTTP [<a href="#RFC2616">RFC2616</a>], SMTP and others. Several of these
    protocols share a reliance on the <span title="Internet Media
Type" class="glossary-entry" id="glossary-mime">Internet Media Type</span> (or, "MIME")
    <span class="glossary-desc" id="desc-glossary-mime">metadata/packaging system [<a href="#RFC2046">RFC2046</a>].</span></li>
</ol>

<h3><a name="doc-structure" id="doc-structure">Structure and
conventions of this document</a></h3>

<p>After this introduction, chapters two, three, and four discuss
identifiers, formats, and protocols, respectively. Each of those
chapters includes principles of Web architecture. Each principle
has a title and is highlighted visually in a shaded box. The last
section of the introduction lists all of the principles.</p>

<p>The terms MUST, SHOULD, MAY, etc. are used in accordance with RFC 2119 [<a
href="#RFC2119">RFC2119</a>].</p>

<p>Open issues or questions are highlighted.</p>

<h3><a name="doc-audience" id="doc-audience">Audience of this document</a></h3>

<p>The intended audience for this document includes:</p>

<ol>
<li>Participants in W3C groups</li>
<li>Groups outside of W3C devloping technologies to be integrated
into the Web</li>
</ol>

<p>The authors have made every effort to keep this document terse,
with the expectation that additional documents will elaborate on the
principles below.</p>

<h3><a name="doc-limits" id="doc-limits">Limits of this document</a></h3>

<p>This document focuses on architectural principles specific to or
fundamental to the Web. It does not address general principles of
design, which are also important to the success of the Web. Indeed,
behind many of the principles of Web Architecture lie these and other
principles: minimal constraint (fewer rules makes the system more
flexible), modularity, minimum redundancy, extensibility, simplicity,
robustness, etc.</p>

<p>This document does not address architectural design goals covered by
targeted W3C specifications:</p>
<ol>
  <li>Internationalization; see W3C's <a
    href="http://www.w3.org/International/">Internationalization
  Activity</a>.</li>
  <li>Accessibility; see W3C's <a href="http://www.w3.org/WAI/">Web
    Accessibility Initiative</a>.</li>
  <li>Device independence; see W3C's <a
    href="http://www.w3.org/2001/di/">Device Independence Activity</a>.</li>
</ol>

<h2><a name="identifiers" id="identifiers">Identifiers and resources</a></h2>

<p>The Web is a universe of resources. <span
class="glossary-entry" id="glossary-resource"
title="Resource">Resources</span> are <span class="glossary-desc" id="desc-glossary-resource">a
generalization over documents, files, menu items, machines, and services, as
well as people, organizations, concepts, etc.</span> Web architecture starts with a
uniform syntax for resource identifiers, so that we can refer to resources,
access them, describe them, share them, etc. The syntax employs an extensible
set of <a href="#URI-scheme">URI schemes</a>. Several URI schemes incorporate
established identification mechanisms (that pre-date the Web) into this
syntax:</p>
<ul>
  <li><code>mailto:nobody@example.org</code>. The MAILTO scheme is for
    mailbox names (including DNS domain names).</li>
  <li><code>ftp://example.org/aDirectory/aFile</code>. The FTP scheme is for
    ftp file names (including DNS domain names).</li>
  <li><code>news:comp.infosystems.www</code>. The NEWS scheme is for
    newsgroup names<code>.</code></li>
  <li><code>tel:+1-816-555-1212</code>. The TEL scheme is for telephone
    numbers.</li>
  <li><code>urn:uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882</code>. For UUIDs,
    from Apollo/DCE/COM</li>
</ul>

<p>Other URI schemes have been introduced since the advent of the Web,
including those introduced as a consequence of new protocols:</p>
<ul>
  <li><code>http://www.example.org/something?with=arg1;and=arg2</code>. For
    HTTP resources.</li>
  <li><code>ldap://ldap.itd.umich.edu/c=GB?objectClass?one</code>. For LDAP
    resources.</li>
  <li><code>urn:oasis:SAML:1.0</code>. A namespace from an Oasis
    specification.</li>
</ul>

<p>Identifiers in any of these schemes can be composed with a fragment
identifier to yield an identifier for a resource that is a part of, or a view
of, another resource:</p>
<ul>
  <li><code>ftp://example.org/aDirectory/aDocument#section1</code></li>
  <li><code>http://www.example.org/aList#item1</code></li>
  <li><code>http://www.example.org/states#texas</code></li>
</ul>

<p>Note that while this composition is syntactically fully general, many
cases such as <code>mailto:nobody@example.org#abc</code> do not make much
sense to any deployed software or specifications.</p>

<p>To summarize, a <span class="glossary-entry" id="glossary-uri"
title="Uniform Resource Identifier (URI)">Uniform Resource Identifier</span>, or
URI, is <span class="glossary-desc" id="desc-glossary-uri">a character sequence starting with a scheme name,
followed by a number of scheme-specific fields.</span> An 
<span class="glossary-entry" title="Absolute URI Reference" id="glossary-abs-uri-ref">absolute URI
reference</span> is <span class="glossary-desc" id="desc-glossary-abs-uri-ref">a URI followed optionally by a <a
href="#fragid">fragment identifier</a></span> (see [<a
href="#RFC2396">RFC2396</a>] for the complete list of syntactic
constraints).  URIs and absolute URI references identify Web
resources. The principles in this document are expressed in terms of
absolute URI references.</p>

<p><span class="open">Open</span>: While people agree that URIs identify
resources (per RFC 2396 [<a href="#RFC2396">RFC2396</a>]), there is not yet
consensus that absolute URI references with fragment identifies may be used
to identify resources. Some people contend that an absolute URI reference
with a fragment identifier identifies a portion of a representation.</p>

<p>Note: The current URI specification, RFC 2396 [<a
href="#RFC2396">RFC2396</a>], also includes the concept of the
"relative URI reference."  The syntax for a relative URI reference is
a shortened form of that for absolute URI reference, where some prefix
of the URI is missing and certain path components ("." and "..") have
a special meaning when, and only when, interpreting a relative path.
For example, in a document whose base URI is
<code>http://example/dir1/dir2/file1</code>, the relative URI
reference <code>../file2</code> abbreviates
<code>http://example/dir1/file2</code> and the relative URI reference
<code>#abc</code> abbreviates
<code>http://example/dir1/dir2/file1#abc</code>.</p>

<h3><a name="resources-uris" id="resources-uris">Resources, URIs, and the
shared information space</a></h3>

<p><span class="glossary-desc" id="desc-glossary-link">When one
resource refers to another via an absolute URI reference, a <span
class="glossary-entry" id="glossary-link" title="Link">link</span> is
formed.</span> When many resources are linked this way, the
large-scale effect is a shared information space, addressable by an
absolute URI reference. The Web is more valuable for every resource in
the space, and in turn, resources are more valuable when they are
addressable in the Web. Hence:</p>

<p class="principle"><a name="pr-use-uri" id="pr-use-uri">Use URIs:</a> All
important resources SHOULD be identified by an absolute URI reference.<span
class="note" id="note-use-uris">This principle dates back at least as far as
Douglas Engelbart's seminal work on open hypertext systems; see section <a
href="http://www.bootstrap.org/augment/AUGMENT/132082.html#11K">Every Object
Addressable</a> in [<a href="#Eng90">Eng90</a>].</span></p>

<p>The impact of making resources addressable with absolute URI references
varies from linking and bookmarking to unintended consequences, such as
global search services. See the TAG finding <a
href="http://www.w3.org/2001/tag/doc/get7">URIs, Addressability, and the use
of HTTP GET</a> for some details about the interaction of this principle in
HTTP application design.</p>

<p>Some resources do not have URIs. URIs are denumerable, which means
there are enough to give one to every real number without collisions,
for example.</p>

<p><span class="open">Open</span> Say something here à la what Tim Bray said:
"Designers SHOULD NOT build a world of resources that cannot be identified by
URI."?</p>

<h3><a name="uri-operations" id="uri-operations">Operations on URIs</a></h3>

<p>The two primary operations on absolute URI references are:</p>
<ol>
  <li>Interaction with resources.</li>
  <li>Comparison (e.g., of XML namespace identifiers [<a
    href="#XMLNS">XMLNS</a>] for <a
  href="#URI-equivalence">equivalence</a>).</li>
</ol>

<p>There may be applications where comparison is expected the sole or
primary operation on an absolute URI reference. In such cases, it does not
matter whether one has chosen a URI or an absolute URI reference to identify
a resource.</p>

<p>When one expects to interact with a resource, there are some advantages to
identifying that resource with a URI rather than an absolute URI reference:
only URIs work with intermediaries in the Web architecture (e.g., proxies) or
with redirection (in HTTP, for example).</p>

<p>Note: Even if an absolute URI reference with a fragment identifier is used
to refer to a resource, one may refer to a portion of that resource with a
<em>different</em> absolute URI reference.</p>

<h4>Interactions with resources</h4>

<p><span id="desc-glossary-deref" class="glossary-desc">To <span id="glossary-deref" title="Dereference" class="glossary-entry">dereference</span> an absolute URI reference is to use it to
interact with the resource it identifies.</span> One interacts with a resource
through <em>representations</em> of the resource. A resource is an
abstraction for which there is a conceptual mapping to a (possibly empty) set
of representations. A representation may be full fidelity, i.e. a complete
description, or it may be partial, i.e. describes some aspect of the
resource. The interpretation of any such representation is determined by its
Media type.</p>

<p>For instance, suppose the URI
<code>http://weather.yahoo.com/forecast/MXOA0069</code> identifies a resource
that is "the weather forecast for Oaxaca, Mexico". A representation retrieved
by means of that URI may be encoded in any number of formats, including HTML,
XHTML, SVG, etc.; see <a href="#formats">chapter 2</a> for more information
about formats.</p>

<p>Interaction with a resource is governed by recursive application of a
finite set of specifications, beginning with the specification that governs
the <a href="#URI-scheme">scheme of the URI</a>. For example, suppose the
absolute URI reference <code>http://www.example.org/test/foo.svg</code> is
used within an <code>a</code> element of an SVG document. The sequence of
specifications applied is:</p>
<ol>
  <li>The URI specification [<a href="#RFC2396">RFC2396</a>]. This
    specification says (in section 3.1) that the scheme "define the semantics
    for the remainder of the URI string." In this case, the URI scheme is
    HTTP.</li>
  <li>The HTTP/1.1 protocol. Section 3.2.2 of RFC2616 [<a
    href="#RFC2616">RFC2616</a>] explains the semantics of HTTP URIs.</li>
  <li>The SVG 1.0 Recommendation [<a href="#SVG10">SVG10</a>], which imports
    the link semantics defined by XLink 1.0 [<a href="#XLink10">XLink10</a>].
    Section 17.4 of the SVG specification suggests that interaction with an
    <code>a</code> link involves retrieving a representation a resource,
    identified by the XLink <code>href</code> attribute: "By activating these
    links (by clicking with the mouse, through keyboard input, voice
    commands, etc.), users may visit these resources." This means that the
    GET method defined in HTTP/1.1 is used to retrieve the representation of
    the resource.</li>
  <li>Once the representation has been retrieved, the Media type of the
    representation (here, SVG 1.0) governs its interpretation (here,
    rendering).</li>
</ol>

<p>Each valid use of an absolute URI reference unambiguously identifies
<strong>one</strong> resource.</p>

<p class="principle"><a name="pr-valid-use" id="pr-valid-use">Valid use
of an absolute URI reference:</a> If you are using a registered <a
href="#URI-scheme">URI scheme</a> and following all the other relevant
protocol specifications, it is unambiguous what resource you are referring
to.</p>

<p>There may be several ways to interact with a resource. One of the most
important operations for the Web is to <dfn><a>retrieve a
representation</a></dfn> of a resource (such as with HTTP GET). There are
other ways to interact with a resource (such as with HTTP POST).</p>

<p class="principle"><a name="pr-allow-deref" id="pr-allow-deref">Allow
dereference:</a> Agents SHOULD be able to dereference absolute URI references
for important resources.</p>

<p class="principle"><a name="pr-describe-resource"
id="pr-describe-resource">Describe resources:</a> Owners of resources that
are important abstract concepts (for example, Internet protocol parameters)
SHOULD make available human and/or machine readable representations that
describe the nature and purpose of those resources.</p>

<p class="principle"><a name="pr-deref-safe" id="pr-deref-safe">Representation
retrieval is safe:</a> Agents do not incur obligations by retrieving a
representation (e.g., by following a link). [TAG finding "<a
href="http://www.w3.org/2001/tag/doc/get7">URIs, Addressability, and the use
of HTTP GET"</a>]</p>

<p><span class="open">Open</span> Need to say something about difference
between assertions about a resource and assertions about a representation.</p>

<h4>Consistent representations</h4>

<p>The representations of a resource may vary as a function of factors
including time, the identity of the agent accessing the resource, data
submitted to the resource when interacting with it, and changes external to
the resource (e.g., the weather). For example, for the resource "the weather
forecast for Oaxaca, Mexico," the representations 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 representation.</p>

<p class="principle"><a name="pr-consistent-rep"
id="pr-consistent-rep">Consistent representations:</a> There is a strong
expectation of consistency between the representations of a resource; to the
extent possible, representations SHOULD be equivalent.</p>

<p><span class="open">Open</span> Need to clarify what "equivalent" means in
the previous sentence.</p>

<h3><a name="uri-generalities" id="uri-generalities">Some generalities about
absolute URI references</a></h3>

<p>The following statements are useful generalities about some absolute URI
references. Some of these generalities do not hold for some <a
href="#URI-scheme">URI schemes</a>.</p>
<ol>
  <li>The authority over an absolute URI reference determines which resource
    it identifies.</li>
  <li>It is not generally possible to inspect an absolute URI reference and
    determine what resource it identifies. For example, in general, one
    cannot look at <code>http://www.example.com/lj45sr</code> and know that
    it refers to "my old car" or "the weather forecast for Oaxaca, Mexico."
    Note that over time, we trust that some absolute URI references will
    identify familiar resources. That trust derives from social behavior, not
    the spelling of the identifier.</li>
  <li>In general, several absolute URI references may identify the same
    resource.</li>
  <li>It is not generally possible to inspect two absolute URI references and
    determine that they identify the same resource. This does not prevent
    some URI schemes from mandating equivalence for particular sets of URIs
    using that scheme.</li>
  <li>It is possible to compare two absolute URI references to see whether
    they are <em>spelled</em> equivalently; see the section on <a
    href="#URI-equivalence">URI equivalence and comparison</a> for more
    details.</li>
</ol>

<h4>Absolute URI references and context-sensitivity</h4>

<p>Each valid use of an absolute URI reference identifies one resource, but
the resource itself may be inherently context-sensitive. For instance,
<code>http://www.example.com/</code> identifies the same resource in any
context. On the other hand, <code>http://localhost/</code> and
<code>file:/etc/hosts</code> each identify one resource, but that resource is
"local" to a particular computer. It is valid to use a URI such as
<code>file:/etc/hosts</code> on a given computer, and even on several
computers, if you are confident that all of those computers are running the
same type of operating system.</p>

<p class="principle"><a name="pr-context-ins"
id="pr-context-ins">Context-insensitive absolute URI references:</a> An
absolute URI reference SHOULD denote the same resource or concept independent
of the context(s) in which the identifier is used.</p>

<h3><a name="uri-characteristics" id="uri-characteristics">Characteristics of
absolute URI references</a></h3>

<h4>Persistence</h4>

<p>Note the difference between changes in representations of a resource and
changes in the binding between an absolute URI reference and a resource.
Today, the absolute URI reference <code>http://www.w3.org/</code> identifies
the resource "the W3C home page." A representation retrieved today for that
absolute URI reference is likely to differ from one you get tomorrow, since
W3C updates its home page frequently with news items. These changes in
representation are predictable, and the resource remains "the W3C home
page".</p>

<p>On the other hand, if tomorrow, the same absolute URI reference identified
a different resource (for example, because the domain was sold and the new
owner decided to assert a different URI-Resource relationship), the
identifier would lose value. This type of indiscriminate use of identifiers
undermines their value and interferes with people who relied on them (e.g.,
historians, court archives, new archive services, and anybody frustrated by a
broken link).</p>

<p>There are strong social expectations that once an absolute URI
reference identifies a particular resource, it should continue indefinitely to
refer to that resource. <span class="glossary-entry"
title="Persistence" id="glossary-persistence">Persistence</span> is always a matter of policy and
commitment on the part of authorities assigning URIs rather than a constraint
imposed by technological means.</p>

<p class="principle"><a name="pr-persistent-uri"
id="pr-persistent-uri">Persistent absolute URI references:</a> Those who
create and manage resources and their identifiers SHOULD design the
identifiers in such a way as to ensure their persistence.</p>

<p>For example, each W3C technical report (e.g., "the SVG specification") is
in fact a series of documents that reflects the maturation of the technical
report (Working Drafts, Candidate Recommendations, Proposed Recommendations,
and a Recommendation). W3C assigns an absolute URI reference to the "latest
version" in the specification series (e.g., http://www.w3.org/TR/SVG). W3C
also assigns an absolute URI reference 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" identifier
will not change over time (to the best of W3C's ability to maintain its
archives intact).</p>

<p>For more discussion about persistence, refer to "Cool URI's don't change"
[<a href="#Cool">Cool</a>].<span class="note" id="note-cool-uri-title">The
title is somewhat misleading. It's not the URIs that change, it's what they
identify.</span></p>

<h4><a name="URI-scheme" id="URI-scheme">URI Schemes</a></h4>

<p>One important characteristic of a <span class="glossary-entry"
title="URI Scheme" id="glossary-uri-scheme">URI</span> is its <b>scheme</b> (the string
that precedes ":" in a URI). For example the scheme of the URI
<code>http://www.example.com/</code> is "http", and for
<code>ftp://ftp.example.com/</code> it is "ftp". It is common to classify
URIs by scheme, calling the two preceding examples respectively an "HTTP URI"
and an "FTP URI".</p>

<p>Many of the properties of URIs are scheme-dependent.</p>

<p class="principle"><a name="pr-new-scheme-expensive"
id="pr-new-scheme-expensive">New URI schemes expensive:</a> 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. Authors of specifications SHOULD avoid
introducing new URI schemes when existing schemes can be used to meet the
same goal..</p>

<p>While "myscheme:blort" is a URI that satisfies the syntactic
constraints of [<a href="#RFC2396">RFC2396</a>], if "myscheme" is not
registered, you don't have license to use that URI in any Internet
protocols; there aren't any valid uses of it. You can't expect anybody
to know what you mean by it, and you aren't guaranteed that somebody
else isn't already using it for something else.</p>

<p class="principle"><a name="public-use-scheme"
id="public-use-scheme">Public use of unregistered schemes:</a> People
MUST NOT use an unregistered URI scheme on the public Internet.</p>

<p>The IANA registry [<a href="#IANASchemes">IANASchemes</a>] lists URI
schemes and the specifications that define them. For instance, the HTTP URI
scheme is defined in section 3.2.2 of the HTTP specification [<a
href="#RFC2616">RFC2616</a>]. Refer to <a href="#RFC2717">RFC2717</a> for
information about registering a new URI scheme.</p>

<h5>Scheme-specific Resource Classes</h5>

<p>Some URI schemes are used for identifying specific classes of resources.
For example, TELNET URIs identify telnet services and MAILTO URIs electronic
mailboxes.</p>

<p><span class="open">Open</span>:<a
href="http://www.w3.org/2001/tag/ilist#httpRange-14">issue httpRange-14</a> :
What is the range of the HTTP dereference function? Two views held within the
TAG are that the range is (1) anything or (2) documents, used in a very broad
sense (see Tim Berners-Lee's "<a
href="http://www.w3.org/DesignIssues/HTTP-URI">What do HTTP URIs
identify?</a>").</p>

<h5><a name="dereference" id="dereference">Dereference
mechanisms</a></h5>

<p>The procedure for retrieving a representation may vary from scheme to
scheme. For example, HTTP URIs are dereferencable using the protocol of the
same name, and the dereferencing procedure is defined in section 3.2.2 of the
HTTP specification [<a href="#RFC2616">RFC2616</a>].</p>

<p>On the other hand, the URN scheme [<a
href="#RFC2141">RFC 2141</a>] does not guarantee that
a dereference procedure is defined for any given URN.</p>

<p><span class="open">Open</span>: "Since HTTP GET is defined and widely
deployed, agents SHOULD use HTTP URIs.</p>

<p><span class="open">Open</span>: <a
href="http://www.w3.org/2001/tag/ilist#deepLinking-25">issue
deepLinking-25</a>: What to say in defense of principle that deep linking is
not an illegal act?</p>

<h5>Social Governance</h5>

<p>The deployment and use of different URI schemes may require varying
degrees of central coordination 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.</p>

<h5><a name="URI-equivalence" id="URI-equivalence">Equivalence and
Comparison</a></h5>

<p>Certain URI schemes provide rules for determining the syntactic
equivalence of absolute URI references, i.e., whether two absolute URI
references are different spellings of the same identifier. These rules vary
from scheme to scheme.</p>

<p>For example, URNs begin with two colon-delimited fields, the first of
which must be <code>urn</code> and the second identifies the subclass of URN,
for example <code>urn:ietf:example</code>. In URNs, these two fields are to
be compared in a case-insensitive fashion. 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.</p>

<p>Section 3.2.3 of the HTTP specification [<a href="#RFC2616">RFC2616</a>]
states that, when comparing two HTTP URIs, the host name part must be
considered case-insensitive, so <code>http://WWW.EXAMPLE/</code> and
<code>http://www.example/</code> identify the same resource.</p>

<p class="principle"><a name="pr-uri-case" id="pr-uri-case">URI case
sensitivity:</a> People SHOULD NOT assume that two URIs that differ only in
case can be used interchangeably.</p>

<p><strong>Note</strong>: Equivalence of URIs is not the same as equivalence
of representations of a resource.</p>

<p><span class="open">Open</span>: <a
href="http://www.w3.org/2001/tag/ilist#URIEquivalence-15">issue
URIEquivalence-15</a>: When are two URI variants considered equivalent?</p>

<h3><a name="fragid" id="fragid">Fragment identifiers</a></h3>

<p>In some URI schemes, absolute URI references may end with a fragment
identifier. The fragment identifier is interpreted only
<strong>after</strong> the retrieval of a representation. Section 4.1 of [<a
href="#RFC2396">RFC2396</a>] states that "the format and interpretation of
fragment identifiers is dependent on the media type [RFC2046] of the
retrieval result," that is, the representation.</p>

<p>For instance, if the representation is an HTML document, the fragment
identifies a hypertext anchor. In the case of a graphics format, a
URI reference might identify a circle or spline. In the case of RDF, a a URI
reference can identify <em>anything</em>, be it abstract (e.g., a dream) or
concrete (e.g., my car). The media type 'text/plain' does not define
semantics for fragment identifiers.</p>

<h4>Design weakness: HTTP content negotiation and fragment identifiers</h4>

<p class="principle"><a name="pr-coneg-frag"
id="pr-coneg-frag">Content
negotiation and fragments:</a> Authors SHOULD NOT use HTTP content negotiation for different
media types that do not share the same fragment identifier semantics.</p>

<p><span class="open">Open</span>: New access protocols should provide a
means to convert fragment identifiers according to media type.</p>

<h2><a id="formats" name="formats">Formats</a></h2>

<h3><a name="scope" id="scope">Scope</a></h3>

<p>What is a format, and how does it relate to the concept of a document. Do
all documents have a format? Is a document a collection of resources of
different formats organized into a whole? Is a document the same as a
resource? the same as a message body? as a non-multipart message body? What
is the distinction between documents and data, if any. Does 'document' imply
human readable and if so, does it imply presentation? Does it imply a
hierarchically structured, report-like document with headings and
subheadings? Is a catalog a document? Is a rave flyer a document?</p>

<p>Negotiation (stuff above might go here also) by network request, by listed
alternatives in content any preference? Resource variants, foo.css and
foo.html unlikely to be equivalent.</p>

<h3><a name="mvc" id="mvc">Model View Controller</a></h3>

<p>Separation allows more easily composable specifications, allows multimodal
access, clarifies the concept of multiple, synchronous views of a document,
and enhances accessibility.</p>

<h3><a name="model" id="model">The model - document formats</a></h3>

<p>Composability (ns-meaning). Use of XML for tree structured content.
Linking in general v. idref in one document. Human readable v. machine data.
Served or not (hidden behind server - semantic firewall, accessibility.
Linking into parts of the model, transclusion of parts. Compound documents,
components from multiple servers - scalability, deep linking. Processing
models, error handling.</p>

<h3><a name="view" id="view">The view - presentation</a></h3>

<p>Presentation by decoration (application of CSS to XML as presentation),
and by derivation (creation of html/svg/etc as presentation). Linking between
view and model. Inheritance of properties across namespaces. Consistency of
property names. Subsets. 'Applies to' as opposed to 'set on'. Specificity of
properties as attributes, chaining styling, restyling. Time-lines, linking to
portions of a time-line.</p>

<h3><a name="controller" id="controller">The controller - animation,
scripting, events, client/server interaction</a></h3>

<p>Declarative v. script based - accessibility, power; formalization of
common functionality (loop animation, rollovers) in declarative form. DOM -
making additional methods, add to rather than replacing XML DOM. Effect of
script/programming language limitations on choice of element and attribute
names. Linking to active components - XForms example with model and abstract
form control, can be extended to presentational instantiation of form
control.</p>

<p>Ideas and issues:</p>
<ol>
  <li>For new format specifications, use XML family of specifications unless
    there's a good reason not to. <span class="open">Open: Which XML
    specifications?</span> <span class="open">Open: which particular family
    members?</span></li>
  <li>Format designers should use URIs without constraining content providers
    to particular URI schemes. <span class="open">Open: what does "use"
    mean?</span> IDREF v. linking - web-wide rather than document-wide
    references.</li>
  <li>Namespaces. Issues <a
    href="http://www.w3.org/2001/tag/ilist#namespaceDocument-8">namespaceDocument-8</a>,
    <a
    href="http://www.w3.org/2001/tag/ilist#mixedNamespaceMeaning-13">mixedNamespaceMeaning-13</a></li>
  <li>Qnames: Issues <a
    href="http://www.w3.org/2001/tag/ilist">rdfmsQnameUriMapping-6</a>, <a
    href="http://www.w3.org/2001/tag/ilist#qnameAsId-18">qnameAsId-18</a> and
    finding "<a href="http://www.w3.org/2001/tag/doc/qnameids.html">Using
    QNames as Identifiers in Content</a>"</li>
  <li>Formatting properties: Issue <a
    href="http://www.w3.org/2001/tag/ilist#formattingProperties-19">formattingProperties-19</a></li>
  <li>Error handling: Issue <a
    href="http://www.w3.org/2001/tag/ilist#errorHandling-20">errorHandling-20</a></li>
  <li>Media type registration: <a
    href="http://www.w3.org/2001/tag/ilist#RFC3023Charset-21">RFC3023Charset-21</a>,
    finding <a href="http://www.w3.org/2001/tag/2002/0129-mime">Internet
    Media Type registration, consistency of use</a>. Also, makes sure to
    define fragment identifier semantics.</li>
  <li>Effect of Mobile on architecture - size, complexity, memory
    constraints. Binary infosets, storage efficiency. Composable subsets.</li>
  <li>What is the scope of using XLink? <a
    href="http://www.w3.org/2001/tag/ilist#xlinkScope-23">xlinkScope-23</a></li>
  <li>Can a specification include rules for overriding HTTP content type
    parameters? <a
    href="http://www.w3.org/2001/tag/ilist#contentTypeOverride-24">contentTypeOverride-24</a></li>
</ol>

<h2><a name="protocols" id="protocols">Protocols</a></h2>

<p>As mentioned in the introduction, the Web is designed to create the
large-scale effect of a shared information space that scales well and behaves
predictably. The architectural style known as Representational State Transfer
[<a href="#REST">REST</a>] encapsulates this notion of a shared information
space. According to Fielding:</p>

<blockquote>
  <p>REST provides a set of architectural constraints that, when applied as a
  whole, emphasizes scalability of component interactions, generality of
  interfaces, independent deployment of components, and intermediary
  components to reduce interaction latency, enforce security, and encapsulate
  legacy systems.<br />
  -- Roy Fielding, Section 5.5 of [<a href="#REST">REST]</a></p>
</blockquote>

<p>HTTP has been specially designed for REST interactions. HTTP has a variety
of methods designed to manipulate resource state through representation
transfer between agents. These methods include GET (covered in <a
href="#dereference">section 1.2</a>), POST, PUT, and DELETE.</p>

<p>This chapter uses the REST model to explain how Web protocols take into
account the properties of resources and URIs, as well as real-world time and
space constraints, in order to improve the user's Web experience.</p>

<p>Ideas and issues:</p>
<ol>
  <li>Consistency of media types and message contents (from "<a
    href="http://www.w3.org/2001/tag/2002/0129-mime">TAG Finding: Internet
    Media Type registration, consistency of use</a>"</li>
  <li>Consistency of communicating character encoding (same source).</li>
  <li>HTTP as a substrate protocol [<a
    href="http://www.w3.org/2001/tag/ilist#HTTPSubstrate-16">TAG issue
    HTTPSubstrate-16</a>]</li>
</ol>

<h2 class="appendix"><a name="uri-tips" id="uri-tips">Tips on URIs</a></h2>

<h3><a name="uri-spelling" id="uri-spelling">Spelling of URIs</a></h3>

<p>Do not make assumptions about a resource based on the spelling of a URI
that refers to it (other than what is defined in specifications for the URI
scheme). Since URIs are opaque, it is an error to assume, for example, that a
URI that happens to end with the string ".html" refers to a resource that has
an HTML representation. Though people must not infer anything about the
nature of a resource representation from a URI ending in ".html", resource
owners must not create confusion by purposely mis-assigning suffixes and
representation types.</p>

<p>At times it is useful or necessary to reveal a URI (e.g., in an
advertisement on the side of a bus), in which case, good social behavior
requires that the URI be easy to use. In general, URIs should be hidden from
view as they tend to lure us into thinking they hold definitive meaning about
a resource.</p>

<p><span class="open">Open: Canonical form of URIs. See</span><a
href="http://www.w3.org/2001/tag/ilist#URIEquivalence-15"><span
class="open">issue URIEquivalence-15</span></a>.</p>

<h3><a name="unique-uris" id="unique-uris">Unique URIs</a></h3>

<p>Authors should not use a URI to identify more than one resource.</p>

<p>Nothing prevents us from considering "a representation of the novel Moby
Dick" to be a resource itself (and thus to have an assigned URI). Authors
should not use the same URI to refer to the resource "Moby Dick" and to the
particular representation of that resource. Similarly, authors should not use
the same URI to refer to a person and to that person's mailbox.</p>

<h2 class="appendix"><a name="appendix-notes" id="appendix-notes">End notes</a></h2>

<h2><a id="glossary" name="glossary">Glossary</a></h2>

<h2><a id="refs" name="refs">References</a></h2>

<h3><a name="normative" id="normative">Normative References</a></h3>
<dl>
  <dt><a name="IANASchemes" id="IANASchemes">IANASchemes</a></dt>
    <dd>IANA's <a href="http://www.iana.org/assignments/uri-schemes">online
      registry of URI Schemes</a> is available at
      http://www.iana.org/assignments/uri-schemes.</dd>
    <dd><a href="http://www.w3.org/Addressing/schemes">Dan Connolly's list of
      URI schemes</a> is a useful resource for finding out which references
      define various URI schemes.</dd>
  <dt><a name="RFC2046" id="RFC2046">RFC2046</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc2046">RFC 2046:
      Multipurpose Internet Mail Extensions (MIME) Part Two: Media
      Types</a>", N. Freed, N. Borenstein, November 1996. Available at
      http://www.ietf.org/rfc/rfc2046.</dd>
  <dt><a name="RFC2119" id="RFC2119">RFC2119</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119: Key
      words for use in RFCs to Indicate Requirement Levels</a>", S. Bradner,
      March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.</dd>
  <dt><a name="RFC2396" id="RFC2396">RFC2396</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396: Uniform
      Resource Identifiers (URI): Generic Syntax</a>", T. Berners-Lee, R.
      Fielding, L. Masinter, August 1998. Available at
      http://www.ietf.org/rfc/rfc2396.</dd>
  <dt><a name="RFC2616" id="RFC2616">RFC2616</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616:
      Hypertext Transfer Protocol -- HTTP/1.1</a>", J. Gettys, J. Mogul, H.
      Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at
      http://www.ietf.org/rfc/rfc2616.</dd>
  <dt><a name="RFC2717" id="RFC2717">RFC2717</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc2717.txt">Registration
      Procedures for URL Scheme Names</a>", R. Petke, I. King, November 1999.
      Available at http://www.ietf.org/rfc/rfc2717.</dd>
</dl>

<h3><a name="informative" id="informative">Non-Normative References</a></h3>
<dl>
  <dt><a name="Axioms" id="Axioms">Axioms</a></dt>
    <dd>"<a href="http://www.w3.org/DesignIssues/Axioms">Universal Resource
      Identifiers - Axioms of Web Architecture</a>", T. Berners-Lee, living
      document dated December 1996. Available at
      http://www.w3.org/DesignIssues/Axioms</dd>
  <dt><a name="Cool" id="Cool">Cool</a></dt>
    <dd>"<a href="http://www.w3.org/Provider/Style/URI.html">Cool URI's don't
      change</a>" T. Berners-Lee, W3C, 1998 Available at
      http://www.w3.org/Provider/Style/URI</dd>
  <dt>CSS2</dt>
    <dd>"<a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">Cascading
      Style Sheets, level 2</a>", B. Bos, H. Lie, C. Lilley, I. Jacobs, 12
      May 1998. This W3C Recommendation is available at
      http://www.w3.org/TR/1998/REC-CSS2-19980512/.</dd>
  <dt><a name="Eng90" id="Eng90">Eng90</a></dt>
    <dd>"<a
      href="http://www.bootstrap.org/augment/AUGMENT/132082.html">Knowledge-Domain
      Interoperability and an Open Hyperdocument System</a>", D. C.
      Engelbart, June 1990.</dd>
  <dt><a name="Fielding" id="Fielding">Fielding</a></dt>
    <dd>"<a
      href="http://www.cs.virginia.edu/~cs650/assignments/papers/p407-fielding.pdf">Principled
      Design of the Modern Web Architecture</a>", R.T. Fielding and R.N.
      Taylor, UC Irvine.In Proceedings of the 2000 International Conference on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000, pp. 407-416.</dd>
  <dt><a name="Fragments" id="Fragments">Fragments</a></dt>
    <dd>"<a href="http://www.w3.org/DesignIssues/Fragment">Fragment
      Identifiers on URIs</a>", T. Berners-Lee, living document dated April
      1997. Available at http://www.w3.org/DesignIssues/Fragment</dd>
  <dt><a name="HTML40" id="HTML40">HTML40</a></dt>
    <dd>"<a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01
      Specification</a>", D. Raggett, A. Le Hors, I. Jacobs, 24 December
      1999. This W3C Recommendation is available at
      http://www.w3.org/TR/1999/REC-html401-19991224/.</dd>
  <dt><a name="P3P10" id="P3P10">P3P10</a></dt>
    <dd>"<a href="http://www.w3.org/TR/2002/REC-P3P-20020416/">The Platform
      for Privacy Preferences 1.0 (P3P1.0) Specification</a>", M. Marchiori,
      ed., 16 April 2002. This W3C Recommendation is available at
      http://www.w3.org/TR/2002/REC-P3P-20020416/.</dd>
  <dt><a name="REST" id="REST">REST</a></dt>
    <dd>"<a
      href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">Representational
      State Transfer (REST)</a>", Chapter 5 of "Architectural Styles and the
      Design of Network-based Software Architectures", Doctoral Thesis of R.
      T. Fielding, 2000.</dd>
  <dt><a name="RFC2141" id="RFC2141">RFC2141</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc2141.txt">RFC 2141: URN
      Syntax</a>", R. Moats, May 1997. Available at
      http://www.ietf.org/rfc/rfc2141.txt.</dd>
  <dt><a name="RFC2718" id="RFC2718">RFC2718</a></dt>
    <dd>"<a href="http://www.ietf.org/rfc/rfc2718.txt">Guidelines for new URL
      Schemes</a>", L. Masinter, H. Alvestrand, D. Zigmond, R. Petke,
      November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.</dd>
  <dt><a name="RFC3236" id="RFC3236">RFC3236</a></dt>
    <dd>IETF "<a href="http://www.ietf.org/rfc/rfc3236">RFC 3236: The
      'application/xhtml+xml' Media Type</a>", M. Baker, P. Stark, January
      2002. Available at: http://www.rfc-editor.org/rfc/rfc3236.</dd>
  <dt><a name="SVG10" id="SVG10">SVG10</a></dt>
    <dd>"<a href="http://www.w3.org/TR/2001/REC-SVG-20010904/">Scalable
      Vector Graphics (SVG) 1.0 Specification</a>", J. Ferraiolo, ed., 4 Sep
      2001. This W3C Recommendation is available at
      http://www.w3.org/TR/2001/REC-SVG-20010904/.</dd>
  <dt><a name="UniqueDNS" id="UniqueDNS">UniqueDNS</a></dt>
    <dd>"<a
      href="http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm">IAB
      Technical Comment on the Unique DNS Root"</a>, B. Carpenter, 27 Sep
      1999.</dd>
  <dt><a name="XHTML10" id="XHTML10">XHTML10</a></dt>
    <dd>"<a href="http://www.w3.org/TR/xhtml1/">XHTML 1.0: The Extensible
      HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0</a>",
      S. Pemberton et al., 26 January 2000. The latest version of this W3C
      Recommendation is available at http://www.w3.org/TR/xhtml1/.</dd>
  <dt><a name="XLink10" id="XLink10">XLink10</a></dt>
    <dd>"<a href="http://www.w3.org/TR/2001/REC-xlink-20010627/">XML Linking
      Language (XLink) Version 1.0</a>", S. DeRose, E. Maler, D. Orchard, 27
      June 2001. This W3C Recommendation is available at
      http://www.w3.org/TR/2001/REC-xlink-20010627/.</dd>
  <dt><a name="XML10" id="XML10">XML10</a></dt>
    <dd>"<a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible
      Markup Language (XML) 1.0 (Second Edition)</a>", T. Bray, J. Paoli,
      C.M. Sperberg-McQueen, E. Maler, 6 October 2000. This W3C
      Recommendation is available at
      http://www.w3.org/TR/2000/REC-xml-20001006.</dd>
  <dt><a name="XMLNS" id="XMLNS">XMLNS</a></dt>
    <dd>"<a
      href="http://www.w3.org/TR/1999/REC-xml-names-19990114/">Namespaces in
      XML</a>", T. Bray, D. Hollander, A. Layman, 14 Jan 1999. This W3C
      Recommendation is available at
      http://www.w3.org/TR/1999/REC-xml-names-19990114/.</dd>
  <dt><a name="W3CPROCESS" id="W3CPROCESS">W3CPROCESS</a></dt>
    <dd>"<a
      href="http://www.w3.org/Consortium/Process-20010719/tr.html#Reports">W3C
      Process Document</a>", 19 July 2001 Version.</dd>
</dl>
<hr />
<address>
  <a href="http://www.w3.org/People/Jacobs/">Ian Jacobs</a><br />
  Last modified $Date: 2002/08/28 13:29:15 $ by $Author: ijacobs $<br />
  Version: $Version$
</address>
</body>
</html>
