WDIFF

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

SIMPLE J. Rosenberg
Internet-Draft dynamicsoft
Expires: April 26, August 15, 2004 February 15, 2004 October 27, 2003

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

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 April 26, August 15, 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 April 26, August 15, 2004 [Page 1]

Internet-Draft XCAP October 2003 February 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 6
4. Application Usages . . . . . . . . . . . . . . . . . . . . 7
4.1 Application Usage ID (AUID) . 6
5. URI Construction . . . . . . . . . . . . . . 7
4.2 Data Validation . . . . . . . . 8
5.1 Identifying the XML Document . . . . . . . . . . . . . 7
4.3 Data Semantics . . . 8
5.2 Identifying the XML Nodes . . . . . . . . . . . . . . . . . 9
6. Client Operations . . 8
4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . 12
6.1 Creating a New Document . 8
4.5 Data Interdependencies . . . . . . . . . . . . . . . . . 12
6.2 Replace an Existing Document . 8
4.6 Authorization Policies . . . . . . . . . . . . . . . . . 12
6.3 Deleting a Document . 8
4.7 Data Extensibility . . . . . . . . . . . . . . . . . . . 12
6.4 Fetching a Document . 9
4.7.1 XML Schema . . . . . . . . . . . . . . . . . . . 12
6.5 Creating a New Element . . . . . 10
4.8 Documenting Application Usages . . . . . . . . . . . . . . 12
6.6 Replacing an Element in the Document 10
5. URI Construction . . . . . . . . . . . . 13
6.7 Delete an Element . . . . . . . . . 11
5.1 Identifying the XML Document . . . . . . . . . . . . 13
6.8 Fetch an Element . . . 11
5.2 Identifying the XML Nodes . . . . . . . . . . . . . . . . 12
6. Client Operations . . . 13
6.9 Create an Attribute . . . . . . . . . . . . . . . . . 15
6.1 Create or Replace a Document . . . 14
6.10 Replacing Attributes . . . . . . . . . . . . 15
6.2 Delete a Document . . . . . . . . 14
6.11 Deleting Attributes . . . . . . . . . . . . 15
6.3 Fetch a Document . . . . . . . . 14
6.12 Fetching Attributes . . . . . . . . . . . . . 15
6.4 Create or Replace an Element . . . . . . . 14
6.13 Read/Modify/Write Transactions . . . . . . . . 16
6.5 Delete an Element . . . . . . . 15
7. Server Behavior . . . . . . . . . . . . . 17
6.6 Fetch an Element . . . . . . . . . 16
7.1 POST Handling . . . . . . . . . . . . 17
6.7 Create or Replace an Attribute . . . . . . . . . . . 16
7.2 PUT Handling . . . 17
6.8 Delete an Attribute . . . . . . . . . . . . . . . . . . . 18
6.9 Fetch an Attribute . . 17
7.3 GET Handling . . . . . . . . . . . . . . . . . . 18
6.10 Read/Modify/Write Transactions . . . . . . 18
7.4 DELETE Handling . . . . . . . . 19
6.11 Reading Server Assigned Data . . . . . . . . . . . . . . 18
7.5 Managing Etags . 19
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21
7.1 POST Handling . 19
8. Examples . . . . . . . . . . . . . . . . . . . . . 21
7.2 PUT Handling . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations 22
7.2.1 Detailed Conflict Reports . . . . . . . . . . . . . . . . 23
7.2.1.1 XML Schema . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . 25
Informative References
7.3 GET Handling . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . 27
7.4 DELETE Handling . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . 28
7.5 Managing Etags . . . . 28

Rosenberg Expires April 26, 2004 . . . . . . . . . . . . . . . . . . 28
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 34
10.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 34
10.2 application/xml-fragment-body MIME Type . . . . . . . . . 34
10.3 application/xml-attribute-value MIME Type . . . . . . . . 35
10.4 application/xcap-error+xml MIME Type . . . . . . . . . . . 36
10.5 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-must-understand . . . . . . . 37
10.6 URN Sub-Namespace Registration for

Rosenberg Expires August 15, 2004 [Page 2]

Internet-Draft XCAP October 2003

1. Introduction February 2004

urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . . . 38
10.7 XCAP Error Schema Registration . . . . . . . . . . . . . . 38
10.8 XCAP Mandatory Namespace Schema Registration . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . 45

Rosenberg Expires August 15, 2004 [Page 3]

Internet-Draft 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 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 [17] authorization
policy and presence lists. Presence lists are lists of users whose
presence is desired by a watcher. One way to obtain presence
information for the list of is to subscribe to a resource which
represents that list [20]. In this case, the Resource List Server
(RLS) requires access to this list in order to process a SIP
[15]SUBSCRIBE [25] 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 [21].

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 not a
new protocol. Rather, it 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)
[23], 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 August 15, 2004 [Page 4]

Internet-Draft XCAP February 2004

2. Overview of Operation

Each application that makes use of XCAP specifies an application
usage (Section 4). 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 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 to HTTP URIs, the basic operations for accessing the data
are provided by existing HTTP primitives. Reading one of the
components is accomplished with HTTP GET, creating or modifying one
of the components is done with an HTTP PUT, and removing one of 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, 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 August 15, 2004 [Page 6]

Internet-Draft XCAP February 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 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 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 [24] based on the
guidelines in Section 10. 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

4.2 Data Validation

One of the responsibilities of the server is to validate the data
generated by the client. This 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 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

Rosenberg Expires August 15, 2004 [Page 7]

Internet-Draft XCAP February 2004

in the schema.

4.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.

4.4 Naming Conventions

In addition to defining the meaning of the document in the context of
a particular application, and application usage has to specify how
elements in that application obtain the various documents necessary
for operation of that application. In particular, what the relevant
URIs are that point to documents used by the application.

As an example, one application that can make use of XCAP is a SIP
event list subscription [20]. In this application, an entity is
defined called a Resource List Server (RLS). When the RLS receives a
subscription to a SIP URI that represents a list, it "expands" the
list and subscribes to its members. The XCAP resource list
application usage [22] specifies how the RLS uses XCAP to find the
XML document that defines the contents of the list.

These conventions are defined as naming conventions.

4.5 Data Interdependencies

In many communications applications, such cases, when a user modifies an XCAP resource, other data
managed by the server needs to change as Voice over IP, instant
messaging, and presence, well. Such interdependencies
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 in the URI associated with that list. These interdependencies
need to be specified by 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 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.

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 an HTTP request made against a resource for that particular
application usage. However, it is necessary not required for network servers the server to
access per-user information in
understand all of the process contents of servicing a request.
This per-user information resides within the network, but document used by an application
usage. A server is managed required to understand the baseline schema defined
by the end user themselves. Its management application usage. However, those schemas can be done through a
multiplicity 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 points, including to their schemas.
Sometimes, it will not.

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

Unfortunately, it may be the case that a PC application.

Examples of per-user information are presence [12] authorization
policy and client needs the server to
understand these new namespaces in order to process a document. This
will be the case when the new content contains data interdependcies
that the server has to understand. To allow for this, this
specification defines an XML element called "mandatory-ns". A server
will look for the presence lists. Presence lists are lists of users whose
presence this element as the child of the root
node of any document. If it finds it, the server will make sure that
it is desired by a watcher. Presence information familiar with any namespaces (and their corresponding schemas)
listed there.

The implication is that the schema for all XCAP application usages
MUST allow for the list "mandatory-ns" element to be present as a child of users
the root node of any document. This can be obtained done by subscribing explicitly
importing its namespace and including it in the schema, or allowing
elements from other namespaces to a resource be present in the schema as
children of the root node.

Rosenberg Expires August 15, 2004 [Page 9]

Internet-Draft XCAP February 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
represents that list [15]. convey the
information described above. In this case, particular, an application usage
specification MUST provide the Resource List Server
(RLS) requires access to this list following information:

Application Usage ID (AUID): The application usage MUST register the
AUID using the IANA procedures defined in order to process Section 10.

MIME Type: Each application usage will have a SIP
[11]SUBSCRIBE [20] request for it. Requirements MIME type for manipulation of
presence lists and authorization policies have been specified by the
SIMPLE working group [16]. its
documents. This specification describes a protocol that can either be used to
manipulate this per-user data. It is called the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP). XCAP is not an existing MIME type, or a new protocol. Rather, it is a set of conventions for mapping one
registered by the application usage.

XML
documents and document components into HTTP URIs, rules Schema: The schema for how documents used by 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 application.

Additional Constraints: Any constraints that can not be used to manipulate represented
by the data. XCAP is based heavily on ideas
borrowed from XML schema.

Data Semantics:

Naming Conventions:

Resource Interdependencies:

Authorization Policies: If the application usage changes the Application Configuration Access Protocol (ACAP)
[18], but default
authorization policies, it is not an extension of it, nor does should specify that. If not, it have any
dependencies on it. Like ACAP, XCAP is meant to support should
specify that the
configuration needs for a multiplicity of applications, rather than
just a single one. default is used.

Rosenberg Expires April 26, August 15, 2004 [Page 3] 10]

Internet-Draft XCAP October 2003

2. Overview of Operation

Each application that makes use February 2004

5. URI Construction

In order to manipulate a piece of XCAP specifies configuration data, the data must
be represented by an application
usage (Section 4). This application usage HTTP URI. XCAP defines the XML schema [1] a specific naming
convention for constructing these URIs. In particular, the data used by host part
identifies 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 server. The abs_path component of that data. These
operations are supported using the HTTP 1.1 [2]. An XCAP server acts as a
repository for collections URI
identifies the specific piece of XML documents. There will data to be modified. This path is
broken into a two parts. The first part identifies the particular XML
document. XCAP servers organize XML documents
stored for each application. Within each application, there are
documents stored for each user. Each user can have in a multiplicity specific
hierarchical fashion, as described in Section 5.1. The second part of
documents for
the path is called a particular application. To access some node selector. When present, it contains an XML
component identifier formatted according to Section 5.2. The node
selector identifies the specific component of
one of those documents, XCAP defines an algorithm for constructing a the XML document. The
HTTP URI without the node selector is called the document URI.

Note that can be used to reference that component. Components refer to
any subtree of there is nothing in the document, or any attribute grammar for any element within
the document. Thus, the HTTP URIs used by XCAP point to pieces of
information URI that are finer grained than
separates the XML document itself.

With a standardized naming convention for mapping components of XML
documents to HTTP URIs, URI from the basic operations for accessing node selector. The path extends
naturally from the data
are provided by existing HTTP primitives. Reading one of document into the XML hierarchy within the
document. Separating the two components is accomplished with HTTP GET, creating or modifying one something a server can do
based on its awareness of the components is done with an HTTP PUT, and removing one structure of the
components document directory.

5.1 Identifying the XML Document

XCAP mandates that a server MUST organize documents according to a
defined hierarchy. The root of this hierarchy is done with an HTTP DELETE. To provide atomic read/
modify/write operations, HTTP entity tags are used.

Rosenberg Expires April 26, 2004 [Page 4]

Internet-Draft URI called
the XCAP October 2003

3. Terminology

In this document, services root URI. This URI identifies the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" root of the tree
within the domain where all XCAP documents are to stored. It can be interpreted as described in RFC 2119 [3] and
indicate requirement levels for compliant implementations.

Rosenberg Expires April 26, 2004 [Page 5]

Internet-Draft 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 October 2003

4. Application Usages

A central concept in services
root URI within the example.com domain. Typically, the XCAP services
root URI is that of an application usage. An
application usage defines provisioned into client devices for bootstrapping
purposes.

Beneath the way in which a specific application
makes use of XCAP. This definition XCAP services root URI is composed a tree structure for organizing
documents. The first level of several pieces this tree consists of
information, such as an XML schema and constraints on values the XCAP AUID.
So, continuing the example above, all 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 documents used by the
presence list application usage would be under http://xcap.example.com/
services/presence-lists.

It is associated
with 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 name, called an AUID. This name uniquely identifies result, within the directory structure for each application usage,
there are two sub-trees. One, called "users", holds the documents
that are applicable to specific users, and is different from the other, called
"global", holds documents applicable to all other AUIDs. AUIDs
exist in one of two namespaces. The first namespace is users.

Within the IETF
namespace. This namespace contains "users" tree are zero or more sub-trees, each of which
identifies documents that apply to a specific user. XCAP does not

Rosenberg Expires August 15, 2004 [Page 11]

Internet-Draft XCAP February 2004

itself define what it means for documents to "apply" to a set of tokens, each of which
is registered with IANA. These registrations occur with the
publication user,
beyond specification of standards track RFCs [19] based on the guidelines a baseline authorization policy, described
below in Section 10. The second namespace is the vendor-proprietary
namespace. 7. Each AUID in that namespace is prefixed with application usage can specify additional
authorization policies which depend on data used by the
reverse domain name name application
itself.

The remainder of the organization creating URI (the path following "global" or the AUID,
followed by a period, followed specific
user) is not constrained by this specification. The application usage
MAY introduce constraints, or may allow 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 structure to be registered with IANA. used.

5.2 Identifying the XML Nodes

The vendor namespace is also meant node selector specifies specific nodes of the XML document which
are to be used in lab environments where no central registry is needed.
The syntax for AUIDs, expressed in ABNF [7] (and using some accessed. A node refers to either an XML element or an
attribute of the
BNF defined in RFC 2396 [8]) an element. The node selector is an expression which
identifies an element or attribute. Its grammar is:

AUID

node-selector = global-auid element-selector ["/" attribute-selector]
element-selector = step *( "/" step)
step = by-name / vendor-auid
global-auid by-pos / by-attr
by-name = QName ; from XML Namespaces
by-pos = auid
auid QName "[" position "]"
position = alphanum / mark
vendor-auid 1*DIGIT
by-attr = rev-hostname "." auid
rev-hostname QName "[" "@" att-name "=" <">
att-value <"> "]"
att-name = toplabel *( "." domainlabel )
domainlabel QName
att-value = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel AttValue ; from XML specification
attribute-selector = ALPHA / ALPHA *( alphanum / "-" ) alphanum

MIME Type: Each application usage MUST register a MIME type for its "@" att-name

The QName grammar is defined the XML documents. This namespaces specification [3].

The node selector 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 concepts in XPath [9]. Indeed, the application. In XCAP, this schema is
represented using XML schema [1].

Rosenberg Expires April 26, 2004 [Page 6]

Internet-Draft XCAP October 2003

Additional Constraints: XML schemas can represent
node selector expression happens to be a variety of
constraints about data, such as ranges and types. valid XPath expression.
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
additional constraints.

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

Naming Conventions: The data defined by functionality far richer than is
needed here, and its breadth would introduce complexity into XCAP.

To determine the XML schema will be used element or attribute selected by any number of entities participating in the application. In node
selector, processing begins at the
case root of presence list, the data XML document. The
first step in the element selector is used by then taken. Each step chooses a
specific XML element within the Resource List
Server (RLS), which reads current document context. The
document context is the data, and by point within the clients, XML document from which
write it. During a
specific step is evaluated. The document context begins at the execution root
of the application (i.e., the
processing of document. When a step determines an element within that
context, that element becomes the list subscription), specific documents will need
to be read or written. In order new context for evaluation of the application to function
properly, there needs to be agreement on exactly which documents
are read
next step. Each step can select an element by its name, by a
combination of name and attribute value, or written by name and position. If
the application. This step is an issue of naming
conventions; agreeing on how an application constructs attempting selection by name, the URI
representing server looks for all

Rosenberg Expires August 15, 2004 [Page 12]

Internet-Draft XCAP February 2004

elements within the document current context with that name. Name matching is to be read or written. The
application usage spells out this information.

Resource Interdependencies: In many cases, when a user modifies an
XCAP resource, many other resources need to change
performed as well. Such
interdependencies are application usage dependent. As an example,
when a user performs a PUT operation to create described below. If there is more than one element with
the specified name, the result is considered a new presence
list, no-match.

If the step is attempting selection by name and attribute, the server
looks for all elements within the current document context with that
name. Of those that match, it looks for ones that have the server may need to fill in given
attribute name, where that attribute has the URI associated with given value. If there is
no match, or if more than one element matches, the result is
considered a no-match. Note that
list. These interdependencies need to elements cannot be specified selected based on
any namespace attributes. Any such attributes are effectively ignored
in terms of the matching operations defined here.

If the step is attempting selection by name and position, the
application usage. Note that, if a server needs to modify data
looks for all elements within a the current document just PUT context with that
name. These are then sorted in document order, as defined by Xpath.
The position-th element is then selected. If there are fewer than
position number of elements with that name, the client, this modification result is
effectively accomplished as considered
a separate transaction. Concretely,
this means that, after the server modifies the data, no-match.

Once the entity
tags are updated as last step is executed, if there is no attribute selector,
the client had made result of the change itself.

Authorization Policies: By default, node selection is the last selected element. If
there is an XCAP attribute selector, the server will only allow a
user checks 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 see if there is
an attribute with that name within the currently selectoed element.
If there is not, the result is considered a no-match. Otherwise, that
attribute is selected. Note that namespace attributes cannot be
selected.

Matching of element names and attributes is used to define performed by expanding
them into the
authorization policies. An application usage for setting
authorization policies can also be defined subsequent to expanded name form, as described in XML Namespaces, and
then performing the
definition comparison of the results. When evaluating the main application usage. In such a case,
QNames in the
main application usage needs only to specify that node selector, the default namespace and namespace
definitions from the document URI apply.

Comments, text content, and processing declarations in the XML
document cannot be selected by the expressions defined here. Of
course, if such information is present in a usage
will document, and a user
selects an XML element enclosing that data, that information would be defined
included in a resulting GET, for example.

As an example, consider the future.

Application usages are similar to dataset classes in ACAP. following XML document:

Rosenberg Expires April 26, August 15, 2004 [Page 7] 13]

Internet-Draft XCAP October 2003

5. URI Construction

In order to manipulate a piece of configuration data, February 2004

<?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 select the following XML element:

<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 client is an HTTP 1.1 compliant client. Specific data must
be represented
manipulation tasks are accomplished by an invoking the right set of HTTP URI. XCAP defines a specific naming
convention for constructing these URIs. In particular,
methods with the host part
identifies right set of headers on the XCAP server. The abs_path component of This section
describes those in detail

6.1 Create or Replace a Document

To create or replace a document, the HTTP client constructs a URI
identifies that
references the location where the specific XML document is to be modified. XCAP servers
organize XML documents in a specific hierarchical fashion, as
described in Section 5.1. The placed. This URI MAY
MUST NOT contain a query. This query is
called NodeSelector component. The client then invokes a node selector. When present, it contains
PUT method on that URI.

The content in the request MUST be an XML component
identifier formatted according document compliant to Section 5.2. The node selector
identifies the specific component of the XML document. The HTTP URI
without
schema associated with the query is called application usage defined by the document URI. , and makes use the
specification for identifying nodes of an XML document.

5.1 Identifying For
example, if the XML Document

XCAP mandates that client performs a server organizes documents according PUT operation to a
defined hierarchy. The root of this hierarchy http://
xcap.example.com/services/presence-lists/users/joe/mybuddies,
presence-lists is an HTTP URI called the XCAP services root URI. This URI identifies application unique ID, and the root of schema defined
by it would dictate the tree
within body of 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 request. The MIME content type
SHOULD be used as the XCAP services
root URI within the example.com domain. Typically, the XCAP services
root URI is provisioned into client devices specific as possible. For example, "application/
resource-lists+xml" for bootstrapping
purposes.

Beneath the XCAP services root URI is a tree structure for organizing
documents. The first level of this tree consists resource list [22], instead of just
"application/xml".

If the XCAP AUID.
So, continuing Request-URI identifies a document that already exists in the example above, all
server, the PUT operation replaces that document with the content of
the documents used by request. If the
presence list application would be under http://xcap.example.com/
services/presence-lists.

It Request-URI does not identify an existing
document, the document is assumed that each application will have data created on the server at that specific URI.

If the result of the PUT is set by
users, and/or it will have global data that applies to all users. As a result, within 200 or 202 response, the directory structure for each application usage,
there are two sub-trees. One, called "users", holds operation was
successful. If it was a 409, the documents
that are applicable user performed some action which
resulted in an invalid document. The 409 response may contain an XML
body, formatted according to specific users, and the other, called
"global", holds documents applicable to all users.

Within schema in Section 7.2.1.1, which
provides further information on the "users" tree are zero or more sub-trees, each nature of which
identifies a documents that apply the error. The client
MAY use this information to a specific user. XCAP does not
itself define what try and alter the request so that this
time, it means for documents to "apply" to a user,
beyond specification might succeed. The client SHOULD NOT simply retry the
request without changing some aspect of it.

6.2 Delete a baseline authorization policy.
Specifically, Document

To delete a document, the default authorization policy is that only client constructs a user
who authenticates themself as user X can read, write, or otherwise
access in any way URI that references the documents within sub-tree X. Each application
usage can specify additional authorization policies which depend
document 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 April 26, August 15, 2004 [Page 8] 15]

Internet-Draft XCAP October 2003

data used by the application itself.

The remainder of February 2004

performing an HTTP GET request with the Request 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 set 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. A node refers to either an XML
element or an attribute of an element. The node selector fetched. When a client fetches a document, and there
is an
expression which identifies 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 the cached copy is still valid. An HTTP server MUST
return Etags for entities that represent resources managed by XCAP.

6.4 Create or Replace an element Element

To create 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 replace an XML element within an existing document, the
client constructs a URI whose document URI points to the document to
be modified. The node selector is based on the concepts MUST be present in XPath [5]. Indeed, the URI. The node
selector expression happens to be a valid XPath expression.
However, XPath provides a set of functionality far richer than is
needed here, and its breadth would introduce complexity into XCAP.

To determne constructed such that, if the XML element or attribute selected was added to the
document as desired by the node
selector, processing begins at client, the root of node selector would select
that element.

The client then invokes the XML document. HTTP PUT method. The
first step content in the element selector is then taken. Each step chooses a
specific
request MUST be an XML element within element. Specifically, it contains the current document context. The
document context is
element, starting with the point within opening bracket for the XML document from which a
specific step is evaluated. The document context begins at begin tag for that
element, including the root attributes and content of the document. When a step determines an element within that
context, that element becomes
(whether it be text or other child elements), and ending with the new context
closing bracket for evaluation of the
next step. Each step can select an end tag for that element. The MIME type in
the request SHOULD be "application/xml-fragment-body", defined in
Section 10.2. The server will insert the element by (including all its name, by a
combination of name and attribute value, or by name
attributes and position. If its content) into the step is attempting selection document such that the node
selector, if evaluated by name, the server looks for all
elements within server, would return the current context with that name. Name matching is
performed as described below. content
present in the request. If there is more than one element with the specified name, node selector, when evaluated against
the result is considered current document, results in a no-match.

Rosenberg Expires April 26, 2004 [Page 9]

Internet-Draft XCAP October 2003 no-match, the server performs a
creation operation. If the step is attempting selection by name and attribute, node selector, when evaluated against the server
looks
current document, is a match for all elements within an element in the current document context with that
name. Of those that match, document,
the server replaces it looks for ones that have with the given
attribute name, where that attribute has content of the given value. If there PUT request. This
replacement is
no match, or if more than one element matches, complete; that is, the result is
considered a no-match.

If old element (including its
attributes and content) are removed, and the step is attempting selection by name new one, including its
attributes and position, content, is put in its place. The client SHOULD be
certain, before making the server
looks for all elements within request, that the current resulting modified
document context with will also be conformant to the schema.

It is important to note that
name. These are then sorted the element might potentially be
inserted in the document order, as in several different ways, and still meet
the constraints defined by Xpath.
The position-th element above. This is then selected. If there are fewer than
position number of elements with that name, analagous to the result is considered case when a no-match.

Once the last step is executed, if there
new file is no attribute selector, PUT into a directory on a server; the result location of that
file within the node selection directory is the last selected element. If
there not specified, and is an attribute selector, up to the server checks local
file system to see if there decide. The only guarantee is
an attribute with that name within the currently selectoed element. GET(PUT(x)) returns
document x.

If there is not, the result is considered a no-match. Otherwise, that
attribute is selected.

Matching of element names and attributes is performed by expanding
them into the expanded name form, as described in XML Namespaces, and
then performing the comparison of PUT is a 200 or 202 response, the results. When evaluating operation was
successful. If it was a 409, the
QNames user performed some action which
resulted in the node selector, the default namespace and namespace
definitions from the document URI apply.

As an example, consider the following XML document:

Rosenberg Expires April 26, August 15, 2004 [Page 10] 16]

Internet-Draft XCAP October 2003

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

Rosenberg Expires April 26, February 2004 [Page 11]

Internet-Draft XCAP October 2003

6. Client Operations

An XCAP client is an HTTP 1.1 compliant client. Specific data
manipulation tasks are accomplished by invoking

body, formatted according to the right set of HTTP
methods with schema in Section 7.2.1.1, which
provides further information on the right set nature of headers on the server. This section
describes those in detail

6.1 Creating a New Document 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
request without changing some aspect of it.

6.5 Delete an Element

To create delete an element from a new document, the client constructs a URI that references
the location where
whose document URI points to the document is containing the element to
be placed. This URI deleted. The node selector MUST NOT
contain a NodeSelector component. be present, and identify the
specific element to be deleted.

The client then invokes a PUT
method on that URI. the HTTP DELETE method. The content in server will
remove the request MUST element from the document (including its attributes and
its content, such as any children). The client SHOULD be an XML certain,
before making the request, that the resulting modified document compliant will
also be conformant to the
schema associated with the application usage defined by schema.

If the URI. For
example, if result of the client performs a PUT operation to http://
xcap.example.com/services/presence-lists/users/joe/mybuddies,
presence-lists DELETE is a 200 response, the application unique ID, and the schema defined
by operation was
successful. If it would dictate the body of was a 409, the request.

6.2 Replace user performed some action which
resulted in an Existing Document

To replace invalid document. The 409 response may contain an existing document with a new one, XML
body, formatted according to the procedures of schema in Section 6.1 are followed; the Request-URI merely refers to an
existing document 7.2.1.1, which is to be replaced with
provides further information on the content nature of the
request.

6.3 Deleting a Document

To delete a document, the error. The client constructs a URI that references the
document
MAY use this information to be deleted. By definition try and alter the request so that this URI will not contain a
NodeSelector component.
time, it might succeed. The client then invokes SHOULD NOT simply retry the
request without changing some aspect of it.

6.6 Fetch an Element

To fetch an element of a DELETE operation on
the URI to delete document, the document.

6.4 Fetching a Document

As one would expect, fetching client constructs a URI whose
document is trivially accomplished by
performing an HTTP GET request with the Request URI set points to the document containing the element to be
fetched. It is useful for clients to perform
conditional GETs using The node selector MUST be present, and must identify the If-Match header field, in order
element to check
if a locally cached copy be fetched.

The client then invokes the GET method. The response will contain
that XML element. Specifically, it contains the content of the document is still valid. An HTTP
server MUST return Etags XML
document, starting with the opening bracket for the begin tag for entities
that represent resources
managed by XCAP.

6.5 Creating element, and ending with the closing bracket for the end tag for
that element. This will, as a New Element result, include all attributes and
child elements of that element.

6.7 Create or Replace an Attribute

To create a new XML element within or replace an attribute in an existing element of a
document, the client

Rosenberg Expires April 26, 2004 [Page 12]

Internet-Draft XCAP October 2003 constructs a URI whose document URI points to
the document to be modified. The node selector MUST be present in the URI. present. The
node selector is MUST be constructed such that it meets two constraints. First, if
evaluated against the current document, the result is a no-match.
Secondly, that, if the element attribute was added to the document

Rosenberg Expires August 15, 2004 [Page 17]

Internet-Draft XCAP February 2004

created or replaced as desired by the
client, desired, the node selector would select that element.
attribute. If the node selector, when evaluated against the current
document, results in a no-match, it is a creation operation. If it
matches an existing attribute, it is a replacement operation.

The client then invokes the HTTP PUT method [[OPEN ISSUE: what is the
content type?]]. method. The content in defined by
the request MUST be an compliant to the grammar for AttValue as defined
in XML element. 1.0. This request MUST be sent with the Content-Type of
"application/xml-attribute-value" as defined in Section 10.3. The
server will insert the element into the document such add that attribute such that, if the node selector, if selector is
evaluated by on the server, would return resulting document, it returns the content 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.

If the result of the PUT is important to note that a 200 or 202 response, the element might potentially be
inserted in operation was
successful. If it was a 409, the document user performed some action which
resulted in several different ways, and still meet
the constraints defined above. This is analagous an invalid document. The 409 response may contain an XML
body, formatted according to the case when a
new file is PUT into a directory schema in Section 7.2.1.1, which
provides further information on a server; the location nature of that
file within the directory is not specified, error. The client
MAY use this information to try and is up alter the local file
system to decide. The only guarantee is request so that GET(PUT(x)) returns
document x.

6.6 Replacing this
time, it might succeed. The client SHOULD NOT simply retry the
request without changing some aspect of it.

6.8 Delete an Element in Attribute

To delete attributes from the Document

Replacing document, the client constructs a URI
whose document URI points to the document containing the attributes
to be deleted. The node selector MUST be present, and evaluate to an element of
attribute in the document is also accomplished with PUT. to be deleted.

The only difference with client then invokes the behavior above for insertion is HTTP DELETE method. The server will
remove the attribute from the document. The client SHOULD be certain,
before making the request, that the
node selector, when evaluated against resulting modified document will
also be conformant to the schema.

If the current document, result of the DELETE is a
match for 200 response, the operation was
successful. If it was a 409, the user performed some action which
resulted in an element invalid document. The 409 response may contain an XML
body, formatted according to the schema in Section 7.2.1.1, which
provides further information on the current document. That element is
removed, nature of the error. The client
MAY use this information to try and replaced with alter the content of request so that this
time, it might succeed. The client SHOULD NOT simply retry the PUT request.

6.7 Delete
request without changing some aspect of it.

6.9 Fetch an Element Attribute

To delete elements from fetch an attribute of a document, the client constructs a URI

Rosenberg Expires August 15, 2004 [Page 18]

Internet-Draft XCAP February 2004

whose
document URI Document-URI points to the document containing the elements attribute to
be
deleted. fetched. The node selector MUST be present, and identify containing an
expression identifying the specific
element attribute whose value is to be deleted. fetched.

The client then invokes the HTTP DELETE method. The GET method. The response will contain an
"application/xml-attribute-value" document with the specified
attribute, formatted according to the grammar of AttValue as defined
in the XML 1.0 specifications.

6.10 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 makes use of entity tags returned by
the server in a GET operation used to read the element, attribute, or
document that is to be modified. To guarantee atomicity, the PUT
operation used to write the changes back to the server will
remove MUST contain
an If-Match header field, whose value is equal to the element entity tag from
the document. The client SHOULD be certain,
before making prior GET response. If the request, request fails with a 412 response, the
client knows that another update of the resulting modified document will
also be conformant data has occurred before it
was able to write the schema.

6.8 Fetch an Element

To results back. The client can then fetch an element of a document, the client constructs
most recent version, and attempt its modification again.

Because there are no batching operations defined in HTTP that would
allow for a URI whose
document URI points number of separate create, modify or delete operations to the document containing the element
be performed atomically, designers of application usages should take
care to structure their schemas so that operations that need to be
fetched. The node selector MUST
performed atomically can be present, and must identify done in a single operation.

6.11 Reading Server Assigned Data

In some application usages, components of the

Rosenberg Expires April 26, 2004 [Page 13]

Internet-Draft XCAP October 2003

element to document cannot be fetched.

The client then invokes set
by the GET method. The response will contain
that XML element. Specifically, it contains user. Rather, they must be filled in by the content server. Such cases
are documented as part of the XML
document, starting with application usage. Frequently, the opening bracket for
client will want to know the begin tag value assigned by the server. As an
example, in the resource list application usage [22], the server
assigns the uri for
that element, and ending with a resource list. The client will need this URI to
subscribe to the closing bracket resource list, for example.

There are two ways such discovery can be accomplished. In the end tag for
that element.

6.9 Create an Attribute

To create an attribute in an existing element of a document, first,
once the client constructs PUTs a URI whose document URI points to or element that requires the document data to
be modified. The node selector MUST be present. The node selector is
constructed such that it meets two constraints. First, if evaluated
against the current document, filled in, the result is client can do a no-match. Secondly, if
the attribute was added subsequent GET to find the document as desired by URI.
This GET can be for the client, entire document, the
node selector would select same URI that attribute.

The client then invokes the HTTP PUT method. The content defined by was used
in the request MUST be compliant PUT, or a URI that points just to the grammar for Attribute as defined
in XML 1.0 [[OPEN ISSUE: content type?]]. specific data assigned

Rosenberg Expires August 15, 2004 [Page 19]

Internet-Draft XCAP February 2004

by the server. The server result of the GET will add that
attribute such that, if tell the node selector is evaluated on client about the
resulting document, it returns
assigned data. Note that the attribute Etag present in the request.
The client SHOULD response is
significant, as it will be certain, before making different from the request, that one returned in the
resulting modified document will also be conformant
previous response to the schema.

6.10 Replacing Attributes

Replacing an attribute PUT. That's because, as a result of the server's
assignment, the document has changed, and is also accomplished with PUT. therefore assigned a new
Etag.

The only difference with second way a client can learn about the behavior above for insertion change is through an
event package that might be used to find out about changes to XCAP
resources.

It is important to note that the 200 OK response to a PUT is that always
empty, and will not contain the
node selector, when evaluated against document or element after the current document, server
has computed the necessary data.

Rosenberg Expires August 15, 2004 [Page 20]

Internet-Draft XCAP February 2004

7. Server Behavior

An XCAP server is a
match for an attribute HTTP 1.1 compliant origin server. The behaviors
mandated by this specification relate to the way in which the current document. That attribute HTTP
URI is
removed, interpreted and replaced with the content is constructed.

An XCAP server MUST be explicitly aware of the PUT request.

6.11 Deleting Attributes

To delete attributes from application usage
against which requests are being made. That is, the document, server must be
explicitly configured to handle URIs for each specific application
usage, and must be aware of the client constructs constraints imposed by that
application usage.

When the server receives a URI
whose document URI points to request, the document containing treatment depends on the attributes
to be deleted. The node selector MUST be present, and evaluate URI.
If the URI refers to an
attribute in application usage not understood by the document to be deleted.

The client then invokes
server, the HTTP DELETE method. The server will
remove the attribute from the document. The client SHOULD be certain,
before making MUST reject the request, that request with a 404 (Not Found)
response. If the resulting modified document will
also be conformant URI refers 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, user that is not recognized by the client constructs
server, it MUST reject the request with a URI
whose Document-URI points to 404 (Not Found).

Next, the document containing server authenticates the attribute to
be fetched. The node selector request. All XCAP servers MUST be present, containing
implement HTTP Digest [10]. Furthermore, servers MUST implement HTTP
over TLS, RFC 2818 [13]. It is RECOMMENDED that administrators use an
expression identifying
HTTPS URI as the attribute whose value is to be fetched.

The XCAP root services URI, so that the digest client then invokes
authentication occurs over TLS.

Next, the GET method. The response will contain
document with server determines if the specified attribute, formatted according client has authorization to
perform the
grammar of Attribute as defined in requested operation on the XML 1.0 specifications.

6.13 Read/Modify/Write Transactions

It resource. The default
authorization policy is anticipated that a common operation will be to read the current
version of a document or element, only client X can access (create, read,
write, modify it on or delete) resources under the client, and then "users/X" directory.
Only priviledged administrators can write resources under the change back
"global" directory, but all users can read them.

An application usage can specify an alternate default authorization
policy specific to the server. In order 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 results to be
consistent with default authorization policy, although this
specification provides no means for doing that.

Once authorized, the client's expectations, specific behavior depends on the operation must be
atomic.

To accomplish this, method and what
the client makes use 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 request 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 of entity tags returned by
the a server in receipt of a GET operation used to read the element, attribute, or
document that is to be modified. To guarantee atomicity, the PUT
operation used to write request is as specified
in HTTP 1.1 Section 9.6 - the changes back to content of the server MUST contain
an If-Match header field, whose value request is equal placed at the
specified location. This section serves to define the entity tag from notion of
"placement" and "specified location" within the prior GET response. context of XCAP
resources.

If the request fails with URI represents a 412 response, document (i.e., there is no node
selector component), the
client knows that another update content of the data has occurred before it
was able request MUST be a valid XML
document, and MUST be compliant to write the results back. The client can then fetch schema associated with 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 usage in a single operation.

Rosenberg Expires April 26, 2004 [Page 15]

Internet-Draft XCAP October 2003

7. Server Behavior

An XCAP server the URI. If it is an HTTP 1.1 compliant origin server. The behaviors
mandated by this specification relate to not, the way in which request MUST be
rejected with a 409 response. If the HTTP request URI matches a document
that exists on the server, that document is interpreted and replaced by the content is constructed.

An XCAP server MUST be explicitly aware
of the application usage
against which requests are being made. That is, request. If the request URI does not match a document that
exists on the server, the server must be
explicitly configured adds the document to handle URIs for each specific application
usage, its repository,
and must be aware of the constraints imposed by that
application usage. Furthermore, an XCAP server MUST be aware of all
of associates it with the XML namespaces present URI in any documents it manages. This is to
ensure that any data constraints or data interdependencies imposed by
a future application usage are properly supported by the server. It
is also required to ensure request URI. Note that authorization policies are properly
implemented.

When the server receives a request, this may
require the treatment depends creation of one or more "directories" on the URI. server.

If the Request URI refers to represents an application usage not understood XML element (i.e., it contains a
node selector, but no attribute 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 request with a 404 (Not Found)
response.
response code. The content of the request MUST be a single XML
element and associated content (including children elements), whose
MIME type is "application/xml-fragment-body". If the request does not
contain a valid XML fragment body, the request is rejected with a 409
response code. If the request URI matches an element within the
document, that element is removed, and replaced with the content of
the request. If the request URI refers to a user that is does not recognized by match an element in the
server, it MUST reject
document, the server inserts the content of the request with as a 404 (Not Found).

Next, new
element in the server authenticates document, such that the request. All XCAP servers MUST
support HTTP Digest [6]. Furthermore, servers MUST support HTTP over
TLS, RFC 2818 [9]. It resulting document is RECOMMENDED that administrators use an HTTPS
URI as
compliant to the XCAP root services URI, so schema, and such that the digest client
authentication occurs over TLS.

Next, the server determines if request URI, when
evaluated, would now point to the client has authorization element which was inserted. There
may be more than one way to perform such an insertion; in that case,
it is the requested operation on discretion of the resource. The default
authorization policy implementor as to how it is done. It may
also be possible that only client X can access (create, read,
write, modify the insertion cannot be done because the parent
of the element does not exist in the document, or delete) resources under cannot be done
because document, after the "users/X" directory. An
application usage can specify an alternate default authorization
policy specific element is added, would not be compliant
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 the schema, or privileged
user can override because the default authorization policy, although this
specification provides new element cannot be described by the
node-selector no means for doing that.

Once authorized, matter what its point of insertion. In such a case,
the server MUST return a 409 response code. In all cases, the specific behavior depends on
resulting document MUST be compliant to the method and what schema.

If the Request URI refers to.

7.1 POST Handling

Resources managed by XCAP do not represent processing scripts. As represents an XML attribute (i.e., it contains a
result, POST operations to XCAP URIs is not defined. A
node selector and an attribute selector) the server
receiving MUST verify that
the document defined by the document URI exists. If no such a document
exists on the server, the server MUST reject the request SHOULD return with a 405. 404

Rosenberg Expires April 26, August 15, 2004 [Page 16] 22]

Internet-Draft XCAP October 2003

7.2 PUT Handling February 2004

response code. The behavior content of the request will be a server in receipt MIME object of
type "application/xml-attribute-value", which represents a PUT single XML
attribute. This attribute will be compliant to the grammar for
AttValue as 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, that attribute is as specified removed, and replaced with the content of
the request. If the request URI does not match an attribute in HTTP 1.1 Section 9.6 - the
document, the server inserts the content of the request as a new
attribute in the document, such that the resulting document is
compliant to the schema, and such that the request URI, when
evaluated, would now point to the attribute which was inserted. There
may be more than one way to perform such an insertion; in that case,
it is placed at the
specified location. This section serves to define discretion of the implementor as to how it is done. It may
also be possible that the insertion cannot be done because the notion of
"placement" and "specified location" within
containing element does not exist, or cannot be done because the context
result of XCAP
resources.

If the request URI represents change would be a document (i.e., there that is no node
selector component), not compliant to the content of
schema. In such a case, the request server MUST be return a valid XML
document, and 409 response code.

The server MUST check the resulting document for the presence of the
"mandatory-schemas" element, which will always be compliant to a child of the schema associated with root
element. If this element is present, the
application usage in server checks each of the URI.
schemas listed. If it a schema is not, listed which the request server does not
support, the server MUST be
rejected reject the request with a 409 response.

If the request URI matches a document
that exists on the server, application usage indicates that document there is replaced by a data dependency,
the content
of server checks to see if the request. If information contained in the request URI does not match a document that
exists on PUT
requires the server, server to compute some component of the document. If it
does, the server adds MUST perform the document to its repository, computation, and associates it with then update the URI in
document with the request URI. Note that this may
require result. Since the creation document has changed, it
represents a new instance of one or more "directories" on the server. resource, and the server MUST assign
a new etag.

If the Request URI represents an XML element (i.e., it contains application usage indicates that there is a
node selector, but no attribute selector) data dependency,
and that dependency requires the server to perform some kind of data
validation beyond that specified in the XML schema, the server MUST verify that
the document defined by
perform the document URI exists. validation. If no such the document
exists on fails the server, validation, the
server MUST reject the request with a 409
response code. response. The content server MAY
add an error report to the response, indicating the nature of the request
validation error.

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

7.2.1 Detailed Conflict Reports

In cases where the server returns a single XML
element and associated content (including children elements). If 409 error response due to any of

Rosenberg Expires August 15, 2004 [Page 23]

Internet-Draft XCAP February 2004

the
request URI matches an element within conditions described above, it MAY 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, that element formatted according to the
schema of Section 7.2.1.1. Its MIME type, registered by this
specification, is
removed, and replaced with "application/xcap-error+xml".

The document structure is simple. It contains the root element
"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 request. If error. All error elements
support a "phrase" attribute, which can contain text meant for
rendering to a human user.

The "schema-validation-error" element indicates that the document was
not compliant to the schema after the requested operation was
performed. The "not-xml-frag" element indicates that the request
URI does 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 match
balanced. The "no-parent" element indicates that an attempt to insert
an element in failed, because the document, element into which the server inserts insertion was
supposed to occur did not exist. This element can contain an optional
"ancestor" element, which provides an HTTP URI pointed to the
content of xcap
resource that identifies the request as a new closest ancestor element that does exist
in the document, such document. The "cannot-insert" element provides a generic
catch-all for other insertion cases. The "no-xml-att-value" element
indicates that the resulting document is compliant request was supposed to the schema, and such contain a valid XML
attribute value, but did not. The "no-element" element indicates that the
request URI, when evaluated, would now point
an attempt to insert an attribute was made, but the element in which
the attribute was
inserted. There may be more than one way to perform such an
insertion; in be inserted does not exist.

The "uri-exists" element supports application usages that case, it is the discretion of the implementor as
to how define data
constraints. In particular, it is done. It may also be possible expected that many application
usages will require the insertion cannot
be done without other additional elements being inserted, or cannot
be done because the new element is not compliant server to the schema. In
such compute a case, URI, or allow the server MUST return client
to provide a 409 response code. URI. In all
cases, either case, the resulting document MUST be compliant URI needs to be unique within
the schema. domain of the server. If the Request URI represents an XML attribute (i.e., it contains client provides a
node selector URI, and an attribute selector) the server MUST verify URI
already exists, it would be an error. This element describes that
the document defined by the document
condition. For each URI exists. If no such document
exists on the server, provided by the server MUST reject client which already exists,
an "exists" element is present as the request with a 409
response code. The content of the request MUST be "uri-exists". Each
"exists" element has a single XML
attribute, compliant to the grammar for Attribute as defined in XML
1.0 (i.e., name=value). If "uri" attribute that contains the request URI matches an ent within which
exists. The "exists" element, in turn, can optionally contain a list
of suggested alternate URIs which do not currently exist on the
document,
server.

The "unknown-mand-ns" element indicates that attribute is removed, and replaced with the document contained a
"mandatory-ns" element that listed a namespace not understood by the
server. The content of the request. If the request "unknown-mand-ns" element is a list of
"ns" elements, each one containing a URI does not match an attribute in the identifying a namespace

Rosenberg Expires April 26, August 15, 2004 [Page 17] 24]

Internet-Draft XCAP October 2003 February 2004

listed as mandatory in the document, but was not understood by the server inserts
server.

As an example, the content of following document indicates that the request as user
attempted to create a new
attribute in resource list using the document, such URI
sip:friends@example.com, but that the 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>
<exists uri="sip:friends@example.com">
<alt-uri>sip:friends2@example.com</alt-uri>
</exists>
</uri-exists>
</xcap-error>

7.2.1.1 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="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 is was not compliant to the schema, and such that the schema.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-xml-frag">
<xs:annotation>
<xs:documentation>The request URI, when
evaluated, would now point to the attribute which was inserted. There
may did not contain a valid xml fragment body.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="no-parent">
<xs:annotation>

Rosenberg Expires August 15, 2004 [Page 25]

Internet-Draft XCAP February 2004

<xs:documentation>The element could not be more than one way to perform such an insertion; inserted because its parent does not exist in that case,
it is the discretion of the implementor as document.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="ancestor" type="xs:anyURI" minOccurs="0">
<xs:annotation>
<xs:documentation>Contains an HTTP URI that points to how it the element which is done. It may
also be possible that the insertion cannot 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 done without other
additional content being inserted, or cannot 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>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="no-element">
<xs:annotation>
<xs:documentation>The attribute could not be done inserted because the new
attribute is element in which to insert does not compliant exist.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="uri-exists">
<xs:annotation>
<xs:documentation>The user tried to the schema. In such set a case, URI that the server
MUST return a 409 response code. In all cases, must constrain to be unique, and this URI exists.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="exists" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>There is an instance of this element for each URI in the resulting document
MUST 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 compliant to the schema.

If the creation or insertion provided.</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 successful, not understood by the server returns a 200
OK or 201 Created, as appropriate. server.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="ns" type="xs:anyURI" maxOccurs="unbounded">
<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
that represents an XCAP resource.

If the request URI contains only a document URI, the server returns
the document specified by the URI if it exists, else returns a 404
response. The MIME type of the response SHOULD 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

Rosenberg Expires August 15, 2004 [Page 27]

Internet-Draft XCAP February 2004

existing document, 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 a node selector, and that node selector contains
an attribute selector, and that attribute exists in the specified
document, the server returns that
attribute, attribute. The MIME type of the
response MUST be "application/xml-attribute-value", which contains an
XML attribute value formatted as Attribute according to the grammar of AttValue in
the XML 1.0 specifications. In all cases, if the referenced resource
does not exist, a 404 is 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, 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. 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 node
selector specifies an XML element that exists, that element is
removed from the document. If the document does exist, and the node
selector specifies an XML attribute that exists in the document, that
attribute is removed from the document. If the node selector returns
a no-match, a 404 (Not Found) is returned. However, if removal of the
element or attribute would result in a document which does not comply
with the XML schema for the application usage, the server deletes
the document specified by MUST NOT
perform the URI if it exists deletion, and returns a 200 OK
response, else returns a 404 response. If MUST reject 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 specifies within a
Node-Selector, particular document. RFC 2616 allows
for entity tags for one resource to be applied to other resources. In
the case of XCAP resources, a server verifies MUST use the same etag to
reference all resources that define elements within a particular
document. In other words, the server effectively maintains a single
etag per document, and all resources within that document specified by inherit the
Document-URI exists. If
same etag.

This constraint is necessary for a client to make changes to various
parts of a document even though it does not exist, only posesses the server returns a 404
(Not Found) response. If etag for the document does exist, and

Rosenberg Expires August 15, 2004 [Page 28]

Internet-Draft XCAP February 2004

overall document.

Rosenberg Expires August 15, 2004 [Page 29]

Internet-Draft XCAP February 2004

8. Examples

This section goes through several examples, making use of the node
selector specifies
resource-lists [22] XCAP application usage.

First, a user Bill creates a new document (see Section 6.1). This
document is a new 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

Next, Bill creates an XML element that exists, that element is in this document (Section 6.4). In
particular, he adds an entry to the list:

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

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

Next, Bill fetches the document (Section 6.3):

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

And the result is:

Rosenberg Expires April 26, August 15, 2004 [Page 18] 30]

Internet-Draft XCAP October 2003

removed from the document. If the document does exist, and the node
selector specifies an XML attribute that exists in February 2004

HTTP/1.1 200 OK
Etag: "wwhha"
Content-Type: application/presence-lists+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 document, that
attribute list, which is removed from the document. If the node selector returns
a no-match, a 404 (Not Found) another list that
has three entries. This is returned. However, if removal of the another element or attribute would result in a document which does not comply
with the XML schema for the application usage, creation (Section 6.4):

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

<list name="close-friends" uri="sip:close-friends@example.com"
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 server MUST NOT
perform list, so he deletes
the deletion, and MUST reject entry (Section 6.5):

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 request with a 409
(Conflict).

7.5 Managing Etags

An XCAP server MUST maintain entity tags URI for all resources that can
be referenced by Nancy, so he fetches a URI. Specifically, this means that each document,
and within the document, each element
particular attribute (Section 6.6):

Rosenberg Expires August 15, 2004 [Page 31]

Internet-Draft XCAP February 2004

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

and attribute, MUST be
associated with an entity tag maintained by the server. These entity
tags are needed to support conditional PUT and DELETE requests.

When a PUT request server responds:

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

"sip:nancy@example.com"

Rosenberg Expires August 15, 2004 [Page 32]

Internet-Draft XCAP February 2004

9. Security Considerations

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

Client and attributes within is
updated.

When a PUT request server authentication are also important. A client needs
to be sure it is made talking to a URI referencing an XML element, the
entity tag of that element, its attributes, and all of its enclosed
children and their attributes server it believes it is updated. For a PUT or DELETE request
for an XML element, the entity tag of all elements contacting.
Otherwise, it may be given false information, which are
ancestors of that element are updated. However, the entity tags of
attributes belonging can lead to elements that are ancestors
denial of the modified
element do not have their entity tags changed, because those
resources have not actually changed.

When service attacks against a PUT request is made to client. To prevent this, a URI referencing an XML attribute, the
entity client
SHOULD attempt to upgrade [14] any connections to TLS. Similarly,
authorization of that attribute read and write operations against the data is updated. For
important, and this requires client authentication. As a PUT or DELETE request for
an attribute, the entity tags for result, a
server SHOULD challenge a client using HTTP Digest [10] to establish
its element, identity, and all elements that
are ancestors of that element are updated. this SHOULD be done over a TLS connection.

Rosenberg Expires April 26, August 15, 2004 [Page 19] 33]

Internet-Draft XCAP October 2003

8. Examples

This section goes through February 2004

10. IANA Considerations

There are several examples, making use of the
resource-lists [17] IANA considerations associated with this
specification.

10.1 XCAP application usage.

First, a user Bill creates Application Usage IDs

This specification instructs IANA to create a new resource-list, initially with no
users registry for XCAP
application usage IDs (AUIDs).

XCAP AUIDs are registered by the IANA when they are published in it:

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

Next, Bill adds an entry to
standards track RFCs. The IANA Considerations section of the list:

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

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

Next, Bill fetches RFC
must include the list:

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

And following information, which appears in the 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

Next, Bill adds another entry to IANA
registry along with the list, which is another list 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
has three entries:

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

Then, Bill decides he doesnt want Petri on describes the application usage.

10.2 application/xml-fragment-body MIME Type

This specification registers a new MIME type according to the list, so he deletes
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].

MIME media type name: application

MIME subtype name: xml-fragment-body

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 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 rest of the URI document 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

uri="sip:nancy@example.com" purposes of
defining it as a fragment.

Rosenberg Expires April 26, August 15, 2004 [Page 22] 34]

Internet-Draft XCAP October 2003

9. Security Considerations

Frequently, the data manipulated by XCAP contains sensitive
information. To avoid eavesdroppers from seeing February 2004

Applications which use this information, it
is RECOMMENDED that an admistrator hand out an https URI as the XCAP
root services URI. media type: This will result document type has been
used to support transport of XML fragment bodies in TLS-encrypted communications
between RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the client and server, preventing any eavesdropping.

Client published RFC
number of this specification.]], the XML Configuration Access
Protocol (XCAP).

Additional Information:

Magic Number: None

File Extension: .xfb or .xml

Macintosh file type code: "TEXT"

Personal and server authentication are also important. A client needs email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net

Intended usage: COMMON

Author/Change controller: The IETF.

10.3 application/xml-attribute-value MIME Type

This specification registers a new MIME type according to be sure it the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].

MIME media type name: application

MIME subtype name: xml-attribute-value

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 of this MIME type is talking compliant to
the server it believes it is contacting.
Otherwise, it may be given false information, grammar for AttValue as specified in XML 1.0 [1].

Rosenberg Expires August 15, 2004 [Page 35]

Internet-Draft XCAP February 2004

Applications which can lead use this media type: This document type has been
used to
denial support transport of service attacks against a client. To prevent this, a client
SHOULD attempt to upgrade [10] any connections to TLS. Similarly,
authorization XML attribute values in RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC
number of read and write operations against this specification.]], the data is
important, XML Configuration Access
Protocol (XCAP).

Additional Information:

Magic Number: None

File Extension: .xav

Macintosh file type code: "TEXT"

Personal and this requires client authentication. As a result, a
server SHOULD challenge email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net

Intended usage: COMMON

Author/Change controller: The IETF.

10.4 application/xcap-error+xml MIME Type

This specification registers a client using HTTP Digest [6] new MIME type according to establish
its identity, the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].

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 conveys
error conditions defined in RFC XXXX. [[NOTE TO RFC EDITOR: Please
replace XXXX with the published RFC number of this SHOULD be done over a TLS connection.

Rosenberg Expires April 26, August 15, 2004 [Page 23] 36]

Internet-Draft XCAP October 2003

10. IANA Considerations February 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 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-must-understand

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

XCAP AUIDs are registered by XML namespace, as per the IANA when they are published guidelines in
standards track RFCs.
RFC 3688 [16].

URI: The IANA Considerations section URI for this namespace is
urn:ietf:params:xml:ns:xcap-must-understand

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 Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Must Understand Element</h1>
<h2>urn:ietf:params:xml:ns:xcap-must-understand</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</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 RFC
must include the following information, which appears guidelines in the IANA
registry along with the
RFC number 3688 [16].

URI: The URI for this namespace is
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 Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Error Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-error</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END

10.7 XCAP Error Schema Registration

This section registers an XML schema per the publication.

Name procedures in [16].

URI: please assign.

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

The XML for this schema can be found as the sole content of
Section 7.2.1.1.

10.8 XCAP Mandatory Namespace Schema Registration

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

URI: please assign.

Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).

The name MAY XML for this schema can be found as the sole content of any length, but SHOULD be no
more than twenty characters long.
Section 4.7.1.

Rosenberg Expires August 15, 2004 [Page 39]

Internet-Draft XCAP February 2004

11. Acknowledgements

The name MUST consist of
alphanum [11] characters only.

Descriptive text that describes the application usage. author would like to thank Ben Campbell, Eva-Maria Leppanen,
Hisham Khartabil, and Chris Newman for their input and comments.

Rosenberg Expires April 26, August 15, 2004 [Page 24] 40]

Internet-Draft XCAP October 2003 February 2004

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.

[2]

[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., Nielsen, Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

[3]

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

[4]

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

[5]

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

[6]

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

[7]

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

[8]

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

[9]

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

[10]

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

[11]

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 April 26, August 15, 2004 [Page 25] 42]

Internet-Draft XCAP October 2003 February 2004

Informative References

[12]

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

[13]

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

[14]

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

[15]

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

[16]

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

[17]

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

[18]

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

[19]

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

[20]

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

Rosenberg Expires April 26, August 15, 2004 [Page 26] 43]

Internet-Draft XCAP October 2003 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 April 26, August 15, 2004 [Page 27] 44]

Internet-Draft XCAP October 2003 February 2004

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 April 26, August 15, 2004 [Page 28] 45]

Internet-Draft XCAP October 2003 February 2004

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

Acknowledgement

Acknowledgment

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

Rosenberg Expires April 26, August 15, 2004 [Page 29] 46]

----