<a shape="rect" name="title" id="title"> Architecture of the World Wide Web 1.0

<a shape="rect" id="principles" name="principles"> List of Principles and Good Practice Notes

The following principles and good practice notes explained in this document are listed here for convenience.

General Architecture Principles

1. deleted text: <a href="#pr-info-hiding"> Identify features that cross abstraction levels </a> </li> <li> Error recovery
deleted text: <li> <a href="#specify-error-handling"> Specify error handling </a> </li>

Identification

1. Identify with URIs
2. URI uniqueness
3. Assign URIs URI assignment
4. <a href="#thoughtful-uris"> Thoughtful URI creation aliases
5. Use URIs consistently Consistent URI usage
6. URI ambiguity
7. New URI schemes
8. URI Opacity opacity

Interaction

1. Fragment identifier consistency: consistency
2. Authoritative server metadata
3. Don't guess Appropriate metadata
4. Safe retrieval
5. Consistent representations representation
6. Available representations representation

Data Formats

1. <a href="#spec-availability"> Format specification availability </a> </li> <li> <a href="#register-media-type"> Media type registration </a> </li> <li> <a href="#define-fragids"> Specified fragment identifier semantics Version information
2. <a href="#text-binary"> Binary or text Namespace policy
3. Allow for extensions </a> </li> <li> <a href="#pr-version-info"> Provide version information Extensibility mechanisms
4. Unknown extensions
5. deleted text: Content, Presentation, Interaction Separation of content, presentation, interaction
6. Link mechanisms
7. Web linking
8. Generic URIs
9. <a href="#use-hyperlinks"> Use of Hyperlinks </a> </li> <li> <a href="#qname-mapping"> QName Mapping Hypertext links
10. <a href="#qname-uri-syntax"> QNames Indistinguishable from URIs Namespace adoption
11. <a href="#use-namespaces"> Use Namespaces Namespace documents
12. <a href="#pr-doc-ns-policy"> Document namespace policy QName Mapping
13. <a href="#namespace-docs"> Namespace documents QNames Indistinguishable from URIs
14. XML and text/*
15. XML and character encodings

1.1. <a shape="rect" name="about" id="about"> About this Document

This document attempts to describe the properties we desire of the Web and the design choices that have been made to achieve them.

This document promotes re-use of existing standards when suitable, and gives guidance on how to innovate in a manner consistent with the Web architecture.

deleted text: <div class="section"> <h4> 1.1.1. <a shape="rect" name="doc-audience" id="doc-audience"> Audience of this Document </a> </h4>

deleted text: This document is intended to inform discussions about issues of Web architecture. The intended audience for this document includes: </p> <ol> <li> Participants in W3C terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the good practice notes, principles, etc. in accordance with RFC 2119 [ RFC2119 ]. However, this document does not include conformance provisions for at least these reasons:

• Conforming software is expected to be so diverse that it would not be useful to be able to refer to the class of conforming software agents.
• Some of the good practice notes concern people; specifications generally define conformance for software, not people.
• The addition a conformance section is not likely to increase the utility of the document.

1.2. <a shape="rect" name="general" id="general"> General Architecture Principles

A number of general architecture principles apply to across all three dimensions bases of Web architecture.

2.1. URI Comparisons

As stated above, Web architecture allows resource owners to assign more than one URI to a resource. Thus, URIs that are not identical (character for character) do not necessarily refer to different resources. The most straightforward way of establishing that two parties are referring to the same Web resource is to compare, as character strings, the URIs they are using. URI equivalence is discussed in section 6 of [ <a shape="rect" href="#URI"> URI ]

URI producers should be conservative about the number of different URIs they produce for the same resource. For example, the parties responsible for weather.example.com should not use both " <code> http://weather.example.com/Oaxaca </code> " "http://weather.example.com/Oaxaca" and " <code> http://weather.example.com/oaxaca </code> " "http://weather.example.com/oaxaca" to refer to the same resource; agents will not detect the equivalence relationship by following specifications. On the other hand, there may be good reasons for creating similar-looking URIs. For instance, one might reasonably create URIs that begin with " <code> http://www.example.com/tempo </code> " "http://www.example.com/tempo" and " <code> http://www.example.com/tiempo </code> " "http://www.example.com/tiempo" to provide access to resources by users who speak Italian and Spanish.

Likewise, URI consumers should ensure URI consistency. For instance, when transcribing a URI, agents should not gratuitously escape characters. The term "character" refers to URI characters as defined in section 2 of [ <a shape="rect" href="#URI"> URI ].

Applications may apply rules beyond basic string comparison (e.g., (for example, for "http" URIs, the authority component is case-insensitive) that are licensed by specifications to reduce the risk of false negatives and positives. Web agents Agents that reach conclusions based on comparisons that are not licensed by relevant specifications take responsibility for any problems that result. Agents should not assume, for example, that " <code> http://weather.example.com/Oaxaca </code> " "http://weather.example.com/Oaxaca" and " <code> http://weather.example.com/oaxaca </code> " "http://weather.example.com/oaxaca" identify the same resource, since none of the specifications involved states that the path part of an "http" URI is case-insensitive.

See section 6 [ <a shape="rect" href="#URI"> URI ] for more information about comparing URIs and reducing the risk of false negatives and positives. See the section on future directions for solutions other than string comparison that may allow different parties to <a shape="rect" href="#future-comparison"> determine that two URIs identify the same resource .

2.2. <a shape="rect" name="URI-ambiguity" id="URI-ambiguity"> URI Ambiguity Ownership

Just as The requirement for URIs to be unambiguous demands that two agents do not assign the same URI to different resources. URI scheme specifications assure this using a shared vocabulary has tangible value, variety of techniques, including:

• Hierarchical delegation of authority. This approach, exemplified by the ambiguous use "http" and "mailto" schemes, allows the assignment of deleted text: terms imposes a cost in communication. <a name="def-uri-ambiguity" id="def-uri-ambiguity"> <dfn> part of URI space to one party, reassignment of a piece of that space to another, and so forth.
• Random numbers. The generation of a fairly large random number, used in the "uuid" scheme, reduces the risk of ambiguity deleted text: </dfn> </a> refers to a calculated small risk.
• Checksums. The generation of a URI as a checksum based on a data object has similar properties to the random number approach. This is the approach taken by the "md5" scheme.
• Combination of approaches. The "mid" and "cid" schemes combine some of the above approaches.

The approach taken for the "http" URI scheme follows the pattern whereby the Internet community delegates authority, via the IANA URI scheme registry [ IANASchemes ] and the use DNS), over a set of the same URI to refer URIs with a common prefix to deleted text: more than one distinct resource. Consider the following scenario: particular owner. One division consequence of a company maintains data about Web pages, including who created them and when. This division naturally uses this approach is the URI of Web's heavy reliance on the page to identify it. Another division of central DNS registry.

Whatever the company maintains data about corporations, including who created them and when. They use techniques used, except for the URI of checksum case, the corporation's home page to identify it. agent has a unique relationship with the URI, called URI ownership URI . The phrase "authority responsible for a URI" is synonymous with "URI owner" in this document.

If The social implications of URI ownership are not discussed here. However, the two divisions decide to merge their data, they will have to exercise care success or failure of these different approaches depends on the fact that they are using the same URIs extent to identify two different resources will cause problems. </p> <p> Ambiguity which there is an error consensus in the Internet community to abide by the defining specifications, as expressed through protocol messages. Of particular importance are those messages that express a relationship between a URI and deleted text: should not be confused with indirect identification. Indirect identification occurs when a representation of the resource it identifies. The concept of URI ownership is identified through another resource to especially visible in the case of the HTTP protocol, which it has a known relationship. For example, people can be identified by their email addresses or organizations by their web pages. When conference organizers ask meeting participants enables the URI owner to register by giving their email addresses, both parties know that they are using serve authoritative representations of a resource. In this case, the HTTP origin server (defined in [ RFC2616 ]) is the mailbox identifier to indirectly identify agent acting on behalf of the deleted text: person. The URI " <code> mailto:joe@example.com </code> " still identifies owner.

2.3. URI Ambiguity

Just as a shared vocabulary has tangible value, the mailbox, not ambiguous use of terms imposes a cost in communication. URI ambiguity refers to the person. use of the same URI to refer to more than one distinct resource.

URI ambiguity should not be confused with ambiguity in natural languages. language. The natural language English statement "'http://www.example.com/moby' identifies 'Moby Dick'" is ambiguous because one could understand the statement to refer to deleted text: very distinct resources: a particular printing of this work, or the work itself in an abstract sense, or the fictional white whale, or a particular copy of the book on the shelves of a library (via the Web interface of the library's online catalog), or the record in the library's electronic catalog which contains the metadata about the work, or the Gutenberg project's online version. version .

2.3. <a shape="rect" name="URI-scheme" id="URI-scheme"> 2.4. URI Schemes

In the URI " <code> http://weather.example.com/ </code> ", "http://weather.example.com/", the "http" that appears before the colon (":") is names a URI scheme name. scheme. Each URI scheme has a normative specification that explains how identifiers are assigned within that scheme. The URI syntax is thus a federated and extensible naming mechanism wherein each scheme's specification may further restrict the syntax and semantics of identifiers within that scheme. Furthermore, the URI scheme specification may specify whether and how an agent can <a shape="rect" href="#dereference-uri"> dereference the URI .

Examples of URIs from various schemes include:

• mailto:joe@example.org
• ftp://example.org/aDirectory/aFile
• news:comp.infosystems.www
• tel:+1-816-555-1212
• ldap://ldap.example.org/c=GB?objectClass?one
• urn:oasis:SAML:1.0

The Internet Assigned Numbers Authority ( <acronym> IANA </acronym> ) maintains a registry [ <a shape="rect" href="#IANASchemes"> IANASchemes </a> ] of mappings between URI scheme names and scheme specifications. For instance, While the IANA registry indicates that Web architecture allows the "http" scheme is defined in [ <a shape="rect" href="#RFC2616"> RFC2616 </a> ]. The process for registering definition of new schemes, introducing a new deleted text: URI scheme is defined in [ <a shape="rect" href="#RFC2717"> RFC2717 </a> ]. </p> <p> Since many costly. Many aspects of URI processing are scheme-dependent, and deleted text: since a huge significant amount of deployed software already processes URIs of well-known schemes, schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [ RFC2718 ] for other considerations and costs related to URI scheme design.

Because of these costs, if a URI scheme exists that meets the needs of an application, designers should use it rather than invent one. The "https" scheme [ RFC2818 ] is an example of a URI scheme that, though commonly implemented by agents, is problematic for a number of reasons:

• It violates the principle of orthogonal specifications since the URI contains information about the expected dereference protocol.
• The scheme does not differ from "http" except that it indicates that agents should expect to use HTTP over TLS when dereferencing these URIs. However, HTTP agents can negotiate a secure exchange whatever the URI scheme, so the scheme did not provide missing functionality.
• Generic URI equivalence testing no longer works.
• Changes in the cost security policy for a resource identified by an "https" URI may require publication of deleted text: introducing a new non-https URI. Security policy management can be managed without requiring URIs to change; see the section on URI scheme is high. </p> persistence for more information.

Consider our <a shape="rect" href="#scenario"> travel scenario : should the authority providing information about the weather in Oaxaca register a new URI scheme "weather" for the identification of resources related to the weather? They might then publish URIs such as " <code> weather://travel.example.com/oaxaca </code> ". While the Web architecture allows the definition of new schemes, there is a cost to registration and especially deployment of new schemes. "weather://travel.example.com/oaxaca". When an a software agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve an HTML a representation of the resource, then an "http" URI would have sufficed. deleted text: If a URI scheme exists that meets the needs of an application, designers should use it rather than invent one.

If the motivation behind registering a new scheme is to allow an a software agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense by registering via Internet Media Types. If you are designing a new data format, the appropriate mechanism to promote its deployment on the Web is the Internet Media Type instead. Deployed software is more likely to Type.

Note that even if an agent cannot yet handle the introduction of representation data in a new media type than format, the introduction of representation data may contain enough information to allow a user or user agent to find more information. When an agent does not handle a new URI scheme. scheme, it cannot retrieve a representation.

<p>

2.4. <a shape="rect" name="uri-opacity" id="uri-opacity"> 2.5. URI Opacity

It is tempting to guess the nature of a resource by inspection of a URI that identifies it. However, the Web is designed so that agents communicate resource state through <a shape="rect" href="#def-representation"> representations , not identifiers. In general, one cannot determine the Internet Media Type of representations of a resource by inspecting a URI for that resource. For example, the ".html" at the end of " <code> http://example.com/page.html </code> " "http://example.com/page.html" provides no guarantee that representations of the identified resource will be served with the Internet Media Type "text/html". The HTTP protocol does not constrain the Internet Media Type based on the path component of the URI; the server is free to return a representation in deleted text: the PNG or any other data format for that URI.

Resource state may evolve over time. Requiring resource owners to change URIs to reflect resource state would lead to a significant number of broken links. For robustness, Web architecture promotes independence between an identifier and the identified resource.

The example URI used in the <a shape="rect" href="#scenario"> travel scenario (" <code> http://weather.example.com/oaxaca </code> ") ("http://weather.example.com/oaxaca") suggests that the identified resource has something to do with the weather in Oaxaca. A site reporting the weather in Oaxaca could just as easily be identified by the URI " <code> http://vjc.example.com/315 </code> ". "http://vjc.example.com/315". And the URI " <code> http://weather.example.com/vancouver </code> " "http://weather.example.com/vancouver" might identify the resource "my photo album."

On the other hand, the URI " <code> mailto:joe@example.com </code> " "mailto:joe@example.com" indicates that the URI refers to a mailbox. The mailto "mailto" URI scheme specification authorizes deleted text: Web agents to infer that URIs of this form identify Internet mailboxes.

In some cases, relevant technical specifications license URI assignment authorities to publish assignment policies. For more information about URI opacity, see the TAG finding " <a shape="rect" href="http://www.w3.org/2001/tag/doc/metaDataInURI-31"> The use of Metadata in URIs " .

2.5. <a shape="rect" name="fragid" id="fragid"> 2.6. Fragment Identifiers

The fragment identifier of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional information. More precisely:

• If URI "U" identifies primary resource "R", and
• a representation of "R" is in the data format "F", and
• the data format specification for "F" specifies that fragment identifiers in instances of "F" identify secondary resources, then
• a URI for the secondary resource identified within an instance of "F" by fragment identifier "fragid" is "U#fragid".

The secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource. The interpretation of fragment identifiers is discussed in the section on <a shape="rect" href="#media-type-fragid"> media types and fragment identifier semantics . deleted text: Note that one can use a URI with a fragment identifier even if one does not have a representation handy for interpreting the fragment identifier (e.g., one can compare two such URIs).

Refer the TAG finding " <a shape="rect" href="http://www.w3.org/2001/tag/doc/abstractComponentRefs.html"> Abstract Component References " for information about indirect identification of abstract components such as those identified in description languages such as WSDL and RDF.

TAG issue DerivedResources-43 : How are secondary resources derived?

2.6. <a shape="rect" name="identifiers-future" id="identifiers-future"> 2.7. Future Directions for Identifiers

There remain open questions regarding identifiers on the Web. The following sections identify a few areas of future work in the Web community. deleted text: The TAG makes no commitment at this time to pursuing these issues.

3.1. <a shape="rect" name="dereference-uri" id="dereference-uri"> Using a URI to Access a Resource

Agents may use a URI to access the referenced resource; this is called dereferencing the URI . Access may take many forms, including retrieving a representation of resource state (e.g., (for instance, by using HTTP GET or HEAD), modifying the state of the resource (e.g., (for instance, by using HTTP POST or PUT), and deleting the resource (e.g., (for instance, by using HTTP DELETE).

There may be more than one way to access a resource for a given URI; application context may determine determines which access mechanism an agent uses. For instance, a browser might use HTTP GET to retrieve a representation of a resource, whereas a link checker might use HTTP HEAD on the same URI simply to establish whether a representation is available. Some URI schemes (e.g., set expectations about available access mechanisms, others (such as the URN scheme [ <a shape="rect" href="#RFC2141"> RFC 2141 ]) do not set expectations about available access mechanisms. ]) do not. Section 1.2.2 of [ <a shape="rect" href="#URI"> URI ] discusses the separation of identification and interaction in more detail. For more information about relationships between multiple access mechanisms and URI addressability, see the TAG finding " <a shape="rect" href="http://www.w3.org/2001/tag/doc/whenToUseGet.html"> URIs, Addressability, and the use of HTTP GET and POST " </cite>. </p> <p> Although many <a shape="rect" href="#URI-scheme"> URI schemes </a> are named after protocols, this does not imply that use of such a URI will result in access to the resource via the named protocol. Even when an agent uses a URI to retrieve a representation, that access might be through gateways, proxies, caches, and name resolution services that are independent of the protocol associated with the scheme name, and the resolution of some URIs may require the use of more than one protocol (e.g., both DNS and HTTP are typically used to access an "http" URI's origin server when a representation isn't found in a local cache). </p> <p> Dereferencing a URI generally involves a succession of steps as defined in multiple independent specifications and implemented by the agent. The following example illustrates the series of specifications that are involved when an agent dereferences the URI " <code> http://weather.example.com/oaxaca </code> " that is part of a link in an SVG document. </p> <ol> <li> Since the URI is part of a link in an SVG document, the first relevant specification is the SVG 1.1 Recommendation [ <a shape="rect" href="#SVG11"> SVG11 </a> ]. This specification imports the link semantics defined in XLink 1.0 [ <a shape="rect" href="#XLink10"> XLink10 </a> ]. Section 17.1 of the SVG specification suggests that interaction with an <code> a </code> link involves retrieving a representation of a resource, identified by the XLink <code> href </code> attribute: "By activating these links (by clicking with the mouse, through keyboard input, and voice commands), users may visit these resources." </li> <li> The XLink 1.0 [ <a shape="rect" href="#XLink10"> XLink10 .

Although many URI schemes ] specification, which defines the attribute <code> xlink:href </code> in section 5.4, states are named after protocols, this does not imply that "The value use of the href attribute must be such a URI reference as defined in [IETF RFC 2396], or must will result in a URI reference after access to the escaping procedure described below is applied." </li> <li> The URI specification [ <a shape="rect" href="#URI"> URI </a> ] states that "Each URI begins with resource via the named protocol. Even when an agent uses a scheme name that refers URI to retrieve a specification for assigning identifiers within representation, that scheme." The URI scheme access might be through gateways, proxies, caches, and name in this example is "http". </li> <li> [ <a shape="rect" href="#IANASchemes"> IANASchemes </a> ] states resolution services that the "http" scheme is defined by the HTTP/1.1 specification (RFC 2616 [ <a shape="rect" href="#RFC2616"> RFC2616 </a> ], section 3.2.2). </li> <li> Section 9.3 are independent of deleted text: [ <a shape="rect" href="#RFC2616"> RFC2616 </a> ] states how the server constructs protocol associated with the scheme name.

Dereferencing a GET response (section 6 URI generally involves a succession of [ <a shape="rect" href="#RFC2616"> RFC2616 </a> ]), including steps as described in multiple independent specifications and implemented by the 'Content-Type' field. In this SVG context, agent. The following example illustrates the series of specifications that are involved when a user instructs a user agent deleted text: employs the GET method to retrieve the representation. </li> <li> Section 1.4 of [ <a shape="rect" href="#RFC2616"> RFC2616 follow a hypertext link deleted text: ] states "HTTP communication usually takes place over TCP/IP connections." This example does not address that step in is part of an SVG document. In this example, the URI is "http://weather.example.com/oaxaca" and the application context calls for the deleted text: process. </li> <li> The user agent deleted text: interprets the returned representation according to retrieve and render a representation of the data format specification that corresponds to identified resource.

1. Since the representation's <a shape="rect" href="#internet-media-type"> Internet Media Type </a> (the value URI is part of the HTTP 'Content-Type') a hypertext link in an SVG document, the first relevant IANA registry specification is the SVG 1.1 Recommendation [ <a shape="rect" href="#MEDIATYPEREG"> MEDIATYPEREG SVG11 ]. </li> </ol> <p> <span class="ednote"> Editor's note </span>: Chris Lilley is expected to provide a revised version Section 17.1 of this specification imports the above sequence. </p> </div> <div class="section"> <h3> 3.2. <a shape="rect" name="msg-representation" id="msg-representation"> Messages and Representations </a> </h3> <p> A <a name="def-message" id="def-message"> <dfn> message </dfn> link semantics defined in XLink 1.0 [ XLink10 ]. "The remote resource (the destination for the link) is an event that is represented in defined by a non-exclusive set of messaging protocols (e.g., HTTP, FTP, NNTP, SMTP, etc.). Messages may carry data, metadata about the data, and <a name="message-metadata" id="message-metadata"> <dfn> message metadata </dfn> </a>: metadata about the message (e.g., URI specified by the HTTP Transfer-encoding header). A message may even include metadata about XLink href attribute on the message metadata (e.g., for message-integrity checks). </p> <p> Two important classes of message are those 'a' element." The SVG specification goes on to state that request interaction with an a element involves retrieving a representation of a resource, and those that return identified by the result of such a request. Such a response message (e.g., a response to an HTTP GET) carries a <a name="def-representation" id="def-representation"> <dfn> representation </dfn> XLink href attribute: "By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may visit these resources."
2. The XLink 1.0 [ XLink10 of the state of ] specification, which defines the resource. A representation is an octet sequence attribute xlink:href in section 5.4, states that consists logically "The value of two parts: </p> <ol> <li> Electronic data about resource state, expressed the href attribute must be a URI reference as defined in one or more <a shape="rect" href="#formats"> formats </a> used separately [IETF RFC 2396], or must result in combination, and a URI reference after the escaping procedure described below is applied."
3. <a name="representation-metadata" id="representation-metadata"> <dfn> Representation metadata </dfn> </a>, especially the <a shape="rect" href="#internet-media-type"> Internet Media Type The URI specification [ URI which governs the interpretation of the representation data. </li> </ol> <p> Some protocols (such as HTTP) may also allow agents ] states that "Each URI begins with a scheme name that refers to exchange <a name="resource-metadata" id="resource-metadata"> <dfn> resource metadata </dfn> </a>. For a specification for assigning identifiers within that scheme." The URI scheme name in this example deleted text: when using HTTP, some resource metadata is specified by headers such as 'Alternates' and 'Vary'. </p> <p> Agents use representations to modify as well as retrieve resource state. Note "http".
4. [ IANASchemes ] states that deleted text: even though the response to an HTTP POST request may contain "http" scheme is defined by the above types of data, HTTP/1.1 specification (RFC 2616 [ RFC2616 ], section 3.2.2).
5. In this SVG context, the response to agent constructs an HTTP POST GET request is not a representation of the state (per section 9.3 of deleted text: the resource identified in the POST request. </p> </div> <div class="section"> <h3> 3.3. <a shape="rect" id="internet-media-type" name="internet-media-type"> Internet Media Type </a> </h3> <p> The Internet Media Type [ <a shape="rect" href="#RFC2046"> RFC2046 RFC2616 ]) governs to retrieve the authoritative interpretation representation.
6. Section 6 of deleted text: representation data, and the IANA registry [ <a shape="rect" href="#MEDIATYPEREG"> MEDIATYPEREG RFC2616 ] determines defines how the <a shape="rect" href="#format-specification"> format specifications server constructs a corresponding response message, including the 'Content-Type' field.
7. Section 1.4 of [ RFC2616 ] states "HTTP communication usually takes place over TCP/IP connections." This example does not address that provide the authoritative interpretation for a given Internet Media Type. If step in the user process, or other steps such as Domain Name System ( DNS ) resolution.
8. The agent deleted text: implements those specifications, it interprets the data accordingly; <a shape="rect" href="#error-handling"> error handling </a> is discussed below. In this document, returned representation according to the deleted text: phrase "media type M" is shorthand for "the data format defined by specification that corresponds to the specification(s) paired with representation's Internet Media Type M (the value of the HTTP 'Content-Type') in the relevant IANA registry." </p> registry [ MEDIATYPEREG ].

<h4> 3.3.1. <a shape="rect" id="media-type-fragid" name="media-type-fragid"> Media Types

3.2. Messages and Fragment Identifier Semantics Representations </h4>

The URI specification [ <a shape="rect" href="#URI"> URI </a> ] states that given a URI with a fragment identifier "U#F": </p> <ul> <li> The authoritative interpretation of "F" depends Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) are based on the <a shape="rect" href="#format-specification"> format specification </a> of representation data that is part of a representation exchange of messages. A message may include data, metadata about the resource identified by "U". </li> </ul> <p> The interpretation of "F" does not depend on data, and message metadata : metadata about the representation where "U#F" appears but on message (such as the representation retrieved by dereferencing "U". HTTP Transfer-encoding header). A message may even include metadata about the message metadata (for message-integrity checks, for instance).

Interpretation Two important classes of the fragment identifier during message are those that request a retrieval action is performed solely by the agent; representation of a resource, and those that return the fragment identifier is not passed result of such a request. Such a response message (for example, a response to other systems during an HTTP GET) carries a representation of the process state of deleted text: retrieval. This means that some intermediaries in the Web architecture (e.g., proxies) have no interaction with fragment identifiers and resource. A representation is an octet sequence that redirection (in HTTP [ <a shape="rect" href="#RFC2616"> RFC2616 </a> ], for example) does not account for them. consists logically of two parts:

</div> <div class="section"> <h4> 3.3.2. <a shape="rect" name="frag-multiple-reps" id="frag-multiple-reps"> Fragment Identifiers and Multiple Representations </a>

1. </h4> <p> For a given resource, an agent may have the choice between representation Representation data , electronic data about resource state, expressed in deleted text: more than one data format (e.g., through HTTP content negotiation). Since different data or more formats may define different fragment identifier semantics, it is used separately or in combination, and
2. Representation metadata . One important to note that by design piece of metadata is the secondary Internet Media Type , discussed below.

Some protocols (such as HTTP) may also allow agents to exchange resource identified by a URI with a fragment identifier metadata . For example when using HTTP, some resource metadata is expected specified by headers such as 'Alternates' and 'Vary'.

Agents use representations to modify as well as retrieve resource state. Note that even though the response to be an HTTP POST request may contain the same independent above types of representations. Thus, if a fragment has defined semantics in any one representation, data, the fragment response to an HTTP POST request is identified for all of them, even though not necessarily a particular format cannot represent it. </p> <p> Suppose, for example, that representation of the party responsible for " <code> http://weather.example.com/oaxaca/map#zicatela </code> " provides representations state of the resource identified by <code> http://weather.example.com/oaxaca/map </code> using three image formats: SVG, PNG, and JPEG/JFIF. in the POST request.

3.3. Internet Media Type

The SVG specification defines semantics for fragment identifiers while Internet Media Type [ RFC2046 ]) of a representation determines which data format specification(s) provide the other specifications do not. It is not considered an error that only authoritative interpretation of the representation data formats specifies semantics for the (including fragment identifier. Because the Web is a distributed system in which formats identifier syntax and agents are deployed in a non-uniform manner, the architecture allows this sort of discrepancy. Authors may take advantage of more powerful semantics , if any). The IANA registry [ MEDIATYPEREG ] maps media types to data formats, while still ensuring reasonable backward-compatibility for users whose agents do not yet implement them. formats .

On the other hand, it is considered an error if the semantics of See the fragment identifiers used in two representations TAG finding " Internet Media Type registration, consistency of a secondary resource are inconsistent. use " for more information about media type registration.

<div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a shape="rect" name="fragid-consistency" id="fragid-consistency">

3.5. <a shape="rect" name="safe-interaction" id="safe-interaction"> Safe Interactions 3.4. Authoritative Representation Metadata

deleted text: <div class="boxedtext"> <p> <span class="storylab"> Story </span> </p> <div class="story">

Nadia decides to book a vacation to Oaxaca at "booking.example.com." She enters data into Successful communication between two parties using a series piece of deleted text: HTML forms and is ultimately asked for credit card information to purchase the airline tickets. She provides this information in another HTML form. When she presses the "Purchase" button, her browser opens another network connection to the server at "booking.example.com" and sends a message conforming to the rules for an HTTP POST request. </p> <p> As described by the HTML specification, the message data consists of a set relies on shared understanding of deleted text: name/value pairs corresponding to the HTML form fields. Note that this is not a <a shape="rect" href="#safe-interaction"> safe interaction </a> ; Nadia wishes to change the state meaning of the system by exchanging money for airline tickets. </p> <p> The server reads the POST request, information. Arbitrary numbers of independent parties can identify and after performing the booking transaction returns a message to Nadia's browser that contains communicate about a representation of Web resource. To give these parties the results of Nadia's request. The representation data is in HTML so that it can be saved or printed out for Nadia's records. Note confidence that neither they are all talking about the data transmitted with same thing when they refer to "the resource identified by the POST nor following URI ..." the design choice for the data received Web is, in general, that the response necessarily correspond to any resource named by owner of a URI. resource assigns the authoritative interpretation of representations of the resource. See the TAG finding " Client handling of MIME headers " for related discussion. See also TAG issue rdfURIMeaning-39 .

deleted text: </div> </div>

Nadia's retrieval In our travel scenario , the authority responsible for "weather.example.com" has license to create representations of weather information qualifies as a "safe" interaction; this resource. Which representation(s) Nadia receives depends on a <a name="def-safe-interaction" id="def-safe-interaction"> <dfn> safe interaction </dfn> </a> is number of factors, including:

1. Whether the authority responsible for "weather.example.com" responds to requests at all;
2. Whether the authority responsible for "weather.example.com" makes available one where or more representations for the agent does not commit resource identified by "http://weather.example.com/oaxaca";
3. Whether Nadia has access privileges to anything beyond such representations (see the interaction section on linking and is not access control );
4. If the authority responsible for any consequences other than the interaction itself (e.g., a read-only query or lookup). Other Web interactions resemble orders "weather.example.com" has provided more than queries. These <a name="def-unsafe-interaction" id="def-unsafe-interaction"> <dfn> unsafe interactions </dfn> one representation (in different formats such as HTML, PNG, or RDF, or in different languages such as English and Spanish), the resulting representation may depend on negotiation between the user agent and server that occurs as part of the HTTP transaction.
5. When Nadia made the request. Since the weather in Oaxaca changes, Nadia should expect that representations will change over time.

3.6. <a shape="rect" name="representation-management" id="representation-management"> Representation Management 3.5. Safe Interactions

The usefulness Nadia's retrieval of weather information (an example of a resource depends on good management by its owner. As is the case with many human interactions, confident interactions with read-only query or lookup) qualifies as a resource depend on stability and predictability. The value of "safe" interaction; a URI increases with the predictability of interactions using that URI. <a shape="rect" href="#thoughtful-uris"> Thoughtful URI creation safe interaction is one aspect of proper resource management. where the agent does not incur any obligation beyond the interaction. An agent may incur an obligation through other means (such as by signing a contract). If an agent does not have an obligation before a safe interaction, it does not have that obligation afterwards.

deleted text: <div class="boxedtext">

Other Web interactions resemble orders more than queries. These <span class="practicelab"> Good practice: <a shape="rect" name="pr-service-uri" id="pr-service-uri"> Consistent representations </a> </span> unsafe interactions </p> <p class="practice"> Publishers of may cause a URI SHOULD provide (or not) representations of change to the identified resource consistently and predictably. </p> </div> <p> This section discusses important aspects state of deleted text: representation management. </p> <div class="section"> <h4> 3.6.1. <a shape="rect" name="representation-available" id="representation-available"> Representation availability </a> </h4> <p> The authority responsible for a resource and the user may supply zero or more representations of a resource. The authority is also be held responsible for accepting or rejecting requests the consequences of these interactions. Unsafe interactions include subscribing to deleted text: modify a resource, e.g., by configuring a server newsletter, posting to accept a list, or reject HTTP PUT modifying a database.

Safe interactions are important because these are interactions where users can browse with confidence and where agents (including search engines and browsers that pre-cache data based for the user) can follow links safely. Users (or agents acting on Internet Media Type, validity constraints, their behalf) do not commit themselves to anything by querying a resource or other constraints. following a link.

In terms of user frustration, there For instance, it is little difference between incorrect to publish a link that, when followed, subscribes a user to a mailing list. Remember that search engines may follow such links.

For more information about safe and unsafe operations using HTTP GET and POST, and handling security concerns around the use of HTTP GET, see the inability to retrieve a representation for an important resource due to a network outage TAG finding " URIs, Addressability, and the inability because none has been provided. use of HTTP GET and POST " .

deleted text: </div> <p> HTTP [ <a shape="rect" href="#RFC2616"> RFC2616

3.6. Representation Management ] has been designed to help service URIs. For example, HTTP redirection (using

The usefulness of a new format specification. Protocols that do not support content negotiation (e.g., FTP) require resource depends on good management by its owner. As is the case with many human interactions, confident interactions with a new identifier when resource depend on stability and predictability. The value of a new format URI increases with the predictability of interactions using that URI. Avoiding unnecessary URI aliases is introduced. one aspect of proper resource management.

This section discusses important aspects of representation management.

deleted text: <p> The Web provides several mechanisms to control access to resources; these mechanisms do not rely on hiding or suppressing URIs for those resources. For more information, see the TAG finding <cite> " <a shape="rect" href="http://www.w3.org/2001/tag/doc/deeplinking.html"> 'Deep Linking' in the World Wide Web </a> " </cite>. </p> </div>

HTTP [ RFC2616 ] has been designed to programmer goals, attention help manage URIs. For example, HTTP redirection (using the 3xx response codes) permits servers to user needs, accessibility, internationalization, etc. The section on <a shape="rect" href="#archspecs"> architectural specifications </a> includes references tell an agent that further action needs to additional format specification guidelines. </p> <p> <strong> Note: </strong> This document does not distinguish be taken by the agent in any formal way order to fulfill the terms "format," "language," and "vocabulary." Context request (for example, the resource has determined which term been assigned a new URI). In addition, content negotiation also promotes consistency, as a site manager is used. not required to define new URIs when adding support for a new format specification. Protocols that do not support content negotiation (such as FTP) require a new identifier when a new data format is introduced.

For more discussion about URI persistence, see [ Cool ].

<h3> 4.1. <a shape="rect" id="standards" name="standards"> Interoperability

3.6.3. Linking and the Use of Standard Format Specifications Access Control </h3>

For a data format It is reasonable to limit access to deleted text: be usefully interoperable between two parties, the parties must have a shared understanding of its syntax and semantics. This resource (for commercial or security reasons, for example), but it is <em> not </em> unreasonable to imply that a sender prohibit others from merely identifying the resource.

As an analogy: The owners of deleted text: data can count on constraining its treatment by a receiver; simply building might have a policy that making good the public may only enter the building via the main front door, and only during business hours. People who work in the building and who make deliveries to it might use of other doors as appropriate. Such a data format requires knowledge policy would be enforced by a combination of security personnel and mechanical devices such as locks and pass-cards. One would not enforce this policy by hiding some of deleted text: its designers' intentions. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a shape="rect" name="spec-availability" id="spec-availability"> Format specification availability </a> </span> </p> <p class="practice"> To promote the interoperability building entrances, nor by requesting legislation requiring the use of deleted text: a Web data format, the format authors SHOULD provide a stable, normative specification for it front door and forbidding anyone to reveal the fact that is a widely available Web resource. there are other doors to the building.

deleted text: </div>

Although the The Web architecture allows provides several mechanisms to control access to resources; these mechanisms do not rely on hiding or suppressing URIs for those resources. For more information, see the deployment of new data formats, TAG finding " 'Deep Linking' in the creation and deployment of new formats (and agents able to handle them) is very expensive. Thus, before inventing a new data format, designers should carefully consider re-using one that is already available. World Wide Web " .

4.2. <a shape="rect" name="binary" id="binary"> Binary and Textual Data Formats 3.7. Future Directions for Interaction

A textual data format is one There remain open questions regarding Web interactions. The TAG expects future versions of this document to address in which more detail the data is specified as a sequence of characters. HTML, Internet e-mail, and all <a shape="rect" href="#xml-formats"> XML-based formats </a> are textual. In modern textual data formats, relationship between the characters are usually taken from architecture described herein, Web Services , the Unicode repertoire Semantic Web , peer-to-peer systems (including Freenet , MLdonkey , and NNTP [ <a shape="rect" href="#UNICODE"> UNICODE RFC977 ]. </p> <p> Binary data formats are those in which portions of the data are encoded for direct use by computer processors, for example thirty-two bit little-endian two's-complement and sixty-four bit IEEE double-precision floating-point. The portions of data so represented include numeric values, pointers, ]), instant messaging systems (including [ XMPP ), and compressed data of all sorts. </p> <p> In principle, all data can be represented using textual formats. voice-over-ip (including RTSP [ RFC2326 ]).

4.3. <a shape="rect" name="ext-version" id="ext-version"> Extensibility 4.1. Binary and Versioning Textual Data Formats

The information that people represent A textual data format is one in which the Web data is specified as a sequence of characters. HTML, Internet e-mail, and all XML-based formats are textual. In modern textual data formats, the technologies they use to represent that information change over time. Versioning is characters are usually taken from the process of managing that change. Unicode repertoire [ UNICODE ].

From early on Binary data formats are those in the Web, HTML agents followed the convention which portions of ignoring unknown elements. This choice left room the data are encoded for innovation (i.e., non-standard elements) direct use by computer processors, for example thirty-two bit little-endian two's-complement and encouraged the deployment of HTML. However, interoperability problems arose as well. In this type of environment, there is an inevitable tension between interoperability in the short term sixty-four bit IEEE double-precision floating-point. The portions of data so represented include numeric values, pointers, and the desire for extensibility. compressed data of all sorts.

Experience shows that designs that strike the right balance In principle, all data can be represented using textual formats.

The trade-offs between allowing change binary and preserving interoperability textual data formats are complex and application-dependent. Binary formats can be substantially more likely to thrive compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by agents in those cases where they can be loaded into memory and used with little or no conversion.

Textual formats are less likely to disrupt usually more portable and interoperable. Textual formats also have the Web community (thus keeping down considerable advantage that they can be directly read and understood by human beings. This can simplify the cost of change). Some examples tasks of successful technologies designed to allow change while minimizing disruption include: URI schemes, Internet Media Types, XML Namespaces, Cascading Style Sheets rules for handling unknown style properties creating and property values, SOAP extensibility model, maintaining software, and deleted text: user agent plug-ins. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a shape="rect" name="pr-allow-exts" id="pr-allow-exts"> Allow for extensions </a> </span> </p> <p class="practice"> Format designers SHOULD provide mechanisms that allow any party to create extensions that do not interfere with conformance the direct intervention of humans in the processing chain without recourse to tools more complex than the original specification. ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats (the "view source" effect).

deleted text: </div>

Application needs determine the most appropriate extension strategy. For example, applications designed to operate in closed environments may be able It is important to employ versioning strategies emphasize that would be impractical on the distributed system of the Web intuition as to such matters as data size and processing speed are not a whole. See the work on RDF ontologies (e.g., [ <a shape="rect" href="#OWL10"> OWL10 </a> ]) for one example reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs. Therefore, data format specification authors should make a well-defined solution for mixing arbitrary ontologies. considered choice between binary and textual format design.

There is typically Note: Text (i.e., a (long) transition period during which multiple versions sequence of characters from a format, protocol, or agent repertoire) is distinct from serving data with a media type beginning with "text/". Although XML-based formats are simultaneously in use. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a shape="rect" name="pr-version-info" id="pr-version-info"> Provide version information </a> </span> </p> <p class="practice"> Format designers SHOULD provide for version information textual, many such formats are not primarily comprised of phrases in language instances. </p> </div> <p> natural language. See the section on <a shape="rect" href="#ns-versioning"> media types for XML deleted text: namespaces and versioning for more information about using issues that arise when "text/" is used in conjunction with an XML-based format.

TAG issue binaryXML-30 : Standardize a namespace name as the basis of version information. "binary XML" format?

4.2. Versioning and Extensibility

Designers can make the transition process smoother by making careful choices about versioning Extensibility and extensibility, in particular with regard versioning are strategies to compatibility: </p> <ul> <li> Design for forward-compatible processing. XSLT 1.0, for example, was designed so that XSLT 1.0 processors would operate predictably when processing stylesheets authored in later versions help manage the natural evolution of information on the specification. </li> <li> Make backward-compatible changes so Web and technologies used to represent that newer processors can also handle older data. </li> </ul> information.

Agent For more information on about versioning strategies and agent behavior in the face of unrecognized content will vary according to application needs, security issues, etc. Application needs will determine extensions, see TAG issue XMLVersioning-41 : What are good practices for designing extensible XML languages and for handling versioning?. See also the appropriate behavior. TAG finding " Versioning XML Languages " and "Web Architecture: Extensible Languages" [ EXTLANG ].

4.3. Separation of Hyperlinks Content, Presentation, and Interaction </span> </p> <p class="practice"> Format specification authors SHOULD incorporate hypertext links into

The Web is a format if hypertext heterogeneous environment where a wide variety of agents provide access to content to users with a wide variety of capabilities. It is deleted text: the expected user interface paradigm. </p> </div> <p> Per the above good practice note, hypertext links should be based on URIs. See also for authors to create content that can reach the widest possible audience, including users with graphical desktop computers, hand-held devices and cell phones, users with disabilities who may require speech synthesizers, and devices not yet imagined. Furthermore, authors cannot predict in some cases how an agent will display or process their content. Experience shows that the allowing authors to separate content, presentation, and interaction concerns promotes reuse and device-independence (see [ DIPRINCIPLES ]); this follows from the section on <a shape="rect" href="#xml-links"> links in XML principle of orthogonal of specifications .

</div> <div class="section"> <h3> 4.6. <a shape="rect" id="xml-formats" name="xml-formats"> XML-Based Data Formats </a> </h3>

Note that when content, presentation, and interaction are separated by design, agents need to recombine them. There is a recombination spectrum, with "client does all" at one end and "server does all" at the syntax rules defined in other. There are advantages to each: recombination on the XML specification <a shape="rect" href="#XML10"> [XML10] </a>. This section discusses issues server allows the server to send out generally smaller amounts of data that are specific can be tailored to specific devices (such as mobile phones). However, such formats. Anyone seeking guidance in this area is urged data will not be readily reusable by other clients and may not allow client-side agents to consult perform useful tasks unanticipated by the "Guidelines For author. When a client does the Use work of XML in IETF Protocols" <a shape="rect" href="#IETFXML"> [IETFXML] </a>, which contains recombination, content is likely to be more reusable by a very thorough discussion broader audience and more robust. However, such date may be of greater size and may require more computation by the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how client.

Of course, it ought to may not always be used. While it is directed at Internet applications with specific reference desirable to protocols, reach the discussion is generally applicable widest possible audience. Application context may require a very specific display (for a legally-binding transaction, for example). Also, digital signature technology, access control , and other technologies are appropriate for controlling access to Web scenarios as well. content.

The discussion here should be seen Some data formats are designed to describe presentation (including SVG and XSL Formatting Objects). Data formats such as ancillary these demonstrate that one can only separate content from presentation (or interaction) so far; at some point it becomes necessary to talk about presentation. Per the content principle of <a shape="rect" href="#IETFXML"> [IETFXML] </a>. Refer also to "XML Accessibility Guidelines" <a shape="rect" href="#XAG"> [XAG] </a> for help designing XML orthogonal specifications, these data formats that lower barriers to Web accessibility for people with disabilities. should only address presentation issues.

See the TAG issues formattingProperties-19 and contentPresentation-26 .

<h4> 4.6.1. <a shape="rect" name="xml-when" id="xml-when"> When to Use an XML-Based Format

4.4. Hypertext </h4>

XML defines textual data formats A defining characteristic of the Web is that are naturally suited it allows embedded references to describing data objects which are hierarchical other Web resources via URIs. The simplicity of creating links using absolute URIs ( <a href="http://www.example.com/foo"> ) and processed in an in-order sequence. It is widely, but not universally applicable for format specifications; an audio or video format, for example, relative URI references ( <a href="foo"> and <a href="foo#anchor"> ) is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include: </p> <ol> <li> Requirement for a hierarchical structure. </li> <li> The data's usefulness should outlive the tools currently used to process it. </li> <li> Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely. </li> <li> Early detection partly (perhaps largely) responsible for the birth of encoding errors with no requirement the hypertext Web as we know it today.

When one resource (representation) refers to "work around" such errors. </li> <li> A high proportion of human-readable textual content. </li> <li> Potential composition another resource with a URI, this constitutes a link between the two resources. Additional metadata may also form part of the data format with other XML-encoded formats. </li> </ol> </div> <div class="section"> <h4> 4.6.2. <a shape="rect" name="xml-links" id="xml-links"> Links and Qnames in XML link (see [ XLink10 </h4> ], for example).

deleted text: TAG issue: What agents do with a hypertext link is not constrained by Web architecture and may depend on application context. Users of the scope hypertext links expect to be able to navigate links among representations. Data formats that do not allow authors to create hypertext links lead to the creation of using XLink? <a shape="rect" href="http://www.w3.org/2001/tag/ilist#xlinkScope-23"> xlinkScope-23 </a>. "terminal nodes" on the Web.

<div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a shape="rect" name="qname-uri-syntax" id="qname-uri-syntax"> QNames Indistinguishable from URIs

<h4> 4.6.3. <a shape="rect" name="xml-namespaces" id="xml-namespaces"> XML Namespaces

4.5. XML-Based Data Formats </h4> <div class="boxedtext">

Many data formats are <span class="storylab"> Story </span> </p> <div class="story"> <p> The authority responsible for "weather.example.com" realizes that it can provide more interesting representations by creating instances that consist of elements defined in different <a shape="rect" href="#xml-based"> XML-based formats , deleted text: such as XHTML, SVG, and MathML. </p> </div> </div> <p> How do the application designers ensure that there are no naming conflicts when is to say they combine elements from different formats (e.g., suppose that conform to the "p" element is syntax rules defined in two or more the XML formats)? "Namespaces in XML" [ <a shape="rect" href="#XMLNS"> XMLNS </a> ] provides a mechanism for establishing a globally unique name specification [XML10] . This section discusses issues that can be understood are specific to such formats. Anyone seeking guidance in any context. </p> <p> The "expanded name" of an XML element or attribute name this area is urged to consult the combination "Guidelines For the Use of its namespace URI and its local name. This is represented lexically XML in documents by associating namespace names with (optional) prefixes and combining prefixes and local names with IETF Protocols" [IETFXML] , which contains a colon thorough discussion of the considerations that govern whether or not XML ought to be used, as well as specific guidelines on how it ought to be used. While it is directed at Internet applications with specific reference to protocols, the discussion is generally applicable to Web scenarios as described in "Namespaces in XML." well.

Format specification designers that declare namespaces thus provide a global context for instances of The discussion here should be seen as ancillary to the data format. Establishing this global context allows those instances (and portions thereof) content of [IETFXML] . Refer also to be re-used and combined in novel ways not yet imagined. Failure "XML Accessibility Guidelines" [XAG] for help designing XML formats that lower barriers to provide a namespace makes such re-use more difficult, perhaps impractical in some cases. Web accessibility for people with disabilities.

<div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a shape="rect" name="use-namespaces" id="use-namespaces"> deleted text: </div>

6.1. <a shape="rect" id="app-principles" name="app-principles"> Principles, Constraints, etc. 4.6. Future Directions for Formats

<span class="ednote"> Editor's note </span>: The TAG is still experimenting with the categorization of points in this document. This list is likely to change. It has also been suggested that the categories clearly indicate their primary audience. </p> <p> There remain open questions regarding resource representations. The important points of this document are categorized as follows: </p> <dl> <dt> <a shape="rect" name="cat-constraint" id="cat-constraint"> Constraint </a> </dt> <dd> An architectural constraint is following sections identify a restriction in behavior or interaction within the system. Constraints may be imposed for technical, policy, or other reasons. </dd> <dt> <a shape="rect" name="cat-design" id="cat-design"> Design Choice </a> </dt> <dd> In the design of the Web, some design choices, like the names of the <p> and <li> elements in HTML, or the choice few areas of the colon character future work in deleted text: URIs, are somewhat arbitrary; if <par>, <elt>, or <code> * </code> had been chosen instead, the large-scale result would, most likely, have been the same. Other design choices are more fundamental; these are Web community.

8.1. <a shape="rect" name="normative" id="normative"> Normative References 6.1. Internet Specifications

<a shape="rect" name="IANASchemes" id="IANASchemes"> IANASchemes

IANA's <a shape="rect" href="http://www.iana.org/assignments/uri-schemes"> online registry of URI Schemes is available at http://www.iana.org/assignments/uri-schemes.

<a shape="rect" href="http://www.w3.org/Addressing/schemes"> Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.

<a shape="rect" name="MEDIATYPEREG" id="MEDIATYPEREG"> MEDIATYPEREG

IANA's <a shape="rect" href="http://www.iana.org/assignments/media-types/index.html"> online registry of Internet Media Types is available at http://www.iana.org/assignments/media-types/index.html.

<a shape="rect" name="RFC2045" id="RFC2045"> RFC2045

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2045.txt"> RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies ", , N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt.

<a shape="rect" name="RFC2046" id="RFC2046"> RFC2046

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2046.txt"> RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", , N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt.

<a shape="rect" name="RFC2119" id="RFC2119"> RFC2119

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2119.txt"> RFC 2119: Key words for use in RFCs to Indicate Requirement Levels ", , S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.

<a shape="rect" name="URI" id="URI"> URI

"Uniform Uniform Resource Identifiers (URI): Generic Syntax" Syntax (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. The IETF Internet Draft <a shape="rect" href="http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html"> draft-fielding-uri-rfc2396bis-03 </a> is expected to obsolete <a shape="rect" href="http://www.ietf.org/rfc/rfc2396.txt"> RFC 2396 </a>, which is the current URI standard. "Architecture of the World Wide Web" uses the concepts and terms defined in draft-fielding-uri-rfc2396bis-03, preferring them to those defined in RFC 2396. The TAG Eds.) is tracking the evolution of draft-fielding-uri-rfc2396bis-03. currently being revised. Citations labeled [ URI ] refer to draft-fielding-uri-rfc2396bis-03 .

<a shape="rect" name="RFC2616" id="RFC2616"> RFC2616

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2616.txt"> RFC 2616: Hypertext Transfer Protocol — HTTP/1.1 ", , J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.

<a shape="rect" name="RFC2717" id="RFC2717"> RFC2717

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2717.txt"> Registration Procedures for URL Scheme Names ", , R. Petke, I. King, November 1999. Available at http://www.ietf.org/rfc/rfc2717.txt.

8.2. <a shape="rect" name="archspecs" id="archspecs"> 6.2. Architectural Specifications

<a shape="rect" name="ATAG10" id="ATAG10"> ATAG10

<a shape="rect" href="http://www.w3.org/TR/2000/REC-ATAG10-20000203/"> "Authoring Authoring Tool Accessibility Guidelines 1.0," 1.0 , J. Treviranus, C. McCathieNevile, I. Jacobs, deleted text: and J. Richards, eds., Editors, W3C Recommendation, 3 February 2000. This 2000, http://www.w3.org/TR/2000/REC-ATAG10-20000203 . Latest version available at http://www.w3.org/TR/ATAG10 .

UAAG10

User Agent Accessibility Guidelines 1.0 , I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/ . Latest version available at http://www.w3.org/TR/UAAG10/ .

XAG

XML Accessibility Guidelines , D. Dardailler, S. B. Palmer, C. McCathieNevile, Editors, W3C Working Draft (work in progress), 3 October 2002, http://www.w3.org/TR/2002/WD-xag-20021003 . Latest version available at http://www.w3.org/TR/xag .

CHARMOD

Character Model for the World Wide Web 1.0 , T. Texin, M. J. Dürst, F. Yergeau, R. Ishida, M. Wolf, Editors, W3C Working Draft (work in progress), 22 August 2003, http://www.w3.org/TR/2003/WD-charmod-20030822/ . Latest version available at http://www.w3.org/TR/charmod/ .

DIPRINCIPLES

Device Independence Principles , R. Gimson, Editors, W3C Working Group Note, 1 September 2003, http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ . Latest version available at http://www.w3.org/TR/di-princ/ .

QA

QA Framework: Specification Guidelines , D. Hazaël-Massieux, L. Henderson, L. Rosenthal, Editors, W3C Candidate Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/. (work in progress), 10 November 2003, http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/ . Latest version available at http://www.w3.org/TR/qaframe-spec/ .

WCAG20

Web Content Accessibility Guidelines 2.0 , W. Chisholm, G. Vanderheiden, J. White, B. Caldwell, Editors, W3C Working Draft (work in progress), 24 June 2003, http://www.w3.org/TR/2003/WD-WCAG20-20030624/ . Latest version available at http://www.w3.org/TR/WCAG20/ .

<a shape="rect" name="CHARMOD" id="CHARMOD"> CHARMOD WSA

<a shape="rect" href="http://www.w3.org/TR/2002/WD-charmod-20020430/"> "Character Model for the World Wide Web," Web Services Architecture , M. Dürst and Champion, C. Ferris, D. Orchard, D. Booth, H. Haas, F. Yergeau, eds., 30 April 2002. This McCabe, E. Newcomer, Editors, W3C Working Draft is http://www.w3.org/TR/2002/WD-charmod-20020430/. The <a shape="rect" href="http://www.w3.org/TR/charmod/"> latest (work in progress), 8 August 2003, http://www.w3.org/TR/2003/WD-ws-arch-20030808/ . Latest version deleted text: is available at http://www.w3.org/TR/charmod/. http://www.w3.org/TR/ws-arch/ .

<a shape="rect" name="DIPRINCIPLES" id="DIPRINCIPLES"> DIPRINCIPLES EXTLANG

<a shape="rect" href="http://www.w3.org/TR/2001/WD-di-princ-20010918/"> "Device Independent Principles," Web Architecture: Extensible Languages R. Gimson, Ed., 18 September 2001. , T. Berners-Lee, D. Connolly, 10 February 1998. This W3C Working Draft is http://www.w3.org/TR/2001/WD-di-princ-20010918/. The <a shape="rect" href="http://www.w3.org/TR/di-princ/"> latest version </a> Note is available at http://www.w3.org/TR/di-princ/. http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210.

<a shape="rect" name="Fielding" id="Fielding"> Fielding

" <a shape="rect" href="http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf"> Principled Design of the Modern Web Architecture ", , 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. This document is available at http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf.

<a shape="rect" name="RFC1958" id="RFC1958"> RFC1958

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc1958.txt"> RFC 1958: Architectural Principles of the Internet ", , B. Carpenter, June 1996. Available at http://www.ietf.org/rfc/rfc1958.txt.

<dt> <a shape="rect" name="QA" id="QA"> QA </a> </dt> <dd> <a shape="rect" href="http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/"> "QA Framework: Specification Guidelines," </a> D. Hazaël-Massieux, L. Henderson, L. Rosenthal, D. Dimitriadis, K. Gavrylyuk, eds., 10 February 2003.This W3C Working Draft is http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/. The <a shape="rect" href="http://www.w3.org/TR/qaframe-spec/"> latest version </a> is available at http://www.w3.org/TR/qaframe-spec/. </dd> <dt> <a shape="rect" name="UAAG10" id="UAAG10"> UAAG10 </a> </dt> <dd> <a shape="rect" href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/"> "User Agent Accessibility Guidelines 1.0," </a> I. Jacobs, J. Gunderson, E. Hansen, eds., 17 December 2002. This W3C Recommendation is http://www.w3.org/TR/2002/REC-UAAG10-20021217/. </dd> <dt> <a shape="rect" name="WCAG10" id="WCAG10"> WCAG10

6.3. Additional References </dt> <dd> <a shape="rect" href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/"> "Web Content Accessibility Guidelines 1.0," </a> W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This W3C Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/. </dd>

<a shape="rect" name="WSA" id="WSA"> WSA CGI

<a shape="rect" href="http://www.w3.org/TR/2003/WD-ws-arch-20030514/"> "Web Services Architecture," </a> D. Booth, M. Champion, C. Ferris, F. McCabe, E. Newcomer, D. Orchard eds., 14 May 2003. This W3C Working Draft is http://www.w3.org/TR/2003/WD-ws-arch-20030514/. The <a shape="rect" href="http://www.w3.org/TR/ws-arch/"> latest version </a> of this document is available at http://www.w3.org/TR/ws-arch/. </dd> <dt> <a shape="rect" name="XAG" id="XAG"> XAG Common Gateway Interface/1.1 Specification </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/2002/WD-xag-20021003"> XML Accessibility Guidelines </a> ", D. Dardailler, S. Palmer, C. McCathieNevile, 3 October 2002. This W3C Working Draft is http://www.w3.org/TR/2002/WD-xag-20021003. The <a shape="rect" href="http://www.w3.org/TR/xag"> latest version </a> is available . Available at http://www.w3.org/TR/xag. http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.

deleted text: </dl> </div> <div class="section"> <h3> 8.3. <a shape="rect" name="informative" id="informative"> Non-Normative References </a> </h3> <dl>

<a shape="rect" name="Cool" id="Cool"> Cool

" <a shape="rect" href="http://www.w3.org/Provider/Style/URI.html"> Cool URIs don't change " T. Berners-Lee, W3C, 1998 Available at http://www.w3.org/Provider/Style/URI. Note that the title is somewhat misleading. It is not the URIs that change, it is what they identify.

<a shape="rect" name="DAMLOIL" id="DAMLOIL"> DAMLOIL </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218"> DAML+OIL (March 2001) Reference Description </a> ", D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, 18 Dec 2001. This W3C Note is available at http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218. </dd> <dt> <a shape="rect" name="EXTLANG" id="EXTLANG"> EXTLANG Eng90

deleted text: " <a shape="rect" href="http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210"> Web Architecture: Extensible Languages </a>, T. Berners-Lee, D. Connolly, 10 February 1998. This W3C Note is available at http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210. </dd> <dt> <a shape="rect" name="Eng90" id="Eng90"> Eng90 </a> </dt> <dd> " <a shape="rect" href="http://www.bootstrap.org/augment/AUGMENT/132082.html"> Knowledge-Domain Interoperability and an Open Hyperdocument System ", , D. C. Engelbart, June 1990.

FREENET

The Free Network Project .

<a shape="rect" href="http://www.w3.org/Addressing/schemes"> Dan Connolly's list of URI schemes is a useful resource for finding out which references define various URI schemes.

<a shape="rect" name="IETFXML" id="IETFXML"> IETFXML

IETF " <a shape="rect" href="http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt"> Guidelines For The Use of XML in IETF Protocols </a>," , S. Hollenbeck, M. Rose, L. Masinter, eds., 2 November 2002. This IETF Internet Draft is available at http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. If this document is no longer available, refer to the <a shape="rect" href="http://www.imc.org/ietf-xml-use/index.html"> ietf-xml-use mailing list .

<a shape="rect" name="IRI" id="IRI"> IRI

IETF " <a shape="rect" href="http://www.w3.org/International/iri-edit/draft-duerst-iri.html"> Internationalized Resource Identifiers (IRIs)" </a>, (IRIs) , M. Duerst, M. Suignard, Nov 2002. This IETF Internet Draft is available at http://www.w3.org/International/iri-edit/draft-duerst-iri.html. If this document is no longer available, refer to the home page for <a shape="rect" href="http://www.w3.org/International/iri-edit/"> Editing 'Internationalized Resource Identifiers (IRIs)' .

<a shape="rect" name="OWL10" id="OWL10"> OWL10 </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/2003/CR-owl-ref-20030818/"> Web Ontology Language (OWL) Reference Version 1.0 </a> ", M. Dean and G. Schreiber, eds., 18 August 2003. This W3C Candidate Recommendation is available at http://www.w3.org/TR/2003/CR-owl-ref-20030818/. </dd> <dt> <a shape="rect" name="P3P10" id="P3P10"> P3P10 MLDONKEY

deleted text: " <a shape="rect" href="http://www.w3.org/TR/2002/REC-P3P-20020416/"> The Platform for Privacy Preferences 1.0 (P3P1.0) Specification MLDonkey Project ", M. Marchiori, ed., 16 April 2002. This W3C Recommendation is available at http://www.w3.org/TR/2002/REC-P3P-20020416/.

<a shape="rect" name="RDDL" id="RDDL"> RDDL

" <a shape="rect" href="http://www.tbray.org/tag/rddl/rddl3.html"> Resource Directory Description Language (RDDL) ", , J. Borden, T. Bray, eds., 1 June 2003. This document is available at http://www.tbray.org/tag/rddl/rddl3.html.

<a shape="rect" name="RDF10" id="RDF10"> RDF10 RELAXNG

" <a shape="rect" href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/"> Resource Description Framework (RDF) Model and Syntax Specification The RELAX NG ", O. Lassila, R. R. Swick, eds., 22 February 1999. This W3C Recommendation is available at http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. schema language project.

<a shape="rect" name="REST" id="REST"> REST

" <a shape="rect" href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm"> Representational State Transfer (REST) ", , Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. T. Fielding, 2000. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

<a shape="rect" name="RFC2141" id="RFC2141"> RFC977

IETF RFC 977: Network News Transfer Protocol , B. Kantor, P. Lapsley, February 1986. Available at http://www.ietf.org/rfc/rfc977.txt.

RFC2141

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2141.txt"> RFC 2141: URN Syntax ", , R. Moats, May 1997. Available at http://www.ietf.org/rfc/rfc2141.txt.

<a shape="rect" name="RFC2718" id="RFC2718"> RFC2326

IETF RFC 2326: Real Time Streaming Protocol (RTSP) , H. Schulzrinne, A. Rao, R. Lanphier, April 1998. Available at: http://www.ietf.org/rfc/rfc2326.txt.

RFC2718

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc2718.txt"> RFC 2718: Guidelines for new URL Schemes ", , L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.

<a shape="rect" name="RFC3023" id="RFC3023"> RFC3023 RFC2818

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc3023.txt"> RFC 3023: XML Media Types 2818: HTTP Over TLS ", M. Murata, S. St. Laurent, D. Kohn, January 2001. , E. Rescorla, May 2000. Available at: http://www.rfc-editor.org/rfc/rfc3023.txt http://www.ietf.org/rfc/rfc2818.txt.

<a shape="rect" name="RFC3236" id="RFC3236"> RFC3236 RFC3023

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc3236.txt"> RFC 3236: The 'application/xhtml+xml' 3023: XML Media Type Types ", , M. Baker, P. Stark, Murata, S. St. Laurent, D. Kohn, January 2002. 2001. Available at: http://www.rfc-editor.org/rfc/rfc3236.txt http://www.rfc-editor.org/rfc/rfc3023.txt

<a shape="rect" name="RFC3401" id="RFC3401"> RFC3401 RFC3236

IETF " <a shape="rect" href="http://www.ietf.org/rfc/rfc3401.txt"> RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: 3236: The Comprehensive DDDS 'application/xhtml+xml' Media Type ", , M. Mealing, October Baker, P. Stark, January 2002. Available at: http://www.rfc-editor.org/rfc/rfc3401.txt </dd> <dt> <a shape="rect" name="SOAP12" id="SOAP12"> SOAP12 </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/"> SOAP Version 1.2 Part 1: Messaging Framework </a> ", M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. Frystyk Nielsen, eds., 24 June 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. http://www.rfc-editor.org/rfc/rfc3236.txt

<a shape="rect" name="SVG11" id="SVG11"> SVG11 SAX

" <a shape="rect" href="http://www.w3.org/TR/2003/REC-SVG11-20030114/"> Scalable Vector Graphics (SVG) 1.1 Specification Resources related to the Simple API for XML ", J. Ferraiolo, Fujisawa Jun, D. Jackson, eds., 14 January 2003. This W3C Recommendation is available at http://www.w3.org/TR/2003/REC-SVG11-20030114/. ( SAX ).

<a shape="rect" name="UNICODE" id="UNICODE"> UNICODE

See the <a shape="rect" href="http://www.unicode.org/"> Unicode Consortium home page for information about the latest version of Unicode and character repertoires.

<a shape="rect" name="UniqueDNS" id="UniqueDNS"> UniqueDNS

" <a shape="rect" href="http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm"> IAB Technical Comment on the Unique DNS Root" </a>, Root , B. Carpenter, 27 September 1999. Available at http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.

<a shape="rect" name="XHTML10" id="XHTML10"> XHTML10 XMPP

deleted text: " <a shape="rect" href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/"> 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, revised 1 August 2002. Available at http://www.w3.org/TR/2002/REC-xhtml1-20020801/. </dd> <dt> <a shape="rect" name="XMLSCHEMA" id="XMLSCHEMA"> XMLSCHEMA </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/"> XML Schema Part 1: Structures </a> ", H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, 2 May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . </dd> <dt> <a shape="rect" name="XLink10" id="XLink10"> XLink10 </a> </dt> <dd> " <a shape="rect" 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 shape="rect" name="XML10" id="XML10"> XML10 </a> </dt> <dd> " <a shape="rect" 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 shape="rect" name="XMLNS" id="XMLNS"> XMLNS </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/1999/REC-xml-names-19990114/"> Namespaces in XML Messaging and Presence Protocol ( XMPP ) IETF Working Group deleted text: ", 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 shape="rect" name="XPTRFR" id="XPTRFR"> XPTRFR </a> </dt> <dd> " <a shape="rect" href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/"> XPointer Framework </a> ", P. Grosso, E. Maler, J. Marsh, N. Walsh, eds., 25 March 2003. This W3C Recommendation developing "an open, XML-based protocol for near real-time extensible messaging and presence. It is available at http://www.w3.org/TR/2003/REC-xptr-framework-20030325/. the core protocol of the Jabber Instant Messaging and Presence technology..."