WDIFF

draft-ietf-simple-xcap-02.txt --> draft-ietf-simple-xcap-03.txt

SIMPLE J. Rosenberg
Internet-Draft dynamicsoft
Expires: August 15, 2004 February 15, January 14, 2005 July 16, 2004

The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP)
draft-ietf-simple-xcap-02
draft-ietf-simple-xcap-03

Status of this Memo

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026.
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 15, 2004. January 14, 2005.

Abstract

This specification defines the Extensible Markup Language (XML)
Configuration Access Protocol (XCAP). XCAP allows a client to read,
write and modify application configuration data, stored in XML format
on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes
to HTTP URIs, so that these components can be directly accessed by
HTTP.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 1]

Internet-Draft XCAP February July 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Application Usages . . . . . . . . . . . . . . . . . . . . 7
4.1 . 9
5.1 Application Usage ID (AUID) . . . . . . . . . . . . . . . 7
4.2 9
5.2 Data Validation . . . . . . . . . . . . . . . . . . . . . 7
4.3 9
5.3 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 8
4.4 11
5.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 8
4.5 Data 11
5.5 Resource Interdependencies . . . . . . . . . . . . . . . . . . 8
4.6 11
5.6 Authorization Policies . . . . . . . . . . . . . . . . . . 8
4.7 12
5.7 Data Extensibility . . . . . . . . . . . . . . . . . . . . 9
4.7.1 XML Schema 12
5.8 Documenting Application Usages . . . . . . . . . . . . . . 13
5.9 Guidelines for Creating Application Usages . . . . . . . . 13
6. URI Construction . . . 10
4.8 Documenting Application Usages . . . . . . . . . . . . . . 10
5. URI Construction . . . . . 16
6.1 XCAP Root . . . . . . . . . . . . . . . . 11
5.1 Identifying the XML . . . . . . . . 16
6.2 Document Selector . . . . . . . . . . . . . . . 11
5.2 Identifying the XML Nodes . . . . . 16
6.3 Node Selector . . . . . . . . . . . 12
6. . . . . . . . . . . . 18
7. Client Operations . . . . . . . . . . . . . . . . . . . . 15
6.1 . 22
7.1 Create or Replace a Document . . . . . . . . . . . . . . . 15
6.2 23
7.2 Delete a Document . . . . . . . . . . . . . . . . . . . . 15
6.3 23
7.3 Fetch a Document . . . . . . . . . . . . . . . . . . . . . 15
6.4 23
7.4 Create or Replace an Element . . . . . . . . . . . . . . . 16
6.5 23
7.5 Delete an Element . . . . . . . . . . . . . . . . . . . . 17
6.6 25
7.6 Fetch an Element . . . . . . . . . . . . . . . . . . . . . 17
6.7 26
7.7 Create or Replace an Attribute . . . . . . . . . . . . . . 17
6.8 26
7.8 Delete an Attribute . . . . . . . . . . . . . . . . . . . 18
6.9 27
7.9 Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 18
6.10 Read/Modify/Write Transactions 27
7.10 Conditional Operations . . . . . . . . . . . . . . 19
6.11 Reading Server Assigned Data . . . 27
8. Server Behavior . . . . . . . . . . . . 19
7. Server Behavior . . . . . . . . . . 29
8.1 POST Handling . . . . . . . . . . . 21
7.1 POST Handling . . . . . . . . . . . 29
8.2 PUT Handling . . . . . . . . . . . 21
7.2 PUT Handling . . . . . . . . . . . . 29
8.2.1 Locating the Parent . . . . . . . . . . . 22
7.2.1 Detailed Conflict Reports . . . . . . 30
8.2.2 Verifying Document Content . . . . . . . . . . 23
7.2.1.1 XML Schema . . . . 30
8.2.3 Creation . . . . . . . . . . . . . . . . . . . . 25
7.3 GET Handling . . . 31
8.2.4 Replacement . . . . . . . . . . . . . . . . . . . . 27
7.4 DELETE Handling . 32
8.2.5 Validation . . . . . . . . . . . . . . . . . . . . 28
7.5 Managing Etags . . 33
8.2.6 Resource Interdependencies . . . . . . . . . . . . . . 33
8.3 GET Handling . . . . . . 28
8. Examples . . . . . . . . . . . . . . . . . 34
8.4 DELETE Handling . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . 34
8.5 Managing Etags . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . 35
9. Detailed Conflict Reports . 34
10.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 34
10.2 application/xml-fragment-body MIME Type 36
9.1 Document Structure . . . . . . . . . . 34
10.3 application/xml-attribute-value MIME Type . . . . . . . . 35
10.4 application/xcap-error+xml MIME Type . . 36
9.2 XML Schema . . . . . . . . . . . . . . . . . 36
10.5 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-must-understand . . . . . . . 37
10.6 URN Sub-Namespace Registration for
10. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . 41
10.1 Application Usage ID (AUID) . . . . . . . . . . . . . . 41

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 2]

Internet-Draft XCAP February July 2004

urn:ietf:params:xml:ns:xcap-error

10.2 XML Schema . . . . . . . . . . . . . . 38
10.7 XCAP Error Schema Registration . . . . . . . . . 41
10.3 MIME Type . . . . . 38
10.8 XCAP Mandatory Namespace Schema Registration . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . 43
10.4 Validation Constraints . . . . . . . . . . 40
Normative References . . . . . . . 43
10.5 Data Semantics . . . . . . . . . . . . 41
Informative References . . . . . . . . . 43
10.6 Naming Conventions . . . . . . . . . . . . . . . . . . . 43
Author's Address
10.7 Resource Interdependencies . . . . . . . . . . . . . . . 43
10.8 Authorization Policies . . . . . . . . . . . . . . . . . 43
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements
12. Security Considerations . . . . . . 45

Rosenberg Expires August 15, 2004 [Page 3]

Internet-Draft . . . . . . . . . . . . 47
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 48
13.1 XCAP February 2004

1. Introduction

In many communications applications, such as Voice over IP, instant
messaging, and presence, it is necessary for network servers to
access per-user Application Usage IDs . . . . . . . . . . . . . . . 48
13.2 MIME Types . . . . . . . . . . . . . . . . . . . . . . . 48
13.2.1 application/xcap-el+xml MIME Type . . . . . . . . . 48
13.2.2 application/xcap-att+xml MIME Type . . . . . . . . . 49
13.2.3 application/xcap-error+xml MIME Type . . . . . . . . 50
13.2.4 application/xcap-caps+xml MIME Type . . . . . . . . 50
13.3 URN Sub-Namespace Registrations . . . . . . . . . . . . 51
13.3.1 urn:ietf:params:xml:ns:xcap-error . . . . . . . . . 51
13.3.2 urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . 51
13.4 XML Schema Registrations . . . . . . . . . . . . . . . . 52
13.4.1 XCAP Error Schema Registration . . . . . . . . . . . 52
13.4.2 XCAP Capabilities Schema Registration . . . . . . . 52
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
15.1 Normative References . . . . . . . . . . . . . . . . . . . 54
15.2 Informative References . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 57

Rosenberg Expires January 14, 2005 [Page 3]

Internet-Draft XCAP July 2004

1. Introduction

In many communications applications, such as Voice over IP, instant
messaging, and presence, it is necessary for network servers to
access per-user information in the process of servicing a request.
This per-user information resides within the network, but is managed
by the end user themselves. Its management can be done through a
multiplicity of access points, including the web, a wireless handset,
or a PC application.

Examples of per-user information are presence [18] authorization
policy and presence lists. Presence lists are lists of users whose
presence is desired by a watcher [26]. One way to obtain presence
information for the list of is to subscribe to a resource which
represents that list [21]. In this case, the Resource List Server
(RLS) requires access to this list in order to process a SIP
[15]SUBSCRIBE [28] request for it. Another way to obtain presence
for the users on the list is for a watcher to subscribe to each user
individually. In that case, it is convenient to have a server store
the list, and when the client boots, it fetches the list from the
server. This would allow a user to access their resource lists from
different clients.

Requirements for manipulation of presence lists and authorization
policies have been specified by the SIMPLE working group [22].

This specification describes a protocol that can be used to
manipulate this per-user data. It is called the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP). XCAP is a set
of conventions for mapping XML documents and document components into
HTTP URIs, rules for how the modification of one resource affects
another, data validation constraints, and authorization policies
associated with access to those resources. Because of this
structure, normal HTTP primitives can be used to manipulate the data.
XCAP is based heavily on ideas borrowed from the Application
Configuration Access Protocol (ACAP) [25], but it is not an extension
of it, nor does it have any dependencies on it. Like ACAP, XCAP is
meant to support the configuration needs for a multiplicity of
applications, rather than just a single one.

Rosenberg Expires January 14, 2005 [Page 4]

Internet-Draft XCAP July 2004

2. Overview of Operation

Each application that makes use of XCAP specifies an application
usage (Section 5). This application usage defines the XML schema [2]
for the data used by the application, along with other key pieces of
information. The principal task of XCAP is to allow clients to read,
write, modify, create and delete pieces of that data. These
operations are supported using HTTP 1.1 [5]. An XCAP server acts as
a repository for collections of XML documents. There will be
documents stored for each application. Within each application,
there are documents stored for each user. Each user can have a
multiplicity of documents for a particular application. To access
some component of one of those documents, XCAP defines an algorithm
for constructing a URI that can be used to reference that component.
Components refer to any element or attribute within the document.
Thus, the HTTP URIs used by XCAP point a document, or to pieces of
information that are finer grained than the XML document itself. An
HTTP resource which follows the naming conventions and validation
constraints defined here is called an XCAP resource.

Since XCAP resources are also HTTP resources, they can be accessed
using HTTP methods. Reading an XCAP resource is accomplished with
HTTP GET, creating or modifying one is done with HTTP PUT, and
removing one of the resources is done with an HTTP DELETE.
Properties that HTTP associates with resources, such as entity tags,
also apply to XCAP resources. Indeed, entity tags are particularly
useful in XCAP, as they allow a number of conditional operations to
be performed.

Rosenberg Expires January 14, 2005 [Page 5]

Internet-Draft XCAP July 2004

3. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [6] and
indicate requirement levels for compliant implementations.

Rosenberg Expires January 14, 2005 [Page 6]

Internet-Draft XCAP July 2004

4. Definitions

The following terms are used throughout this document:
XCAP Resource: An HTTP resource representing an XML document, an
element within an XML document, or an attribute of an element
within an XML document that follows the naming and validation
constraints of XCAP.
XCAP Server: An HTTP server that understands how to follow the naming
and validation constraints defined in this specification.
Application: A collection of software components within a network
whose operation depends on data managed and stored on an XCAP
server.
Application Usage: Detailed information on the interaction of an
application with the XCAP server.
Application Unique ID (AUID): A unique identifier that differentiates
XCAP resources accessed by one application from XCAP resources
accessed by another.
Naming Conventions: The part of an application usage that specifies
well-known URIs used by an application, or more generally,
specifies the URIs that are typically accessed by an application
during its processing.
XCAP User Identifier (XUI): The XUI is a string, valid as a path
element in an HTTP URI, that is associated with each user served
by the XCAP server.
XCAP Root: A context that contains all of the documents across all
application usages and users that are managed by the server.
Document Selector: A sequence of path segments, with each segment
being separated by a "/", that identify the XML document within an
XCAP root that is being selected.
Node Selector: A sequence of path segments, with each segment being
separated by a "/", that identify the XML node (element or
attribute) being selected within a document.
Path Separator: A single path segment equal to two tilde characters
(~~) that is used to separate the document selector from the node
selector within an HTTP URL.
Document URI: The HTTP URI containing the XCAP root and document
selector, resulting in the selection of a specific document. As a
result, performing a GET against the document URI would retrieve
the document.
Node URI: The HTTP URI containing the XCAP root, document selector,
path separator and node selector, resulting in the selection of a
specific XML node.
XCAP Root URI: An HTTP URI that representing the XCAP root. Although
a valid URI, the XCAP Root URI does not correspond to an actual
resource.

Rosenberg Expires January 14, 2005 [Page 7]

Internet-Draft XCAP July 2004

Global Tree: A URI that represents the parent for all global
documents for a particular application usage within a particular
XCAP root.
Home Directory: A URI that represents the parent for all documents
for a particular user for a particular application usage within a
particular XCAP root.
Positional Insertion: A PUT operation that results in the insertion
of a new element into a document such that its position relative
to other children of the same parent is set by the client.

Rosenberg Expires January 14, 2005 [Page 8]

Internet-Draft XCAP July 2004

5. Application Usages

Each XCAP resource on a server is associated with an application. In
order for an application to use those resources, application specific
conventions must be specified. Those conventions include the XML
schema that defines the structure and constraints of the data, well
known URIs to bootstrap access to the data, and so on. All of those
application specific conventions are defined by the application
usage.

5.1 Application Usage ID (AUID)

Each application usage is associated with a name, called an
Application Unique ID (AUID). This name uniquely identifies the
application usage, and is different from AUIDs used by other
applications. AUIDs exist in one of two namespaces. The first
namespace is the IETF namespace. This namespace contains a set of
tokens, each of which is registered with IANA. These registrations
occur with the publication of standards track RFCs [27] based on the
guidelines in Section 13. The second namespace is the
vendor-proprietary namespace. Each AUID in that namespace is
prefixed with the reverse domain name name of the organization
creating the AUID, followed by a period, followed by any vendor
defined token. As an example, the example.com domain can create an
AUID with the value "com.example.foo" but cannot create one with the
value "org.example.foo". AUIDs within the vendor namespace do not
need to be registered with IANA. The vendor namespace is also meant
to be used in lab environments where no central registry is needed.
The syntax for AUIDs, expressed in ABNF [11] (and using some of the
BNF defined in RFC 2396 [12]) is:

AUID = global-auid / vendor-auid
global-auid = auid
auid = alphanum / mark
vendor-auid = rev-hostname "." auid
rev-hostname = toplabel *( "." domainlabel )
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

5.2 Data Validation

One of the responsibilities of an XCAP server is to validate the
content of each XCAP resource when an XCAP client tries to modify
one. This is done using two mechanisms. Firstly, all application
usages MUST describe their document contents using XML schema [2].

Rosenberg Expires January 14, 2005 [Page 9]

Internet-Draft XCAP July 2004

The application usage MUST also identify the MIME type for documents
compliant to that schema.

Unfortunately, XML schemas cannot represent every form of data
constraint. As an example, one XML element may contain an integer
which defines the maximum number of instances of another element.
This constraint cannot be represented with XML schema. However, such
constraints may be important to the application usage. The
application usage defines any additional constraints beyond those in
the schema.

Of particular importance are uniqueness constraints. In many cases,
an application will require that there only be one instance of some
element or attribute within a particular scope. Each uniqueness
constraint needs to be specified by identifying the field, or
combinations of fields, that need to be unique, and then identifying
the scope in which that uniqueness applies. One typical scope is the
set of all elements of a certain name within the same parent.
Another typical scope is the set of all URIs valid within a
particular domain. In some cases these constraints can be specified
using XML schema, which provides the <unique> element for this
purpose. Other uniqueness constraints, such as URI uniqueness across
a domain, cannot be expressed by schema. Whether or not the schema
is used to express some of the uniqueness requirements, the
application usage MUST specify all uniqueness requirements when it
defines its data validation needs.

For example, the resource lists application usage [23] requires that
each <list> element have a unique value for the "name" attribute
within a single parent. As another example, the RLS services
application usage [23] requires that the value of the "uri" attribute
of the <service> element be a URI that is unique within the domain of
the URI.

Another form of constraint are URI constraints. These are
constraints on the scheme or structure of the scheme specific part of
the URI. These kinds of constraints cannot be expressed in an XML
schema. If these constraints are important to an application usage,
they need to be explicitly called out. As an example, the resource
lists application usage requires that the URI present in the "uri"
attribute of the <entry> element be either a SIP or pres URI [24].

Another important data constraint is referential integrity.
Referential integrity is important when the name or value of an
element or attribute is used as a key to select another element or
attribute. An application usage MAY specify referential integrity
constraints. However, XCAP servers are not a replacement for
Relational Database Management Systems (RDBMS), and therefore servers

Rosenberg Expires January 14, 2005 [Page 10]

Internet-Draft XCAP July 2004

are never responsible for maintaining referential integrity. XCAP
clients are responsible for making all of the appropriate changes to
documents in order to maintain referential integrity.

The data validation information is consumed by both clients, which
use them to make sure they construct requests that will be accepted
by the server, and by servers, which validate the constraints when
they receive a request (with the exception of referential integrity
constraints, which are not validated by the server).

5.3 Data Semantics

For each application usage, the data present in the XML document has
a well defined semantic. The application usage defines that
semantic, so that a client can properly construct a document in order
to achieve the desired result. They are not used by the server, as
it is purposefully unaware of the semantics of the data it is
managing. The data semantics are expressed in English prose by the
application usage.

5.4 Naming Conventions

In addition to defining the meaning of the document in the context of
a particular application, an application usage has to specify how the
applications obtain the documents they need. In particular, it needs
to define any well-known URIs used for bootstrapping purposes, and
document any other conventions on the URIs used by an application.
It should also document how documents reference each other. These
conventions are called naming conventions.

As an example, the RLS services application usage allows an RLS to
obtain the contents of a resource list when the RLS receives a
SUBSCRIBE request for a SIP URI identifying an RLS service. The
application usage specifies that the list of service definitions is
present within a specific document with a specific name within the
global tree. This allows the RLS to perform a single XCAP request to
fetch the service definition for the service associated with the SIP
URI in a SUBSCRIBE request.

Naming conventions are used by XCAP clients to construct their URIs.
The XCAP server does not make use of them.

5.5 Resource Interdependencies

When a user modifies an XCAP resource, the content of many other
resources is affected. For example, when a user deletes an XML
element within a document, it does so by issuing a DELETE request
against the URI for the element resource. However, deleting this

Rosenberg Expires January 14, 2005 [Page 11]

Internet-Draft XCAP July 2004

element also deletes all child elements and their attributes, each of
which is also an XCAP resource. As such, manipulation of one
resource affects the state of other resources.

For the most part, these interdependencies are fully specified by the
XML schema used by the application usage. However, in some
application usages, there is a need for the server to relate
resources together, and such a relationship cannot be specified
through a schema. This occurs when changes in one document need to
affect another document. Typically, this is the case when an
application usage is defining a document that acts as a collection of
information defined in other documents.

As an example, when a user creates a new RLS service (that is, it
creates a new <service> element within an RLS services document), the
server adds that element to a read-only global list of services
maintained by the server in the global tree. This read-only global
list is accessed by the RLS when processing a SIP SUBSCRIBE request.

Resource interdependencies are used by both XCAP clients and servers.

5.6 Authorization Policies

By default, each user is able to access (read, modify, and delete)
all of the documents below their home directory, and any user is able
to read documents within the global directory. However, only trusted
users, explicitly provisioned into the server, can modify global
documents.

The application usage can specify a different authorization policy
that applies to all documents associated with that application usage.
An application usage can also specify whether another application
usage is used to define the authorization policies. An application
usage for setting authorization policies can also be defined
subsequent to the definition of the the main application usage. In
such a case, the main application usage needs only to specify that
such a usage will be defined in the future.

If an application usage does not wish to change the default
authorization policy, it can merely state that the default policy is
used.

The authorization policies defined by the application usage are used
by the XCAP server during its operation.

5.7 Data Extensibility

An XCAP server MUST understand an application usage in order to

Rosenberg Expires January 14, 2005 [Page 12]

Internet-Draft XCAP July 2004

process an HTTP request made against a resource for that particular
application usage. However, it is not required for the server to
understand all of the contents of a document used by an application
usage. A server is required to understand the baseline schema
defined by the application usage. However, those schemas can define
points of extensibility where new content can be added from other
namespaces and corresponding schemas. Sometimes, the server will
understand those namespaces and therefore have access to their
schemas. Sometimes, it will not.

A server MUST allow for documents that contain elements from
namespaces not known to the server. In such a case, the server
cannot validate that such content is schema compliant; it will only
verify that the XML is well-formed.

If a client wants to verify that a server supports a particular
namespace before operating on a resource, it can query the server for
its capabilities using the XCAP Capabilities application usage,
discussed in Section 10.

5.8 Documenting Application Usages

Application usages are documented in specifications which convey the
information described above. In particular, an application usage
specification MUST provide the following information:
o Application Usage ID (AUID): If the application usage is meant for
general use on the Internet, the application usage MUST register
the AUID into the IETF tree using the IANA procedures defined in
Section 13.
o XML Schema
o MIME Type
o Validation Constraints
o Data Semantics
o Naming Conventions
o Resource Interdependencies
o Authorization Policies

5.9 Guidelines for Creating Application Usages

The primary design task when creating a new application usage is to
define the schema. Although XCAP can be used with any XML document,
intelligent schema design will improve the efficiency and utility of
the document when it is manipulated with XCAP.

XCAP provides three fundamental ways to select elements amongst a set
of siblings - by the name of the element, by its position, or by the
value of a specific attribute. Positional selection always allows a
client to get exactly what it wants. However, it requires a client

Rosenberg Expires January 14, 2005 [Page 13]

Internet-Draft XCAP July 2004

to cache a copy of the document in order to construct the predicate.
Furthermore, if a client performs a PUT, it requires the client to
reconstruct the PUT processing that a server would follow in order to
update its local cached copy. Otherwise, the client will be forced
to re-GET the document after every PUT, which is inefficient. As
such, it is a good idea to design schemas such that common operations
can be performed without requiring the client to cache a copy of the
document.

Without positional selection, a client can pick the element at each
step by its name or the value of an attribute. Many schemas include
elements that can be repeated within a parent (often, minOccurs
equals zero or one, and maxOccurs is unbounded). As such, all of the
elements have the same name. This leaves the attribute value as the
only way to select an element. Because of this, if an application
usage expects user to manipulate elements or attributes that are
descendants of an element which can repeat, that element SHOULD
include, in its schema, an attribute which can be suitably used as a
unique index. Furthermore, the naming conventions defined by that
application usage SHOULD specify this uniqueness constraint
explicitly.

URIs often make a good choice for such unique index. They have
fundamental uniqueness properties, and are also usually of semantic
significance in the application usage. However, care must be taken
when using a URI as an attribute value. URI equality is ususally
complex. However, attribute equality is performed by the server
using XML rules, which are based on case sensitive string comparison.
Thus, XCAP will match URIs based on lexical equality, not functional
equality. In such cases, an application usage SHOULD consider these
implications carefully.

XCAP provides the ability of a client to operate on a single element,
attribute or document at a time. As a result, it may be possible
that common operations the client might perform will require a
sequence of multiple requests. This is inefficient, and introduces
the possibility of failure conditions when another client modifies
the document in the middle of a sequence. In such a case, the client
will be forced to detect this case using entity tags (discussed below
in Section 7.10), and undo its previous changes. This is very
difficult.

As a result, the schemas SHOULD be defined so that common operations
generally require a single request to perform. Consider an example.
Lets say an application usage is defining permissions for users to
perform certain operations. The schema can be designed in two ways.
The top level of the tree can identify users, and within each user,
there can be the permissions associated with the user. In an

Rosenberg Expires January 14, 2005 [Page 14]

Internet-Draft XCAP July 2004

alternative design, the top level of the tree identifies each
permission, and within that permission, the set of users who have it.
If, in this application usage, it is common to change the permission
for a user from one value to another, the former schema design is
better for xcap; it will require a single PUT to make such a change.
In the latter case, either the entire document needs to be replaced
(which is a single operation), or two PUT operations need to occur -
one to remove the user from the old permission, and one to add the
user to the new permission.

Naming conventions form another key part of the design of an
application usage. The application usage should be certain that XCAP
clients know where to "start" to retrieve and modify documents of
interest. Generally, this will involve the specification of a
well-known document at a well-known URI. That document can contain
references to other documents that the client needs to read or
modify.

Rosenberg Expires January 14, 2005 [Page 15]

Internet-Draft XCAP July 2004

6. URI Construction

In order to manipulate an XCAP resource, the data must be represented
by an HTTP URI. XCAP defines a specific naming convention for
constructing these URIs. The URI is constructed by concatenating the
XCAP root with the document selector with the path separator with a
escape coded form of the node selector. The XCAP root is the
enclosing context in which all XCAP resources live. The document
selector is a path that identifies a document within the XCAP root.
The path separator is a path segment with a value of double tilde
(~~). It is piece of syntactic sugar that separates the document
selector from the node selector. The node selector is an expression
that identifies an XML element within a document.

The sections below describe these components in more detail.

6.1 XCAP Root

The root of the XCAP hierarchy is called the XCAP root. It defines
the context in which all other resources exist. The XCAP root is
represented with an HTTP URI, called the XCAP Root URI. This URI is
a valid HTTP URL; however, it doesnt point to any resource that
actually exists on the server. Its purpose is to identify the root
of the tree within the domain where all XCAP documents are stored.
It can be any valid HTTP URL, but MUST NOT contain a query string.
As an example, http://xcap.example.com/services might be used as the
XCAP root URI within the example.com domain. Typically, the XCAP
root URI is provisioned into client devices. A server or domain MAY
support multiple XCAP root URIs. In such a case, it is effectively
operating as if it were serving separate domains. There is never
information carryover or interactions between resources in different
XCAP root URIs.

6.2 Document Selector

Each document within the XCAP root is identified by its document
selector. The document selector is a sequence of path segments,
separated by a slash ("/"). These path segments define a
hierarchical structure for organizing documents within any XCAP root.
The first path segment MUST be the XCAP AUID. So, continuing the
example above, all of the documents used by the resource lists
application would be under
http://xcap.example.com/services/resource-lists.

It is assumed that each application will have data that is set by
users, and/or it will have global data that applies to all users. As
a result, beneath each AUID there are two sub-trees. One, called
"users", holds the documents that are applicable to specific users,

Rosenberg Expires January 14, 2005 [Page 16]

Internet-Draft XCAP July 2004

and the process other, called "global", holds documents applicable to all
users. The subtree beneath "global" is called the global tree. The
path segment after the AUID MUST either be "global" or "users".

Within the "users" tree are zero or more sub-trees, each of servicing which
identifies documents that apply to a request.
This per-user information resides within specific user. Each user known
to the network, but server is managed
by associated with a username, called the end user themselves. Its management can XCAP User
Identifier (XUI). This XUI MUST be done through a
multiplicity of access points, including used as the web, a wireless handset,
or path segment beneath
the "users" segment. The subtree beneath an XUI for a PC application.

Examples of per-user information are presence [17] authorization
policy and presence lists. Presence lists are lists of users whose
presence particular
user is desired by called their home directory. "User" in this context should
be interpreted loosely; a watcher. One way user might correspond to obtain presence
information device, for the list of is
example.

XCAP does not itself define what it means for documents to subscribe "apply" to
a resource user, beyond specification of a baseline authorization policy,
described below in Section 8. Each application usage can specify
additional authorization policies which
represents that list [20]. In this case, depend on data used by the Resource List Server
(RLS) requires access to
application itself.

The remainder of the document selector (the path following "global"
or the XUI) is not constrained by this list in order to process a SIP
[15]SUBSCRIBE [25] request for it. Another way specification. The
application usage MAY introduce constraints, or may allow any
structure to obtain presence for be used.

The final path segment in the document selector identifies the users on actual
document in the list hierarchy. This is for a watcher to subscribe equivalent to each user
individually. In a filename, except
that case, it is convenient to have XCAP does not require that its document resources be stored as
files in a server store file system. However, the list, and when term "filename" is used to
describe the client boots, it fetches final path segment in the list from document selector. In
traditional filesystems, the
server. This filename would allow a user to access their resource lists from
different clients.

Requirements for manipulation of presence lists and authorization
policies have been specified by the SIMPLE working group [21].

This specification describes a protocol filename
extension, such as ".xml". There is nothing in this specification
that can be requires or prevents such extensions from being used to
manipulate this per-user data. It is called in the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP). XCAP is not a
new protocol. Rather, it is
filename. In some cases, the application usage will specify a set of conventions naming
convention for mapping XML
documents documents, and document components into HTTP URIs, rules for how those naming conventions may or may not
specify a file extension. For example, in the
modification of one resource affects another, data validation
constraints, and authorization policies associated RLS services
application usage [23], documents in the user's home directory with access to
those resources. Because of this structure, normal HTTP primitives
can
the filename "index" will be used by the server to manipulate compute the data. XCAP global
index, which is based heavily on ideas
borrowed from also a document with the Application Configuration Access Protocol (ACAP)
[23], but filename "index".

When the naming conventions in an application usage do not constrain
the filename conventions (or, more generally, the document selector),
an application will know the filename (or more generally, the
document selector) because it is not an extension of it, nor does it have any
dependencies on it. Like ACAP, XCAP included as a reference in a
document which is meant to support at a well known location. As another example,
within the
configuration needs for index document defined by RLS services, the <service>
element has a multiplicity of applications, rather than
just child element called <resource-list> whose content is a single one.
URI pointing to a resource list within the users home directory.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 4] 17]

Internet-Draft XCAP February July 2004

2. Overview of Operation

Each application

As a result, if the user creates a new document, and then references
that makes use of XCAP specifies an application
usage (Section 4). This application usage defines document from a well-known document (such as the XML schema [2]
for index document
above), it doesn't matter whether the data used by user includes an extension in
the application, along with other key pieces of
information. The principal task of XCAP is to allow clients to read,
write, modify, create and delete pieces of that data. These
operations are supported using HTTP 1.1 [5]. An XCAP server acts filename or not, as a
repository for collections of XML documents. There will be documents
stored for each application. Within each application, there are
documents stored for each user. Each long as the user can have a multiplicity of
documents for a particular application. To access some component is consistent and maintains
referential integrity. Indeed, it doesn't even matter what the rest
of
one the filename is, independent of those documents, XCAP defines an algorithm for constructing whether it has a
URI that can be used to reference that component. Components refer to
any subtree filename
extension or not.

6.3 Node Selector

The node selector specifies specific nodes of the document, XML document which
are to be accessed. A node refers to either an XML element or any an
attribute for any of an element. The node selector is an expression which
identifies an element within or attribute. Its grammar is:

node-selector = element-selector ["/" attribute-selector]
element-selector = step *( "/" step)
step = by-name / by-pos / by-attr / by-pos-attr
by-name = NameorAny
by-pos = NameorAny "[" position "]"
position = 1*DIGIT
by-attr = NameorAny "[" "@" att-name "=" <">
att-value <"> "]"
by-pos-attr = NameorAny "[" position "]" "[" "@" att-name "=" <">
att-value <"> "]"
NameorAny = QName / "*" ; QName from XML Namespaces
att-name = QName
att-value = AttValue ; from XML specification
attribute-selector = "@" att-name

The QName grammar is defined the document. Thus, XML namespaces [3] specification,
and the HTTP URIs used by XCAP point to pieces of
information that are finer grained than AttValue grammar is defined in the XML document itself.

With a standardized naming convention for mapping components of specification XML
documents to HTTP URIs, the basic operations for accessing 1.0
[1].

Note that the data left bracket, right bracket, and double quote
characters, which are provided by existing HTTP primitives. Reading one of meaningful to XCAP, cannot be directly
represented in the
components is accomplished with HTTP GET, creating or modifying one
of URI. As a result, they are escape coded when
placed within the components is done with an HTTP PUT, and removing one of URI.

Similarly, the
components is done with an HTTP DELETE. To provide atomic read/
modify/write operations, HTTP entity tags are used.

Rosenberg Expires August 15, 2004 [Page 5]

Internet-Draft XCAP February 2004

3. Terminology

In this document, XML specification defines the QName production for the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
grammar for element and "OPTIONAL" attribute names, and the AttValue production
for the attribute values. Unfortunately, the characters permitted by
these productions include some that are to not allowed for pchar, which
is the production for the allowed set of characters in path segments
in the URI. The AttValue production allows many such characters
within the US-ASCII set, including the space. Those characters MUST
be interpreted as described escaped coded when placed in RFC 2119 [6] the URI. Furthermore, QName and
indicate requirement levels for compliant implementations.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 6] 18]

Internet-Draft XCAP February July 2004

4. Application Usages

A central concept in XCAP is that of an application usage. An
application usage defines the way in which a specific application
makes use

AttValue allow many Unicode characters, outside of XCAP.

4.1 Application Usage ID (AUID)

Each application usage is associated with a name, called an AUID.
This name uniquely identifies the application usage, and is different
from all other AUIDs. AUIDs exist US-ASCII. When
these characters need to be represented in one of two namespaces. The first
namespace is the IETF namespace. This namespace contains a set of
tokens, each of which is registered with IANA. These registrations
occur with HTTP URI, they are
escape coded. To do this, the publication of standards track RFCs [24] based on data should be encoded first as octets
according to the
guidelines UTF-8 character encoding [17] and then only those
octets that do not correspond to characters in Section 10. The second namespace is the
vendor-proprietary namespace. Each AUID in that namespace is prefixed
with unreserved set
should be percent-encoded. For example, the reverse domain name name of character A would be
represented as "A", the organization creating character LATIN CAPITAL LETTER A WITH GRAVE
would be represented as "%C3%80", and the
AUID, followed by a period, followed by any vendor defined token. character KATAKANA LETTER A
would be represented as "%E3%82%A2".

As
an example, a result, the example.com domain can create an AUID with grammar above represents the value
"com.example.foo" but cannot create one with expressions processed
by the value
"org.example.foo". AUIDs within XCAP server internally after it has un-escape-coded the vendor namespace do not need to
be registered with IANA. URL.
The vendor namespace is also meant to be
used in lab environments where no central registry on-the-wire format is needed. The
syntax for AUIDs, expressed in ABNF [11] (and using some of the BNF
defined in dictated by RFC 2396 [12]) is:

4.2 Data Validation

One of [12]. In the responsibilities of
discussions an examples below, the server is node selectors are presented in
their internal format prior to validate encoding when not part of an HTTP URL.
If an example includes a node selector within an HTTP URL, it is
presented in its escape coded form.

The node selector is based on the data
generated by concepts in XPath [9]. Indeed, the client. This
node selector expression, before it is done using two mechanisms. Firstly,
all application usages MUST describe their document contents using
XML schema [2]. Unfortunately, XML schemas cannot represent every
form escape coded for
representation in the HTTP URL, happens to be a valid XPath
expression. However, XPath provides a set of data constraint. As an example, one functionality far
richer than is needed here, and its breadth would introduce much
unneeded complexity into XCAP.

To determine the XML element may contain
an integer which defines or attribute selected by the maximum number of instances node
selector, processing begins at the root of another
element. This constraint cannot be represented with XML schema.
However, such constraints may be important to the application usage. XML document. The application usage defines any additional constraints beyond those

Rosenberg Expires August 15, 2004 [Page 7]

Internet-Draft XCAP February 2004
first step in the schema.

4.3 Data Semantics

For each application usage, element selector is then taken. Each step chooses
a single XML element within the data present in current document context. The
document context is the point within the XML document has from which a well defined semantic.
specific step is evaluated. The application usage defines that semantic,
so that a client can properly construct a document in order to
achieve the desired result.

4.4 Naming Conventions

In addition to defining context begins at the meaning root
of the document in document. When a step determines an element within that
context, that element becomes the new context for evaluation of the
next step. Each step can select an element by its name, by a particular application,
combination of name and application usage has to specify how
elements in that application obtain attribute value, by name and position, or by
name, position and attribute. In all cases, the various documents necessary
for name can be
wildcarded, so that all elements get selected.

The selection operation operates as follows. Within the current
document context, the children of that application. In particular, what the relevant
URIs context are that point to documents used by enumerated in
document order. If the context is the document, its child is the
root element in the document. If the application.

As context is an example, one application that can make use element, its
children are all of XCAP the children of that element (naturally). Next,
those elements whose name is not a SIP
event list subscription [20]. In this application, an entity match for NameorAny are discarded.
An elements name is
defined called a Resource List Server (RLS). When match if NameorAny is the RLS receives a
subscription to a SIP URI that represents wildcard, or, if its
not a list, it "expands" wildcard, the
list and subscribes to its members. element name matches NameorAny. Matching is
discussed below. The XCAP resource result is an ordered list
application usage [22] specifies how the RLS uses XCAP to find the
XML document that defines the contents of elements.

Rosenberg Expires January 14, 2005 [Page 19]

Internet-Draft XCAP July 2004

The elements in the list.

These conventions list are defined as naming conventions.

4.5 Data Interdependencies

In many cases, when a user modifies an XCAP resource, other data
managed further filtered by the server needs to change as well. Such interdependencies predicates,
which are application usage dependent. As an example, when a user performs
a PUT operation to create a new presence list, the server may need to
fill expressions in square brackets following NameorAny.
Each predicate further prunes the URI associated with that elements from the current ordered
list. These interdependencies
need to be specified by predicates are evaluated in order. If the application usage.

4.6 Authorization Policies

By default, an XCAP server will only allow a user to access (read,
write, delete or modify) their own documents. The application usage
can specify differing default authorization policies. An application
usage can also specify whether another application usage content of
the content is used to
define a position, the authorization policies. An application usage for setting
authorization policies can also be defined subsequent to position-th element is selected, and
all others are discarded. If there are fewer elements in the
definition of list
than the value of position, the main application usage. In such result is a case, no-match.

If the
main application usage needs only to specify that such a usage will
be defined in content of the future.

Rosenberg Expires August 15, 2004 [Page 8]

Internet-Draft XCAP February 2004

4.7 Data Extensibility

An XCAP server MUST understand an application usage in order to
process predicate is an HTTP request made against a resource for attribute name and value, all
elements possessing that particular
application usage. However, it is not required for the server to
understand attribute with that value are selected, and
all of the contents of others are discarded. Note that elements cannot be selected
based on any namespace attributes. That is, a document used by step like
el-name[@xmlns="namespace"] will never match an application
usage. A server element, even if
there is required to understand the baseline schema defined
by an element in the application usage. However, those schemas can define points list that specifies a default namespace of
extensibility where new content can be added from other namespaces
and corresponding schemas. Sometimes,
"namespace". If there are no elements with attributes having the server will understand
those namespaces
given name and therefore value, the result is a no-match.

After the predicates have access to their schemas.
Sometimes, it been applied, the result will not.

A server be a
no-match, one element, or multiple elements. If the result is
multiple elements, the node selector is invalid. Each step in a node
selector MUST allow produce a single element to form the context for documents that contain elements from
namespaces not known the
next step. This is more restrictive than general XPath expressions,
which allow a context to contain multiple elements. If the server. In such result is
a case, no-match, the server cannot
validate that such content node selector is invalid. The node selector is schema compliant; it will only verify
that
valid if a single element was selected. This element becomes the XML is well-formed.

Unfortunately, it may be
context for the case that a client needs evaluation of the server to
understand these new namespaces next step in order to process a document. This
will be the case when node selector
expression.

Once the new content contains data interdependcies
that last step is executed, if there is no attribute selector,
the result of the node selection is the last selected element. If
there is an attribute selector, the server has checks to understand. To allow for this, this
specification defines see if there is
an XML element called "mandatory-ns". A server
will look for attribute with that name in the presence of this element as in the child of current context.
If there is not, the root result is considered a no-match. Otherwise,
that attribute is selected. Note that namespace attributes (such as
xmlns) cannot be selected.

As a result, once the entire node of any document. If it finds it, selector is evaluated against the server
document, the result will make sure that
it either be a no-match, invalid, or a single
element or single attribute.

Matching of element names and attributes is familiar with any performed as follows.
All elements and attributes are expanded as described in XML
namespaces (and their corresponding schemas)
listed there. [3]. The implication is element and attribute names in the step being
evaluated are also expanded. This expansion form requires that any
namespace prefixes in the schema for all XCAP application usages
MUST allow QName be expanded. This expansion is done
using the namespace bindings that are in scope for the "mandatory-ns" element to be present as current
context element. Like attributes, if the QName within a child of step has no
namespace prefix, the root node of any document. namespace URI is null. The comparisons are

Rosenberg Expires January 14, 2005 [Page 20]

Internet-Draft XCAP July 2004

then done against these expanded forms [[TODO: This is the rules in
XPath, but I dont see how they can be done by explicitly
importing its namespace work. Need to check up on that.]]

Comments, text content, and including it processing declarations in the schema, or allowing
elements from other namespaces to XML
document cannot be selected by the expressions defined here. Of
course, if such information is present in a document, and a user
selects an XML element enclosing that data, that information would be
included in a resulting GET, for example.

As an example, consider the schema as
children of following XML document:

<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:professor@example.net" package="presence">
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved" >sip:userA@example.net</watcher>
<watcher status="pending"
id="hh8juja87s997-ass7"
display-name="Mr. Subscriber"
event="subscribe">sip:userB@example.org</watcher>
</watcher-list>
</watcherinfo>

Example XML Document

Figure 3

The node selector "watcherinfo/watcher-list/
watcher[@id="8ajksjda7s"]" would select the root node. following XML element:

<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved" >sip:userA@example.net
</watcher>

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 9] 21]

Internet-Draft XCAP February July 2004

4.7.1 XML Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:xcap-must-understand"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:xcap-must-understand"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="mandatory-ns">
<xs:complexType>
<xs:sequence>
<xs:element name="ns" type="xs:anyURI" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

4.8 Documenting Application Usages

Application usages are documented in specifications which convey the
information described above. In particular,

7. Client Operations

An XCAP client is an application usage
specification MUST provide HTTP 1.1 compliant client. Specific data
manipulation tasks are accomplished by invoking the following information:

Application Usage ID (AUID): The application usage MUST register right set of HTTP
methods with the
AUID using right set of headers on the IANA procedures defined server. This section
describes those in Section 10.

MIME Type: Each application usage will have detail.

In all cases where the client modifies a MIME type for its
documents. This can either be an existing MIME type, document, by deleting or
inserting a new one
registered document, element or attribute resource, the client
SHOULD verify that, if the operation were to succeed, the resulting
document would meet the data constraints defined by the application usage.

XML Schema: The
usage, including schema for documents used by validation. For example, if the client
performs a PUT operation to
http://xcap.example.com/rls-services/users/joe/mybuddies,
rls-services is the application unique ID, and the application.

Additional Constraints: Any constraints that can not
defined by it SHOULD be represented followed.

The client will know what URI to use based on the naming conventions
described by the XML schema.

Data Semantics:

Naming Conventions:

Resource Interdependencies:

Authorization Policies: application usage.

If the application usage changes document, after modification, does not meet the default
authorization policies, it should specify that. If not, data
constraints, the server will reject it should
specify with a 409. The 409 response
may contain an XML body, formatted according to the schema in Section
9.2, which provides further information on the nature of the error.
The client MAY use this information to try and alter the request so
that this time, it might succeed. The client SHOULD NOT simply retry
the default is used.

Rosenberg Expires August 15, 2004 [Page 10]

Internet-Draft XCAP February 2004

5. URI Construction request without changing some aspect of it.

In order to manipulate some cases, the application usage will dictate involve a piece of configuration data,
uniqueness constraint that the data must client cannot guarantee on its own.
One such example is that a URI has to be represented by an HTTP URI. XCAP defines unique within a specific naming
convention for constructing these URIs. In particular, domain.
Typically, the host part
identifies client is not the XCAP server. The abs_path component owner of the HTTP URI
identifies the specific piece of data to domain, and so it
cannot be modified. This path sure that a URI is
broken into unique. In such a two parts. The first part identifies case, the particular XML
document. XCAP servers organize XML documents in client can
either generate a specific
hierarchical fashion, as described sufficiently random identifier, or it can pick a
"vanity" identifier in Section 5.1. The second part of the path is called a node selector. When present, hopes that it contains an XML
component is not taken. In either
case, if the identifier formatted according is not unique, the server will reject the
request with a 409 and suggest alternatives that the client can use
to Section 5.2. The node
selector identifies try again. If the specific component of server does not suggest alternatives, the XML document. The
client SHOULD attempt to use random identifiers with increasing
amounts of randomness.

HTTP URI without also specifies that PUT and DELETE requests are idempotent.
This means that, if the node selector is called client performs a PUT on a document and it
succeeds, it can perform the same PUT, and the resulting document URI.

Note that there is nothing
will look the same. Similarly, when a client performs a DELETE, if
it succeeds, a subsequent DELETE to the same URI should find the
resource deleted and thus have no further effect. To maintain this
property, the client SHOULD construct its URIs such that, after the

Rosenberg Expires January 14, 2005 [Page 22]

Internet-Draft XCAP July 2004

modification has taken place, the URI in the grammar request will point to
the resource just inserted for PUT (i.e., the body of the request),
and will point to nothing for DELETE. If this property is
maintained, it is the HTTP URI case that
separates GET to the document URI from in the node selector. The path extends
naturally from PUT will return
the document into same content (i.e., GET(PUT(X)) == x). This property is
synonymous with idempotency. If the XML hierarchy within client's request does not have
this property, the
document. Separating server will reject the two components is something request with a server can do
based on its awareness of 409 and
indicate a cannot-insert error condition.

If the structure result of the document directory.

5.1 Identifying PUT is a 200 or 201 response, the XML operation was
successful. Other response codes to any request, such as a
redirection, are processed as per RFC 2616 [5].

7.1 Create or Replace a Document

XCAP mandates that

To create or replace a server MUST organize documents according to document, the client constructs a
defined hierarchy. The root of this hierarchy is an HTTP URI called that
references the XCAP services root URI. location where the document is to be placed. This URI identifies
MUST be a document URI, and therefore contain the XCAP root of and
document selector. The client then invokes a PUT method on that URI.

The MIME content type MUST be the tree
within type defined by the domain where all XCAP documents are stored. It can be any
valid HTTP URL, but MUST NOT contain a query string. As an application
usage. For example,
http://xcap.example.com/services might it would be used as the XCAP "application/rls-services+xml" for
an RLS services
root URI within [23] document, and not "application/xml".

If the Request-URI identifies a document that already exists in the
server, the PUT operation replaces that document with the content of
the request. If the example.com domain. Typically, Request-URI does not identify an existing
document, the XCAP services
root URI document is provisioned into created on the server at that specific URI.

7.2 Delete a Document

To delete a document, the client devices for bootstrapping
purposes.

Beneath constructs a URI that references the XCAP services root
document to be deleted. This URI is MUST be a tree structure for organizing
documents. document URI. The first level of this tree consists of the XCAP AUID.
So, continuing the example above, all of client
then invokes a DELETE operation on the documents used by URI to delete the
presence list application document.

7.3 Fetch a Document

As one would be under http://xcap.example.com/
services/presence-lists.

It is assumed that each application will have data that expect, fetching a document is set trivially accomplished by
users, and/or it will have global data that applies
performing an HTTP GET request with the Request URI set to all users. As
a result, within the directory structure for each application usage,
there are two sub-trees. One, called "users", holds
document URI.

7.4 Create or Replace an Element

To create or replace an XML element within an existing document, the documents
that are applicable
client constructs a URI whose document selector points to specific users, and the other, called
"global", holds documents applicable
document to all users.

Within be modified. The node selector MUST be present in the "users" tree are zero or more sub-trees, each of which
identifies documents that apply to a specific user. XCAP does not
URI, separated from the document selector with the path separator.
To create this this element within the document, the node selector is

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 11] 23]

Internet-Draft XCAP February July 2004

itself define what

constructed such that it means for documents to "apply" to a user,
beyond specification of is a baseline authorization policy, described
below no-match against the current document,
but if the element in Section 7. Each application usage can specify additional
authorization policies which depend on data used by the application
itself.

The remainder body of the URI (the path following "global" or request was added to the specific
user) is not constrained
document as desired by this specification. The application usage
MAY introduce constraints, or may allow any structure to be used.

5.2 Identifying the XML Nodes

The client, the node selector specifies specific nodes of would select
that element. To replace an element in the XML document, the node
selector is constructed so that it is a match against the element in
the current document which
are to be accessed. A node refers replaced, as well as a match to either an XML the new
element or an
attribute (present in the body of an element. The node selector the PUT request) that is an expression which
identifies to replace
it.

Oftentimes, the client will wish to insert an element or attribute. Its grammar is:

node-selector = element-selector ["/" attribute-selector]
element-selector = step *( "/" step)
step = by-name / by-pos / by-attr
by-name = QName ; from XML Namespaces
by-pos = QName "[" position "]" into a document
in a certain position = 1*DIGIT
by-attr = QName "[" "@" att-name "=" <">
att-value <"> "]"
att-name = QName
att-value = AttValue ; from XML specification
attribute-selector = "@" att-name

The QName grammar relative to other children of the same parent.
This is called a positional insertion. They often arise because the
schema constrains where the element can occur, or because ordering of
elements is defined significant within the XML namespaces specification [3].

The schema. To accomplish this, the
client can use a node selector of the following form:

parent/*[position][unique-attribute-value]

Here, "parent" is based on an expression for the concepts parent of the element to be
inserted. "position" is the position amongst the existing children
of this parent where the new element is to be inserted.
"unique-attribute-value" is an attribute name and value for the
element to be inserted, which is different from the current element
in XPath [9]. Indeed, "position". The second predicate is needed so that the
node selector overall
expression happens is a no-match when evaluated against the current children.
Otherwise, the PUT would replace the existing element in that
position.

Consider the example document in Figure 3. The client would like to be
insert a valid XPath expression. new <watcher> element as the second element underneath
<watcher-list>. However, XPath provides it cannot just PUT to a set URI with the
watcherinfo/watcher-list/*[2] node selector; this node selector would
select the existing 2nd child of functionality far richer than is
needed here, <watcher-list> and its breadth would introduce complexity into XCAP.

To determine replace it.
Thus, the XML element or attribute selected by PUT has to be made to a URI with watcherinfo/watcher-list/
*[2][@id="hhggff"] as the node selector, processing begins at where "hhggff" is the root value
of the XML document. The
first step in "id" attribute of the new element selector to be inserted. This
node-selector is then taken. Each step chooses a
specific XML element within no-match against the current document context. The
document context is document, and would
be a match against the point within new element if it was inserted as the XML document from which a
specific step is evaluated. 2nd
child of <watcher-list>.

The document context begins at the root "*" indicates that all children of <watcher-info> are to be
considered when computing the document. When position for insertion. If, instead of
a step determines *, an element within that
context, that element becomes name was present, the expression above would insert
the new context for evaluation of element as the
next step. Each step can select an position-th element by its name, by a
combination of name and attribute value, or by name and position. If amongst those with the step is attempting selection by name,
same name.

Once the server looks for all client constructs the URI, it invokes the HTTP PUT method.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 12] 24]

Internet-Draft XCAP February July 2004

elements within the current context with that name. Name matching is
performed as described below. If there is more than one element with
the specified name,

The content in the result is considered a no-match.

If request MUST be an XML element. Specifically, it
contains the step is attempting selection by name and attribute, element, starting with the server
looks opening bracket for all elements within the current document context with begin
tag for that
name. Of those element, including the attributes and content of that match,
element (whether it looks be text or other child elements), and ending with
the closing bracket for ones that have the given
attribute name, where end tag for that attribute has element. The MIME type
in the given value. request MUST be "application/xcap-el+xml", defined in Section
13.2.1. If there is
no match, or if more than one element matches, the result is
considered a no-match. Note that elements cannot be selected based on
any namespace attributes. Any such attributes are effectively ignored node selector, when evaluated against the current
document, results in terms of a no-match, the matching operations defined here. server performs a creation
operation. If the step node selector, when evaluated against the current
document, is attempting selection by name and position, the server
looks a match for all elements within an element in the current document context document, the
server replaces it with the content of the PUT request. This
replacement is complete; that
name. These is, the old element (including its
attributes and content) are then sorted removed, and the new one, including its
attributes and content, is put in document order, as defined by Xpath.
The position-th its place.

To be certain that element is then selected. If there insertions are fewer than
position number of elements with that name, idempotent, the result is considered
a no-match.

Once client can
check that the last step is executed, if there is no attribute selector, predicates in the result final path segment of the node selection is
URI match the last selected element. If
there is an attribute selector, attributes of the server checks to see if there is element in the body of the request.
As an attribute with example of an request that name within the currently selectoed element.
If there is not, would not be idempotent, consider
the result is considered following PUT request:

PUT
http://xcap.example.com/rls-services/users/bill/index/~~/rls-services/service%5b@uri=%22sip:good-friends@example.com%5d
HTTP/1.1
Content-Type:application/xcap-el+xml

<service uri="sip:mybuddies@example.com">
<resource-list>http://xcap.example.com/resource-lists/users/joe/index/~~/resource-lists/list%5b@name=%22l1%22%5d
</resource-list>
<packages>
<package>presence</package>
</packages>
</service>

This request will fail with a no-match. Otherwise, that
attribute is selected. Note that namespace 409. The Request URI contains a final
path segment with a predicate based on attributes cannot be
selected.

Matching -
@uri="sip:good-friends@example.com". However, this will not match
the value of the "uri" attribute in the element names and attributes is performed by expanding
them into in the expanded name form, as described body.

When the client does not explicitly indicate a position in XML Namespaces, and
then performing which to
insert a new element, the server will insert that element as the comparison last
child of that parent. If this is not the desired position, the
client should perform a positional insertion.

7.5 Delete an Element

To delete an element from a document, the results. When evaluating client constructs a URI

Rosenberg Expires January 14, 2005 [Page 25]

Internet-Draft XCAP July 2004

whose document selector points to the
QNames in document containing the element
to be deleted. The node selector, selector MUST be present following the default namespace path
separator, and namespace
definitions identify the specific element to be deleted.

The client then invokes the HTTP DELETE method. The server will
remove the element from the document URI apply.

Comments, text content, (including its attributes and processing declarations in the XML
document cannot be selected by the expressions defined here. Of
course, if
its content, such information is present in as any children).

7.6 Fetch an Element

To fetch an element of a document, and the client constructs a user
selects an XML URI whose
document selector points to the document containing the element enclosing that data, that information would to be
included in a resulting GET, for example.

As an example, consider the following XML document:

Rosenberg Expires August 15, 2004 [Page 13]

Internet-Draft XCAP February 2004

<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved" >sip:userA@example.net</watcher>

Rosenberg Expires August 15, 2004 [Page 14]

Internet-Draft XCAP February 2004

6. Client Operations

An XCAP the path
separator, and must identify the element to be fetched.

The client is an HTTP 1.1 compliant client. Specific data
manipulation tasks are accomplished by invoking then invokes the GET method. The 200 OK response will
contain that XML element. Specifically, it contains the right set content of HTTP
methods
the XML document, starting with the right set of headers on opening bracket for the server. begin tag
for that element, and ending with the closing bracket for the end tag
for that element. This section
describes those in detail

6.1 will, as a result, include all attributes and
child elements of that element.

7.7 Create or Replace a Document an Attribute

To create or replace an attribute in an existing element of a
document, the client constructs a URI that
references the location where whose document selector points
to the document is to be placed. This URI
MUST NOT contain a NodeSelector component. The client then invokes a
PUT method on that URI. modified. The content in node selector, following the request
path separator, MUST be an XML document compliant to the
schema associated with the application usage defined by the URI. For
example, present. The node selector MUST be
constructed such that, if the client performs a PUT operation to http://
xcap.example.com/services/presence-lists/users/joe/mybuddies,
presence-lists is the application unique ID, and attribute was created or replaced as
desired, the schema defined
by it node selector would dictate select that attribute. If the body of node
selector, when evaluated against the request. The MIME content type
SHOULD be as specific as possible. For example, "application/
resource-lists+xml" for current document, results in a resource list [22], instead of just
"application/xml".
no-match, it is a creation operation. If the Request-URI identifies it matches an existing
attribute, it is a document that already exists in the
server, replacement operation.

The client then invokes the HTTP PUT operation replaces that document with the method. The content defined by
the request MUST be the value of the request. If attribute, compliant to the Request-URI does not identify an existing
document,
grammar for AttValue as defined in XML 1.0. Note that, unlike when
AttValue is present in the document URI, there is created on no escape coding. Escaping
only applies to URIs. This request MUST be sent with the
Content-Type of "application/xcap-att+xml" as defined in Section
13.2.2. The server at will add that specific URI.

If the result of attribute such that, if the PUT node
selector is a 200 or 202 response, evaluated on the operation was
successful. If resulting document, it was a 409, returns the user performed some action which
resulted
attribute present in an invalid document. The 409 response may contain an XML
body, formatted according to the schema request.

To be certain that attribute insertions are idempotent, the client
can check that any attribute predicate in Section 7.2.1.1, the path segment that
selects the element into which
provides further information on the nature of attribute is inserted, matches a
different attribute than the error. The client
MAY use this information to try and alter one being inserted by the request. As

Rosenberg Expires January 14, 2005 [Page 26]

Internet-Draft XCAP July 2004

an example of a request so that this
time, it might succeed. The client SHOULD NOT simply retry would not be idempotent, consider the
following PUT request:

PUT
http://xcap.example.com/rls-services/users/bill/index/~~/rls-services/service%5b@uri=%22sip:good-friends@example.com%5d/@uri
HTTP/1.1
Content-Type:application/xcap-att+xml

"sip:bad-friends@example.com"

This request without changing some aspect of it.

6.2 Delete will fail with a Document 409.

7.8 Delete an Attribute

To delete a attributes from the document, the client constructs a URI that references
whose document selector points to the document containing the
attributes to be deleted. By definition this URI will not contain a
NodeSelector component. The client then invokes a DELETE operation on
the URI to delete the document.

6.3 Fetch a Document

As one would expect, fetching a document is trivially accomplished by

Rosenberg Expires August 15, 2004 [Page 15]

Internet-Draft XCAP February 2004

performing an HTTP GET request with node selector MUST be present
following the Request URI set path separator, and evaluate to an attribute in the
document to be fetched. When a deleted.

The client fetches a document, and there
is an older version cached, it is useful for clients to perform
conditional GETs using the If-Match header field, in order to reduce
network usage if then invokes the cached copy is still valid. An HTTP DELETE method. The server MUST
return Etags for entities that represent resources managed by XCAP.

6.4 Create or Replace will
remove the attribute from the document.

7.9 Fetch an Element Attribute

To create or replace an XML element within fetch an existing attribute of a document, the client constructs a URI
whose document URI selector points to the document containing the
attribute to be modified. fetched. The node selector MUST be present in following
the URI. The node
selector is constructed such that, if path separator, containing an expression identifying the element was added
attribute whose value is to the
document as desired by the client, the node selector would select
that element. be fetched.

The client then invokes the HTTP PUT GET method. The content 200 OK response will
contain an "application/xcap-att+xml" document with the specified
attribute, formatted according to the grammar of AttValue as defined
in the
request MUST be an XML element. Specifically, it contains 1.0 specifications.

7.10 Conditional Operations

The HTTP specification defines several header fields that can be used
by a client to make the
element, starting with processing of the opening bracket for request conditional. In
particular, the begin If-None-Match and If-Match header fields allow a
client to make them conditional on the current value of the entity
tag for the resource. These conditional operations are particularly
useful for XCAP resources.

For example, it is anticipated that
element, including clients will frequently wish to
cache the current version of a document. So, when the client starts

Rosenberg Expires January 14, 2005 [Page 27]

Internet-Draft XCAP July 2004

up, it will fetch the attributes current document from the server and content of that element
(whether store it.
When it be text or other child elements), and ending with does so, the
closing bracket for GET response will contain the end entity tag for that element. The MIME type in the request SHOULD be "application/xml-fragment-body", defined in
Section 10.2. The
document resource. Each resource within a document maintained by the
server will insert share the element (including all its
attributes and its content) into same value of the document such that entity tag. As a result, the node
selector, if evaluated
entity tag returned by the server, would return server for the content
present in document resource is
applicable to element and attribute resources within the request. document.

If the node selector, when evaluated against client wishes to modify an element or attribute within the current
document, results but it wants to be certain that the document hasn't been
modified since the client last operated on it, it can include an
If-Match header field in a no-match, the server performs a
creation operation. If request, containing the node selector, when evaluated against value of the
current document, is a match
entity tag known to the client for an element in all resources within the current document, document.
If the document has changed, the server replaces it will reject this request with the content of the PUT request. This
replacement is complete;
a 412 response. In that is, case, the old element (including client will need to flush its
attributes and content) are removed, and
cached version, fetch the new one, including its
attributes entire document, and content, is put in its place. The client SHOULD be
certain, before making the request, that store the resulting modified
document will also be conformant new entity
tag returned by the server in the 200 OK to the schema.

It is GET request.

Its important to note that the element might potentially be
inserted entity tags are defined for each resource
in the document document, even though they share the same value. As a result,
if a resource does not exist in several different ways, and still meet the constraints defined above. This document, there is analagous no entity tag
for it, and a PUT to the case when such a
new file is resource with an If-Match header field
will always fail with a 412. For this reason, PUT operations that
insert a new element or attribute into a directory document cannot be
conditioned on a server; the location of that
file within the directory is not specified, and is up to entity tag for the local
file system to decide. The only guarantee is that GET(PUT(x)) returns document x.

If the result of the PUT is a 200 or 202 response, the operation was
successful. itself. If it was a 409, the user performed some action which
resulted in an invalid document. The 409 response may contain an XML

Rosenberg Expires August 15, 2004 [Page 16]

Internet-Draft XCAP February 2004

body, formatted according client
wishes to make sure that the schema in Section 7.2.1.1, which
provides further information on document has not changed before adding
the nature of new element or attribute, the error. The client
MAY use this information to try can "pop up a level", and alter the request so that this
time,
instead of inserting a new element or attribute, it might succeed. The client SHOULD NOT simply retry can modify the
request without changing some aspect
parent of it.

6.5 Delete an Element

To delete an that new element from a document, the client constructs a URI
whose document URI points to and attribute such that the document containing new value
contains the new element or attribute.

In another example, a client may wish to
be deleted. The node selector MUST be present, and identify the
specific insert a new element into a
document, but wants to be deleted.

The client then invokes sure that the HTTP DELETE method. The server insertion will
remove the only take
place if that element from does not exist. In other words, the document (including its attributes and
its content, such as any children). The client SHOULD be certain,
before making
wants the request, that the resulting modified document will
also be conformant PUT operation to the schema.

If the result of the DELETE is be a 200 response, the operation was
successful. If it was creation, not a 409, replacement. To
accomplish that, the user performed some action which
resulted in an invalid document. The 409 response may contain an XML
body, formatted according to client can insert the schema in Section 7.2.1.1, which
provides further information on If-None-Match header field
into the nature PUT request, with a value of *. This tells the error. The client
MAY use this information server to try and alter
reject the request so that this
time, it might succeed. The with a 412 if resource exists.

As another example, a when a client SHOULD NOT simply retry the
request without changing some aspect of it.

6.6 Fetch an Element

To fetch an element of fetches a document, the client constructs and there is
an older version cached, it is useful for clients to use a URI whose
document URI points
conditional GET in order to reduce network usage if the document containing cached copy
is still valid. This is done by including, in the element to be
fetched. The node selector MUST be present, and must identify GET request, the
element
If-None-Match header field with a value equal to be fetched.

The the current etag
held by the client then invokes for the GET method. document. The response server will contain only generate a
200 OK reponse if the etag held by the server differs than that XML element. Specifically, it contains held
by the content of client. If it doesnt differ, the XML
document, starting server will respond with a
304 response.

Rosenberg Expires January 14, 2005 [Page 28]

Internet-Draft XCAP July 2004

8. Server Behavior

An XCAP server is an HTTP 1.1 compliant origin server. The behaviors
mandated by this specification relate to the opening bracket for way in which the begin tag for
that element, HTTP
URI is interpreted and ending with the closing bracket for content is constructed.

An XCAP server MUST be explicitly aware of the end tag application usage
against which requests are being made. That is, the server must be
explicitly configured to handle URIs for
that element. This will, as a result, include all attributes each specific application
usage, and
child elements must be aware of the constraints imposed by that element.

6.7 Create or Replace an Attribute

To create or replace an attribute in an existing element of a
document,
application usage.

When the client constructs server receives a URI whose document URI points to
the document to be modified. The node selector MUST be present. The
node selector MUST be constructed such that, if request, the attribute was

Rosenberg Expires August 15, 2004 [Page 17]

Internet-Draft XCAP February 2004

created or replaced as desired, treatment depends on the node selector would select that
attribute. URI.
If the node selector, when evaluated against URI refers to an application usage not understood by the
server, the server MUST reject the current
document, results in a no-match, it is request with a creation operation. 404 (Not Found)
response. If it
matches an existing attribute, it is a replacement operation.

The client then invokes the HTTP PUT method. The content defined URI refers to a user that is not recognized by the request
server, it MUST be compliant to reject the grammar for AttValue as defined
in XML 1.0. This request MUST be sent with a 404 (Not Found).

Next, the Content-Type of
"application/xml-attribute-value" as defined in Section 10.3. The server will add authenticates the request. All XCAP servers MUST
implement HTTP Digest [10]. Furthermore, servers MUST implement HTTP
over TLS, RFC 2818 [13]. It is RECOMMENDED that attribute such that, administrators use
an HTTPS URI as the XCAP root URI, so that the digest client
authentication occurs over TLS.

Next, the server determines if the node selector is
evaluated client has authorization to
perform the requested operation on the resulting document, it returns resource. The application
usage defines the attribute present authorization policies. An application usage may
specify that the default is used. This default is described in
Section 5.6.

Once authorized, the request. The client SHOULD be certain, before making specific behavior depends on the
request, that method and what
the resulting modified document will also be conformant URI refers to.

8.1 POST Handling

XCAP resources do not represent processing scripts. As a result,
POST operations to HTTP URIs representing XCAP resources are not
defined. A server receiving such a request for an XCAP resource
SHOULD return a 405.

8.2 PUT Handling

The behavior of a server in receipt of a PUT request is as specified
in HTTP 1.1 Section 9.6 - the schema.

If the result content of the PUT request is a 200 or 202 response, the operation was
successful. If it was a 409, placed at the user performed some action which
resulted in an invalid document. The 409 response may contain an XML
body, formatted according
specified location. This section serves to define the schema in Section 7.2.1.1, which
provides further information on notion of
"placement" and "specified location" within the nature context of XCAP
resources.

Rosenberg Expires January 14, 2005 [Page 29]

Internet-Draft XCAP July 2004

8.2.1 Locating the error. Parent

The client
MAY use this information first step the server performs is to try and alter locate the request so that this
time, parent, whether
it might succeed. The client SHOULD NOT simply retry is a directory or element, in which the
request without changing some aspect of it.

6.8 Delete an Attribute resource is to be placed.
To delete attributes do that, the server removes the last path segment from the document, URI.
The rest of the client constructs a URI
whose document URI points refers to the parent. This parent can be a
document, element, or prefix of a document containing selector (called a
directory, even though this specification does not mandate that
doocuments are actually stored in a filesystem). This URI is called
the attributes
to be deleted. parent URI. The node selector MUST be present, path segment that was removed is called the
target selector, and evaluate to an
attribute in the node (element, document or attribute) it
describes is called the target node.

If the parent URI has no path separator, it is referring to be deleted.

The client then invokes the HTTP DELETE method. The server will
remove
directory into which the attribute from document should be inserted. If this
directory does not exist, the document. The client server MUST return a 409 response, and
SHOULD be certain,
before making include a detailed conflict report including the request, that <no-parent>
element. Detailed conflict reports are discussed in Section 9. If
the resulting modified document will
also be conformant directory does exist, the server checks to see if there is a
document with the schema.

If same filename as the result of target node. If there is, the DELETE
operation is a 200 response, the replacement operation was
successful. discussed in Section 8.2.4.
If it was a 409, the user performed some action which
resulted in an invalid document. The 409 response may contain an XML
body, formatted according to does not exist, it is the schema creation operation, discussed in
Section 7.2.1.1, which
provides further information on 8.2.4.

If the nature of parent URI has a path separator, the error. The client
MAY use this information to try document selector is
extracted, and alter the request so that this
time, it might succeed. The client SHOULD NOT simply retry document is retrieved. If the
request without changing some aspect of it.

6.9 Fetch an Attribute

To fetch an attribute of a document, document does not
exist, the client constructs server MUST return a URI

Rosenberg Expires August 15, 2004 [Page 18]

Internet-Draft XCAP February 2004

whose Document-URI points to 409 response, and SHOULD include a
detailed conflict report including the document containing <no-parent> element. If it
does exist, the attribute to
be fetched. The node selector MUST be present, containing an
expression identifying is extracted, and unescaped (recall
that the attribute whose value node selector is to be fetched. escape coded). The client then invokes node selector is
applied to the GET method. The response will contain an
"application/xml-attribute-value" document with the specified
attribute, formatted according to based on the grammar of AttValue as defined matching operations discussed in
Section 6.3. If the result is a no-match or invalid, the server MUST
return a 409 response, and SHOULD include a detailed conflict report
including the <no-parent> element.

If the XML 1.0 specifications.

6.10 Read/Modify/Write Transactions

It node-selector is anticipated that a common operation will be to read valid, the current
version of a document or element, modify it on server examines the client, target
selector, and then
write evaluates in within the change back to context of the server. In order for parent node. If
the results to be
consistent with target node exists within the client's expectations, parent, the operation must be
atomic.

To accomplish this, the client makes use of entity tags returned by is a
replacement, as described in Section 8.2.4. If it does not exist, it
is the server creation operation, discussed in a GET operation used to read Section 8.2.4.

Before performing the element, attribute, replacement or
document that is to be modified. To guarantee atomicity, the PUT
operation used to write creation, as determined based on
the changes back to logic above, the server MUST contain
an If-Match header field, whose value is equal to validates the entity tag from content of the prior GET response. request as
described in Section 8.2.2

8.2.2 Verifying Document Content

If the PUT request fails with is for a 412 response, document (the request URI had no path

Rosenberg Expires January 14, 2005 [Page 30]

Internet-Draft XCAP July 2004

separator), the
client knows that another update content of the data request body has occurred before it
was able to write be a well-formed
XML document. If it is not, the results back. The client can then fetch server MUST reject the
most recent version, and attempt its modification again.

Because there are no batching operations defined in HTTP that would
allow for a number of separate create, modify or delete operations to
be performed atomically, designers of application usages should take
care to structure their schemas so that operations that need to be
performed atomically can be done in request with
a single operation.

6.11 Reading Server Assigned Data

In some application usages, components of 409 response code. That response SHOULD include a detailed
conflict report including the document cannot be set
by <not-well-formed> element. If the user. Rather, they must be filled MIME
type in by the server. Such cases
are documented as part Content-Type header field of the application usage. Frequently, the
client will want request is not equal to know the value assigned by
the server. As an
example, in MIME type defined for the resource list application usage [22], usage, the server
assigns MUST
reject the uri for request with a resource list. The client will need this URI to
subscribe to 415.

If the resource list, PUT request is for example.

There are two ways such discovery can an element, the content of the request body
has to be accomplished. In a well-balanced region of an XML document, also known as an
XML fragment body in The XML Fragment Interchange [4] specification,
including only a single element. If it is not, the first,
once server MUST
reject the client PUTs request with a document or element that requires 409 response code. That response SHOULD
include a detailed conflict report including the data <not-xml-frag>
element. If the MIME type in the Content-Type header field of the
request is not equal to
be filled in, "application/xcap-el+xml", the client can do server MUST
reject the request with a subsequent GET to find 415.

If the URI.
This GET can be PUT request is for an attribute, the entire document, the same URI that was used
in content of the PUT, or request
body has to be a URI sequence of characters that points just to comply with the specific data assigned

Rosenberg Expires August 15, 2004 [Page 19]

Internet-Draft XCAP February 2004

by grammar
for AttValue as defined above. If it is not, the server MUST reject
the request with a 409 response code. That response SHOULD include a
detailed conflict report including the server. The result of <not-xml-att-value> element.
If the GET will tell MIME type in the client about Content-Type header field of the
assigned data. Note that request is
not equal to "application/xcap-att+xml", the Etag present server MUST reject the
request with a 415.

8.2.3 Creation

The steps in this sub-section are followed if the response is
significant, as it PUT request will be different from the one returned
result in the
previous response to PUT. That's because, as creation of a result new document, element or attribute.

If the PUT request is for a document, the content of the server's
assignment, request body
is placed into the document has changed, directory, and its filename is associated with the
target node, which is therefore assigned a new
Etag.

The second way a client can learn about document.

If the change PUT request is through for an
event package that might be used to find out about changes to XCAP
resources.

It element, the server inserts the content
of the request body as a new child element of the parent element
selected in Section 8.2.1. The insertion is important to note that done such that, the 200 OK response
request URI, when evaluated, would now point to the element which was
inserted. If the target selector is defined by a PUT by-name or by-attr
production (in other words, there is always
empty, and will not contain no position indicated) the
server MUST insert the document or element after any other siblings. If a
position is indicated, the server
has computed MUST insert the necessary data.

Rosenberg Expires August 15, 2004 [Page 20]

Internet-Draft XCAP February 2004

7. Server Behavior

An XCAP server element so that it
is an HTTP 1.1 compliant origin server. The behaviors
mandated by this specification relate to the way in which the HTTP
URI position-th element amongst all siblings whose name matches
NameorAny.

It is interpreted and possible that the content is constructed.

An XCAP server MUST element cannot be explicitly aware of the application usage
against which requests are being made. That is, inserted such that the server must be
explicitly configured to handle URIs for each specific application
usage, and must be aware of

Rosenberg Expires January 14, 2005 [Page 31]

Internet-Draft XCAP July 2004

request URI, when evaluated, returns the constraints imposed by that
application usage.

When content provided in the server receives
request. Such a request, the treatment depends on request is not idempotent, and is not allowed for
PUT. This happens when the URI.
If element in the URI refers to an application usage body is not understood described by
the
server, expression in the target selector. An example of this case is
described in Section 7.4. If this happens the server MUST NOT
perform the insertion, and MUST reject the request with a 404 (Not Found) 409
response. If The body of the URI refers to response SHOULD contain a user that detailed
conflict report containing the <cannot-insert> element. It is
important to note that schema compliance does not recognized play a role while
performing the insertion. That is, the decision of where the element
gets inserted is dictated entirely by the
server, it MUST reject structure of the request with a 404 (Not Found).

Next,
request-URI, the server authenticates current document, and the request. All XCAP servers MUST
implement HTTP Digest [10]. Furthermore, servers MUST implement HTTP
over TLS, RFC 2818 [13]. It rules in this
specification.

If the PUT request is RECOMMENDED that administrators use for an
HTTPS URI as attribute, the XCAP root services URI, so that server inserts the digest client
authentication occurs over TLS.

Next,
content of the server determines if request body as the value of the attribute. The name
of the client has authorization attribute is equal to
perform the requested operation on att-name from the resource. The default
authorization policy is attribute-selector
in the target selector.

Assuming that only client X can access (create, read,
write, modify or delete) resources under the "users/X" directory.
Only priviledged administrators insertion can write resources under be accomplished, the
"global" directory, but all users can read them.

An application usage can specify an alternate default authorization
policy specific to that usage. The server may also know of an
application usage verifies
that itself defines authorization policies for
another the insertion results in a document that meets the constraints
of the application usage. Of course, an administrator This is dicussed in Section 8.2.5.

8.2.4 Replacement

The steps in this sub-section are followed if the PUT request will
result in the replacement of a document, element or privileged
user can override attribute with
the default authorization policy, although this
specification provides no means contents of the request.

If the PUT request is for doing that.

Once authorized, a document, the specific behavior depends on content of the method and what request body
is placed into the URI refers to.

7.1 POST Handling

Resources managed by XCAP do not represent processing scripts. As a
result, POST operations to XCAP URIs are not defined. A server
receiving such a directory, replacing the document with the same
filename.

If the PUT request is for an xcap resource SHOULD return a 405.

Rosenberg Expires August 15, 2004 [Page 21]

Internet-Draft XCAP February 2004

7.2 PUT Handling

The behavior element, the server replaces the target
node with the content of the request body. As in the creation case,
it is possible that, after replacement, the request URI does not
select the element that was just inserted. If this happens the
server MUST NOT perform the replacement, and MUST reject the request
with a server in receipt 409 response. The body of the response SHOULD contain a
detailed conflict report containing the <cannot-insert> element.

If the PUT request is as specified
in HTTP 1.1 Section 9.6 - for an attribute, the server sets the value of
the selected attribute to the content of the request body. It is placed at
possible in the
specified location. This section serves to define replacement case (but not in the notion creation case),
that, after replacement of
"placement" and "specified location" within the context of XCAP
resources.

If attribute, the request URI represents a document (i.e., there is no node
selector component), longer
selects the content of attribute that was just replaced. The scenario in which
this can happen is discussed in Section 7.7. If this is the request case,
the server MUST be a valid XML
document, NOT perform the replacement, and MUST be compliant to the schema associated with the
application usage in the URI. If it is not, reject the

Rosenberg Expires January 14, 2005 [Page 32]

Internet-Draft XCAP July 2004

request MUST be
rejected with a 409 response. If The body of the request URI matches response SHOULD contain
a document
that exists on detailed conflict report containing the server, that document is replaced by <cannot-insert> element.

8.2.5 Validation

Once the content
of document, element or attribute has been tentatively
inserted, the request. If server needs to verify that the request URI does not match a resulting document that
exists on
meets the server, data constraints outlined by the application usage.

First, the server adds checks that the final document is compliant to its repository,
and associates the
schema. If it with is not, the URI in server MUST NOT perform the insertion. It
MUST reject the request URI. Note that this may
require with a 409 response. That response SHOULD
contain a detailed conflict report containing the creation of one or more "directories" on
<schema-validation-error> element.

Next, the server checks for any uniqueness constraints identified by
the server. application usage. If the Request URI represents an XML element (i.e., it contains application usage required that a
node selector, but no
particular element or attribute selector) had a unique value within a specific
scope, the server MUST verify would check that
the document defined by the document URI this uniqueness property still
exists. If no such the application usage required that a URI within the
document
exists on was unique within the server, domain, the server checks whether it
is the case. If any of these uniqueness constraints are not met, the
server MUST NOT perform the insertion. It MUST reject the request
with a 404 409 response. That response code. The content of the request MUST be SHOULD contain a single XML detailed
conflict report containing the <uniqueness-failure> element. That
element can contain suggested values that the client can retry with.
These SHOULD be values that, at the time the server generates the
409, would meet the uniqueness constraints.

The server also checks for URI constraints and associated content (including children elements), whose
MIME type is "application/xml-fragment-body". other non-schema data
constraints. If the request does not
contain a valid XML fragment body, document fails one of these constraints, the
server MUST NOT perform the insertion. It MUST reject the request is rejected
with a 409 response. That response code. If SHOULD contain a detailed
conflict report containing the request URI matches an <constraint-failure> element. That
element within the
document, indicates that element is removed, and replaced with the content of document failed non-schema data
constraints explicitly called out by the request. If application usage.

8.2.6 Resource Interdependencies

Because XCAP resources include elements, attributes and documents,
each of which has its own HTTP URI, the request URI does not match an element in creation or modification of
one resource affects the
document, state of many others. For example,
insertion of a document creates resources on the server inserts the content for all of
the request as a new
element in the document, such that the resulting document is
compliant to the schema, elements and such attributes within that document. After the request URI, when
evaluated, would now point to server
has performed the element which was inserted. There
may be more than one way to perform such an insertion; in that case,
it is insertion associated with the discretion of PUT, the implementor as to how it is done. It may
also be possible server MUST
create and/or modify those resources affected by that the insertion cannot be done because the parent PUT. The
structure of the element does not exist in the document, or cannot be done
because document, after document completely defines the element is added, would inter-relationship
between those resources. Normally a server will not be compliant need to actually

Rosenberg Expires January 14, 2005 [Page 33]

Internet-Draft XCAP July 2004

do anything to meet this requirement, since those other resources
would normally be resolved dynamically when requests are made against
them.

However, the schema, application usage can specify other resource
inter-dependencies. The server MUST create or because modify the new element cannot be described resources
specified by the
node-selector no matter what its point of insertion. In such a case, application usage.

If the creation or insertion was successful, and the resource
interdependcies are resolved, the server MUST return returns a 409 200 OK or 201
Created, as appropriate. This response code. In all cases, the
resulting document MUST be compliant to the schema.

If not contain any content.

8.3 GET Handling

The semantics of GET are as specified in RFC 2616. This section
clarifies the Request specific content to be returned for a particular URI
that represents an XML attribute (i.e., it XCAP resource.

If the request URI contains only a
node selector and an attribute selector) document selector, the server MUST verify that
returns the document defined specified by the document URI exists. If no such document
exists on the server, the server MUST reject the request with if it exists, else returns
a 404

Rosenberg Expires August 15, 2004 [Page 22]

Internet-Draft XCAP February 2004

response code. response. The content MIME type of the request will be a MIME object body of
type "application/xml-attribute-value", which represents a single XML
attribute. This attribute will the 200 OK response
MUST be compliant to the grammar for
AttValue as MIME type defined in XML 1.0. If the content is not a valid
xml-attribute-value, the server rejects the request with a 409
response. If the request URI matches an existing attribute within the
document, by that attribute is removed, and replaced with the content of
the request. application usage (i.e.,
"application/resource-lists+xml").

If the request URI does not match an attribute in the
document, contains a node selector, the server inserts obtains the content of
document specified by the request as a new
attribute in document selector, and if it is found,
evaluates the document, such node-selector within that the resulting document. If no document is
compliant to
found, or if the schema, and such that node-selector is a no-match or invalid, the request URI, when
evaluated, would now point to server
returns a 404 response. Otherwise, the attribute which was inserted. There
may be more than one way to perform such server returns a 200 OK
response. If the node selector identifies an insertion; in XML element, that case,
it
element is returned in the discretion of the implementor 200 OK response as to how it is done. It may
also be possible that the insertion cannot be done because the
containing element does not exist, or cannot be done because an XML fragment body
containing the
result selected element. The MIME type of the change would response MUST
be a document "application/xcap-el+xml". If the node selector identifies an XML
attribute, the value of that attribute is not compliant to returned in the
schema. In such a case, body of the server MUST return a 409 response code.
response. The server MUST check the resulting document for the presence MIME type of the
"mandatory-schemas" element, which will always response MUST be a child "application/
xcap-att+xml".

8.4 DELETE Handling

The semantics of DELETE are as specified in RFC 2616. This section
clarifies the root
element. specific content to be deleted for a particular URI
that represents an XCAP resource.

If this element is present, the server checks each of the
schemas listed. If request URI contains only a schema is listed which document selector, the server does not
support,
deletes the server MUST reject document specified by the request with URI if it exists and returns a 409
200 OK, else returns a 404 response.

If the application usage indicates that there is request URI contains a data dependency, node selector, the server checks to see if the information contained in obtains the PUT
requires

Rosenberg Expires January 14, 2005 [Page 34]

Internet-Draft XCAP July 2004

document specified by the server to compute some component of document selector, and if it is found,
evaluates the node-selector within that document. If it
does, no document is
found, or if the node-selector is a no-match or invalid, the server MUST perform
returns a 404 response. Otherwise, the computation, and then update server removes the specified
element or attribute from the document with and performs the result. Since validation
checks defined in Section 8.2.2. If the document has changed, it
represents deletion will cause a new instance
failure of one of the resource, and constraints, the server deletion MUST assign
a new etag. NOT take place.
The server follows the procedures in Section 8.2.2 for computing the
409 response. If the application usage indicates that there is deletion results in a data dependency,
and document that dependency requires is still
valid, the server to MUST perform some kind of data
validation beyond that specified in the XML schema, deletion and return a 200 OK
response.

Before the server returns the 200 OK response to a DELETE, it MUST
perform
process the validation. If resource interdependcies as defined in Section 8.2.6.

8.5 Managing Etags

An XCAP server MUST maintain entity tags for all resources that it
maintains. This specification introduces the additional constraint
that when one resource within a document fails (including the validation, document
itself) changes, that resource is assigned a new etag, and all other
resources within that document MUST be assigned the same etag value.
An XCAP server MUST reject include the request with a 409 response. The server Etag header field in all 200 or 201
responses to PUT, GET, or DELETE [[Todo: Not sure we'll see them in
DELETE responses. Need to check.]]. XCAP resources do not introduce
new requirements on the strength of the entity tags; as in RFC 2616,
weak ones MAY
add be used if performance constraints or other conditions
make usage of strong ones untenable for some reason.

As a result of this constraint, when a client makes a change to an error report
element or attribute within a document, the response to that
operation will convey the response, indicating entity tag of the nature resource that was just
affected. Since the client knows that this entity tag value is
shared by all of the
validation error.

If other resources in the creation or insertion was successful, document, the server returns a 200
OK or 201 Created, as appropriate. This response MUST not contain any
content.

7.2.1 client can
make conditional requests against other resources using that entity
tag.

Rosenberg Expires January 14, 2005 [Page 35]

Internet-Draft XCAP July 2004

9. Detailed Conflict Reports

In cases where the server returns a 409 error response, that response due to any of

Rosenberg Expires August 15, 2004 [Page 23]

Internet-Draft XCAP February 2004

the conditions described above, it MAY
will usually include a document in the body of the response which
provides further details on the nature of the error. This document
is an XML document, formatted according to the schema of Section 7.2.1.1. 9.2.
Its MIME type, registered by this specification, is "application/xcap-error+xml". "application/
xcap-error+xml".

9.1 Document Structure

The document structure is simple. It contains the root element
"xcap-error".
<xcap-error>. The content of this element is a specific error
condition. Each error condition is represented by a different
element. This allows for different error conditions to provide
different data about the nature of the error. All error elements
support a "phrase" attribute, which can contain text meant for
rendering to a human user.

The "schema-validation-error" element following error elements are defined by this specification:
<not-well-formed>: This indicates that the document was
not compliant to the schema after body of the requested operation request was
performed. The "not-xml-frag" element
not a well-formed XML document.
<not-xml-frag>: This indicates that the request was supposed to
contain a valid XML fragment body, but did not. Most likely this
is because the XML in the body was malformed or not balanced. The "no-parent" element
<no-parent>: This indicates that an attempt to insert an element failed, element,
attribute or document failed because the document or element into
which the insertion was supposed to occur did does not exist. This
error element can contain an optional
"ancestor" <ancestor> element, which
provides an HTTP URI pointed to of the xcap resource that identifies the
closest ancestor element that does exist in the document. The "cannot-insert" element provides Because
this is a generic
catch-all for other insertion cases. The "no-xml-att-value" valid HTTP URI, its node selector component MUST be
escape encoded.
<schema-validation-error>: This element indicates that the document
was not compliant to the schema after the requested operation was
performed.
<not-xml-att-value>: This indicates that the request was supposed to
contain a valid XML attribute value, but did not. The "no-element" element
<cannot-insert>: This indicates that
an attempt to insert an attribute was made, but the element in which the attribute was to be inserted does requested PUT operation
could not exist.

The "uri-exists" element supports application usages that define data
constraints. In particular, be performed because it is expected would not be idempotent.
<uniqueness-failure>: This indicates that many application
usages will require the server to compute requested operation
would result in a document that did not meet a uniqueness
constraint defined by the application usage. For each URI,
element or allow attribute specified by the client
to provide a URI. In either case, the URI needs to be unique within which is not unique,
an <exists> element is present as the domain content of the server. If the client provides error
element. Each <exists> element has a URI, and "field" attribute that
contains the URI
already exists, it would be an error. This node selector identifying the XML element describes that
condition. For each URI provided by or
attribute whose value needs to be unique, but wasn't. Note that

Rosenberg Expires January 14, 2005 [Page 36]

Internet-Draft XCAP July 2004

the client double quote character, which already exists,
an "exists" element is present as allowed in node selectors,
cannot appear within the content value of "uri-exists". Each
"exists" element has a "uri" attribute that contains an attribute. As such, it MUST
be represented as &quot. Beyond that, since the URI which
exists. node selector is
not appearing within an HTTP URL, there is no escape encoding.
The "exists" element, in turn, <exists> element can optionally contain a list of suggested
alternate URIs values which do not currently exist on the server.

The "unknown-mand-ns" element
<constraint-failure>: This indicates that the document contained requested operation
would result in a
"mandatory-ns" element document that listed failed a namespace not understood data constraint defined
by the
server. The content of the "unknown-mand-ns" element is a list of
"ns" elements, each one containing a URI identifying a namespace

Rosenberg Expires August 15, 2004 [Page 24]

Internet-Draft XCAP February 2004

listed as mandatory in the document, application usage, but was not understood enforced by the
server. schema or a
uniqueness constraint.

Extensions to XCAP can define additional error elements.

As an example, the following document indicates that the user
attempted to create a resource list an RLS service using the URI
sip:friends@example.com, but that URI already exists:

<?xml version="1.0" encoding="UTF-8"?>
<xcap-error xmlns="urn:ietf:params:xml:ns:xcap-error"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<uri-exists> xmlns="urn:ietf:params:xml:ns:xcap-error">
<uniqueness-failure>
<exists uri="sip:friends@example.com">
<alt-uri>sip:friends2@example.com</alt-uri> field="rls-services/service/@uri">
<alt-value>sip:mybuddies@example.com</alt-value>
</exists>
</uri-exists>
</uniqueness-failure>
</xcap-error>

7.2.1.1

9.2 XML Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-error"
xmlns="urn:ietf:params:xml:ns:xcap-error"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="error-element" abstract="true"/>
<xs:element name="xcap-error">
<xs:annotation>
<xs:documentation>Indicates the reason for the error.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:choice>
<xs:element name="schema-validation-error">
<xs:annotation>
<xs:documentation>The resulting document was not compliant to the schema.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:sequence>
<xs:element name="not-xml-frag">
<xs:annotation>
<xs:documentation>The request did not contain a valid xml fragment body.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/> ref="error-element"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="no-parent">
<xs:annotation>

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 25] 37]

Internet-Draft XCAP February July 2004

<xs:documentation>The element could not be inserted because its parent does not exist in the document.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>

<xs:element name="ancestor" type="xs:anyURI" minOccurs="0"> name="schema-validation-error" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>Contains an HTTP URI
<xs:documentation>This element indicates
that points the document was not compliant to the element which is schema after the closest ancestor that does exist.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="cannot-insert">
<xs:annotation>
<xs:documentation>The element could not be inserted.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-xml-att-value">
<xs:annotation>
<xs:documentation>The request did not contain a valid xml attribute value.</xs:documentation> requested
operation was performed.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="no-element"> name="not-xml-frag" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>The attribute could not be inserted because
<xs:documentation>This indicates that the element in which request was supposed to insert does not exist.</xs:documentation>
contain a valid XML fragment body, but did not.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="uri-exists"> name="no-parent" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>The user tried to set a URI
<xs:documentation>This indicates that an attempt to insert
an element, attribute or document failed because the server must constrain document or
element into which the insertion was
supposed to be unique, and this URI exists.</xs:documentation> occur does not exist</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="exists" maxOccurs="unbounded"> name="ancestor" type="xs:anyURI" minOccurs="0">
<xs:annotation>
<xs:documentation>There is
<xs:documentation>Contains an instance of this element for each HTTP URI in that points to the document
element which suffered this failure.</xs:documentation>
</xs:annotation>
<xs:complexType>

Rosenberg Expires August 15, 2004 [Page 26]

Internet-Draft XCAP February 2004

<xs:sequence minOccurs="0">
<xs:element name="alt-uri" type="xs:string" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>An optional set of alternate URIs can be provided.</xs:documentation> is the closest ancestor that does exist.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="unknown-mand-ns">
<xs:annotation>
<xs:documentation>The document had a mandatory namespace which was not understood by the server.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="ns" type="xs:anyURI" maxOccurs="unbounded"> name="cannot-insert" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>Each unknown namespace is listed.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>

7.3 GET Handling

The semantics of GET are as specified in RFC 2616. This section
clarifies the specific content to be returned for a particular URI
<xs:documentation>This indicates that represents an XCAP resource.

If the request URI contains only a document URI, the server returns
the document specified by the URI if requested
PUT operation could not be performed because it exists, else returns a 404
response. The MIME type of the response SHOULD would not be the most specific
type known for that document (i.e., "application/resource-lists+xml"
instead of "application/xml"). If the request URI contains a node
selector, and that node selector identifies an XML element in an
idempotent.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 27] 38]

Internet-Draft XCAP February July 2004

existing document,

<xs:element name="not-xml-att-value" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that element is returned in the 200 response. The
MIME type of the response MUST be "application/xml-fragment-body".
The content of the response is the portion of the XML document
starting with the left bracket of the begin tag of the element,
ending with the right bracket of the end tag of the element. If the
request URI contains was supposed to contain a node selector, and that node selector contains
an valid XML attribute selector, and value, but did
not.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="uniqueness-failure" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that attribute exists in the specified
document, the server returns
requested operation would result in a document that attribute. The MIME type of did not meet a
uniqueness constraint defined by the
response MUST be "application/xml-attribute-value", which contains an
XML application usage.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="exists" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>For each URI,
element or attribute value formatted according to the grammar of AttValue in
the XML 1.0 specifications. In all cases, if specified by the referenced resource
does client which is not exist, a 404 unique,
one of these is returned.

7.4 DELETE Handling

The semantics present.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0">
<xs:element name="alt-value" type="xs:string" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>An optional set of DELETE are as specified in RFC 2616. This section
clarifies the specific content to alternate values
can be deleted for a particular URI
that represents an XCAP resource.

If the request URI contains only a Document-URI, the server deletes
the document specified by provided.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="field" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-well-formed" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the URI if it exists and returns a 200 OK
response, else returns a 404 response. If body of the request URI specifies was
not a
Node-Selector, the server verifies well-formed document.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="constraint-failure" substitutionGroup="error-element">
<xs:annotation>

Rosenberg Expires January 14, 2005 [Page 39]

Internet-Draft XCAP July 2004

<xs:documentation>This indicates that the
requested operation would result in a document specified that failed a data
constraint defined by the
Document-URI exists. If it does application usage, but not exist, enforced by the server returns
schema or a 404
(Not Found) response. If uniqueness constraint.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:schema>

Rosenberg Expires January 14, 2005 [Page 40]

Internet-Draft XCAP July 2004

10. XCAP Server Capabilities

XCAP can be extended through the document does exist, addition of new application usages
and extensions to the node
selector specifies core protocol. An XCAP server can also be
extended to support new namespaces. It will often be necessary for a
client to determine what extensions, application usages or namespaces
a server supports before making a request. To enable that, this
specification defines an XML element that exists, that element is
removed from the document. If application usage with the AUID "xcap-caps".
All XCAP servers MUST support this application usage. This usage
defines a single document does exist, and within the node
selector specifies an XML attribute that exists in global tree which lists the
capabilities of the server. Clients can read this well-known
document, that
attribute is removed from and therefore learn the document. If capabilities of the node selector returns
a no-match, a 404 (Not Found) server.

The structure of the document is returned. However, if removal simple. The root element is
<xcap-caps>. Its children are <auids>, <extensions>, and
<namespaces>. Each of these contain a list of AUIDs, extensions and
namespaces supported by the server. Extensions are named by tokens
defined by the extension. Namespaces are identified by their
namespace URI. Since all XCAP servers support the
element or attribute would result "xcap-caps" AUID,
it MUST be listed in a document which does not comply
with the XML schema for <auids> element.

The following sections provide the information needed to define this
application usage, usage.

10.1 Application Usage ID (AUID)

This specification defines the server MUST NOT
perform "xcap-caps" AUID within the deletion, and MUST reject IETF tree,
via the request with a 409
(Conflict).

7.5 Managing Etags

An XCAP server MUST maintain entity tags for all resources that can
be referenced by a URI within a particular document. RFC 2616 allows
for entity tags IANA registration in Section 13.

10.2 XML Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:xml:params:ns:xcap-caps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:xml:params:ns:xcap-caps"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="xcap-caps">
<xs:annotation>
<xs:documentation>Root element for one resource to be applied to other resources. In
the case xcap-caps</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="auids">
<xs:annotation>
<xs:documentation>List of supported AUID.</xs:documentation>
</xs:annotation>

Rosenberg Expires January 14, 2005 [Page 41]

Internet-Draft XCAP resources, a server MUST use the same etag July 2004

<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="auid" type="auidType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="extensions">
<xs:annotation>
<xs:documentation>List of supported extensions.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="extension" type="extensionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="namespaces">
<xs:annotation>
<xs:documentation>List of supported namespaces.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="namespace" type="namespaceType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="auidType">
<xs:annotation>
<xs:documentation>AUID Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="extensionType">
<xs:annotation>
<xs:documentation>Extension Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="namespaceType">
<xs:annotation>
<xs:documentation>Namespace type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>

Rosenberg Expires January 14, 2005 [Page 42]

Internet-Draft XCAP July 2004

</xs:schema>

10.3 MIME Type

Documents conformant to
reference all resources that define elements within a particular
document. In other words, this schema are known by the MIME type
"application/xcap-caps+xml", registered in Section 13.2.4.

10.4 Validation Constraints

There are no additional validation constraints associated with this
application usage.

10.5 Data Semantics

Data semantics are defined above.

10.6 Naming Conventions

A server effectively maintains MUST maintain a single
etag per document, and all resources within that single instance of the document inherit in the
same etag.

This constraint is necessary for a client to make changes to various
parts
global tree, using the filename "index". There MUST NOT be an
instance of a this document even though it only posesses in the etag for users tree.

10.7 Resource Interdependencies

There are no resource interdependencies in this application usage
beyond those defined by the schema.

10.8 Authorization Policies

This application usage does not change the default authorization
policy defined by XCAP.

Rosenberg Expires August 15, 2004 [Page 28]

Internet-Draft XCAP February 2004

overall document.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 29] 43]

Internet-Draft XCAP February July 2004

11. Examples

This section goes through several examples, making use of the
resource-lists [22] and rls-services [23] XCAP application usage. usages.

First, a user Bill creates a new document (see Section 6.1). 7.1). This
document is a new resource-list, initially with a single list, called
friends, with no users in it:

PUT
http://xcap.example.com/services/presence-lists/users/bill/fr.xml
http://xcap.example.com/services/resource-lists/users/bill/fr.xml HTTP/1.1
Content-Type:application/presence-lists+xml
Content-Type:application/resource-lists+xml

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends" uri="sip:friends@example.com" subscribeable="true"> name="friends">
</list>
</resource-lists>

Next, Bill creates an RLS services document defining a single RLS
service referencing this list. This service has a URI of
sip:myfriends@example.com:

PUT
http://xcap.example.com/services/rls-services/users/bill/index HTTP/1.1
Content-Type:application/rls-services+xml

<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<service uri="sip:myfriends@example.com">
<resource-list>http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/resource-lists/list%5b@name=%22friends%22%5d
</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>

Next, Bill creates an element in this the resource-lists document (Section 6.4).
7.4). In particular, he adds an entry to the list:

Rosenberg Expires January 14, 2005 [Page 44]

Internet-Draft XCAP July 2004

PUT
http://xcap.example.com/services/presence-lists/users/bill/fr.xml/
resource-lists/list[@name="friends"]/entry
http://xcap.example.com/services/resource-lists/users/bill/fr.xml
/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
Content-Type:application/xml-fragment-body
Content-Type:application/xcap-el+xml

<entry name="Bob" uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry>

Next, Bill fetches the document (Section 6.3): 7.3):

GET
http://xcap.example.com/services/presence-lists/users/bill/fr.xml
http://xcap.example.com/services/resource-lists/users/bill/fr.xml HTTP/1.1

And the result is:

Rosenberg Expires August 15, 2004 [Page 30]

Internet-Draft XCAP February 2004

HTTP/1.1 200 OK
Etag: "wwhha"
Content-Type: application/presence-lists+xml application/resource-lists+xml

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="friends" uri="sip:friends@example.com"
subscribeable="true"> name="friends">
<entry name="Bob" uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry>
</list>
</resource-lists>

Next, Bill adds another entry to the list, which is another list that
has three entries. This is another element creation (Section 6.4): 7.4):

Rosenberg Expires January 14, 2005 [Page 45]

Internet-Draft XCAP July 2004

PUT
http://xcap.example.com/services/presence-lists/users/bill/fr.xml/
presence-lists/list[@name="friends"]/list[@name="close-friends"]
http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/
resource-lists/list%5b@name=%22friends%22%5d/list%5b@name=%22close-friends%22%5d HTTP/1.1
Content-Type: application/xml-fragment-body

<list name="close-friends" uri="sip:close-friends@example.com"
subscribeable="true"> name="close-friends">
<entry name="Joe" uri="sip:joe@example.com">
<display-name>Joe Smith</display-name>
</entry>
<entry name="Nancy" uri="sip:nancy@example.com">
<display-name>Nancy Gross</display-name>
</entry>
<entry name="Petri" uri="sip:petri@example.com">
<display-name>Petri Aukia</display-name>
</entry>
</list>

Then, Bill decides he doesnt want Petri on the list, so he deletes
the entry (Section 6.5): 7.5):

DELETE
http://xcap.example.com/services/presence-lists/users/bill/fr.xml/
presence-lists/list/list/entry[@name="Petri"]
http://xcap.example.com/services/resource-lists/users/bill/fr.xml/
~~/resource-lists/list/list/entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1

Bill decides to check on the URI for Nancy, so he fetches a
particular attribute (Section 6.6):

Rosenberg Expires August 15, 2004 [Page 31]

Internet-Draft XCAP February 2004 7.6):

GET
http://xcap.example.com/services/presence-lists/users/bill/fr.xml/
presence-lists/list/list/entry[@name="Nancy"]/@uri
http://xcap.example.com/services/resource-lists/users/bill/fr.xml/
~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1

and the server responds:

HTTP/1.1 200 OK
Etag: "ad88"
Content-Type:application/xml-attribute-value
Content-Type:application/xcap-att+xml

"sip:nancy@example.com"

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 32] 46]

Internet-Draft XCAP February July 2004

12. Security Considerations

Frequently, the data manipulated by XCAP contains sensitive
information. To avoid eavesdroppers from seeing this information, it
is RECOMMENDED that an admistrator hand out an https URI as the XCAP
root services URI. This will result in TLS-encrypted communications between
the client and server, preventing any eavesdropping.

Client and server authentication are also important. A client needs
to be sure it is talking to the server it believes it is contacting.
Otherwise, it may be given false information, which can lead to
denial of service attacks against a client. To prevent this, a
client SHOULD attempt to upgrade [14] any connections to TLS.
Similarly, authorization of read and write operations against the
data is important, and this requires client authentication. As a
result, a server SHOULD challenge a client using HTTP Digest [10] to
establish its identity, and this SHOULD be done over a TLS
connection.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 33] 47]

Internet-Draft XCAP February July 2004

10.

13. IANA Considerations

There are several IANA considerations associated with this
specification.

10.1

13.1 XCAP Application Usage IDs

This specification instructs IANA to create a new registry for XCAP
application usage IDs (AUIDs). This registry is defined as a table
that contains three colums:
AUID: This will be a string provided in the IANA registrations into
the registry.
Description: This is text that is supplied by the IANA registration
into the registry.
Document: This is a reference to the RFC containing the registration.

This specification instructs IANA to create this table with an
initial entry. The resulting table would look like:

Application Unique Description Document
ID (AUID)
-----------------------------------------------------------

xcap-caps Capabilities of an RFC XXXX
XCAP server

[[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of
this specification.]]

XCAP AUIDs are registered by the IANA when they are published in
standards track RFCs. The IANA Considerations section of the RFC
must include the following information, which appears in the IANA
registry along with the RFC number of the publication.
Name of the AUID. The name MAY be of any length, but SHOULD be no
more than twenty characters long. The name MUST consist of
alphanum [15] characters only.
Descriptive text that describes the application usage.

10.2 application/xml-fragment-body

13.2 MIME Type Types

This specification registers a requests the registration of several new MIME type
types according to the procedures of RFC 2048 [7] and guidelines in
RFC 3023 [8].

13.2.1 application/xcap-el+xml MIME Type

This specification registers a new MIME type according to the

Rosenberg Expires January 14, 2005 [Page 48]

Internet-Draft XCAP July 2004

MIME media type name: application
MIME subtype name: xml-fragment-body xcap-el+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: The XML Fragment Interchange [4], which
defines an XML fragment body as a well-balanced region of an XML
document being considered as (logically and/or physically)
separate from the rest of the document for RFC XXXX [[NOTE TO RFC EDITOR: Please
replace XXXX with the purposes published RFC number of
defining it as a fragment.

Rosenberg Expires August 15, 2004 [Page 34]

Internet-Draft XCAP February 2004 this
specification.]]
Applications which use this media type: This document type has been
used to support transport of XML fragment bodies in RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC
number of this specification.]], the XML Configuration Access
Protocol (XCAP).
Additional Information:
Magic Number: None
File Extension: .xfb .xel or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.

10.3 application/xml-attribute-value

13.2.2 application/xcap-att+xml MIME Type

This specification registers a new MIME type according to the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].
MIME media type name: application
MIME subtype name: xml-attribute-value xcap-att+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: An entity RFC XXXX [[NOTE TO RFC EDITOR: Please
replace XXXX with the published RFC number of this MIME
specification.]].
Applications which use this media type: This document type is compliant has been
used to
the grammar for AttValue as specified support transport of XML attribute values in RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC
number of this specification.]], the XML 1.0 [1]. Configuration Access
Protocol (XCAP).
Additional Information:

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 35] 49]

Internet-Draft XCAP February July 2004

Magic Number: None
File Extension: .xav
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.

13.2.3 application/xcap-error+xml MIME Type
MIME media type name: application
MIME subtype name: xcap-error+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: This specification.
Applications which use this media type: This document type has been
used to support transport of XML attribute values conveys
error conditions defined in RFC XXXX XXXX. [[NOTE TO RFC EDITOR:
Please replace XXXX with the published RFC number of this specification.]], the XML Configuration Access
Protocol (XCAP).
specification.]]
Additional Information:
Magic Number: None
File Extension: .xav .xe
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.

10.4 application/xcap-error+xml

13.2.4 application/xcap-caps+xml MIME Type

This specification registers a new MIME type according to the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].
MIME media type name: application
MIME subtype name: xcap-error+xml xcap-caps+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: This specification.
Applications which use this media type: This document type conveys
error conditions
capabililites of an XML Configuration Access Protocol (XCAP)
server, as defined in RFC XXXX. [[NOTE TO RFC EDITOR: Please
replace XXXX with the published RFC number of this
specification.]]

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 36] 50]

Internet-Draft XCAP February July 2004

specification.]]

Additional Information:
Magic Number: None
File Extension: .xe
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.

10.5

13.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-must-understand Registrations

This section specification registers a several new XML namespace, namespaces, as per the
guidelines in RFC 3688 [16].

13.3.1 urn:ietf:params:xml:ns:xcap-error
URI: The URI for this namespace is
urn:ietf:params:xml:ns:xcap-must-understand urn:ietf:params:xml:ns:xcap-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML:

BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Resource Lists
<title>XCAP Error Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Must Understand Element</h1>
<h2>urn:ietf:params:xml:ns:xcap-must-understand</h2> Error Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-error</h2>
<p>See <a href="[[[URL href="[URL of published RFC]]]">RFCXXXX</a>.</p> RFC]">RFCXXXX [[NOTE
TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
this specification]]</a>.</p>
</body>

Rosenberg Expires August 15, 2004 [Page 37]

Internet-Draft XCAP February 2004
</html>
END

10.6 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-error

This section registers a new XML namespace, as per the guidelines in
RFC 3688 [16].

13.3.2 urn:ietf:params:xml:ns:xcap-caps
URI: The URI for this namespace is
urn:ietf:params:xml:ns:xcap-error urn:ietf:params:xml:ns:xcap-caps
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).

Rosenberg Expires January 14, 2005 [Page 51]

Internet-Draft XCAP July 2004

XML:

BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Resource Lists
<title>XCAP Capabilities Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Error Capability Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-error</h2>
<h2>urn:ietf:params:xml:ns:xcap-caps</h2>
<p>See <a href="[[[URL href="[URL of published RFC]]]">RFCXXXX</a>.</p> RFC]">RFCXXXX [[NOTE
TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
this specification]]</a>.</p>
</body>
</html>
END

10.7 XCAP Error

13.4 XML Schema Registration Registrations

This section registers an two XML schema schemas per the procedures in [16].

13.4.1 XCAP Error Schema Registration
URI: please assign. urn:ietf:params:xml:schema:xcap-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).

Rosenberg Expires August 15, 2004 [Page 38]

Internet-Draft XCAP February 2004
XML Schema: The XML for this schema can be found as the sole content
of Section 7.2.1.1.

10.8 9.2.

13.4.2 XCAP Mandatory Namespace Capabilities Schema Registration

This section registers an XML schema per the procedures in [16].
URI: please assign. urn:ietf:params:xml:schema:xcap-caps
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML Schema: The XML for this schema can be found as the sole content
of Section 4.7.1. 10.2.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 39] 52]

Internet-Draft XCAP February July 2004

11.

14. Acknowledgements

The author would like to thank Ben Campbell, Eva-Maria Leppanen,
Hisham Khartabil, and Chris Newman Newman, Joel Halpern, Jari Urpalainen, and
Lisa Dusseault for their input and comments. A special thanks to Ted
Hardie for his input and support.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 40] 53]

Internet-Draft XCAP February July 2004

15. References

15.1 Normative References

[1] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000.

[2] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
May 2001.

[3] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
REC REC-xml-names-19990114, January 1999.

[4] Grosso, P. and D. Veillard, "XML Fragment Interchange", W3C CR
CR-xml-fragment-20010212, February 2001.

[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[7] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.

[8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.

[9] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", W3C REC REC-xpath-19991116, November 1999.

[10] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.

[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.

[13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

Rosenberg Expires January 14, 2005 [Page 54]

Internet-Draft XCAP July 2004

[14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
RFC 2817, May 2000.

Rosenberg Expires August 15, 2004 [Page 41]

Internet-Draft XCAP February 2004

[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.

[16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.

Rosenberg Expires August 15, 2004 [Page 42]

Internet-Draft XCAP February 2004

[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.

15.2 Informative References

[17]

[18] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.

[18]

[19] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.

[19]

[20] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information",
draft-ietf-simple-winfo-format-04 (work in progress), January
2003.

[20]

[21] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource
Lists", draft-ietf-simple-event-list-04 (work in progress),
June 2003.

[21]

[22] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
Data Elements in Session Initiation Protocol (SIP) for Instant
Messaging and Presence Leveraging Extensions (SIMPLE) Systems",
draft-ietf-simple-data-req-03 (work in progress), June 2003.

[22]

[23] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence
Lists", draft-ietf-simple-xcap-list-usage-01 draft-ietf-simple-xcap-list-usage-02 (work in
progress), February 2004.

[24] Peterson, J., "Common Profile for Presence (CPP)",
draft-ietf-impp-pres-04 (work in progress), October 2003.

[23]

[25] Newman, C. and J. Myers, "ACAP -- Application Configuration

Rosenberg Expires January 14, 2005 [Page 55]

Internet-Draft XCAP July 2004

Access Protocol", RFC 2244, November 1997.

[24]

[26] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.

[27] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.

[25]

[28] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.

Rosenberg Expires August 15, 2004 [Page 43]

Internet-Draft XCAP February 2004

Author's Address

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US

Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 44] 56]

Internet-Draft XCAP February July 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be
found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose at
ietf-ipr@ietf.org.

Disclaimer of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. Validity

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION

Rosenberg Expires August 15, 2004 [Page 45]

Internet-Draft XCAP February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Rosenberg Expires August 15, 2004 January 14, 2005 [Page 46] 57]

----