Architecture of the World Wide Web, First Edition

List of Principles Principles, Constraints, and Good Practice Notes

The following principles principles, constraints, and good practice notes explained are discussed in this document are and listed here for convenience. There is also a free-standing summary .

General Architecture Principles

<ol>

• Error recovery (principle, 1.2.3)
</ol>

Identification

<ol>

• Identify with URIs (constraint, 2)
• URI assignment (principle, 2)
• <a href="#design-mult-URI"> URI uniqueness multiplicity (constraint, 2.1)
• <a href="#uri-aliases"> Avoiding URI aliases (practice, 2.1.1)
• Consistent URI usage (practice, 2.1.1)
• <a href="#pr-uri-ambiguity"> Avoiding URI ambiguity Overloading (practice, 2.2)
• New URI schemes (practice, 2.4)
• URI opacity (practice, 2.5)
</ol>

Interaction

<ol>

• Fragment identifier consistency (practice, 3.3.2)
• Authoritative deleted text: server metadata (principle, 3.4.1)
• Safe retrieval (principle, 3.5)
• Consistent representation (practice, 3.6)
• Available representation (practice, 3.6.1)
</ol>

Data Formats

<ol>

• Version information (practice, 4.2.1)
• Namespace policy (practice, 4.2.2)
• Extensibility mechanisms (practice, 4.2.3)
• Unknown extensions (practice, 4.2.3)
• Separation of content, presentation, interaction (practice, 4.3)
• Link mechanisms (practice, 4.4)
• Web linking (practice, 4.4)
• Generic URIs (practice, 4.4)
• Hypertext links (practice, 4.4)
• Namespace adoption (practice, 4.5.3)
• Namespace documents (practice, 4.5.4)
• QNames Indistinguishable from URIs (practice, 4.5.5)
• QName Mapping (practice, 4.5.5)
• XML and "text/*" (practice, 4.5.7)
• XML and character encodings (practice, 4.5.7)
</ol>

1.1. About this Document

This document describes 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.

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in the principles, constraints, and good practice notes, principles, etc. notes in accordance with RFC 2119 [ RFC2119 ]. However, this document does not include conformance provisions for deleted text: 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 of a conformance section is not likely to increase the utility of the document.

1.2. General Architecture Principles

A number of its principles could guide their design: statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs. </p> </div> </div> <div class="section"> <h3> 1.2. <a name="general" id="general" shape="rect"> General Architecture Principles </a> </h3> <p> A number of general architecture general architecture principles apply to deleted text: across all three bases of Web architecture.

2.1. URI Comparisons

The most straightforward way of establishing that two parties are referring to the same resource is to compare, character-by-character, the URIs they are using. Two URIs that are identical (character for character) refer to the same resource. However, Web architecture allows resource owners people to assign more than one URI to a resource.

Thus, Consequently, two URIs that are not identical (character for character) can still refer to the same resource (i.e., they do not necessarily refer to different resources. The most straightforward way resources).

To reduce the risk of establishing a false negative comparison (i.e., an incorrect conclusion that two parties are referring URIs do not refer to the same Web resource is resource) or a false positive comparison (i.e., an incorrect conclusion that two URIs do refer to deleted text: compare, as character strings, the same resource), certain specifications license applications to apply tests in addition to character-by-character comparison. For example, for "http" URIs, the authority component (the part after "//" and before the next "/") is defined to be case-insensitive. Thus, the "http" URI specification licenses applications to conclude that authority components in two "http" URIs deleted text: they are using. equivalent when those strings are character-by-character equivalent or differ only by case. By following the "http" URI specification, agents are licensed to conclude that "http://Weather.Example.Com/Oaxaca" and "http://weather.example.com/Oaxaca" identify the same resource.

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 "http://weather.example.com/Oaxaca" and "http://weather.example.com/OAXACA" identify the same resource, since none of the specifications involved states that the path component of an "http" URI deleted text: equivalence is discussed in section case-insensitive.

Section 6 deleted text: of [ URI ] provides more information about comparing URIs and reducing the risk of false negatives and positives. See the section below on approaches other than string comparison that allow different parties to assert that two URIs identify the same resource .

2.2. <a name="uri-ownership" id="uri-ownership" shape="rect"> URI Ownership Overloading

The requirement for URIs to be <a href="#URI-ambiguity" shape="rect"> unambiguous </a> demands that At times, different agents do not assign intentionally or unintentionally use the same URI to identify different resources. <a href="#URI-scheme" shape="rect"> URI scheme overloading specifications assure this using a variety of techniques, including: </p> <ul> <li> Hierarchical delegation of authority. This approach, exemplified by refers to the "http" and "mailto" schemes, allows use, in the assignment context of a part Web protocols and formats, of one URI deleted text: space to refer to more than one party, reassignment of resource. Just as promoting a piece of shared vocabulary has tangible value, overloading often imposes a cost in communication.

Suppose that space one organization uses a URI on their site to refer to deleted text: another, and so forth. </li> <li> Random numbers. The generation of a fairly large random number, used in the "uuid" scheme, reduces movie "The Sting", and another organization uses the risk of ambiguity to a calculated small risk. </li> <li> Checksums. The generation of a same URI deleted text: 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. </li> <li> Combination of approaches. The "mid" and "cid" schemes combine some refer to a resource that talks about "The Sting." Inconsistent use of the deleted text: above approaches. </li> </ul> <p> The approach taken for the "http" URI scheme follows the pattern whereby the Internet community delegates authority, via creates confusion about what the deleted text: IANA URI scheme registry [ <a href="#IANASchemes" shape="rect"> IANASchemes </a> ] and identifies. In many contexts, inconsistent use may not lead to error or cause harm. However, in some contexts such as the DNS, over a set Semantic Web, software relies on consistent use of URIs with a common prefix to URIs. If one particular owner. One consequence of this approach is wanted to talk about the Web's heavy reliance on creation date of the central DNS registry. </p> <p> Whatever resource identified by the techniques used, except URI, for instance, it would not be clear whether this meant "when the checksum case, movie created" or "when the agent has a unique relationship with resource about the URI, called <a name="def-uri-ownership" id="def-uri-ownership"> movie was created."

The social implications of section below on URI ownership are not discussed here. However, examines approaches for establishing the success or failure authoritative source of these different approaches depends on the extent to which there is consensus in the Internet community on abiding by the defining specifications. The concept of URI ownership is especially visible in the case of the HTTP protocol, which enables the URI owner to serve <a href="#authoritative-metadata" shape="rect"> authoritative representations </a> of a resource. In this case, the HTTP origin server (defined in [ <a href="#RFC2616" shape="rect"> RFC2616 </a> ]) is the agent acting on behalf of the URI owner. </p> </div> <div class="section"> <h3> 2.3. <a name="URI-ambiguity" id="URI-ambiguity" shape="rect"> URI Ambiguity </a> </h3> <p> Just as a shared vocabulary has tangible value, the ambiguous use of terms imposes information about what resource a deleted text: cost in communication. <a name="def-uri-ambiguity" id="def-uri-ambiguity"> <dfn> URI ambiguity </dfn> </a> refers to the use of the same URI to refer to more than one distinct resource. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="pr-uri-ambiguity" id="pr-uri-ambiguity" shape="rect"> URI ambiguity </a> </span> </p> <p class="practice"> Avoid URI ambiguity. </p> </div> <p> URI ambiguity should not be confused with ambiguity in natural language. The English statement "'http://www.example.com/moby' identifies 'Moby Dick'" is ambiguous because one could understand the phrase "Moby Dick" to refer to 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 <a href="http://ibiblio.org/gutenberg/etext01/moby10b.txt" shape="rect"> Gutenberg project's online version </a>. identifies.

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

In the URI "http://weather.example.com/", the "http" The requirement that appears before URIs not be overloaded (explained below) demands that different agents do not assign the colon (":") names a same URI scheme. Each to different resources. URI scheme has a normative specification that explains how identifiers are assigned within that scheme. The URI syntax is thus specifications assure this using a federated and extensible naming mechanism wherein each scheme's specification may further restrict the syntax and semantics of identifiers within that scheme. </p> <p> Examples variety of URIs from various schemes include: techniques, including:

• mailto:joe@example.org </li> <li> ftp://example.org/aDirectory/aFile </li> <li> news:comp.infosystems.www </li> <li> tel:+1-816-555-1212 </li> <li> ldap://ldap.example.org/c=GB?objectClass?one </li> <li> urn:oasis:names:tc:entity:xmlns:xml:catalog </li> </ul> <p> While Hierarchical delegation of authority. This approach, exemplified by the Web architecture "http" and "mailto" schemes, allows the definition assignment of deleted text: new schemes, introducing a new scheme is costly. Many aspects part of URI processing are scheme-dependent, and space to one party, reassignment of a significant amount piece of deployed software already processes URIs that space to another, and so forth.
• Large numbers. The generation of deleted text: well-known schemes. Introducing a new URI scheme requires fairly large random number or a checksum reduces the development and deployment not only risk of client software URI overloading to handle the scheme, but a calculated small risk. A draft "uuid" scheme adopted this approach; one could also imagine a scheme based on md5 checksums.
• Combination of ancillary agents such as gateways, proxies, approaches. The "mid" and caches. See [ <a href="#RFC2718" shape="rect"> RFC2718 </a> ] "cid" schemes combine some of the above approaches.

The approach taken for other considerations and costs related to the "http" URI scheme design. </p> <p> Because of these costs, if a follows the pattern whereby the Internet community delegates authority, via the IANA URI scheme exists that meets the needs of an application, designers should use it rather than invent one. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="pr-new-scheme-expensive" id="pr-new-scheme-expensive" shape="rect"> New URI schemes registry [ IANASchemes </span> </p> <p class="practice"> Authors of specifications SHOULD NOT introduce a new URI scheme when an existing scheme provides the desired properties of identifiers ] and deleted text: their relation to resources. </p> </div> <p> Consider our <a href="#scenario" shape="rect"> travel scenario </a>: should the authority providing information about the weather in Oaxaca register DNS, over a new URI scheme "weather" for the identification set of deleted text: resources related to the weather? They might then publish URIs such as "weather://travel.example.com/oaxaca". When a software agent dereferences such with a URI, if what really happens is that HTTP GET is invoked common prefix to retrieve a representation one particular owner. One consequence of this approach is the resource, then an "http" URI would have sufficed. Web's heavy reliance on the central DNS registry.

If the motivation behind registering Except when a new scheme URI is to allow constructed from a software agent checksum, all of the techniques seek to launch establish a particular application when retrieving unique relationship between a representation, such dispatching can be accomplished at lower expense via Internet Media Types. When designing social entity and a new data format, URI. This relationship is called URI ownership . In this document, the appropriate mechanism to promote its deployment on phrase "authority responsible for domain X" indicates that the Web same entity owns those URIs where the authority component is domain X. This document does not address how the Internet Media Type. benefits and responsibilities of URI ownership may be delegated to other parties (e.g., to individuals managing an HTTP server).

Note that even if an agent cannot process representation data in an unknown format, it can at least retrieve it. The data A URI owner may contain enough information to allow a user or user agent to make some use provide representations of it. the resource identified by the URI upon request. When an the HTTP protocol is used to provide representations, the HTTP origin server (defined in [ RFC2616 ]) is the software agent does not handle a new acting on behalf of the URI scheme, it cannot retrieve owner. The URI owner has a representation. privileged position in the Web architecture as the entity that assigns authoritative metadata to such representations; see the section on authoritative metadata for more information. There are also social expectations for responsible representation management by URI owners. Additional social implications of URI ownership are not discussed here. However, the success or failure of these different approaches depends on the extent to which there is consensus in the Internet community on abiding by the defining specifications.

2.4. URI Scheme Registration Schemes </h4>

The Internet Assigned Numbers Authority ( <acronym> IANA </acronym> ) maintains a registry [ <a href="#IANASchemes" shape="rect"> IANASchemes </a> ] of mappings between In the URI scheme names and scheme specifications. For instance, "http://weather.example.com/", the IANA registry indicates "http" that appears before the "http" scheme is defined in [ <a href="#RFC2616" shape="rect"> RFC2616 </a> ]. The process for registering colon (":") names a new URI scheme. Each URI scheme is defined in [ <a href="#RFC2717" shape="rect"> RFC2717 </a> ]. </p> <p> has a normative specification that explains how identifiers are assigned within that scheme. The deleted text: use of unregistered URI schemes syntax is discouraged for thus a number federated and extensible naming mechanism wherein each scheme's specification may further restrict the syntax and semantics of reasons: identifiers within that scheme.

Examples of URIs from various schemes include:

• There is no generally accepted way to locate the scheme specification. mailto:joe@example.org
• Someone else may be using the scheme for other purposes. ftp://example.org/aDirectory/aFile
• One should not expect that general-purpose software will do anything useful with URIs of this scheme; the network effect is lost. news:comp.infosystems.www
• tel:+1-816-555-1212
• ldap://ldap.example.org/c=GB?objectClass?one
• urn:oasis:names:tc:entity:xmlns:xml:catalog

<strong> Note: </strong> Some URI scheme specifications (such as the "ftp" URI scheme specification) use While the term "designate" where Web architecture allows the current document uses "identify." </p> <p> TAG issue <a href="http://www.w3.org/2001/tag/issues.html#siteData-36" shape="rect"> siteData-36 </a> is about expropriation definition of naming authority. </p> </div> </div> <div class="section"> <h3> 2.5. <a name="uri-opacity" id="uri-opacity" shape="rect"> URI Opacity </a> </h3> <p> It new schemes, introducing a new scheme is tempting to guess the nature costly. Many aspects of URI processing are scheme-dependent, and a resource by inspection significant amount of deployed software already processes URIs of well-known schemes. Introducing a new URI that identifies it. However, scheme requires the Web is designed so that agents communicate resource state through <a href="#def-representation" shape="rect"> representations </a>, development and deployment not identifiers. In general, one cannot determine only of client software to handle the Internet Media Type scheme, but also of representations ancillary agents such as gateways, proxies, and caches. See [ RFC2718 ] for other considerations and costs related to URI scheme design.

Because of a resource by inspecting these costs, if a URI for scheme exists that resource. For example, meets the ".html" at the end of "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 PNG or any other data format for that URI. </p> <p> Resource state may evolve over time. Requiring resource owners to change URIs to reflect resource state would lead to a significant number needs of deleted text: broken links. For robustness, Web architecture promotes independence between an identifier and the identified resource. application, designers should use it rather than invent one.

The example URI used in the Consider our travel scenario </a> ("http://weather.example.com/oaxaca") suggests that the identified resource has something to do with : should the weather in Oaxaca. A site reporting agent providing information about the weather in Oaxaca could just as easily be identified by the register a new URI "http://vjc.example.com/315". And scheme "weather" for the URI "http://weather.example.com/vancouver" identification of resources related to the weather? They might identify then publish URIs such as "weather://travel.example.com/oaxaca". When a software agent dereferences such a URI, if what really happens is that HTTP GET is invoked to retrieve a representation of the resource "my photo album." resource, then an "http" URI would have sufficed.

On the other hand, If the URI "mailto:joe@example.com" indicates that the URI refers to motivation behind registering a mailbox. The "mailto" URI new scheme specification authorizes agents is to infer that URIs of this form identify allow a software agent to launch a particular application when retrieving a representation, such dispatching can be accomplished at lower expense via Internet mailboxes. media types. When designing a new data format, the appropriate mechanism to promote its deployment on the Web is the Internet media type.

In some cases, relevant technical specifications license URI assignment authorities to publish assignment policies. For more Note that even if an agent cannot process representation data in an unknown format, it can at least retrieve it. The data may contain enough information about to allow a user or user agent to make some use of it. When an agent does not handle a new URI opacity, see TAG issue <a href="http://www.w3.org/2001/tag/ilist#metadataInURI-31" shape="rect"> metaDataInURI-31 </a>. scheme, it cannot retrieve a representation.

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

There remain open questions regarding identifiers on the Web. The following sections identify a few areas of future work in It is tempting to guess the Web community. </p> <div class="section"> <h4> 2.7.1. <a id="i18n-id" name="i18n-id" shape="rect"> Internationalized Identifiers </a> </h4> <p> The integration of internationalized identifiers (i.e., composed nature of characters beyond those allowed a resource by [ <a href="#URI" shape="rect"> inspection of a URI </a> ]) into that identifies it. However, the Web deleted text: architecture is an important and open issue. See TAG issue <a href="http://www.w3.org/2001/tag/ilist#IRIEverywhere-27" shape="rect"> IRIEverywhere-27 </a> designed so that agents communicate resource state through representations , not identifiers. In general, one cannot determine the Internet media type of representations of a resource by inspecting a URI for deleted text: discussion about work going on in this area. </p> </div> <div class="section"> <h4> 2.7.2. <a name="future-comparison" id="future-comparison" shape="rect"> Assertion that Two URIs Identify resource. For example, the Same Resource </a> </h4> <p> Emerging Semantic Web technologies, including ".html" at the "Web Ontology Language (OWL)" [ <a href="#OWL10" shape="rect"> OWL10 </a> ], define RDF [ <a href="#RDF10" shape="rect"> RDF10 </a> ] properties such as <code> sameAs </code> to assert end of "http://example.com/page.html" provides no guarantee that two URIs identify representations of the same identified resource or <code> functionalProperty </code> 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 URI owner is free to imply it. configure the server to return a representation using PNG or any other data format.

Communication between agents Resource state may evolve over time. Requiring a network about resources involves URIs, messages, URI owner to publish a new URI for each change in resource state would lead to a significant number of broken links. For robustness, Web architecture promotes independence between an identifier and data. the identified resource.

The example URI and determines that its <a href="#URI-scheme" shape="rect"> scheme used in the travel scenario is "http". The browser configuration determines how it locates ("http://weather.example.com/oaxaca") suggests that the identified information, which might be via a cache of prior retrieval actions, by contacting an intermediary (such as a proxy server), or by direct access resource has something to do with the server weather in Oaxaca. A site reporting the weather in Oaxaca could just as easily be identified by the URI. In this example, URI "http://vjc.example.com/315". And the browser opens URI "http://weather.example.com/vancouver" might identify the resource "my photo album."

On the other hand, the URI "mailto:joe@example.com" indicates that the URI refers to a network connection mailbox. The "mailto" URI scheme specification authorizes agents to port 80 on 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 TAG issue metaDataInURI-31 .

2.6. Fragment Identifiers

This section describes the architectural principles and constraints regarding interactions between agents, including such topics as network protocols and interaction styles, along with interactions between the Web as The fragment identifier component of a system and the people that make use URI allows indirect identification of deleted text: it. The fact that the Web is a highly distributed system affects architectural constraints and assumptions about interactions. </p> <p> <strong> Note: </strong> The Web Architecture does not require secondary resource by reference to a formal definition primary resource and additional identifying information. The secondary resource may be some portion or subset of the commonly used phrase "on primary resource, some view on representations of the Web." Informally, a primary resource, or some other resource defined or described by those representations. The interpretation of fragment identifiers is "on discussed in the Web" when it has a URI section on media types and an agent can use the URI to retrieve a representation of it using network protocols (given appropriate access privileges, network connectivity, etc.). fragment identifier semantics .

See deleted text: the related TAG issue <a href="http://www.w3.org/2001/tag/ilist.html#httpRange-14" shape="rect"> httpRange-14 issues abstractComponentRefs-37 and DerivedResources-43 .

3.1. <a name="dereference-uri" id="dereference-uri" shape="rect"> Using a URI to Access a Resource 2.7. Future Directions for Identifiers

Agents may use a URI to access the referenced resource; this is called <a name="uri-dereference" id="uri-dereference"> <dfn> dereferencing There remain open questions regarding identifiers on the URI </dfn> </a>. Access may take many forms, including retrieving Web. The following sections identify a representation of resource state (for instance, by using HTTP GET or HEAD), modifying the state few areas of future work in the resource (for instance, by using HTTP POST or PUT), and deleting the resource (for instance, by using HTTP DELETE). Web community.

3.1. Using a URI to Access a Resource ])

Agents may use a URI to retrieve access the representation. </li> <li> Section 6 of [ <a href="#RFC2616" shape="rect"> RFC2616 </a> ] defines how referenced resource; this is called dereferencing the server constructs a corresponding response message, URI . Access may take many forms, including retrieving a representation of the 'Content-Type' field. </li> <li> Section 1.4 state of deleted text: [ <a href="#RFC2616" shape="rect"> RFC2616 </a> ] states "HTTP communication usually takes place over TCP/IP connections." This example does not address that step in the process, resource (for instance, by using HTTP GET or other steps such as Domain Name System ( <acronym> DNS </acronym> ) resolution. </li> <li> The agent interprets the returned HEAD), adding or modifying a representation according to the data format specification that corresponds to of the representation's <a href="#internet-media-type" shape="rect"> Internet Media Type </a> (the value state of the resource (for instance, by using HTTP 'Content-Type') POST or PUT, which in some cases may change the relevant IANA registry [ <a href="#MEDIATYPEREG" shape="rect"> MEDIATYPEREG </a> ]. </li> </ol> </div> <div class="section"> <h3> 3.2. <a name="msg-representation" id="msg-representation" shape="rect"> Messages and Representations </a> </h3> <p> The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) are based on the exchange actual state of deleted text: messages. A <a name="def-message" id="def-message"> <dfn> message </dfn> </a> may include representation data as well as metadata about the resource (such as the "Alternates" and "Vary" HTTP headers), if the representation, submitted representations are interpreted as instructions to that end), and deleting some or all representations of the message (such as state of the "Transfer-encoding" resource (for instance, by using HTTP header). A message DELETE, which in some cases may even include metadata about result in the message metadata (for message-integrity checks, for instance). deletion of the resource itself).

Two important classes of message are those that request a representation of a resource, and those that return the result of such a request. Such There may be more than one way to access a response message (for example, resource for a response to given URI; application context determines which access mechanism an agent uses. For instance, a browser might use HTTP GET) includes GET to retrieve a deleted text: <a name="def-representation" id="def-representation"> <dfn> representation </dfn> </a> of the state of the resource. A representation deleted text: is an octet sequence that consists logically of two parts: </p> <ol> <li> <a name="representation-data" id="representation-data"> <dfn> Representation data </dfn> </a>, electronic data about resource state, expressed in one or more <a href="#formats" shape="rect"> formats </a> used separately or in combination, and </li> <li> <a name="representation-metadata" id="representation-metadata"> <dfn> Representation metadata </dfn> </a>. One important piece of metadata is the <a href="#internet-media-type" shape="rect"> Internet Media Type </a>, discussed below. </li> </ol> <p> Agents a resource, whereas a link checker might use deleted text: representations to modify as well as retrieve resource state. Note that even though the response to an HTTP POST request may contain the above types of data, HEAD on the response same URI simply to an HTTP POST request is not necessarily establish whether a representation of the state of the resource identified in is available. Some URI schemes set expectations about available access mechanisms, others (such as the POST request. </p> </div> <div class="section"> <h3> 3.3. <a id="internet-media-type" name="internet-media-type" shape="rect"> Internet Media Type </a> </h3> <p> The Internet Media Type URN scheme [ <a href="#RFC2046" shape="rect"> RFC2046 RFC 2141 ]) do not. Section 1.2.2 of a representation determines which data format specification(s) provide [ URI ] discusses the authoritative interpretation separation of the representation data (including <a href="#media-type-fragid" shape="rect"> fragment identifier syntax identification and semantics </a>, if any). The IANA registry [ <a href="#MEDIATYPEREG" shape="rect"> MEDIATYPEREG </a> ] maps media types to <a href="#formats" shape="rect"> data formats </a>. </p> <p> See interaction in more detail. For more information about relationships between multiple access mechanisms and URI addressability, see the TAG finding " <a href="http://www.w3.org/2001/tag/2002/0129-mime" shape="rect"> Internet Media Type registration, consistency of URIs, Addressability, and the use </a> " </cite> for more information about media type registration. </p> <div class="section"> <h4> 3.3.1. <a id="media-type-fragid" name="media-type-fragid" shape="rect"> Media Types of HTTP GET and Fragment Identifier Semantics POST </h4> <div class="boxedtext"> <p> <span class="storylab"> Story </span> " .

In one of his XHTML pages, Dirk links to an image Although many URI schemes are named after protocols, this does not imply that Nadia has published on the Web. He creates a hypertext link with <code> <a href="http://www.example.com/images/nadia#hat">Nadia's hat</a> </code>. Nadia serves an SVG representation use of such a URI will necessarily result in access to the image (with Internet Media Type "image/svg+xml"), so resource via the authoritative interpretation 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 fragment identifier "hat" depends on protocol associated with the SVG specification. scheme name.

Per [ <a href="#URI" shape="rect"> URI </a> ], in order to know the authoritative interpretation of Dereferencing a deleted text: fragment identifier, one must dereference the URI containing the fragment identifier. The Internet Media Type generally involves a succession of steps as described in multiple independent specifications and implemented by the retrieved representation specifies agent. The following example illustrates the authoritative interpretation series of the fragment identifier. Thus, in the case specifications that are involved when a user instructs a user agent to follow a hypertext link that is part of Dirk and Nadia, the authoritative interpretation depends on the an SVG specification, not document. In this example, the XHTML specification (i.e., URI is "http://weather.example.com/oaxaca" and the application context where calls for the URI appears). </p> <p> Given a URI "U#F", user agent to retrieve and render a representation deleted text: retrieved by dereferencing URI "U", the ( <a href="#def-secondary-resource" shape="rect"> secondary </a> ) resource identified by "U#F" is determined by interpreting "F" according to the specification associated with the Internet Media Type of the representation. identified resource.

1. Since the fragment identifier during a retrieval action URI is performed solely by the agent; part of a hypertext link in an SVG document, the fragment identifier first relevant specification is deleted text: not passed to other systems during the process SVG 1.1 Recommendation [ SVG11 ]. Section 17.1 of retrieval. This means that some intermediaries in this specification imports the Web architecture (such as proxies) have no interaction with fragment identifiers and that redirection (in HTTP link semantics defined in XLink 1.0 [ <a href="#RFC2616" shape="rect"> RFC2616 XLink10 ], for example) does not account ]: "The remote resource (the destination for them. </p> <p> Note that one can use the link) is defined by a URI with specified by the XLink href attribute on the 'a' element." The SVG specification goes on to state that interpretation of an a fragment identifier even if one does not have element involves retrieving a representation available for interpreting of a resource, identified by the href attribute in the XLink namespace: "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 ] specification, which defines the href attribute in section 5.4, states that "The value of the href attribute must be a URI reference as defined in [IETF RFC 2396], or must result in a URI reference after the escaping procedure described below is applied."
3. The URI specification [ URI ] states that "Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme." The URI scheme name in this example is "http".
4. [ IANASchemes ] states that the "http" scheme is defined by the HTTP/1.1 specification (RFC 2616 [ RFC2616 ], section 3.2.2).
5. In this SVG context, the agent constructs an HTTP GET request (per section 9.3 of [ RFC2616 ]) to retrieve the representation.
6. Section 6 of [ RFC2616 ] defines how the 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 step in the process, or other steps such as Domain Name System ( DNS ) resolution.
8. The agent interprets the returned representation according to the data format specification that corresponds to the representation's Internet Media Type (the value of the HTTP 'Content-Type') in the relevant IANA registry [ MEDIATYPEREG ].

3.2. Messages and Representations

The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP) are based on the exchange of messages. A message may include representation data as well as metadata about the resource (such as the "Alternates" and "Vary" HTTP headers), the representation, and the message itself (such as the "Transfer-encoding" HTTP header). A message may even include metadata about the message metadata (for message-integrity checks, for instance).

Two important classes of message are those that request a representation of a resource, and those that return the result of such a request. Such a response message (for example, a response to an HTTP GET) includes a representation of the resource. A representation is an octet sequence that consists logically of two parts:

1. Representation data , data about resource state, expressed in one or more formats used separately or in combination, and
2. Representation metadata . One important piece of metadata is the Internet media type , discussed below.

Agents use representations to modify as well as retrieve resource state. Note that even though the response to an HTTP POST request may contain the above types of data, the response to an HTTP POST request is not necessarily a representation of the resource identified in the POST request.

3.3. Internet Media Type

The Internet media type [ RFC2046 ]) of a representation determines which data format specification(s) provide the authoritative interpretation of the representation data (including fragment identifier syntax and semantics , if any). The IANA registry [ MEDIATYPEREG ] maps media types to data formats .

See the TAG finding " Internet media type registration, consistency of use " for more information about media type registration.

3.4. Authoritative Representation Metadata

Successful communication between two parties using a piece of information relies on shared understanding of the meaning of the information. Arbitrary numbers of independent parties can identify and communicate about a resource. To give these parties the confidence that they are all talking about the same thing when they refer to "the resource identified by the following URI ..." the design choice for the Web is, in general, that metadata provided by a message sender is authoritative. When a message is a response to a request for a representation of a resource identified by a given URI, the representation metadata provided by the owner of that URI is authoritative for that representation data.

In our travel scenario , the owner of "http://weather.example.com/oaxaca" provides the authoritative metadata for representations retrieved for that URI. Precisely which representation(s) Nadia receives depends on a 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 or more representations for the resource identified by "http://weather.example.com/oaxaca";
3. Whether Nadia has access privileges to such representations (see the section on linking and access control );
4. If the authority responsible for "weather.example.com" has provided more than one representation (in different formats such as HTML, PNG, or RDF; in different languages such as English and Spanish; or transformed dynamically according to the hardware or software capabilities of the recipient), 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.

Note that the choice and expressive power of a format can affect how precisely a representation provider communicates resource state. The use of natural language to communicate resource state may lead to ambiguity about what the associated resource is. This ambiguity can in turn lead to URI overloading .

See TAG issues contentTypeOverride-24 and rdfURIMeaning-39 .

3.5. Safe Interactions

Nadia's retrieval of weather information (an example of a read-only query or lookup) qualifies as a "safe" interaction; a safe interaction is one where the interpretation 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.

Other Web interactions resemble orders more than queries. These unsafe interactions may cause a change to the state of a resource and the user may be held responsible for the consequences of these interactions. Unsafe interactions include subscribing to a newsletter, posting to a fragment identifier without retrieving list, or modifying a representation do so at their own risk; such interpretations are database. Note: In this context, the word "unsafe" does not authoritative. </p> </div> <div class="section"> <h4> 3.3.2. <a name="frag-multiple-reps" id="frag-multiple-reps" shape="rect"> Fragment Identifiers and Multiple Representations mean "dangerous"; the term "safe" is used in section 9.1.1 of [ RFC2616 </h4> ] and "unsafe" is the natural opposite.

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

For instance, it is incorrect to publish a link that, when followed, subscribes a user to a mailing list. Remember that search engines may follow such links.

On the other hand, it is considered an error if For more information about safe and unsafe operations using HTTP GET and POST, and handling security concerns around the semantics use of HTTP GET, see the fragment identifiers used in two representations TAG finding " URIs, Addressability, and the use of a secondary resource are inconsistent. HTTP GET and POST " .

3.6. Representation Management

The actual character encoding usefulness of a representation URI depends on good management by its owner. As is deleted text: inconsistent with the charset parameter in the representation metadata. </li> <li> case with many human interactions, confident interactions with a resource depend on stability and predictability. The namespace value of a URI increases with the root element predictability of XML representation data interactions using that URI. Avoiding unnecessary URI aliases is inconsistent with the value one aspect of the 'Content-Type' field in HTTP headers. </li> </ul> <p> User agents should detect such inconsistencies but should not resolve them without involving the user. proper resource management.

Furthermore, server managers can help reduce the risk of error through careful assignment This section discusses important aspects of representation metadata (especially that which applies across representations). The section on <a href="#xml-media-types" shape="rect"> media types for XML management.

HTTP [ RFC2616 ] has been designed to help manage URIs. For example, HTTP redirection (using the results of Nadia's request. The representation data is in XHTML so 3xx response codes) permits servers to tell an agent that it can further action needs to be saved or printed out for Nadia's records. Note that neither the data transmitted with the POST nor taken by the data received agent in the response necessarily correspond order to any fulfill the request (for example, the resource named by a URI. </p> </div> </div> <p> Nadia's retrieval of weather information (an example of has been assigned a read-only query or lookup) qualifies new URI). In addition, content negotiation also promotes consistency, as a "safe" interaction; a <a name="def-safe-interaction" id="def-safe-interaction"> <dfn> safe interaction </dfn> </a> site manager is deleted text: one where the agent does not incur any obligation beyond the interaction. An agent may incur an obligation through other means required to define new URIs when adding support for a new format specification. Protocols that do not support content negotiation (such as by signing FTP) require a contract). If an agent does not have an obligation before new identifier when a safe interaction, it does not have that obligation afterwards. new data format is introduced.

Other Web interactions resemble orders For more than queries. These <a name="def-unsafe-interaction" id="def-unsafe-interaction"> <dfn> unsafe interactions </dfn> discussion about URI persistence, see [ Cool may cause a change to the state of a resource and the user may be held responsible for the consequences of these interactions. Unsafe interactions include subscribing to a newsletter, posting to a list, or modifying a database. ].

3.6.3. Linking and browsers that pre-cache data for the user) can follow links safely. Users (or agents acting on their behalf) do not commit themselves Access Control

It is reasonable to limit access to deleted text: anything by querying a resource (for commercial or following a link. </p> <div class="boxedtext"> <p> <span class="principlelab"> Principle: <a name="pr-deref-safe" id="pr-deref-safe" shape="rect"> Safe retrieval </a> </span> </p> <p class="principle"> Agents do not incur obligations by retrieving a representation. </p> </div> <p> For instance, security reasons, for example), but it is incorrect unreasonable to publish a link that, when followed, subscribes prohibit others from merely identifying the resource.

As an analogy: The owners of a user to building might have a mailing list. Remember policy that search engines the public may follow such links. </p> <p> For more information about safe and unsafe operations using HTTP GET and POST, only enter the building via the main front door, and handling security concerns around only during business hours. People who work in the building and who make deliveries to it might use other doors as appropriate. Such a policy would be enforced by a combination of HTTP GET, see the TAG finding <cite> " <a href="http://www.w3.org/2001/tag/doc/whenToUseGet.html" shape="rect"> URIs, Addressability, security personnel and mechanical devices such as locks and pass-cards. One would not enforce this policy by hiding some of the building entrances, nor by requesting legislation requiring the use of HTTP GET the front door and POST </a> " </cite>. forbidding anyone to reveal the fact that there are other doors to the building.

It is a breakdown of the The Web architecture if agents cannot use URIs to reconstruct a "paper trail" of transactions, i.e., to refer provides several mechanisms to receipts and other evidence of accepting an obligation. Indeed, each electronic mail message includes a unique message identifier, one reason why email is so useful for managing accountability (since, for example, email can be copied control access to public archives). On the other hand, HTTP servers and deployed user agents resources; these mechanisms do not generally keep records of POST transactions, making it difficult rely on hiding or suppressing URIs for all parties to reconstruct a series of transactions. those resources. For more information, see the TAG finding " 'Deep Linking' in the World Wide Web " .

3.7. Future Directions for Interaction

There are mechanisms in HTTP, not widely deployed, to remedy remain open questions regarding Web interactions. The TAG expects future versions of this situation. HTTP servers can assign a URI document to address in more detail the results of a POST transaction using relationship between the architecture described herein, Web Services , the "Content-Location" header (described in section 14.14 of Semantic Web , peer-to-peer systems (including Freenet , MLdonkey , and NNTP [ <a href="#RFC2616" shape="rect"> RFC2616 RFC977 ]), instant messaging systems (including [ XMPP ]), and allow authorized parties to retrieve a record of the transaction thereafter via this URI (the value of <a href="#URI-persistence" shape="rect"> URI persistence voice-over-IP (including RTSP [ RFC2326 is apparent in this case). User agents can provide an interface for managing transactions where the user agent has incurred an obligation on behalf of the user. ]).

4.1. Binary and predictability. The value Textual Data Formats

Binary data formats are those in which portions of deleted text: a URI increases with the predictability 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 interactions using that URI. Avoiding unnecessary <a href="#uri-aliases" shape="rect"> URI aliases </a> is one aspect data so represented include numeric values, pointers, and compressed data of proper resource management. all sorts.

<span class="practicelab"> Good practice: <a name="pr-service-uri" id="pr-service-uri" shape="rect"> Consistent representation </a> </span> </p> <p class="practice"> Publishers of A textual data format is one in which the data is specified as a URI SHOULD provide representations sequence of the identified resource consistently characters. HTML, Internet e-mail, and predictably. all XML-based formats are textual. Increasingly, internationalized textual data formats refer to the Unicode repertoire [ UNICODE ] for character definitions.

This section discusses important aspects of representation management. In principle, all data can be represented using textual formats.

The authority responsible for a resource may supply zero or trade-offs between binary and textual data formats are complex and application-dependent. Binary formats can be substantially more representations of a resource. The authority is also responsible for accepting or rejecting requests to modify a resource, compact, particularly for example, by configuring a server to accept or reject HTTP PUT complex pointer-rich data based on Internet Media Type, validity constraints, 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 other constraints. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="pr-describe-resource" id="pr-describe-resource" shape="rect"> Available representation </a> </span> </p> <p class="practice"> Publishers of a URI SHOULD provide representations of the identified resource. no conversion.

There Textual formats are strong social expectations usually more portable and interoperable. Textual formats also have the considerable advantage that once a URI identifies a particular resource, it should continue indefinitely to refer they can be directly read and understood by human beings. This can simplify the tasks of creating and maintaining software, and allow the direct intervention of humans in the processing chain without recourse to that resource; tools more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats; this is called <a name="def-URI-persistence" id="def-URI-persistence"> the URI persistence "view source" effect . deleted text: URI persistence is a matter of policy and commitment on the part of authorities servicing URIs. The choice of a particular URI scheme provides no guarantee that those URIs will be persistent or that they will not be persistent.

Since representations are used It is important to communicate resource state, persistence emphasize that intuition as to such matters as data size and processing speed is directly affected by how well representations are served. Service breakdowns include: </p> <ul> <li> Inconsistent representations served. Note the difference between not a resource owner changing representations predictably reliable guide in light of the nature of the resource (the changing weather data format design; quantitative studies are essential to a correct understanding of deleted text: Oaxaca) and the owner changing representations arbitrarily. </li> <li> Improper use trade-offs. Therefore, designers of deleted text: content negotiation, such as serving two images as equivalent through HTTP content negotiation, where one image represents a square and the other data format specification should make a circle. </li> </ul> </div> considered choice between binary and textual format design.

HTTP [ <a href="#RFC2616" shape="rect"> RFC2616 </a> ] has been designed to help manage URIs. For example, HTTP redirection (using the 3xx response codes) permits servers to tell an agent that further action needs to be taken by the agent in order to fulfill the request (for example, the resource has been assigned Note: Text (i.e., a new URI). In addition, content negotiation also promotes consistency, as sequence of characters from a site manager repertoire) is not required to define new URIs when adding support for distinct from serving data with a new format specification. Protocols that media type beginning with "text/". Although XML-based formats are textual, many XML-based formats do not support content negotiation (such as FTP) require a new identifier consist primarily of phrases in natural language. See the section on media types for XML for issues that arise when a new data format "text/" is introduced. used in conjunction with an XML-based format.

For more discussion about URI persistence, see [ <a href="#Cool" shape="rect"> Cool </a> ]. See TAG issue binaryXML-30 .

4.2. Versioning and Access Control Extensibility </h4>

It is reasonable to limit access to a resource (for commercial or security reasons, for example), but it is unreasonable Extensibility and versioning are strategies to prohibit others from merely identifying help manage the resource. </p> <p> As an analogy: The owners natural evolution of a building might have a policy that the public may only enter the building via the main front door, and only during business hours. People who work in information on the building Web and who make deliveries technologies used to it might use other doors as appropriate. Such a 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 the building entrances, nor by requesting legislation requiring represent that information.

For more information about versioning strategies and agent behavior in the use face of the front door unrecognized extensions, see TAG issue XMLVersioning-41 and forbidding anyone to reveal the fact that there "Web Architecture: Extensible Languages" [ EXTLANG ].

4.2. <a name="ext-version" id="ext-version" shape="rect"> Versioning 4.3. Separation of Content, Presentation, and Extensibility Interaction

Extensibility and versioning are strategies The Web is a heterogeneous environment where a wide variety of agents provide access to help manage the natural evolution content to users with a wide variety of information on capabilities. It is good practice for authors to create content that can reach the Web widest possible audience, including users with graphical desktop computers, hand-held devices and technologies used to represent mobile 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 information. </p> <p> the separation of content, presentation, and interaction promotes the reuse and device-independence of content; his follows from the principle of independent specifications . For more information deleted text: on about versioning strategies and agent behavior in the face principles of unrecognized extensions, device-independence, see deleted text: TAG issue <a href="http://www.w3.org/2001/tag/issues.html#XMLVersioning-41" shape="rect"> XMLVersioning-41 </a> and "Web Architecture: Extensible Languages" [ <a href="#EXTLANG" shape="rect"> EXTLANG DIPRINCIPLES ].

Nadia Note that when content, presentation, and Dirk interaction are designing an XML data format to encode data about the film industry. They provide for extensibility separated by using XML namespaces and creating a schema that allows the inclusion, in certain places, of elements from any namespace. When they revise their format, Nadia proposes a new optional "lang" attribute on the "film" element. Dirk feels that such a change requires them design, agents need to assign recombine them. There is a new namespace name, which might require changes to deployed software. Nadia explains to Dirk that their choice of extensibility strategy in conjunction recombination spectrum, with their namespace policy allows certain changes that do not affect conformance of existing content and software, "client does all" at one end and thus no change to "server does all" at the namespace identifier is required. They chose this policy other. There are advantages to help them meet their goals of reducing each: recombination on the cost of change. </p> </div> </div> <p> Dirk and Nadia have chosen a particular namespace change policy that server allows deleted text: them to avoid changing the namespace name whenever they make changes server to send out generally smaller amounts of data that do can be tailored to specific devices (such as mobile phones). However, such data will not be readily reusable by other clients and may not affect conformance allow client-side agents to perform useful tasks unanticipated by the author. When a client does the work of deployed recombination, content and software. They might have chosen a different policy, for example that any new element or attribute has to belong is likely to be more reusable by a namespace other than the original one. Whatever broader audience and more robust. However, such data may be of greater size and may require more computation by the chosen policy, client.

Of course, it may not always be desirable to reach the widest possible audience. Designers should set clear expectations consider appropriate technologies for users of limiting the format. </p> <div class="boxedtext"> <p> <span class="practicelab"> Good practice: <a name="pr-doc-ns-policy" id="pr-doc-ns-policy" shape="rect"> Namespace policy </a> </span> </p> <p class="practice"> Format designers SHOULD document change policies audience. For instance digital signature technology, access control , and other technologies are appropriate for XML namespaces. controlling access to content.

As an example of a change policy Some data formats are designed to reflect the variable stability of a namespace, consider the <a href="http://www.w3.org/1999/10/nsuri" shape="rect"> W3C namespace policy </a> for documents on the W3C Recommendation track. The policy sets expectations describe presentation (including SVG and XSL Formatting Objects). Data formats such as these demonstrate that the Working Group responsible for the namespace may modify it in any way until a certain point in the process ("Candidate Recommendation") one can only separate content from presentation (or interaction) so far; at which some point W3C constrains the set possible changes it becomes necessary to talk about presentation. Per the namespace in order to promote stable implementations. principle of independent specifications, these data formats should only address presentation issues.

Note that since namespace names are URIs, the party (if any) responsible for a namespace URI has the authority to decide See the namespace change policy. TAG issues formattingProperties-19 and contentPresentation-26 .

4.4. Hypertext </h4>

Designers can facilitate A defining characteristic of the transition process by making careful choices about extensibility during Web is that it allows embedded references to other resources via URIs. The simplicity of creating links using absolute URIs ( <a href="http://www.example.com/foo"> ) and relative URI references ( <a href="foo"> and <a href="foo#anchor"> ) is partly (perhaps largely) responsible for the design birth of the hypertext Web as we know it today.

When one resource (representation) refers to another resource with a language or protocol specification. URI, this constitutes a link between the two resources. Additional metadata may also form part of the link (see [ XLink10 ], for example).

Extensibility What agents do with a hypertext link is not free. Providing hooks for extensibility is one constrained by Web architecture and may depend on application context. Users of many requirements hypertext links expect to be able to navigate links among representations. Data formats that do not allow content authors to create hypertext links lead to deleted text: be factored into the costs creation of language design. Experience suggests that "terminal nodes" on the long term benefits of extensibility generally outweigh Web.

4.5. XML-Based Data Formats </span> </p> <p class="practice"> Language designers SHOULD design

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

Of course, it may not always The discussion here should be desirable seen as ancillary to deleted text: reach the widest possible audience. Application context may require a very specific display (for a legally-binding transaction, for example). Also, digital signature technology, <a href="#id-access" shape="rect"> access control </a>, and other technologies are appropriate content of [IETFXML] . Refer also to "XML Accessibility Guidelines" [XAG] for controlling access help designing XML formats that lower barriers to content. Web accessibility for people with disabilities.

6. References

<a href="#def-uri-ambiguity"> URI ambiguity CGI

deleted text: The use of the same URI to refer to more than one distinct resource. </dd> <dt> <a href="#def-uri-ownership"> URI ownership Common Gateway Interface/1.1 Specification </dt> <dd> The relationship between assigning agent and URI that is defined by a URI scheme. . Available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html.

<a href="#def-URI-persistence"> URI persistence Cool

The social expectation 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 once a URI identifies a particular resource, change, it should continue indefinitely to refer to that resource. is what they identify.

<a href="#uriref"> URI reference Eng90

deleted text: An operational shorthand for a URI. </dd> <dt> <a href="#def-uri"> Uniform Resource Identifier (URI) Knowledge-Domain Interoperability and an Open Hyperdocument System </dt> <dd> A global identifier in the context of the World Wide Web. , D. C. Engelbart, June 1990.

<a href="#def-unsafe-interaction"> Unsafe interaction FREENET

Interaction with a resource that is not safe interaction. The Free Network Project .

<a href="#def-user-agent"> User agent IANASchemes

One type of Web agent; a piece of software acting on behalf IANA's online registry of a person. URI Schemes is available at http://www.iana.org/assignments/uri-schemes.

<a href="#def-web-agent"> Web agent IETFXML

A person or a piece IETF Guidelines For The Use of software acting on XML in IETF Protocols , 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 information space on behalf of a person, entity, or process. ietf-xml-use mailing list .

<a href="#xml-based"> XML-based format INFOSET

One that conforms to the syntax rules defined in the XML specification. </dd> </dl> <!-- Generated --> </div> <div class="section"> <h2> 6. <a id="refs" name="refs" shape="rect"> References Information Set (Second Edition) </h2> <!-- See also refs.xsl, which extracts data from the W3C TR home page automatically for inclusion in this document. --> <div class="section"> <h3> 6.1. <a name="internet" id="internet" shape="rect"> Internet Specifications , J. Cowan, R. Tobin, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204 . Latest version </h3> <dl> available at http://www.w3.org/TR/xml-infoset .

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

IANA's <a href="http://www.iana.org/assignments/uri-schemes" shape="rect"> online registry of URI Schemes IETF Internationalized Resource Identifiers (IRIs) , M. D&uumlaut;rst, M. Suignard, Nov 2002. This IETF Internet Draft is available at http://www.iana.org/assignments/uri-schemes. </dd> <dd> <a href="http://www.w3.org/Addressing/schemes" shape="rect"> Dan Connolly's list of URI schemes </a> http://www.w3.org/International/iri-edit/draft-duerst-iri.html. If this document is a useful resource no longer available, refer to the home page for finding out which references define various URI schemes. Editing 'Internationalized Resource Identifiers (IRIs)' .

MEDIATYPEREG

IANA's online registry of Internet Media Types is available at http://www.iana.org/assignments/media-types/index.html.

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

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

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

deleted text: IETF <cite> <a href="http://www.ietf.org/rfc/rfc2046.txt" shape="rect"> RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types </a> </cite>, N. Freed, N. Borenstein, November 1996. Available at http://www.ietf.org/rfc/rfc2046.txt. </dd> <dt> deleted text: <a name="RFC2119" id="RFC2119" shape="rect"> RFC2119 </a> </dt> <dd> IETF <a href="http://www.ietf.org/rfc/rfc2119.txt" shape="rect"> RFC 2119: Key words for use in RFCs to Indicate Requirement Levels OWL Web Ontology Language Reference </cite>, S. Bradner, March 1997. Available , G. Schreiber, M. Dean, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/ . Latest version available at http://www.ietf.org/rfc/rfc2119.txt. http://www.w3.org/TR/owl-ref/ .

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

deleted text: Uniform Resource Identifiers (URI): Generic Syntax </cite> (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. Citations labeled [ <a href="#URI" shape="rect"> URI </a> ] refer to <a href="http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html" shape="rect"> draft-fielding-uri-rfc2396bis-03 </a>. </dd> <dt> <a name="RFC2616" id="RFC2616" shape="rect"> RFC2616 The Platform for Privacy Preferences 1.0 (P3P1.0) Specification </dt> <dd> IETF <cite> <a href="http://www.ietf.org/rfc/rfc2616.txt" shape="rect"> RFC 2616: Hypertext Transfer Protocol — HTTP/1.1 , M. Marchiori, Editor, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ . Latest version </cite>, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available available at http://www.ietf.org/rfc/rfc2616.txt. http://www.w3.org/TR/P3P/ .

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

IETF <a href="http://www.ietf.org/rfc/rfc2717.txt" shape="rect"> Registration Procedures for URL Scheme Names Resource Directory Description Language (RDDL) , R. Petke, I. King, November 1999. Available J. Borden, T. Bray, eds., 1 June 2003. This document is available at http://www.ietf.org/rfc/rfc2717.txt. http://www.tbray.org/tag/rddl/rddl3.html.

deleted text: </dl> </div> <div class="section"> <h3> 6.2. <a name="archspecs" id="archspecs" shape="rect"> Architectural Specifications </a> </h3> <dl>

<a name="ATAG10" id="ATAG10"> ATAG10 RDF10

<a href="http://www.w3.org/TR/2000/REC-ATAG10-20000203"> Authoring Tool Accessibility Guidelines 1.0 Resource Description Framework (RDF) Model and Syntax Specification , J. Treviranus, C. McCathieNevile, I. Jacobs, J. Richards, O. Lassila, R. R. Swick, Editors, W3C Recommendation, 3 22 February 2000, http://www.w3.org/TR/2000/REC-ATAG10-20000203 1999, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 . <a href="http://www.w3.org/TR/ATAG10"> Latest version available at http://www.w3.org/TR/ATAG10 http://www.w3.org/TR/REC-rdf-syntax .

<a name="CHARMOD" id="CHARMOD"> CHARMOD RELAXNG

The RELAX NG schema language project.

REST

<a href="http://www.w3.org/TR/2003/WD-charmod-20030822/"> Character Model for the World Wide Web 1.0 Representational State Transfer (REST) </cite> , T. Texin, M. J. Dürst, F. Yergeau, , Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Thesis of R. Ishida, M. Wolf, Editors, W3C Working Draft (work T. Fielding, 2000. Designers of protocol specifications in progress), 22 August 2003, http://www.w3.org/TR/2003/WD-charmod-20030822/ . <a href="http://www.w3.org/TR/charmod/"> Latest version particular should invest time in understanding the REST model and the relevance of its principles to a given design. These principles include statelessness, clear assignment of roles to parties, uniform address space, and a limited, uniform set of verbs. Available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

RFC2045

IETF RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies available , N. Freed, N. Borenstein, November 1996. Available at http://www.w3.org/TR/charmod/ . http://www.ietf.org/rfc/rfc2045.txt.

<a name="DIPRINCIPLES" id="DIPRINCIPLES"> DIPRINCIPLES RFC2046

IETF <a href="http://www.w3.org/TR/2003/NOTE-di-princ-20030901/"> Device Independence Principles RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types </cite> , R. Gimson, Editors, W3C Working Group Note, 1 September 2003, http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ . <a href="http://www.w3.org/TR/di-princ/"> Latest version </a> available , N. Freed, N. Borenstein, November 1996. Available at http://www.w3.org/TR/di-princ/ . http://www.ietf.org/rfc/rfc2046.txt.

<a name="QA" id="QA"> QA RFC2119

IETF <a href="http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/"> QA Framework: Specification Guidelines </a> </cite> , D. Hazaël-Massieux, L. Henderson, L. Rosenthal, Editors, W3C Candidate Recommendation (work RFC 2119: Key words for use in progress), 10 November 2003, http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/ . <a href="http://www.w3.org/TR/qaframe-spec/"> Latest version RFCs to Indicate Requirement Levels available , S. Bradner, March 1997. Available at http://www.w3.org/TR/qaframe-spec/ . http://www.ietf.org/rfc/rfc2119.txt.

<a name="UAAG10" id="UAAG10"> UAAG10 RFC2141

IETF <a href="http://www.w3.org/TR/2002/REC-UAAG10-20021217/"> User Agent Accessibility Guidelines 1.0 RFC 2141: URN Syntax </cite> , I. Jacobs, J. Gunderson, E. Hansen, Editors, W3C Recommendation, 17 December 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/ . <a href="http://www.w3.org/TR/UAAG10/"> Latest version </a> available , R. Moats, May 1997. Available at http://www.w3.org/TR/UAAG10/ . http://www.ietf.org/rfc/rfc2141.txt.

<a name="WCAG20" id="WCAG20"> WCAG20 RFC2326

IETF <a href="http://www.w3.org/TR/2003/WD-WCAG20-20030624/"> Web Content Accessibility Guidelines 2.0 RFC 2326: Real Time Streaming Protocol (RTSP) </cite> , 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/ . <a href="http://www.w3.org/TR/WCAG20/"> Latest version , H. Schulzrinne, A. Rao, R. Lanphier, April 1998. Available at: http://www.ietf.org/rfc/rfc2326.txt.

RFC2616

IETF RFC 2616: Hypertext Transfer Protocol &mdash; HTTP/1.1 available , J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at http://www.w3.org/TR/WCAG20/ . http://www.ietf.org/rfc/rfc2616.txt.

<a name="WSA" id="WSA"> WSA RFC2717

IETF <a href="http://www.w3.org/TR/2003/WD-ws-arch-20030808/"> Web Services Architecture Registration Procedures for URL Scheme Names </cite> , M. Champion, C. Ferris, D. Orchard, D. Booth, H. Haas, F. McCabe, E. Newcomer, Editors, W3C Working Draft (work in progress), 8 August 2003, http://www.w3.org/TR/2003/WD-ws-arch-20030808/ . <a href="http://www.w3.org/TR/ws-arch/"> Latest version </a> available , R. Petke, I. King, November 1999. Available at http://www.w3.org/TR/ws-arch/ . http://www.ietf.org/rfc/rfc2717.txt.

<a name="XAG" id="XAG"> XAG RFC2718

IETF <a href="http://www.w3.org/TR/2002/WD-xag-20021003"> XML Accessibility RFC 2718: Guidelines for new URL Schemes </cite> , , L. Masinter, H. Alvestrand, 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 . <a href="http://www.w3.org/TR/xag"> Latest version </a> available at http://www.w3.org/TR/xag . Zigmond, R. Petke, November 1999. Available at: http://www.ietf.org/rfc/rfc2718.txt.

deleted text: </dl> <dl>

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

IETF RFC 2818: HTTP Over TLS , E. Rescorla, May 2000. Available at: http://www.ietf.org/rfc/rfc2818.txt.

RFC3023

IETF <a href="http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210" shape="rect"> Web Architecture: Extensible Languages RFC 3023: XML Media Types , T. Berners-Lee, M. Murata, S. St. Laurent, D. Connolly, 10 February 1998. This W3C Note is available at http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210. Kohn, January 2001. Available at: http://www.ietf.org/rfc/rfc3023.txt

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

IETF <a href="http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf" shape="rect"> Principled Design of the Modern Web Architecture RFC 3236: The 'application/xhtml+xml' Media Type , 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. M. Baker, P. Stark, January 2002. Available at: http://www.ietf.org/rfc/rfc3236.txt

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

IETF <a href="http://www.ietf.org/rfc/rfc1958.txt" shape="rect"> RFC 1958: Architectural Principles of the Internet 977: Network News Transfer Protocol , B. Carpenter, June 1996. Kantor, P. Lapsley, February 1986. Available at http://www.ietf.org/rfc/rfc1958.txt. http://www.ietf.org/rfc/rfc977.txt.

deleted text: </dl> </div> <div class="section"> <h3> 6.3. <a name="additional" id="additional" shape="rect"> Additional References </a> </h3> <dl>

<a name="INFOSET" id="INFOSET"> INFOSET SOAP12

<a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024/"> XML Information Set SOAP Version 1.2 Part 1: Messaging Framework , M. Hadley, N. Mendelsohn, J. Cowan, R. Tobin, Moreau, H. Frystyk Nielsen, M. Gudgin, Editors, W3C Recommendation, 24 October 2001, http://www.w3.org/TR/2001/REC-xml-infoset-20011024/ . <a href="http://www.w3.org/TR/xml-infoset"> Latest version </a> available at http://www.w3.org/TR/xml-infoset . </dd> <dt> <a name="OWL10" id="OWL10"> OWL10 </a> </dt> <dd> <cite> <a href="http://www.w3.org/TR/2003/CR-owl-ref-20030818/"> OWL Web Ontology Language Reference </a> </cite> , M. Dean, G. Schreiber, Editors, W3C Candidate Recommendation (work in progress), 18 August June 2003, http://www.w3.org/TR/2003/CR-owl-ref-20030818/ http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ . <a href="http://www.w3.org/TR/owl-ref/"> Latest version available at http://www.w3.org/TR/owl-ref/ http://www.w3.org/TR/soap12-part1/ .

<a name="P3P10" id="P3P10"> P3P10 SVG11

<a href="http://www.w3.org/TR/2002/REC-P3P-20020416/"> The Platform for Privacy Preferences 1.0 (P3P1.0) Scalable Vector Graphics (SVG) 1.1 Specification , M. Marchiori, J. Ferraiolo, 藤沢, D. Jackson, Editors, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/ . <a href="http://www.w3.org/TR/P3P/"> Latest version available at http://www.w3.org/TR/P3P/ http://www.w3.org/TR/SVG11/ .

<a name="RDF10" id="RDF10"> RDF10 UNICODE

<cite> <a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222"> Resource Description Framework (RDF) Model and Syntax Specification See the Unicode Consortium home page </cite> , O. Lassila, R. R. Swick, Editors, W3C Recommendation, 22 February 1999, http://www.w3.org/TR/1999/REC-rdf-syntax-19990222 . <a href="http://www.w3.org/TR/REC-rdf-syntax"> Latest for information about the latest version </a> available at http://www.w3.org/TR/REC-rdf-syntax . of Unicode and character repertoires.

<a name="SOAP12" id="SOAP12"> SOAP12 URI

<a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/"> SOAP Version 1.2 Part 1: Messaging Framework </a> </cite> , M. Hadley, N. Mendelsohn, J. Moreau, H. Frystyk Nielsen, M. Gudgin, Editors, W3C Recommendation, 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ . <a href="http://www.w3.org/TR/soap12-part1/"> Latest version Uniform Resource Identifiers (URI): Generic Syntax (T. Berners-Lee, R. Fielding, L. Masinter, Eds.) is currently being revised. Citations labeled [ URI available at http://www.w3.org/TR/soap12-part1/ . ] refer to draft-fielding-uri-rfc2396bis-03 .

<a name="SVG11" id="SVG11"> SVG11 UniqueDNS

<a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/"> Scalable Vector Graphics (SVG) 1.1 Specification IAB Technical Comment on the Unique DNS Root </cite> , J. Ferraiolo, 藤. , D. Jackson, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/ . <a href="http://www.w3.org/TR/SVG11/"> Latest version </a> available , B. Carpenter, 27 September 1999. Available at http://www.w3.org/TR/SVG11/ . http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm.

XHTML11

XHTML™ 1.1 - Module-based XHTML , M. Altheim, S. McCarron, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531 . Latest version available at http://www.w3.org/TR/xhtml11/ .

deleted text: <a name="XMLSCHEMA" id="XMLSCHEMA"> XMLSCHEMA </a> </dt> <dd> <cite> <a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/"> XML Schema Part 1: Structures </a> </cite> , H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, Editors, W3C Recommendation, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . <a href="http://www.w3.org/TR/xmlschema-1/"> Latest version </a> available at http://www.w3.org/TR/xmlschema-1/ . </dd> <dt> XLink10

XML Linking Language (XLink) Version 1.0 , S. J. DeRose, E. Maler, D. Orchard, Editors, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/ . Latest version available at http://www.w3.org/TR/xlink/ .

XML10

<a href="http://www.w3.org/TR/2000/REC-xml-20001006"> Extensible Markup Language (XML) 1.0 (Second (Third Edition) , F. Yergeau, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Editors, W3C Recommendation, 6 October 2000, http://www.w3.org/TR/2000/REC-xml-20001006 . <a href="http://www.w3.org/TR/REC-xml"> Latest version </a> available at http://www.w3.org/TR/REC-xml . </dd> <dt> <a name="XMLNS" id="XMLNS"> XMLNS </a> </dt> <dd> <cite> <a href="http://www.w3.org/TR/1999/REC-xml-names-19990114"> Namespaces in XML </a> </cite> , T. Bray, D. Hollander, A. Layman, Editors, W3C Recommendation, 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 . <a href="http://www.w3.org/TR/REC-xml-names"> Latest version </a> available at http://www.w3.org/TR/REC-xml-names . </dd> <dt> <a name="XPTRFR" id="XPTRFR"> XPTRFR </a> </dt> <dd> <cite> <a href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/"> XPointer Framework </a> </cite> , P. Grosso, E. Maler, J. Marsh, N. Walsh, Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . <a href="http://www.w3.org/TR/xptr-framework/"> Latest version </a> available at http://www.w3.org/TR/xptr-framework/ . </dd> <dt> <a name="XSLT10" id="XSLT10"> XSLT10 </a> </dt> <dd> <cite> <a href="http://www.w3.org/TR/1999/REC-xslt-19991116"> XSL Transformations (XSLT) Version 1.0 </a> </cite> , J. Clark, E. Maler, Editors, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 4 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204 . <a href="http://www.w3.org/TR/xslt"> Latest version available at http://www.w3.org/TR/xslt http://www.w3.org/TR/REC-xml .

deleted text: </dl> <dl> <dt> <a name="CGI" id="CGI" shape="rect"> CGI </a> </dt> <dd> <cite> <a href="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html" shape="rect"> Common Gateway Interface/1.1 Specification </a> </cite>. Available at http://hoohoo.ncsa.uiuc.edu/cgi/interface.html. </dd>

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

<a href="http://www.w3.org/Provider/Style/URI.html" shape="rect"> Cool URIs don't change Namespaces in XML , T. Berners-Lee, W3C, 1998 Available Bray, D. Hollander, A. Layman, Editors, W3C Recommendation, 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114 . Latest version 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. http://www.w3.org/TR/REC-xml-names .

<a name="Eng90" id="Eng90" shape="rect"> Eng90 XMLSCHEMA

<a href="http://www.bootstrap.org/augment/AUGMENT/132082.html" shape="rect"> Knowledge-Domain Interoperability and an Open Hyperdocument System XML Schema Part 1: Structures </cite>, , H. S. Thompson, D. C. Engelbart, June 1990. </dd> <dt> <a name="FREENET" id="FREENET" shape="rect"> FREENET </a> </dt> <dd> The <a href="http://freenet.sourceforge.net/" shape="rect"> Free Network Project </a>. </dd> <dd> <a href="http://www.w3.org/Addressing/schemes" shape="rect"> Dan Connolly's list of URI schemes Beech, M. Maloney, N. Mendelsohn, Editors, W3C Recommendation, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ . Latest version is a useful resource for finding out which references define various URI schemes. available at http://www.w3.org/TR/xmlschema-1/ .

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

deleted text: IETF <cite> <a href="http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt" shape="rect"> Guidelines For The Use of XML in Extensible Messaging and Presence Protocol ( XMPP ) IETF Protocols Working Group deleted text: </cite>, 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 developing "an open, XML-based protocol for near real-time extensible messaging and presence. It is deleted text: no longer available, refer to the <a href="http://www.imc.org/ietf-xml-use/index.html" shape="rect"> ietf-xml-use mailing list </a>. core protocol of the Jabber Instant Messaging and Presence technology..."

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

IETF <a href="http://www.w3.org/International/iri-edit/draft-duerst-iri.html" shape="rect"> Internationalized Resource Identifiers (IRIs) XPointer Framework </cite>, M. Duerst, M. Suignard, Nov 2002. This IETF Internet Draft is , P. Grosso, E. Maler, J. Marsh, N. Walsh, Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . Latest version 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 href="http://www.w3.org/International/iri-edit/" shape="rect"> Editing 'Internationalized Resource Identifiers (IRIs)' </a>. http://www.w3.org/TR/xptr-framework/ .

<a name="MLDONKEY" id="MLDONKEY" shape="rect"> MLDONKEY XSLT10

The <a href="http://mldonkey.org/" shape="rect"> MLDonkey Project XSL Transformations (XSLT) Version 1.0 , J. Clark, Editor, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 . Latest version available at http://www.w3.org/TR/xslt .