WDIFF

draft-ietf-simple-xcap-00.txt --> draft-ietf-simple-xcap-01.txt

SIMPLE J. Rosenberg
Internet-Draft dynamicsoft
Expires: December 22, 2003 June 23, April 26, 2004 October 27, 2003

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

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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.

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

This Internet-Draft will expire on December 22, 2003. April 26, 2004.

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 December 22, 2003 April 26, 2004 [Page 1]

Internet-Draft XCAP June October 2003

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Application Usages . . . . . . . . . . . . . . . . . . . . . 6
5. URI Construction . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Identifying the XML Document . . . . . . . . . . . . . . . . 8
5.2 Identifying the XML Nodes . . . . . . . . . . . . . . . . . 9
6. Client Operations . . . . . . . . . . . . . . . . . . . . . 10 12
6.1 Creating a New Document . . . . . . . . . . . . . . . . . . 10 12
6.2 Replace an Existing Document . . . . . . . . . . . . . . . . 10 12
6.3 Deleting a Document . . . . . . . . . . . . . . . . . . . . 10 12
6.4 Fetching a Document . . . . . . . . . . . . . . . . . . . . 10 12
6.5 Creating a New Element . . . . . . . . . . . . . . . . . . . 10 12
6.6 Replacing an Element in the Document . . . . . . . . . . . . 11 13
6.7 Delete an Element . . . . . . . . . . . . . . . . . . . . . 12 13
6.8 Fetch an Element . . . . . . . . . . . . . . . . . . . . . . 12 13
6.9 Create an Attribute . . . . . . . . . . . . . . . . . . . . 12 14
6.10 Replacing Attributes . . . . . . . . . . . . . . . . . . . . 13 14
6.11 Deleting Attributes . . . . . . . . . . . . . . . . . . . . 13 14
6.12 Fetching Attributes . . . . . . . . . . . . . . . . . . . . 13 14
6.13 Fetching Metadata . . . . . . . . . . . . . . . . . . . . . 13
6.14 Read/Modify/Write Transactions . . . . . . . . . . . . . . . 14 15
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . 15 16
7.1 POST Handling . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 PUT Handling . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 GET Handling . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4 DELETE Handling . . . . . . . . . . . . . . . . . . . . . . 18
7.5 Managing Modification Times Etags . . . . . . . . . . . . . . . . . . . . . . . 19
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 20
9. Security Considerations . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . 25
Informative References . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 28

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 2]

Internet-Draft XCAP June October 2003

1. Introduction

The Session Initiation Protocol for Instant Messaging and Presence
Leveraging Extensions (SIMPLE) working group has been developing
specifications for subscribing to,

In many communications applications, such as Voice over IP, instant
messaging, and receiving notifications of,
user presence [10]. An important aspect of user presence presence, it is
authorization policy. Indeed, the presence specification requires a
Presence Agent (PA) necessary for network servers to both authenticate and authorize all
subscriptions before accepting them. However, it does not define how
the server determines
access per-user information in the authorization status process of servicing a subscriber. Users
can set their authorization policy through web pages or voice
response systems. However, there is currently no protocol specified
for setting this policy. A protocol for this purpose request.
This per-user information resides within the network, but is called an
authorization manipulation protocol.

Mechanisms have also been defined to support reactive authorization
[11][12]. Reactive authorization allows managed
by the end user to themselves. Its management can be informed when
someone has attempted to subscribe to their presence when done through a
multiplicity of access points, including the server
is unable to determine an authorization policy. The user can then go
and set an web, a wireless handset,
or a PC application.

Examples of per-user information are presence [12] authorization
policy for the subscriber, using the same
unspecified mechanism for setting the policy.

Another important aspect of and presence systems is the buddy list, also
known as the lists. Presence lists are lists of users whose
presence list. This is desired by a watcher. Presence information for the list
of users that a watcher
wishes to learn presence state for. This list can be stored in the
client, or it can be stored in obtained by subscribing to a centralized server. resource which
represents that list [15]. In the latter this case, the client would subscribe Resource List Server
(RLS) requires access to the list as a whole [13]. The
presence this list can be set by using a web page or voice response
application. However, there is no protocol mechanism currently
specified in order to manage the presence list. Such a protocol is called process a
presence list manipulation protocol.

The SIMPLE group has defined requirements SIP
[11]SUBSCRIBE [20] request for it. Requirements for an authorization manipulation protocol and a of
presence list manipulation protocol.
These protocols have similar requirements, lists and are captured in [14]. authorization policies have been specified by the
SIMPLE working group [16].

This document proposes specification describes a candidate for the authorization and presence
manipulation protocol, 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 not actually a
new protocol. XCAP Rather, it is a set of conventions for using mapping XML
documents and document components into HTTP to read, write URIs, rules for how the
modification of one resource affects another, data validation
constraints, and modify XML configuration 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)
[15],
[18], 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 December 22, 2003 April 26, 2004 [Page 3]

Internet-Draft XCAP June October 2003

2. Overview of Operation

XCAP supports the needs of any application that needs access to data
defined by clients of the application.

Each application that makes use of XCAP specifies an application
usage (Section 4). This application usage defines the XML schema [1]
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 [2]. 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 subtree of the document, or any attribute for any element within
the document. Thus, the HTTP URIs used by XCAP point to pieces of
information that are finer grained than the XML document itself.

With a standardized naming convention for mapping components of XML
documents,
documents to HTTP URIs, the basic operations for accessing the data
are simple. provided by existing HTTP primitives. Reading one of the
components is just a standard accomplished with HTTP GET operation.
Writing, GET, creating or modifying one
of the components is a standard done with an HTTP POST or PUT operation. Deleting a component PUT, and removing one of the
components is just a standard
DELETE operation. For example, to add a friend to a presence list, a
client would construct done with an XML document fragment which contains the
information on that friend. The client would then construct a URI
that refers to the location in the presence list document where this
new fragment is to be added. The client then performs a POST
operation against the URI, placing the document fragment into the
body of the POST request. HTTP DELETE. To provide atomic read/modify/write read/
modify/write operations, the HTTP If-Unmodified-Since header field is entity tags are used. The
HTTP POST operation used by the client would contain the date
obtained in the Last-Modified header field from the GET used to read
the data.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 4]

Internet-Draft XCAP June October 2003

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 [3] and
indicate requirement levels for compliant implementations.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 5]

Internet-Draft XCAP June October 2003

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 of XCAP. This definition is composed of several pieces of
information, such as an XML schema and constraints on values of one
element given values in another.

Application usages are documented in specifications which convey this
information. In particular, an application usage specification MUST
provide the following information:

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 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 [16] [19] based on the guidelines
in Section 10. The second namespace is the vendor-proprietary
namespace. Each AUID in that namespace is prefixed with the token
"vnd", followed by a period ("."),
reverse domain name name of the organization creating the AUID,
followed by a valid DNS name,
followed by another period, followed by any vendor defined token.
A vendor creating such an AUID MUST only create one using domain
names for which it is an administrator. As an
example, the example.com domain can create an AUID with the value
"vnd.example.com.foo"
"com.example.foo" but cannot create one with the value
"vnd.example.org.bar".
"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 [7] (and using some of the
BNF defined in RFC 2396 [8]) 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

MIME Type: Each application usage MUST register a MIME type for its
XML documents. This is done based on the procedures of RFC 3023
[4].

XML Schema: Each application will have a unique schema which defines
the data needed by the application. In XCAP, this schema is
represented using XML schema. As an example, presence list data
is composed of a list of URIs, each of which represends a member
of presence list. [17] defines the XML schema for this data. [1].

Rosenberg Expires April 26, 2004 [Page 6]

Internet-Draft XCAP October 2003

Additional Constraints: XML schemas can represent a variety of
constraints about data, such as ranges and types. However, schemas
cannot cover all types of data constraints, including constraints
introduced by data interdependencies. For example, one XML element
may contain an integer which defines the maximum number of
instances of another element. The application usage defines these

Rosenberg Expires December 22, 2003 [Page 6]

Internet-Draft XCAP June 2003
additional constraints.

Data Semantics: The application usage needs to define detailed
semantics for each piece of data in the schema.

Naming Conventions: The data defined by the XML schema will be used
by any number of entities participating in the application. In the
case of presence list, the data is used by the Resource List
Server (RLS), which reads the data, and by the clients, which
write it. During the execution of the application (i.e., the
processing of the list subscription), specific documents will need
to be read or written. In order for the application to function
properly, there needs to be agreement on exactly which documents
are read or written by the application. This is an issue of naming
conventions; agreeing on how an application constructs the URI
representing the document that is to be read or written. The
application usage spells out this information.

Computed Data: Frequently, some of the data defined in the schema
is not independent; that is, its value depends on the values of
other elements in the document. As a result,

Resource Interdependencies: In many cases, when a client uses user modifies an
XCAP resource, many other resources need to modify the independent pieces of the document, the server
needs to compute the dependent ones in order to fully populate the
document. The change as well. Such
interdependencies are application usage needs to define which data
components are dependent, and how they are computed. dependent. As an example,
when the URI for a presence list is not specified by user performs a
client, PUT operation to create a URI is chosen by new presence
list, the server and filled in. This needs may need to fill in the URI associated with that
list. These interdependencies need to be specified by the
application usage. Note that, if a server needs to modify data
within a document just PUT by the client, this modification is
effectively accomplished as a separate transaction. Concretely,
this means that, after the server modifies the data, the entity
tags are updated as if the client had made the change itself.

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. Of course, An application usage can also specify
whether another application usage is used to define the default
authorization policies. An application usage for setting
authorization policies can always also be
overriden by operator or user-specified policies. 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.

Application usages are similar to dataset classes in ACAP.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 7]

Internet-Draft XCAP June October 2003

5. URI Construction

In order to manipulate a piece of configuration data, the data must
be represented by an HTTP URI. XCAP defines a specific naming
convention for constructing these URIs. This convention is very
similar to In particular, the naming conventions used for dataset classes in ACAP,
and makes use host part
identifies the XPath [5] specification for identifying nodes of an
XML document. XCAP server. The abs_path component of the HTTP URI consists of two parts:

XCAP-URI = Document-URI ["?" Node-Selector]
Document-URI = http_URL ;from RFC2616
Node-Selector = *uric ;Escape coded LocationPath from XPath

The first part,
identifies the Document-URI, selects a specific XML document. It
is a valid HTTP URL, subject document to the constraints be modified. XCAP servers
organize XML documents in a specific hierarchical fashion, as
described here. The
constraints for constructing this URI are discussed below in Section 5.1. Once The URI MAY contain a document query. This query is selected,
called a node selector. When present, it contains an XML component
identifier formatted according to Section 5.2. The node selector
identifies the remainder specific component of the XML document. The HTTP URI (the
Node-Selector) identifies which components of
without the document are being
addressed. The Node-Selector query is an XPath [5] LocationPath expression,
subject to constraints described below. called the document URI. , and makes use the
specification for identifying nodes of an XML document.

5.1 Identifying the XML Document

XCAP mandates that a server organizes documents according to a
defined hierarchy. The root of this hierarchy is an HTTP URI called
the XCAP services root URI. This URI identifies 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 services
root URI within the example.com domain. Typically, the XCAP services
root URI is provisioned into client devices for bootstrapping
purposes.

Beneath the XCAP services root URI is a tree structure for organizing
documents. The first level of this tree consists of the XCAP AUID.
So, continuing the example above, all of the documents used by the
presence list application would be under http://xcap.example.com/
services/presence-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, within the directory structure for each application usage,
there are two sub-trees. One, called "users", holds the documents
that are applicable to only specific users, and the other, called
"global", holds documents applicable to all users.

Rosenberg Expires December 22, 2003 [Page 8]

Internet-Draft XCAP June 2003

Within the "users" tree are zero or more sub-trees, each of which
identifies a documents that apply to a specific user. XCAP does not
itself define what it means for documents to "apply" to a user,
beyond specification of a baseline authorization policy.
Specifically, the default authorization policy is that only a user
who authenticates themself as user X can read, write, or otherwise
access in any way the documents within sub-tree X. Each application
usage can specify additional authorization policies which depend on

Rosenberg Expires April 26, 2004 [Page 8]

Internet-Draft XCAP October 2003

data used by the application itself.

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

5.2 Identifying the XML Nodes

The second component of the XCAP URI specifies specific nodes of the
XML document which are to be accessed. Nodes, in this context, A node refers to the definition provided in the XPath specification, and therefore
includes either an XML elements, attributes, text, namespaces, processing
instructions, comments, and roots. These nodes are identified by a
LocationPath expression, as defined in XPath. Either the abbreviated
element or unabbreviated form MAY be used.

Contraints are imposed on the XPath an attribute of an element. The node selector is an
expression which identifies 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 "]"
position = 1*DIGIT
by-attr = QName "[" "@" att-name "=" <">
att-value <"> "]"
att-name = QName
att-value = AttValue ; from XML specification
by-pos = QName "[" position "]"
position = *DIGIT
attribute-selector = "@" att-name

The node selector is based on the operation
being performed. These do not constrain the functions or axes that
can be used concepts in the XPath expression, but rather constrain [5]. Indeed, the
resulting
node set. See Section 6 for details.

Rosenberg Expires December 22, 2003 [Page 9]

Internet-Draft XCAP June 2003

6. Client Operations

An XCAP client is an HTTP 1.1 compliant client. An XCAP client
performs selector expression happens to be a valid XPath expression.
However, XPath provides a set of primitive operations functionality far richer than is
needed here, and its breadth would introduce complexity into XCAP.

To determne the XML element or attribute selected by invoking specific methods
against the server, using specific URIs, where node
selector, processing begins at the requests contain
bodies and headers subject to specific constraints. The set root of
primitive operations, the methods used to accomplish them, and the
header and body constraints are described here.

6.1 Creating a New Document

To create a new document, XML document. The
first step in the client constructs element selector is then taken. Each step chooses a URI that references
the location where
specific XML element within the current document context. The
document context is to be placed. This URI MUST NOT
contain a NodeSelector component, and MUST meet the constraints
described in Section 5.1. point within the XML document from which a
specific step is evaluated. The client then invokes document context begins at the root
of the document. When a PUT method on step determines an element within that URI.

The content in
context, that element becomes the request MUST be new context for evaluation of the
next step. Each step can select an XML document compliant to element by its name, by a
combination of name and attribute value, or by name and position. If
the
schema associated step is attempting selection by name, the server looks for all
elements within the current context with that name. Name matching is
performed as described below. If there is more than one element with
the application usage defined specified name, the result is considered a no-match.

Rosenberg Expires April 26, 2004 [Page 9]

Internet-Draft XCAP October 2003

If the step is attempting selection by name and attribute, the URI. For
example, server
looks for all elements within the current document context with that
name. Of those that match, it looks for ones that have the given
attribute name, where that attribute has the given value. If there is
no match, or if more than one element matches, the client performs a PUT operation to http://
xcap.example.com/services/presence-lists/users/joe/mybuddies,
presence-lists result is
considered a no-match.

If the application unique ID, step is attempting selection by name and position, the schema server
looks for all elements within the current document context with that
name. These are then sorted in document order, as defined by it would dictate the body Xpath.
The position-th element is then selected. If there are fewer than
position number of the request.

6.2 Replace an Existing Document

To replace an existing document elements with that name, the result is considered
a new one, no-match.

Once the procedures last step is executed, if there is no attribute selector,
the result of
Section 6.1 are followed; the Request-URI merely refers to an
existing document which node selection is the last selected element. If
there is an attribute selector, the server checks to be replaced see if there is
an attribute with that name within the content of the
request.

6.3 Deleting a Document

To delete a document, currently selectoed element.
If there is not, the client constructs result is considered a URI no-match. Otherwise, that references
attribute is selected.

Matching of element names and attributes is performed by expanding
them into the
document to be deleted. By definition this URI will not contain a
NodeSelector component. The client expanded name form, as described in XML Namespaces, and
then invokes a DELETE operation on performing the URI to delete comparison of the document.

6.4 Fetching a Document results. When evaluating the
QNames in the node selector, the default namespace and namespace
definitions from the document URI apply.

As one an example, consider the 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>

The node selector "watcherinfo/watcher-list/
watcher[@id="8ajksjda7s"]" would expect, fetching a document select the following XML element:

Rosenberg Expires April 26, 2004 [Page 10]

Internet-Draft XCAP October 2003

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

Rosenberg Expires April 26, 2004 [Page 11]

Internet-Draft XCAP October 2003

6. Client Operations

An XCAP client is trivially an HTTP 1.1 compliant client. Specific data
manipulation tasks are accomplished by
performing an invoking the right set of HTTP GET request
methods with the Request URI right set to the
document to be fetched. It is useful for clients to perform
conditional GETs using the If-Modified-Since header field, in order
to check if a locally cached copy of headers on the document is still valid.

6.5 server. This section
describes those in detail

6.1 Creating a New Element

Rosenberg Expires December 22, 2003 [Page 10]

Internet-Draft XCAP June 2003 Document

To create a new XML element within an existing document, the client constructs a URI whose Document-URI points to the document to be
modified. The Node-Selector MUST be present, containing an expression
identifying the point in that references
the document location where the new element document is to be
added. The node-set selected by the expression be placed. This URI MUST NOT
contain only a
single XML element. NodeSelector component. The client then invokes the HTTP POST method. a PUT
method on that URI.

The content in the request MUST be an XML document. That XML document MUST be conformant compliant to the
schema associated with the application usage defined by the URI. The server will insert the document such that the first element
of the document becomes the next sibling immediately following the
element specified by For
example, if the Request-URI. The client SHOULD be certain,
before making the request, that the resulting modified document will
also be conformant to the schema.

6.6 Replacing an Element in the Document

Replacing an element of the document constitutes storage of performs a
supplied entity under the specified URI, and is therefore
accomplished with the PUT method (as opposed to POST, which will
insert). The client constructs a URI whose Document-URI points to the
document operation to be modified. The Node-Selector MUST be present,
containing an expression identifying the element whose value http://
xcap.example.com/services/presence-lists/users/joe/mybuddies,
presence-lists is to be
replaced. The node-set selected by the expression MUST contain only a
single XML element.

The client then invokes the PUT method. The entity of the request
MUST be of type text/plain. The server will take the value of application unique ID, and the
element specified schema defined
by the request URI, and replace it with would dictate the content body of the PUT request. Here, value refers to the binary contents of

6.2 Replace an
XML document, starting Existing Document

To replace an existing document with a new one, the beginning tag procedures of
Section 6.1 are followed; the element, and
ending with the end tag. This differs from the "string value" defined
in XPath, which Request-URI merely refers only to an
existing document which is to be replaced with the values content of the text element
descendants of an element. The client SHOULD be certain, before
making
request.

6.3 Deleting a Document

To delete a document, the request, client constructs a URI that references the resulting modified
document will be
conformant to the schema. be deleted. By definition this URI will not contain a
NodeSelector component. The body of client then invokes a DELETE operation on
the request here is of type text/plain because URI to delete the value
of an element need not be document.

6.4 Fetching a valid XML document; frequently, it will
be text or CDATA. Of course, the value of Document

As one would expect, fetching a document is trivially accomplished by
performing an XML element may be other
XML elements, in which case HTTP GET request with the body of Request URI set to the request will be an XML
document fragment, and by itself not compliant to any schema.

Note that this operation only modifies the value of an element. be fetched. It
cannot modify is useful for clients to perform
conditional GETs using the attributes If-Match header field, in order to check
if a locally cached copy of the element. document is still valid. An HTTP
server MUST return Etags for entities that represent resources
managed by XCAP.

6.5 Creating a New Element

To do that, create a new XML element within an existing document, the replace
attribute operation is performed. client

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 11] 12]

Internet-Draft XCAP June October 2003

6.7 Delete an Element

To delete elements from a document, the client

constructs a URI whose
Document-URI document URI points to the document containing the elements to be
deleted.
modified. The Node-Selector node selector MUST be present, containing an expression
identifying present in the elements to be deleted. Unlike most of URI. The node
selector is constructed such that it meets two constraints. First, if
evaluated against the other
operations, current document, the node-set selected result is a no-match.
Secondly, if the element was added to the document as desired by the expression MAY contain
multiple elements.
client, the node selector would select that element.

The client then invokes the HTTP DELETE method. All of PUT method [[OPEN ISSUE: what is the elements
specified by
content type?]]. The content in the node set will request MUST be deleted an XML element.
The server will insert the element into the document such that the
node selector, if evaluated by the server. The body of server, would return the request SHOULD be empty. content
present in the request. The client SHOULD be certain, before making
the request, that the resulting modified document will also be
conformant to the schema.

6.8 Fetch an Element

To fetch an element of a document, the client constructs a URI whose
Document-URI points

It is important to the document containing note that the element to be
fetched. The Node-Selector MUST might potentially be present, containing an expression
identifying
inserted in the element whose value document in several different ways, and still meet
the constraints defined above. This is analagous to be fetched. The node-set
selected by the expression MUST contain only case when a single XML element.

The client then invokes
new file is PUT into a directory on a server; the GET method. location of that
file within the directory is not specified, and is up the local file
system to decide. The response will contain an
XML only guarantee is that GET(PUT(x)) returns
document with x.

6.6 Replacing an Element in the specified Document

Replacing an element as the one and only child of the document root.

OPEN ISSUE: This is also accomplished with PUT.
The only allows you to get one element at a time. We
could allow the XPath expression to specify multiple elements, and
then the response contains a document difference with each of those elements
as a child of the document root. However, behavior above for insertion is that document might not
be compliant to the schema,
node selector, when evaluated against the current document, is a
match for an element in the current document. That element is
removed, and worse, replaced with the document doesnt
actually reflect any specific sub-tree content of the actual document.

6.9 Create PUT request.

6.7 Delete an Attribute Element

To create an attribute in an existing element of delete elements from a document, the client constructs a URI whose Document-URI
document URI points to the document containing the elements to be modified.
deleted. The Node-Selector node selector MUST be present, containing an
expression identifying an attribute that is to created. Specifically,
the last location step of the expression MUST specify an attribute
axis, and identify the context MUST specify a single specific
element that exists
within the document. to be deleted.

The client then invokes the HTTP POST DELETE method. The content defined by
the request MUST be of type text/plain. A new attribute is added to server will
remove the element defined by the context, with the name specified by the

Rosenberg Expires December 22, 2003 [Page 12]

Internet-Draft XCAP June 2003

node test in the last location step, with a value specified by the
body of from the request. If an attribute of this name already exists, it
is replaced. document. The client SHOULD be certain,
before making the request, that the resulting modified document will
also be conformant to the schema.

6.10 Replacing Attributes

6.8 Fetch an Element

To replace fetch an element of a document, the client constructs a URI whose
document URI points to the document containing the element to be
fetched. The node selector MUST be present, and must identify the

Rosenberg Expires April 26, 2004 [Page 13]

Internet-Draft XCAP October 2003

element to be fetched.

The client then invokes the GET method. The response will contain
that XML element. Specifically, it contains the content of the XML
document, starting with the opening bracket for the begin tag for
that element, and ending with the closing bracket for the end tag for
that element.

6.9 Create an Attribute

To create an attribute in an existing element of a document, the
client constructs a URI whose Document-URI document URI points to the document to
be modified. The Node-Selector node selector MUST be present, containing an
expression identifying an attribute present. The node selector is
constructed such that it meets two constraints. First, if evaluated
against the current document, the result is a no-match. Secondly, if
the attribute was added to be replaced. the document as desired by the client, the
node selector would select that attribute.

The client then invokes the HTTP PUT method. The content defined by
the request MUST be of type text/plain. The value of compliant to the attribute grammar for Attribute as defined by
in XML 1.0 [[OPEN ISSUE: content type?]]. The server will add that
attribute such that, if the Node-Selector node selector is replaced by evaluated on the body of
resulting document, it returns the attribute present in the request.
The client SHOULD be certain, before making the request, that the
resulting modified document will also be conformant to the schema.

6.10 Replacing Attributes

Replacing an attribute of the document is also accomplished with PUT.
The only difference with the behavior above for insertion is that the
node selector, when evaluated against the current document, is a
match for an attribute in the current document. That attribute is
removed, and replaced with the content of the PUT request.

6.11 Deleting Attributes

To delete attributes from the document, the client constructs a URI
whose Document-URI document URI points to the document containing the attributes
to be deleted. The Node-Selector node selector MUST be present, containing and evaluate to an
expression identifying
attribute in the attributes document to be deleted. Unlike most of
the other operations, the node-set selected by the expression MAY
contain multiple attributes.

The client then invokes the HTTP DELETE method. All of the attributes
specified by the node set The server will be deleted by
remove the server. The body of attribute from the request SHOULD be empty. document. The client SHOULD be certain,
before making the request, that the resulting modified document will
also be conformant to the schema.

6.12 Fetching Attributes

Rosenberg Expires April 26, 2004 [Page 14]

Internet-Draft XCAP October 2003

To fetch an attribute of a document, the client constructs a URI
whose Document-URI points to the document containing the attribute to
be fetched. The Node-Selector node selector MUST be present, containing an
expression identifying the attribute whose value is to be fetched.

The node-set selected by the expression MUST contain only a single
XML attribute.

The client then invokes the GET method. The response will contain an
text/plain document with the value of the specified attribute.

6.13 Fetching Metadata

Rosenberg Expires December 22, 2003 [Page 13]

Internet-Draft XCAP June 2003

Elements and attributes in an XML document have various meta-data
associated with them. For example, and XML element has a certain
number of child elements. That number is a piece of meta-data that
describes the element. Currently, there is no way to fetch meta-data
for XML elements or attributes.

OPEN ISSUE: Is this restriction OK? XPath does specify functions
for computing meta-data about node sets. We can't use them since
XCAP mandates that will contain
document with the request URI be a location set, which does
not include these other functions. We could relax specified attribute, formatted according to the constraint
if this is deemed important.

6.14
grammar of Attribute as defined in the XML 1.0 specifications.

6.13 Read/Modify/Write Transactions

It is anticipated that a common operation will be to read the current
version of a document or element, modify it on the client, and then
write the change back to the server. In order for the results to be
consistent with the client's expectations, the operation must be
atomic.

To accomplish this, the client stores the value makes use of entity tags returned by
the Last-Modified
header field from the response to its server in a GET operation used to read the element, attribute, or
document that is to be modified. To guarantee atomicity, the PUT or POST
operation used to write the changes back to the server MUST contain
an If-Unmodified-Since If-Match header field, whose value is equal to the value entity tag from
the prior GET response. If the request fails with a 412 response, the
client knows that another update of the data has occurred before it
was able to write the results back. The client can then fetch 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 a single operation.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 14] 15]

Internet-Draft XCAP June October 2003

7. Server Behavior

TODO: Specify an XML body type for the responses that contains
error conditions or success results.

An XCAP server is an HTTP 1.1 compliant origin server. The behaviors
mandated by this specification relate to the way in which the HTTP
URI is interpreted and the content is constructed.

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

OPEN ISSUE: It may Furthermore, an XCAP server MUST be possible aware of all
of the XML namespaces present in any documents it manages. This is to remove this restriction
ensure that any data constraints or data interdependencies imposed by
allowing an
a future application usage to define operation in a server that
doesnt understand are properly supported by the usage. That may require some capabilities
discovery server. It
is also required to be introduced, this constraint didnt seem ensure that
problematic. authorization policies are properly
implemented.

When the server receives a request, the treatment depends on the URI.
If the URI refers to an application usage not understood by the
server, the server MUST reject the request with a 404 (Not Found)
response. If the URI refers to a user that is not recognized by the
server, it MUST reject the request with a 404 (Not Found).

Next, the server authenticates the request. All XCAP servers MUST
support HTTP Digest [6]. Furthermore, servers MUST support HTTP over
TLS, RFC 2818 [7]. [9]. It is RECOMMENDED that administrators use an HTTPS
URI as the XCAP root services URI, so that the digest client
authentication occurs over TLS.

Next, the server determines if the client has authorization to
perform the requested operation on the resource. The default
authorization policy is that only client X can access (create, read,
write, modify or delete) resources under the "users/X" directory. An
application usage can specify an alternate default authorization
policy specific to that usage. The server may also know of an
application usage that itself defines authorization policies for
another application usage. Of course, an administrator or privileged
user can override the default authorization policy, although this
specification provides no means for doing that.
Generally, if users need to be able to control authorization for
access to XCAP data, an XCAP application usage should be specified
which allows the user to set the policies as needed.

OPEN ISSUE: This is different from ACAP, where authorization
policies are built into the protocol. I think the default
generally will suffice, so I would rather not burden the baseline

Rosenberg Expires December 22, 2003 [Page 15]

Internet-Draft XCAP June 2003

protocol with it. for doing that.

Once authorized, the specific behavior depends on the method and what
the URI refers to.

7.1 POST Handling

If the URI contains only a Document-URI, the server examines the
entity body of the request. If there is no entity in the body, the
server MUST reject the request with a 409 response. If there is an
entity, but it is not well-formed, the server MUST reject the request
with a 409 response. If it is well-formed, but

Resources managed by XCAP do not compliant to the
schema associated with the application usage, the server MUST reject
the request with represent processing scripts. As a 409 response. If it is compliant
result, POST operations to the schema,
the server MUST store the document at the requested URI. If there XCAP URIs is not already a document stored at that URI, defined. A server
receiving such a 201 (Created) response
code MUST be sent, and it MUST include request SHOULD return a Location header field
containing the value 405.

Rosenberg Expires April 26, 2004 [Page 16]

Internet-Draft XCAP October 2003

7.2 PUT Handling

The behavior of the URI for the document (which will be the
same as the one in the Request-URI). Otherwise, a 200 OK response is
returned, and the document in the body replaces the existing one at
that URI. For either a 200 or 201 response, the new document is
returned server in the body receipt of the response, with a Content-Type equal to
the MIME type defined by the application usage.

If the Request URI contains a Node-Selector, the server MUST verify
that the document defined by the Document-URI exists. If no such
document exists on the server, the server MUST reject the PUT request
with a 409 response code. If the document does exist, the server
evaluates the Node-Selector is as an XPath RelativeLocationPath,
relative to specified
in HTTP 1.1 Section 9.6 - the root content of the document. If request is placed at the Node-Selector does not
comply
specified location. This section serves to define the grammar for RelativeLocationPath, the server MUST
reject notion of
"placement" and "specified location" within the request with a 400 response code. context of XCAP
resources.

If the Node-Selector
does comply, and it evaluates to anything other than the empty set, request URI represents a
single attribute document (i.e., there is no node or single element node,
selector component), the server MUST reject content of the request with MUST be a 409 response code.

If the Node-Selector evaluates to the empty set, and the last
location step is on the attribute axis, valid XML
document, and the expression without
the last location step evaluates MUST be compliant to a single element node, the server
adds an attribute to that element. Its name is schema associated with the name given
application usage in the
node test of the last location step, and its value URI. If it is taken from the
body of the request. The server then generates a 200 OK response,
whose body contains the value of not, the attribute, request MUST be
rejected with a Content-Type
of text/plain. 409 response. If the Node-Selector evaluates to request URI matches a single element node, the server
takes the content of the request, and inserts it into the document
specified by the URI such
that exists on the selected element server, that document is the immediate

Rosenberg Expires December 22, 2003 [Page 16]

Internet-Draft XCAP June 2003

sibling of the nodes defined replaced by the content
of the request. The
server then generates a 200 OK response, whose body contains If the
parent element of request URI does not match a document that
exists on the new elements just inserted. The parent element
is represented by extracting server, the contents of server adds the XML document,
starting with, document to its repository,
and including, the begin tag of associates it with the element, up to,
and including, URI in the end tag for request URI. Note that this may
require the element. The Content-Type creation of one or more "directories" on the
response is set to application/xml.

OPEN ISSUE: We can't use the MIME type for server.

If the application usage,
since Request URI represents an XML element (i.e., it contains a
node selector, but no attribute selector) the schema may not allow for server MUST verify that
the document to start with any
element defined by the schema. Is that OK? I think so. document URI exists. If no such document
exists on the Node-Selector evaluates to a single attribute node, server, the server
takes MUST reject the request with a 409
response code. The content of the request, request MUST be a single XML
element and sets it as associated content (including children elements). If the value of
request URI matches an element within the
attribute specified by document, that element is
removed, and replaced with the body content of the request. The If the request
URI does not match an element in the document, the server then
generates a 200 OK response, whose body contains inserts the value
content of the
attribute, with request as a Content-Type of text/plain.

If new element in the result of document, such that
the POST is a resulting document which does not comply with is compliant to the XML schema for schema, and such that the application usage,
request URI, when evaluated, would now point to the server MUST NOT element which was
inserted. There may be more than one way to perform such an
insertion; in that case, it is the POST, and MUST reject discretion of the request with a 409 (Conflict).

7.2 PUT Handling

When implementor as
to how it is done. It may also be possible that the Request URI contains only insertion cannot
be done without other additional elements being inserted, or cannot
be done because the Document-URI, new element is not compliant to the semantics of
PUT are as defined in HTTP 1.1 Section 9.6 - schema. In
such a case, the content of server MUST return a 409 response code. In all
cases, the
request is placed at resulting document MUST be compliant to the specified location. schema.

If the Request URI represents an XML attribute (i.e., it contains a Node-Selector,
node selector and an attribute selector) the server MUST verify that
the document defined by the Document-URI document URI exists. If no such document
exists on the server, the server MUST reject the request with a 409
response code. If the document does exist, the server
evaluates the Node-Selector as an XPath RelativeLocationPath,
relative to the root The content of the document. If the Node-Selector does not
comply to the grammar for RelativeLocationPath, the server MUST
reject the request with a 400 response code. If the Node-Selector
does comply, and it evaluates to anything other than the a single
element node or attribute node, the server MUST reject the request
with a 409 response code.

If the Node-Selector evaluates to a single element node, the server
takes the content of the request, and replaces the value of that
element (where value is defined as all of the content - elements,
text, or CDATA - between the begin and end tags of the element) with
that content. The server then returns a 200 OK response.

OPEN ISSUE: PUT is not quite right here, since a subsequent GET on
the same URI will not return exactly the same thing - the begin

Rosenberg Expires December 22, 2003 [Page 17]

Internet-Draft XCAP June 2003

and end tags will be present. This may need to be POST, but then,
how to differentiate a replace with an append operation?

If the Node-Selector evaluates to a single attribute node, the server
takes the content of the request, and sets it as the value of the
attribute. It then returns a 200 OK response.

If the result of the PUT is a document which does not comply with the XML schema for the application usage, the server MUST NOT perform
attribute, compliant to the
PUT, and MUST reject grammar for Attribute as defined in XML
1.0 (i.e., name=value). If the request URI matches an ent within the
document, that attribute is removed, and replaced with a 409 (Conflict).

7.3 GET Handling the content of
the request. If the request URI contains only a Document-URI, does not match an attribute in the server returns

Rosenberg Expires April 26, 2004 [Page 17]

Internet-Draft XCAP October 2003

document, the document specified by server inserts the URI if it exists, else returns a 404
response.

If content of the request URI specifies as a Node-Selector, new
attribute in the server verifies document, such that the resulting document specified by is
compliant to the Document-URI exists. If it does
not exist, schema, and such that the server returns a 404 (Not Found) response. If request URI, when
evaluated, would now point to the
document does exist, attribute which was inserted. There
may be more than one way to perform such an insertion; in that case,
it is the server evaluates discretion of the Node-Selector implementor as an
XPath RelativeLocationPath, relative to how it is done. It may
also be possible that the root of the document. If insertion cannot be done without other
additional content being inserted, or cannot be done because the Node-Selector does new
attribute is not comply compliant to the grammar for
RelativeLocationPath, schema. In such a case, the server
MUST reject the request with return a 400 409 response code. If In all cases, the Node-Selector does comply, and it evaluates resulting document
MUST be compliant to
anything other than the a single element node schema.

If the creation or attribute node, insertion was successful, the server MUST reject returns a 200
OK or 201 Created, as appropriate.

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
that represents an XCAP resource.

If the request with URI contains only a document URI, the server returns
the document specified by the URI if it exists, else returns a 409 response code. 404
response. If the Node-Selector evaluates to request URI contains a single node selector, and that node
selector identifies an XML element in an existing document, that
element node, is returned in the server
takes 200 response. The content of the response
is the portion of the XML document text, starting with, and including, with the left bracket of
the begin tag of the element, up to, and including, ending with the right bracket of the
end tag for the element,
and places it into the body of a 200 OK response, setting the
Content-Type to application/xml. element. If the Node-Selector evaluates to request URI contains a single node selector,
and that node selector contains an attribute node, the server
takes selector, and that
attribute exists in the value of specified document, the attribute and server returns it that
attribute, formatted as Attribute in the content of the
200 OK response, setting XML 1.0 specifications. In
all cases, if the Content-Type to text/plain.

OPEN ISSUE: Do we need to say anything about HEAD? We havent said
anything about meta-data so far; most of that referenced resource does not exist, a 404 is just regular HTTP
usage, I think.
returned.

7.4 DELETE Handling

The semantics of DELETE are as specified in RFC 2616. This section
clarifies the specific content to 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 the URI if it exists and returns a 200 OK
response, else returns a 404 response.

Rosenberg Expires December 22, 2003 [Page 18]

Internet-Draft XCAP June 2003 If the request URI specifies a
Node-Selector, the server verifies that the document specified by the
Document-URI exists. If it does not exist, the server returns a 404
(Not Found) response. If the document does exist, and the server evaluates the Node-Selector as node
selector specifies an
XPath RelativeLocationPath, relative to the root of XML element that exists, that element is

Rosenberg Expires April 26, 2004 [Page 18]

Internet-Draft XCAP October 2003

removed from the document. If the Node-Selector does not comply to the grammar for
RelativeLocationPath, the server MUST reject the request with a 400
response code. If the Node-Selector document does comply, and it evaluates to
the empty set, the server MUST reject the request with a 404 (Not
Found).

Otherwise, the server removes all of the data defined by the
node-set. Specifically, any elements in the node set are removed from
the document, and any attributes in exist, and the node set are
selector specifies an XML attribute that exists in the document, that
attribute is removed from the document. It then returns a 200 OK response. If the result node selector returns
a no-match, a 404 (Not Found) is returned. However, if removal of the deletion is
element or attribute would result in a document which does not comply
with the XML schema for the application usage, the server MUST NOT
perform the deletion, and MUST reject the request with a 409
(Conflict).

7.5 Managing Modification Times Etags

An XCAP server MUST maintain modification times entity tags for all resources that can
be referenced by a URI. Specifically, this means that each document,
and within the document, each element and attribute, MUST be
associated with a modification time an entity tag maintained by the server. These modification times entity
tags are needed to support condition GET, POST
and conditional PUT and DELETE requests.

When a PUT or POST request is made that creates or replaces a document, the modification time
entity tag of that document and all elements and attributes within is set to the current time.
updated.

When a PUT request is made to a URI referencing an XML element, the modification time
entity tag of that element element, its attributes, and all of its enclosed
children and their attributes is
set to the current time. Furthermore, updated. For a PUT or DELETE request
for an XML element, the modification time entity tag of all elements which are
ancestors of that element have their modification
time set to the current time. are updated. However, the modification times entity tags of
attributes belong belonging to elements that are ancestors of the modified
element do not have their modification times changed.

When a POST request is made to a URI referencing an XML element, the
modification time of all of the elements and their attributes within
the document in the body of the request is set to the current time.
Furthermore, the modification time of the element which is the new
parent of the elements in the request, and all of its ancestors, entity tags changed, because those
resources have
their modification time set to the current time. However, the
modification times of their attributes are unchanged.

Rosenberg Expires December 22, 2003 [Page 19]

Internet-Draft XCAP June 2003

When a POST request is made to a URI referencing an XML attribute,
the modification time of that attribute, its element, and all
elements that are ancestors of that element is set to the current
time.

When a DELETE request is made to a URI referencing an element, the
modification time of all ancestors of that element is set to the
current time. not actually changed.

When a DELETE PUT request is made to a URI referencing an XML attribute, the modification time
entity of that attribute is updated. For a PUT or DELETE request for
an attribute, the entity tags for its element, and all elements that
are ancestors of that element, is set to the current time. element are updated.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 20] 19]

Internet-Draft XCAP June October 2003

8. Examples

This section goes through several examples, making use of the
presence-lists
resource-lists [17] XCAP application usage.

First, a user Bill creates a new presence-list, resource-list, initially with no
users in it:

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

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

Next, Bill adds an entry to the list:

PUT
http://xcap.example.com/services/presence-lists/users/bill/fr.xml?
presence-lists/list[@name="friends"]
resource-lists/list[@name="friends"]/entry HTTP/1.1
Content-Type:text/plain

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

Note how the URI in the PUT request selects

Next, Bill fetches the list element whose
name attribute is "friends". The body of that request replaces list:

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

And the
existing value of that element, which was empty. result is:

Rosenberg Expires April 26, 2004 [Page 20]

Internet-Draft XCAP October 2003

HTTP/1.1 200 OK
Etag: "wwhha"
Content-Type: application/xml

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

Rosenberg Expires December 22, 2003 [Page 21]

Internet-Draft XCAP June 2003

POST

PUT
http://xcap.example.com/services/presence-lists/users/bill/fr.xml?
presence-lists/list[@name="friends"]/entry[@name="Bill"]
presence-lists/list[@name="friends"]/list[@name="close-friends"] HTTP/1.1
Content-Type:text/plain

<list name="close-friends" uri="sip:close-friends@example.com"
subscribable="true">
subscribeable="true">
<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:

DELETE
http://xcap.example.com/services/presence-lists/users/bill/fr.xml?
presence-lists/list/list/entry[@name="Petri"] HTTP/1.1

Bill decides to check on the URI for Nancy:

Rosenberg Expires April 26, 2004 [Page 21]

Internet-Draft XCAP October 2003

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

and the server responds:

HTTP/1.1 200 OK
Etag: "ad88"
Content-Type:text/plain

sip:nancy@example.com

uri="sip:nancy@example.com"

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 22]

Internet-Draft XCAP June October 2003

9. Security Considerations

Frequently, the data manipulated by XCAP contains sensitive
information. To avoid eavesdroppers from seeing this information,
XCAP RECOMMENDS 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 [8] [10] 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 [6] to establish
its identity, and this SHOULD be done over a TLS connection.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 23]

Internet-Draft XCAP June October 2003

10. IANA Considerations

This specification instructs IANA to create a new registry for XCAP
application usage IDs (AUIDs).

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 [9] [11] characters only.

Descriptive text that describes the application usage.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 24]

Internet-Draft XCAP June October 2003

Normative References

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

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

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

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

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

[6] 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.

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

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

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

[8]

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

[9]

[11] 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.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 25]

Internet-Draft XCAP June October 2003

Informative References

[10]

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

[11]

[13] 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.

[12]

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

[13] Rosenberg, J.,

[15] Roach, A. 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.

[14]

[16] 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-02
draft-ietf-simple-data-req-03 (work in progress), April June 2003.

[15]

[17] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence
Lists", draft-ietf-simple-xcap-list-usage-00 (work in
progress), June 2003.

[18] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.

[16]

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

[17] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access

[20] Roach, A., "Session Initiation Protocol (XCAP) Usage for Presence Lists",
draft-rosenberg-simple-xcap-list-usage-00 (work in progress),
May 2003. (SIP)-Specific Event
Notification", RFC 3265, June 2002.

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 26]

Internet-Draft XCAP June October 2003

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 December 22, 2003 April 26, 2004 [Page 27]

Internet-Draft XCAP June October 2003

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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 does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
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 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.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 28]

Internet-Draft XCAP June October 2003

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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

Rosenberg Expires December 22, 2003 April 26, 2004 [Page 29]

----