< draft-ietf-simple-xcap-11.txt   draft-ietf-simple-xcap-12.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: November 6, 2006 May 5, 2006 Expires: April 16, 2007 October 13, 2006
The Extensible Markup Language (XML) Configuration Access Protocol The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) (XCAP)
draft-ietf-simple-xcap-11 draft-ietf-simple-xcap-12
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 6, 2006. This Internet-Draft will expire on April 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This specification defines the Extensible Markup Language (XML) This specification defines the Extensible Markup Language (XML)
Configuration Access Protocol (XCAP). XCAP allows a client to read, Configuration Access Protocol (XCAP). XCAP allows a client to read,
write and modify application configuration data, stored in XML format write and modify application configuration data, stored in XML format
skipping to change at page 2, line 13 skipping to change at page 2, line 13
HTTP. HTTP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Application Usages . . . . . . . . . . . . . . . . . . . . . . 7 5. Application Usages . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 7 5.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 7
5.2. Default Namespace Binding . . . . . . . . . . . . . . . . 8 5.2. Default Document Namespace . . . . . . . . . . . . . . . . 8
5.3. Data Validation . . . . . . . . . . . . . . . . . . . . . 8 5.3. Data Validation . . . . . . . . . . . . . . . . . . . . . 9
5.4. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Naming Conventions . . . . . . . . . . . . . . . . . . . . 10 5.5. Naming Conventions . . . . . . . . . . . . . . . . . . . . 10
5.6. Resource Interdependencies . . . . . . . . . . . . . . . . 11 5.6. Resource Interdependencies . . . . . . . . . . . . . . . . 11
5.7. Authorization Policies . . . . . . . . . . . . . . . . . . 11 5.7. Authorization Policies . . . . . . . . . . . . . . . . . . 12
5.8. Data Extensibility . . . . . . . . . . . . . . . . . . . . 12 5.8. Data Extensibility . . . . . . . . . . . . . . . . . . . . 12
5.9. Documenting Application Usages . . . . . . . . . . . . . . 12 5.9. Documenting Application Usages . . . . . . . . . . . . . . 13
5.10. Guidelines for Creating Application Usages . . . . . . . . 13 5.10. Guidelines for Creating Application Usages . . . . . . . . 13
6. URI Construction . . . . . . . . . . . . . . . . . . . . . . . 14 6. URI Construction . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. XCAP Root . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. XCAP Root . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Document Selector . . . . . . . . . . . . . . . . . . . . 16 6.2. Document Selector . . . . . . . . . . . . . . . . . . . . 16
6.3. Node Selector . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Node Selector . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Namespace Bindings for the Selector . . . . . . . . . . . 22 6.4. Namespace Bindings for the Selector . . . . . . . . . . . 23
7. Client Operations . . . . . . . . . . . . . . . . . . . . . . 24 7. Client Operations . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Create or Replace a Document . . . . . . . . . . . . . . . 25 7.1. Create or Replace a Document . . . . . . . . . . . . . . . 25
7.2. Delete a Document . . . . . . . . . . . . . . . . . . . . 25 7.2. Delete a Document . . . . . . . . . . . . . . . . . . . . 26
7.3. Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26 7.3. Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26
7.4. Create or Replace an Element . . . . . . . . . . . . . . . 26 7.4. Create or Replace an Element . . . . . . . . . . . . . . . 26
7.5. Delete an Element . . . . . . . . . . . . . . . . . . . . 28 7.5. Delete an Element . . . . . . . . . . . . . . . . . . . . 28
7.6. Fetch an Element . . . . . . . . . . . . . . . . . . . . . 29 7.6. Fetch an Element . . . . . . . . . . . . . . . . . . . . . 29
7.7. Create or Replace an Attribute . . . . . . . . . . . . . . 30 7.7. Create or Replace an Attribute . . . . . . . . . . . . . . 30
7.8. Delete an Attribute . . . . . . . . . . . . . . . . . . . 31 7.8. Delete an Attribute . . . . . . . . . . . . . . . . . . . 31
7.9. Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31 7.9. Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31
7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 31 7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 32
7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32 7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 34 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. POST Handling . . . . . . . . . . . . . . . . . . . . . . 34 8.1. POST Handling . . . . . . . . . . . . . . . . . . . . . . 35
8.2. PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35
8.2.1. Locating the Parent . . . . . . . . . . . . . . . . . 35 8.2.1. Locating the Parent . . . . . . . . . . . . . . . . . 35
8.2.2. Verifying Document Content . . . . . . . . . . . . . . 36 8.2.2. Verifying Document Content . . . . . . . . . . . . . . 36
8.2.3. Creation . . . . . . . . . . . . . . . . . . . . . . . 37 8.2.3. Creation . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.4. Replacement . . . . . . . . . . . . . . . . . . . . . 41 8.2.4. Replacement . . . . . . . . . . . . . . . . . . . . . 41
8.2.5. Validation . . . . . . . . . . . . . . . . . . . . . . 42 8.2.5. Validation . . . . . . . . . . . . . . . . . . . . . . 42
8.2.6. Conditional Processing . . . . . . . . . . . . . . . . 42 8.2.6. Conditional Processing . . . . . . . . . . . . . . . . 43
8.2.7. Resource Interdependencies . . . . . . . . . . . . . . 43 8.2.7. Resource Interdependencies . . . . . . . . . . . . . . 44
8.3. GET Handling . . . . . . . . . . . . . . . . . . . . . . . 43 8.3. GET Handling . . . . . . . . . . . . . . . . . . . . . . . 44
8.4. DELETE Handling . . . . . . . . . . . . . . . . . . . . . 44 8.4. DELETE Handling . . . . . . . . . . . . . . . . . . . . . 45
8.5. Managing Etags . . . . . . . . . . . . . . . . . . . . . . 45 8.5. Managing Etags . . . . . . . . . . . . . . . . . . . . . . 46
9. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 45 9. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 46
10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 46 10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 47
11. Detailed Conflict Reports . . . . . . . . . . . . . . . . . . 46 11. Detailed Conflict Reports . . . . . . . . . . . . . . . . . . 47
11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 46 11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 48
11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 48 11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 49
12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 52 12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 53
12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 53 12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 54
12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 53 12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 54
12.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 54 12.3. Default Document Namespace . . . . . . . . . . . . . . . . 55
12.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 54 12.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 55
12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 54 12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 55
12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 54 12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 56
12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 55 12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 56
12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 55 12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 56
12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 55 12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 56
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14. Security Considerations . . . . . . . . . . . . . . . . . . . 58 14. Security Considerations . . . . . . . . . . . . . . . . . . . 59
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
15.1. XCAP Application Unique IDs . . . . . . . . . . . . . . . 59 15.1. XCAP Application Unique IDs . . . . . . . . . . . . . . . 60
15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 59 15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 61
15.2.1. application/xcap-el+xml MIME Type . . . . . . . . . . 60 15.2.1. application/xcap-el+xml MIME Type . . . . . . . . . . 61
15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 61 15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 62
15.2.3. application/xcap-ns+xml MIME Type . . . . . . . . . . 61 15.2.3. application/xcap-ns+xml MIME Type . . . . . . . . . . 63
15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 62 15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 64
15.2.5. application/xcap-caps+xml MIME Type . . . . . . . . . 63 15.2.5. application/xcap-caps+xml MIME Type . . . . . . . . . 65
15.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 64 15.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 66
15.3.1. urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . 64 15.3.1. urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . 66
15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 65 15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 66
15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 66 15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 67
15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 66 15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 67
15.4.2. XCAP Capabilities Schema Registration . . . . . . . . 66 15.4.2. XCAP Capabilities Schema Registration . . . . . . . . 67
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
17.1. Normative References . . . . . . . . . . . . . . . . . . . 67 17.1. Normative References . . . . . . . . . . . . . . . . . . . 68
17.2. Informative References . . . . . . . . . . . . . . . . . . 68 17.2. Informative References . . . . . . . . . . . . . . . . . . 70
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . . . . 71 Intellectual Property and Copyright Statements . . . . . . . . . . 72
1. Introduction 1. Introduction
In many communications applications, such as Voice over IP, instant In many communications applications, such as Voice over IP, instant
messaging, and presence, it is necessary for network servers to messaging, and presence, it is necessary for network servers to
access per-user information in the process of servicing a request. access per-user information in the process of servicing a request.
This per-user information resides within the network, but is managed This per-user information resides within the network, but is managed
by the end user themselves. Its management can be done through a by the end user themselves. Its management can be done through a
multiplicity of access points, including the web, a wireless handset, multiplicity of access points, including the web, a wireless handset,
or a PC application. or a PC application.
skipping to change at page 4, line 46 skipping to change at page 4, line 46
associated with access to those resources. Because of this associated with access to those resources. Because of this
structure, normal HTTP primitives can be used to manipulate the data. structure, normal HTTP primitives can be used to manipulate the data.
XCAP is based heavily on ideas borrowed from the Application XCAP is based heavily on ideas borrowed from the Application
Configuration Access Protocol (ACAP) [25], but it is not an extension Configuration Access Protocol (ACAP) [25], but it is not an extension
of it, nor does it have any dependencies on it. Like ACAP, XCAP is of it, nor does it have any dependencies on it. Like ACAP, XCAP is
meant to support the configuration needs for a multiplicity of meant to support the configuration needs for a multiplicity of
applications, rather than just a single one. applications, rather than just a single one.
2. Overview of Operation 2. Overview of Operation
Each application that makes use of XCAP specifies an application Each application (where an application refers to a use case that
usage (Section 5). This application usage defines the XML schema [2] implies a collection of data and associated semantics) that makes use
for the data used by the application, along with other key pieces of of XCAP specifies an application usage (Section 5). This application
information. The principal task of XCAP is to allow clients to read, usage defines the XML schema [2] for the data used by the
write, modify, create and delete pieces of that data. These application, along with other key pieces of information. The
operations are supported using HTTP/1.1 [6]. An XCAP server acts as principal task of XCAP is to allow clients to read, write, modify,
a repository for collections of XML documents. There will be create and delete pieces of that data. These operations are
documents stored for each application. Within each application, supported using HTTP/1.1 [6]. An XCAP server acts as a repository
there are documents stored for each user. Each user can have a for collections of XML documents. There will be documents stored for
multiplicity of documents for a particular application. To access each application. Within each application, there are documents
some component of one of those documents, XCAP defines an algorithm stored for each user. Each user can have a multiplicity of documents
for constructing a URI that can be used to reference that component. for a particular application. To access some component of one of
Components refer to any element or attribute within the document. those documents, XCAP defines an algorithm for constructing a URI
Thus, the HTTP URIs used by XCAP point to a document, or to pieces of that can be used to reference that component. Components refer to
information that are finer grained than the XML document itself. An any element or attribute within the document. Thus, the HTTP URIs
HTTP resource which follows the naming conventions and validation used by XCAP point to a document, or to pieces of information that
constraints defined here is called an XCAP resource. are finer grained than the XML document itself. An HTTP resource
which follows the naming conventions and validation constraints
defined here is called an XCAP resource.
Since XCAP resources are also HTTP resources, they can be accessed Since XCAP resources are also HTTP resources, they can be accessed
using HTTP methods. Reading an XCAP resource is accomplished with using HTTP methods. Reading an XCAP resource is accomplished with
HTTP GET, creating or modifying one is done with HTTP PUT, and HTTP GET, creating or modifying one is done with HTTP PUT, and
removing one of the resources is done with an HTTP DELETE. XCAP removing one of the resources is done with an HTTP DELETE. XCAP
resources do not represent processing scripts; as a result, POST resources do not represent processing scripts; as a result, POST
operations to HTTP URIs representing XCAP resources are not defined. operations to HTTP URIs representing XCAP resources are not defined.
Properties that HTTP associates with resources, such as entity tags, Properties that HTTP associates with resources, such as entity tags,
also apply to XCAP resources. Indeed, entity tags are particularly also apply to XCAP resources. Indeed, entity tags are particularly
useful in XCAP, as they allow a number of conditional operations to useful in XCAP, as they allow a number of conditional operations to
skipping to change at page 8, line 27 skipping to change at page 8, line 32
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
auid-char = auid-unreserved / pct-encoded / sub-delims auid-char = auid-unreserved / pct-encoded / sub-delims
/ ":" / "@" / ":" / "@"
auid-unreserved = ALPHA / DIGIT / "-" / "_" / "~" auid-unreserved = ALPHA / DIGIT / "-" / "_" / "~"
The allowed characters for the auid production is a subset of the The allowed characters for the auid production is a subset of the
pchar production defined in RFC3986. In particular, it omits the pchar production defined in RFC3986. In particular, it omits the
".", which allows for the auid to be separated from the reverse ".", which allows for the auid to be separated from the reverse
hostname. hostname.
5.2. Default Namespace Binding 5.2. Default Document Namespace
In order for the XCAP server to match a URI to an element or In order for the XCAP server to match a URI to an element or
attribute of a document, any XML namespace prefixes used within the attribute of a document, any XML namespace prefixes used within the
URI must be expanded [3]. This expansion requires a namespace URI must be expanded [3]. This expansion requires a namespace
binding context. That context maps namespace prefixes to namespace binding context. That context maps namespace prefixes to namespace
URIs. It also defines a default namespace that applies to elements URIs. It also defines a default namespace that applies to elements
without namespace prefixes. The namespace binding context comes from in the URI without namespace prefixes. The namespace binding context
two sources. Firstly, the mapping of namespace prefixes to namespace comes from two sources. Firstly, the mapping of namespace prefixes
URIs is obtained from the URI itself (see Section 6.4). However, the to namespace URIs is obtained from the URI itself (see Section 6.4).
default namespace URI is defined by the application usage itself, and However, the default document namespace is defined by the application
applies to all URIs referencing resources within that application usage itself, and applies to all URIs referencing resources within
usage. All application usages MUST define a namespace URI that that application usage. All application usages MUST define a
represents the default namespace to be used when evaluating URIs. namespace URI that represents the default document namespace to be
The default namespace does not apply to elements or attributes within used when evaluating URIs. The default document namespace does not
the documents themselves. However, if a document contains a URI apply to elements or attributes within the documents themselves - it
representing an XCAP resource, the default namespace defined by the applies only to the evaluation of URIs within that application usage.
Indeed, the term 'default document namespace' is distinct from the
term 'default namespace'. The latter has the standard meaning within
XML documents, and the former refers to the default used in
evaluation of XCAP URIs. XCAP does not change in any way the
mechanisms for determining the default namespace within XML
documents. However, if a document contains a URI representing an
XCAP resource, the default document namespace defined by the
application usage applies to that URI as well. application usage applies to that URI as well.
5.3. Data Validation 5.3. Data Validation
One of the responsibilities of an XCAP server is to validate the One of the responsibilities of an XCAP server is to validate the
content of each XCAP resource when an XCAP client tries to modify content of each XCAP resource when an XCAP client tries to modify
one. This is done using two mechanisms. Firstly, all application one. This is done using two mechanisms. Firstly, all application
usages MUST describe their document contents using XML schema [2]. usages MUST describe their document contents using XML schema [2].
The application usage MUST also identify the MIME type for documents The application usage MUST also identify the MIME type for documents
compliant to that schema. compliant to that schema.
skipping to change at page 9, line 50 skipping to change at page 10, line 14
constraints on the scheme or structure of the scheme specific part of constraints on the scheme or structure of the scheme specific part of
the URI. These kinds of constraints cannot be expressed in an XML the URI. These kinds of constraints cannot be expressed in an XML
schema. If these constraints are important to an application usage, schema. If these constraints are important to an application usage,
they need to be explicitly called out. they need to be explicitly called out.
Another important data constraint is referential integrity. Another important data constraint is referential integrity.
Referential integrity is important when the name or value of an Referential integrity is important when the name or value of an
element or attribute is used as a key to select another element or element or attribute is used as a key to select another element or
attribute. An application usage MAY specify referential integrity attribute. An application usage MAY specify referential integrity
constraints. However, XCAP servers are not a replacement for constraints. However, XCAP servers are not a replacement for
Relational Database Management Systems (RDBMS), and therefore servers Relational Database Management Systems (RDBMS), and therefore clients
are never responsible for maintaining referential integrity. XCAP MUST NOT depend on servers to maintain referential integrity. XCAP
clients are responsible for making all of the appropriate changes to clients are responsible for making all of the appropriate changes to
documents in order to maintain referential integrity. documents in order to maintain referential integrity.
Another constraint is character encoding. XML allows documents to be Another constraint is character encoding. XML allows documents to be
encoded using several different character sets. However, this encoded using several different character sets. However, this
specification mandates that all documents used with XCAP MUST be specification mandates that all documents used with XCAP MUST be
encoded using UTF-8. This cannot be changed by an application usage. encoded using UTF-8. This cannot be changed by an application usage.
The data validation information is consumed by both clients, which The data validation information is consumed by both clients, which
use them to make sure they construct requests that will be accepted use them to make sure they construct requests that will be accepted
skipping to change at page 13, line 7 skipping to change at page 13, line 18
information described above. In particular, an application usage information described above. In particular, an application usage
specification MUST provide the following information: specification MUST provide the following information:
o Application Unique ID (AUID): If the application usage is meant o Application Unique ID (AUID): If the application usage is meant
for general use on the Internet, the application usage MUST for general use on the Internet, the application usage MUST
register the AUID into the IETF tree using the IANA procedures register the AUID into the IETF tree using the IANA procedures
defined in Section 15. defined in Section 15.
o XML Schema o XML Schema
o Default Namespace o Default Document Namespace
o MIME Type o MIME Type
o Validation Constraints o Validation Constraints
o Data Semantics o Data Semantics
o Naming Conventions o Naming Conventions
o Resource Interdependencies o Resource Interdependencies
skipping to change at page 16, line 27 skipping to change at page 16, line 38
6.2. Document Selector 6.2. Document Selector
Each document within the XCAP root is identified by its document Each document within the XCAP root is identified by its document
selector. The document selector is a sequence of path segments, selector. The document selector is a sequence of path segments,
separated by a slash ("/"). These path segments define a separated by a slash ("/"). These path segments define a
hierarchical structure for organizing documents within any XCAP root. hierarchical structure for organizing documents within any XCAP root.
The first path segment MUST be the XCAP AUID. So, continuing the The first path segment MUST be the XCAP AUID. So, continuing the
example above, all of the documents used by the resource lists example above, all of the documents used by the resource lists
application would be under "http://xcap.example.com/resource-lists". application would be under "http://xcap.example.com/resource-lists".
Implementors making use of HTTP servlets should be aware that XCAP
may require them to get authorization from the server
administrator to place resources within this specific subset of
the URI namespace.
It is assumed that each application will have data that is set by It is assumed that each application will have data that is set by
users, and/or it will have global data that applies to all users. As users, and/or it will have global data that applies to all users. As
a result, beneath each AUID there are two sub-trees. One, called a result, beneath each AUID there are two sub-trees. One, called
"users", holds the documents that are applicable to specific users, "users", holds the documents that are applicable to specific users,
and the other, called "global", holds documents applicable to all and the other, called "global", holds documents applicable to all
users. The subtree beneath "global" is called the global tree. The users. The subtree beneath "global" is called the global tree. The
path segment after the AUID MUST either be "global" or "users". path segment after the AUID MUST either be "global" or "users".
Within the "users" tree are zero or more sub-trees, each of which Within the "users" tree are zero or more sub-trees, each of which
identifies documents that apply to a specific user. Each user known identifies documents that apply to a specific user. Each user known
skipping to change at page 18, line 27 skipping to change at page 18, line 45
node-selector = element-selector ["/" terminal-selector] node-selector = element-selector ["/" terminal-selector]
terminal-selector = attribute-selector / namespace-selector / terminal-selector = attribute-selector / namespace-selector /
extension-selector extension-selector
element-selector = step *( "/" step) element-selector = step *( "/" step)
step = by-name / by-pos / by-attr / by-pos-attr / step = by-name / by-pos / by-attr / by-pos-attr /
extension-selector extension-selector
by-name = NameorAny by-name = NameorAny
by-pos = NameorAny "[" position "]" by-pos = NameorAny "[" position "]"
position = 1*DIGIT position = 1*DIGIT
attr-test = ( "@" att-name "=" <"> att-value <"> ) / attr-test = "@" att-name "=" att-value
( "@" att-name "=" <'> att-value <'> )
by-attr = NameorAny "[" attr-test "]" by-attr = NameorAny "[" attr-test "]"
by-pos-attr = NameorAny "[" position "]" "[" attr-test "]" by-pos-attr = NameorAny "[" position "]" "[" attr-test "]"
NameorAny = QName / "*" ; QName from XML Namespaces NameorAny = QName / "*" ; QName from XML Namespaces
att-name = QName att-name = QName
att-value = AttValue ; from XML specification att-value = AttValue ; from XML specification
attribute-selector = "@" att-name attribute-selector = "@" att-name
namespace-selector = "namespace::*" namespace-selector = "namespace::*"
extension-selector = 1*( %x00-2e / %x30-ff ) ; anything but "/" extension-selector = 1*( %x00-2e / %x30-ff ) ; anything but "/"
The QName grammar is defined in the XML namespaces [3] specification, The QName grammar is defined in the XML namespaces [3] specification,
skipping to change at page 21, line 32 skipping to change at page 21, line 48
element, a single attribute or a set of namespace bindings. element, a single attribute or a set of namespace bindings.
Matching of element names is performed as follows. The element being Matching of element names is performed as follows. The element being
compared in the step has its name expanded as described in XML compared in the step has its name expanded as described in XML
namespaces [3]. The element name in the step is also expanded. This namespaces [3]. The element name in the step is also expanded. This
expansion requires that any namespace prefix is converted to its expansion requires that any namespace prefix is converted to its
namespace URI. Doing that requires a set of bindings from prefixes namespace URI. Doing that requires a set of bindings from prefixes
to namespace URIs. This set of bindings is obtained from the query to namespace URIs. This set of bindings is obtained from the query
component of the URI (see Section 6.4). If the prefix of the QName component of the URI (see Section 6.4). If the prefix of the QName
of an element is empty, the corresponding URI is then the default of an element is empty, the corresponding URI is then the default
namespace URI defined by the application usage, or null if not document namespace URI defined by the application usage, or null if
defined. Comparisons are then performed as described in XML not defined. Comparisons are then performed as described in XML
namespaces [3]. Note that the namespace prefix expansions described namespaces [3]. Note that the namespace prefix expansions described
here are different than those specified in the XPath 1.0 here are different than those specified in the XPath 1.0
specification, but are closer to those currently defined by the XPath specification, but are closer to those currently defined by the XPath
2.0 specification [24]. 2.0 specification [24].
Matching of attribute names proceeds in a similar way. The attribute Matching of attribute names proceeds in a similar way. The attribute
in the document has its name expanded as described in XML namespaces in the document has its name expanded as described in XML namespaces
[3]. If the attribute name in the attribute selector has a namespace [3]. If the attribute name in the attribute selector has a namespace
prefix, its name is expanded using the namespace bindings obtained prefix, its name is expanded using the namespace bindings obtained
from the query component of the URI. An unprefixed attribute QName from the query component of the URI. An unprefixed attribute QName
skipping to change at page 22, line 33 skipping to change at page 22, line 49
event="approved">sip:userA@example.net</watcher> event="approved">sip:userA@example.net</watcher>
<watcher status="pending" <watcher status="pending"
id="hh8juja87s997-ass7" id="hh8juja87s997-ass7"
display-name="Mr. Subscriber" display-name="Mr. Subscriber"
event="subscribe">sip:userB@example.org</watcher> event="subscribe">sip:userB@example.org</watcher>
</watcher-list> </watcher-list>
</watcherinfo> </watcherinfo>
Figure 3: Example XML Document Figure 3: Example XML Document
Assuming that the default namespace URI for this application usage is Assuming that the default document namespace for this application
"urn:ietf:params:xml:ns:watcherinfo", the node selector watcherinfo/ usage is "urn:ietf:params:xml:ns:watcherinfo", the node selector
watcher-list/watcher[@id="8ajksjda7s"] would select the following XML watcherinfo/watcher-list/watcher[@id="8ajksjda7s"] would select the
element: following XML element:
<watcher status="active" <watcher status="active"
id="8ajksjda7s" id="8ajksjda7s"
duration-subscribed="509" duration-subscribed="509"
event="approved">sip:userA@example.net</watcher> event="approved">sip:userA@example.net</watcher>
6.4. Namespace Bindings for the Selector 6.4. Namespace Bindings for the Selector
In order to expand the namespace prefixes used in the node selector, In order to expand the namespace prefixes used in the node selector,
a set of bindings from those namespace prefixes to namespace URI must a set of bindings from those namespace prefixes to namespace URI must
be used. Those bindings are contained in the query component of the be used. Those bindings are contained in the query component of the
URI. If no query component is present, it means that only the URI. If no query component is present, it means that only the
default namespace URI (as identified by the application usage) is default document namespace (as identified by the application usage)
defined. The query component is formatted as a valid xpointer is defined. The query component is formatted as a valid xpointer
expression [5] after suitable URI encoding as defined in Section 4.1 expression [5] after suitable URI encoding as defined in Section 4.1
of the Xpointer framework. This xpointer expression SHOULD only of the Xpointer framework. This xpointer expression SHOULD only
contain expressions from the xmlns() scheme [4]. A server compliant contain expressions from the xmlns() scheme [4]. A server compliant
to this specification MUST ignore any xpointer expressions not from to this specification MUST ignore any xpointer expressions not from
the xmlns() scheme. The xmlns() xpointer expressions define the set the xmlns() scheme. The xmlns() xpointer expressions define the set
of namespace bindings in use for evaluating the URI. of namespace bindings in use for evaluating the URI.
Note that xpointer expressions were originally designed for usage Note that xpointer expressions were originally designed for usage
within fragment identifiers of URIs. However, within XCAP, they are within fragment identifiers of URIs. However, within XCAP, they are
used within query components of URIs. used within query components of URIs.
skipping to change at page 23, line 35 skipping to change at page 24, line 4
<ns2:baz xmlns:ns2="urn:test:namespace2-uri"/> <ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
</ns1:bar> </ns1:bar>
<ns3:hi xmlns:ns3="urn:test:namespace3-uri"> <ns3:hi xmlns:ns3="urn:test:namespace3-uri">
<there/> <there/>
</ns3:hi> </ns3:hi>
</foo> </foo>
Assume that this document has a document URI of Assume that this document has a document URI of
"http://xcap.example.com/test/users/sip:joe@example.com/index", where "http://xcap.example.com/test/users/sip:joe@example.com/index", where
"test" is the application usage. This application usage defines a "test" is the application usage. This application usage defines a
default namespace URI of "urn:test:default-namespace". The XCAP URI: default document namespace of "urn:test:default-namespace". The XCAP
URI:
http://xcap.example.com/test/users/sip:joe@example.com/index/ http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace1-uri) xmlns(b=urn:test:namespace1-uri)
will select the first <baz> child element of the <bar> element in the will select the first <baz> child element of the <bar> element in the
document. The XCAP URI: document. The XCAP URI:
http://xcap.example.com/test/users/sip:joe@example.com/index/ http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
skipping to change at page 24, line 24 skipping to change at page 24, line 39
An XCAP client is an HTTP/1.1 compliant client. Specific data An XCAP client is an HTTP/1.1 compliant client. Specific data
manipulation tasks are accomplished by invoking the right set of HTTP manipulation tasks are accomplished by invoking the right set of HTTP
methods with the right set of headers on the server. This section methods with the right set of headers on the server. This section
describes those in detail. describes those in detail.
In all cases where the client modifies a document, by deleting or In all cases where the client modifies a document, by deleting or
inserting a document, element or attribute resource, the client inserting a document, element or attribute resource, the client
SHOULD verify that, if the operation were to succeed, the resulting SHOULD verify that, if the operation were to succeed, the resulting
document would meet the data constraints defined by the application document would meet the data constraints defined by the application
usage, including schema validation. For example, if the client usage, including schema validation. For example, if the client
performs a PUT operation to performs a PUT operation to "http://xcap.example.com/rls-services/
"http://xcap.example.com/rls-services/users/joe/mybuddies", rls- users/sip:joe@example.com/mybuddies", rls-services is the application
services is the application unique ID, and the constraints defined by unique ID, and the constraints defined by it SHOULD be followed.
it SHOULD be followed.
The client will know what URI to use based on the naming conventions The client will know what URI to use based on the naming conventions
described by the application usage. described by the application usage.
If the document, after modification, does not meet the data If the document, after modification, does not meet the data
constraints, the server will reject it with a 409. The 409 response constraints, the server will reject it with a 409. The 409 response
may contain an XML body, formatted according to the schema in may contain an XML body, formatted according to the schema in
Section 11.2, which provides further information on the nature of the Section 11.2, which provides further information on the nature of the
error. The client MAY use this information to try and alter the error. The client MAY use this information to try and alter the
request so that this time, it might succeed. The client SHOULD NOT request so that this time, it might succeed. The client SHOULD NOT
skipping to change at page 31, line 43 skipping to change at page 32, line 9
those prefixes. those prefixes.
The client then invokes the GET method. The 200 OK response will The client then invokes the GET method. The 200 OK response will
contain an "application/xcap-att+xml" document with the specified contain an "application/xcap-att+xml" document with the specified
attribute, formatted according to the grammar of AttValue as defined attribute, formatted according to the grammar of AttValue as defined
in the XML 1.0 specifications. in the XML 1.0 specifications.
7.10. Fetch Namespace Bindings 7.10. Fetch Namespace Bindings
If a client wishes to insert an element or attribute into a document, If a client wishes to insert an element or attribute into a document,
and that element or attribute are part of a namespace declared and that element or attribute is part of a namespace declared
elsewhere in the document, the client will need to know the namespace elsewhere in the document, the client will need to know the namespace
bindings in order to construct the XML content in the request. If bindings in order to construct the XML content in the request. If
the client has a cached copy of the document, it will know the the client has a cached copy of the document, it will know the
bindings. However, if it doesn't have the whole document cached, it bindings. However, if it doesn't have the whole document cached, it
can be useful to fetch just the bindings that are in scope for an can be useful to fetch just the bindings that are in scope for an
element, in order to construct a subsequent PUT request. element, in order to construct a subsequent PUT request.
To get those bindings, the client constructs a URI whose document To get those bindings, the client constructs a URI whose document
selector points to the document containing the element whose selector points to the document containing the element whose
namespace bindings are to be fetched. The node selector MUST be namespace bindings are to be fetched. The node selector MUST be
skipping to change at page 39, line 14 skipping to change at page 39, line 22
<xs:element name="foobar"> <xs:element name="foobar">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="foo" maxOccurs="unbounded" /> <xs:element ref="foo" maxOccurs="unbounded" />
<xs:element ref="bar" maxOccurs="unbounded" /> <xs:element ref="bar" maxOccurs="unbounded" />
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
Not any <bar> element may precede one or multiple <foo> elements. Based on this schema, the document contains some number of <foo>
Either <bar> or <foo> elements may easily be added without wildcards elements followed by some number of <bar> elements. Either <bar> or
and positional constraints. Note that if "minOccurs" cardinality of <foo> elements may easily be added without wildcards and positional
<foo> element were zero and <foo> elements don't exist yet, a constraints. Note that if "minOccurs" cardinality of <foo> element
positional predicate with the * wildcard MUST be used. were zero and <foo> elements don't exist yet, a positional predicate
with the * wildcard must be used.
The whole insert logic is best described by complete examples, The whole insert logic is best described by complete examples,
consider the following document: consider the following document:
<?xml version="1.0"?> <?xml version="1.0"?>
<root> <root>
<el1 att="first"/> <el1 att="first"/>
<el1 att="second"/> <el1 att="second"/>
<!-- comment --> <!-- comment -->
<el2 att="first/> <el2 att="first/>
skipping to change at page 41, line 15 skipping to change at page 41, line 27
target selector. An example of this case is described in target selector. An example of this case is described in
Section 7.4. If this happens the server MUST NOT perform the Section 7.4. If this happens the server MUST NOT perform the
insertion, and MUST reject the request with a 409 response. The body insertion, and MUST reject the request with a 409 response. The body
of the response SHOULD contain a detailed conflict report containing of the response SHOULD contain a detailed conflict report containing
the <cannot-insert> element. It is important to note that schema the <cannot-insert> element. It is important to note that schema
compliance does not play a role while performing the insertion. That compliance does not play a role while performing the insertion. That
is, the decision of where the element gets inserted is dictated is, the decision of where the element gets inserted is dictated
entirely by the structure of the request-URI, the current document, entirely by the structure of the request-URI, the current document,
and the rules in this specification. and the rules in this specification.
If the element being inserted (or any of its children) contain
namespace declarations, those declarations are retained when the
element is inserted, even if those same declarations exist in a
parent element after insertion. The XCAP server MUST NOT remove
redundant namespace declarations or otherwise change the namespace
declarations that were present in the element being inserted.
If the PUT request is for an attribute, the server inserts the If the PUT request is for an attribute, the server inserts the
content of the request body as the value of the attribute. The name content of the request body as the value of the attribute. The name
of the attribute is equal to the att-name from the attribute-selector of the attribute is equal to the att-name from the attribute-selector
in the target selector. in the target selector.
Assuming that the insertion can be accomplished, the server verifies Assuming that the insertion can be accomplished, the server verifies
that the insertion results in a document that meets the constraints that the insertion results in a document that meets the constraints
of the application usage. This is dicussed in Section 8.2.5. of the application usage. This is dicussed in Section 8.2.5.
8.2.4. Replacement 8.2.4. Replacement
skipping to change at page 41, line 42 skipping to change at page 42, line 13
filename. filename.
If the PUT request is for an element, the server replaces the target If the PUT request is for an element, the server replaces the target
node with the content of the request body. As in the creation case, node with the content of the request body. As in the creation case,
it is possible that, after replacement, the request URI does not it is possible that, after replacement, the request URI does not
select the element that was just inserted. If this happens the select the element that was just inserted. If this happens the
server MUST NOT perform the replacement, and MUST reject the request server MUST NOT perform the replacement, and MUST reject the request
with a 409 response. The body of the response SHOULD contain a with a 409 response. The body of the response SHOULD contain a
detailed conflict report containing the <cannot-insert> element. detailed conflict report containing the <cannot-insert> element.
As with creation, replacement of an element does not result in the
changing or elimination of namespace declarations within the newly
modified element.
If the PUT request is for an attribute, the server sets the value of If the PUT request is for an attribute, the server sets the value of
the selected attribute to the content of the request body. It is the selected attribute to the content of the request body. It is
possible in the replacement case (but not in the creation case), possible in the replacement case (but not in the creation case),
that, after replacement of the attribute, the request URI no longer that, after replacement of the attribute, the request URI no longer
selects the attribute that was just replaced. The scenario in which selects the attribute that was just replaced. The scenario in which
this can happen is discussed in Section 7.7. If this is the case, this can happen is discussed in Section 7.7. If this is the case,
the server MUST NOT perform the replacement, and MUST reject the the server MUST NOT perform the replacement, and MUST reject the
request with a 409 response. The body of the response SHOULD contain request with a 409 response. The body of the response SHOULD contain
a detailed conflict report containing the <cannot-insert> element. a detailed conflict report containing the <cannot-insert> element.
8.2.5. Validation 8.2.5. Validation
Once the document, element or attribute has been tentatively inserted Once the document, element or attribute has been tentatively inserted
the server needs to verify that the resulting document meets the data the server needs to verify that the resulting document meets the data
constraints outlined by the application usage. constraints outlined by the application usage.
First, the server checks that the final document is compliant to the First, the server checks that the final document is compliant to the
schema. If it is not, the server MUST NOT perform the insertion. It schema. If it is not, the server MUST NOT perform the insertion. It
MUST reject the request with a 409 response. That response SHOULD MUST reject the request with a 409 response. That response SHOULD
contain a detailed conflict report containing the <schema-validation- contain a detailed conflict report containing the <schema-validation-
error> element. error> element. If a schema allows for elements or attributes from
other namespaces, and the new document contains elements or
attributes from an unknown namespace, the server MUST allow the
change. In other words, it is not necessary for an XCAP server to
understand the namespaces and corresponding schemas for elements and
attributes within a document, as long as the schema itself allows for
such elements or attributes to be included. Of course, such unknown
namespaces would not be advertised by the server in its XCAP
capabilities document Section 12.
If the final document contains elements or attributes from a
namespace that the server does understand (and has consequently
advertised in its XCAP capabilities document), but the server does
not have the schema for that particular element or attribute, the
server MUST reject the request with a 409 response. That response
SHOULD contain a detailed conflict report containing the <schema-
validation-error> element.
Next, the server checks for any uniqueness constraints identified by Next, the server checks for any uniqueness constraints identified by
the application usage. If the application usage required that a the application usage. If the application usage required that a
particular element or attribute had a unique value within a specific particular element or attribute had a unique value within a specific
scope, the server would check that this uniqueness property still scope, the server would check that this uniqueness property still
exists. If the application usage required that a URI within the exists. If the application usage required that a URI within the
document was unique within the domain, the server checks whether it document was unique within the domain, the server checks whether it
is the case. If any of these uniqueness constraints are not met, the is the case. If any of these uniqueness constraints are not met, the
server MUST NOT perform the insertion. It MUST reject the request server MUST NOT perform the insertion. It MUST reject the request
with a 409 response. That response SHOULD contain a detailed with a 409 response. That response SHOULD contain a detailed
skipping to change at page 43, line 4 skipping to change at page 43, line 42
8.2.6. Conditional Processing 8.2.6. Conditional Processing
A PUT request for an XCAP resource, like any other HTTP resource, can A PUT request for an XCAP resource, like any other HTTP resource, can
be made conditional through usage of the If-Match and If-None-Match be made conditional through usage of the If-Match and If-None-Match
header fields. For a replacement, these are processed as defined in header fields. For a replacement, these are processed as defined in
[6]. For an insertion of an element or attribute, conditional [6]. For an insertion of an element or attribute, conditional
operations are permitted. The entity tag that is used for the operations are permitted. The entity tag that is used for the
procedures in [6] is the one for all of the resources within the same procedures in [6] is the one for all of the resources within the same
document as the parent of the element or attribute being inserted. document as the parent of the element or attribute being inserted.
One way to think of this is that, logically speaking, on receipt of One way to think of this is that, logically speaking, on receipt of
the PUT request, the XCAP server instantiates the resource referenced the PUT request, the XCAP server instantiates the etag for the
by the request and assigns it its entity tag, and then applies the resource referenced by the request, and then applies the processing
processing of the request. of the request. Because of this behavior, it is not possible to
perform a conditional insert on an attribute or element conditioned
on the operation being an insertion and not a replacement. In other
words, a conditional PUT of an element or attribute with an If-None-
Match: * will always fail.
8.2.7. Resource Interdependencies 8.2.7. Resource Interdependencies
Because XCAP resources include elements, attributes and documents, Because XCAP resources include elements, attributes and documents,
each of which has its own HTTP URI, the creation or modification of each of which has its own HTTP URI, the creation or modification of
one resource affects the state of many others. For example, one resource affects the state of many others. For example,
insertion of a document creates resources on the server for all of insertion of a document creates resources on the server for all of
the elements and attributes within that document. After the server the elements and attributes within that document. After the server
has performed the insertion associated with the PUT, the server MUST has performed the insertion associated with the PUT, the server MUST
create and/or modify those resources affected by that PUT. The create and/or modify those resources affected by that PUT. The
skipping to change at page 43, line 32 skipping to change at page 44, line 27
However, the application usage can specify other resource inter- However, the application usage can specify other resource inter-
dependencies. The server MUST create or modify the resources dependencies. The server MUST create or modify the resources
specified by the application usage. specified by the application usage.
If the creation or replacement was successful, and the resource If the creation or replacement was successful, and the resource
interdependencies are resolved, the server returns a 201 Created or interdependencies are resolved, the server returns a 201 Created or
or 200 OK, respectively. Note that a 201 Created is generated for or 200 OK, respectively. Note that a 201 Created is generated for
creation of new documents, elements, or attributes. A 200 OK creation of new documents, elements, or attributes. A 200 OK
response to PUT MUST not contain any content. Per the response to PUT MUST not contain any content. Per the
recommendations of RFC 2616, the 201 can contain a Location header recommendations of RFC 2616, the 201 can contain a Location header
field and entity that identify the resource that was created. field and entity that identify the resource that was created. An
entity tag MUST be included in all successful responses to a PUT.
8.3. GET Handling 8.3. GET Handling
The semantics of GET are as specified in RFC 2616. This section The semantics of GET are as specified in RFC 2616. This section
clarifies the specific content to be returned for a particular URI clarifies the specific content to be returned for a particular URI
that represents an XCAP resource. that represents an XCAP resource.
If the request URI contains only a document selector, the server If the request URI contains only a document selector, the server
returns the document specified by the URI if it exists, else returns returns the document specified by the URI if it exists, else returns
a 404 response. The MIME type of the body of the 200 OK response a 404 response. The MIME type of the body of the 200 OK response
MUST be the MIME type defined by that application usage (i.e., MUST be the MIME type defined by that application usage (i.e.,
"application/resource-lists+xml"). "application/resource-lists+xml").
If the request URI contains a node selector, the server obtains the If the request URI contains a node selector, the server obtains the
document specified by the document selector, and if it is found, document specified by the document selector, and if it is found,
evaluates the node-selector within that document. If no document is evaluates the node-selector within that document. If no document is
found, or if the node-selector is a no-match or invalid, the server found, or if the node-selector is a no-match or invalid, the server
returns a 404 response. Otherwise, the server returns a 200 OK returns a 404 response. Otherwise, the server returns a 200 OK
response. If the node selector identifies an XML element, that response. If the node selector identifies an XML element, that
element is returned in the 200 OK response as an XML fragment body element is returned in the 200 OK response as an XML fragment body
containing the selected element. The MIME type of the response MUST containing the selected element. The server MUST NOT add namespace
be "application/xcap-el+xml". If the node selector identifies an XML bindings representing namespaces used by the element or its children,
attribute, the value of that attribute is returned in the body of the but declared in ancestor elements; the client will either know these
response. The MIME type of the response MUST be "application/ bindings already (since it has a cached copy of the whole document),
xcap-att+xml". If the node selector identifies a set of namespace or it can learn them by explicitly querying for the bindings. The
bindings, the server computes the set of namespace bindings in scope MIME type of the response MUST be "application/xcap-el+xml". If the
for the element (including the default) and encodes it using the node selector identifies an XML attribute, the value of that
"application/xcap-ns+xml" format defined in Section 10. That attribute is returned in the body of the response. The MIME type of
document is then returned in the body of the response. the response MUST be "application/xcap-att+xml". If the node
selector identifies a set of namespace bindings, the server computes
the set of namespace bindings in scope for the element (including the
default) and encodes it using the "application/xcap-ns+xml" format
defined in Section 10. That document is then returned in the body of
the response.
GET operations can be conditional, and follow the procedures defined GET operations can be conditional, and follow the procedures defined
in [6]. in [6].
Note that the GET of a resource that was just PUT might not be octet-
for-octet equivalent to what was PUT, due to XML normalization and
equivalency rules.
A successful response to a GET MUST include an entity tag.
8.4. DELETE Handling 8.4. DELETE Handling
The semantics of DELETE are as specified in RFC 2616. This section The semantics of DELETE are as specified in RFC 2616. This section
clarifies the specific content to be deleted for a particular URI clarifies the specific content to be deleted for a particular URI
that represents an XCAP resource. that represents an XCAP resource.
If the request URI contained a namespace-selector, the server MUST If the request URI contained a namespace-selector, the server MUST
reject the request with a 405 (Method Not Allowed) and MUST include reject the request with a 405 (Method Not Allowed) and MUST include
an Allow header field including the GET method. an Allow header field including the GET method.
skipping to change at page 45, line 10 skipping to change at page 46, line 17
response. If the deletion results in a document that is still valid, response. If the deletion results in a document that is still valid,
the server MUST perform the deletion, process the resource the server MUST perform the deletion, process the resource
interdependencies defined by the application usage, and return a 200 interdependencies defined by the application usage, and return a 200
OK response. OK response.
DELETE operations can be conditional, and follow the procedures DELETE operations can be conditional, and follow the procedures
defined in [6]. defined in [6].
Before the server returns the 200 OK response to a DELETE, it MUST Before the server returns the 200 OK response to a DELETE, it MUST
process the resource interdependencies as defined in Section 8.2.7. process the resource interdependencies as defined in Section 8.2.7.
As long as the document still exists after the delete operation, any
successful response to DELETE MUST include the entity tag of the
document.
8.5. Managing Etags 8.5. Managing Etags
An XCAP server MUST maintain entity tags for all resources that it An XCAP server MUST maintain entity tags for all resources that it
maintains. This specification introduces the additional constraint maintains. This specification introduces the additional constraint
that when one resource within a document (including the document that when one resource within a document (including the document
itself) changes, that resource is assigned a new etag, and all other itself) changes, that resource is assigned a new etag, and all other
resources within that document MUST be assigned the same etag value. resources within that document MUST be assigned the same etag value.
An XCAP server MUST include the Etag header field in all 200 or 201 Effectively, there is a single etag for the entire document. An XCAP
responses to PUT, GET, and DELETE, assuming the document itself still server MUST include the Etag header field in all 200 or 201 responses
exists after the operation. In the case of a DELETE, the entity tag to PUT, GET, and DELETE, assuming the document itself still exists
refers to the value of the entity tag for all other resources after after the operation. In the case of a DELETE, the entity tag refers
the deletion of the specified resource has occurred. One way to to the value of the entity tag for the document after the deletion of
think about this is that the server is, logically speaking, re- the element or attribute.
instantiating the resource for a brief instant, so that it can have
an entity tag that can be reasonably returned in the response to
DELETE.
XCAP resources do not introduce new requirements on the strength of XCAP resources do not introduce new requirements on the strength of
the entity tags; as in RFC 2616, weak ones MAY be used if performance the entity tags.
constraints or other conditions make usage of strong ones untenable
for some reason.
As a result of this constraint, when a client makes a change to an As a result of this constraint, when a client makes a change to an
element or attribute within a document, the response to that element or attribute within a document, the response to that
operation will convey the entity tag of the resource that was just operation will convey the entity tag of the resource that was just
affected. Since the client knows that this entity tag value is affected. Since the client knows that this entity tag value is
shared by all of the other resources in the document, the client can shared by all of the other resources in the document, the client can
make conditional requests against other resources using that entity make conditional requests against other resources using that entity
tag. tag.
9. Cache Control 9. Cache Control
skipping to change at page 48, line 4 skipping to change at page 49, line 10
would result in a document that did not meet a uniqueness would result in a document that did not meet a uniqueness
constraint defined by the application usage. For each URI, constraint defined by the application usage. For each URI,
element or attribute specified by the client which is not unique, element or attribute specified by the client which is not unique,
an <exists> element is present as the content of the error an <exists> element is present as the content of the error
element. Each <exists> element has a "field" attribute that element. Each <exists> element has a "field" attribute that
contains a relative URI identifying the XML element or attribute contains a relative URI identifying the XML element or attribute
whose value needs to be unique, but wasn't. The relative URI is whose value needs to be unique, but wasn't. The relative URI is
relative to the document itself, and will therefore start with the relative to the document itself, and will therefore start with the
root element. The query component of the URI MUST be present if root element. The query component of the URI MUST be present if
the node selector portion of the URI contains namespace prefixes. the node selector portion of the URI contains namespace prefixes.
Since the "field" node selector is a valid HTTP URI, it MUST be
Qualified elements attached with default namespace declaration are percent-encoded. The <exists> element can optionally contain a
selected as described in Section 6.4. Since the "field" node list of <alt-value> elements. Each one is a suggested alternate
selector is a valid HTTP URI, it MUST be percent-encoded. The value which does not currently exist on the server.
<exists> element can optionally contain a list of <alt-value>
elements. Each one is a suggested alternate value which does not
currently exist on the server.
<constraint-failure>: This indicates that the requested operation <constraint-failure>: This indicates that the requested operation
would result in a document that failed a data constraint defined would result in a document that failed a data constraint defined
by the application usage, but not enforced by the schema or a by the application usage, but not enforced by the schema or a
uniqueness constraint. uniqueness constraint.
<extension>: This indicates an error condition that is defined by an <extension>: This indicates an error condition that is defined by an
extension to XCAP. Clients which do not understand the content of extension to XCAP. Clients which do not understand the content of
the extension element MUST discard the xcap-error document and the extension element MUST discard the xcap-error document and
treat the error as an unqualified 409. treat the error as an unqualified 409.
skipping to change at page 52, line 44 skipping to change at page 53, line 46
MUST support this application usage. This usage defines a single MUST support this application usage. This usage defines a single
document within the global tree which lists the capabilities of the document within the global tree which lists the capabilities of the
server. Clients can read this well-known document, and therefore server. Clients can read this well-known document, and therefore
learn the capabilities of the server. learn the capabilities of the server.
The structure of the document is simple. The root element is <xcap- The structure of the document is simple. The root element is <xcap-
caps>. Its children are <auids>, <extensions>, and <namespaces>. caps>. Its children are <auids>, <extensions>, and <namespaces>.
Each of these contain a list of AUIDs, extensions and namespaces Each of these contain a list of AUIDs, extensions and namespaces
supported by the server. Extensions are named by tokens defined by supported by the server. Extensions are named by tokens defined by
the extension, and typically define new selectors. Namespaces are the extension, and typically define new selectors. Namespaces are
identified by their namespace URI. Since all XCAP servers support identified by their namespace URI. To 'support' a namespace, the
the "xcap-caps" AUID, it MUST be listed in the <auids> element and server must have the schemas for all elements within that namespace,
the "urn:ietf:params:xml:ns:xcap-caps" namespace MUST be listed in and be able to validate them if they appear within documents. Since
the <namespaces> element. all XCAP servers support the "xcap-caps" AUID, it MUST be listed in
the <auids> element and the "urn:ietf:params:xml:ns:xcap-caps"
namespace MUST be listed in the <namespaces> element.
The following sections provide the information needed to define this The following sections provide the information needed to define this
application usage. application usage.
12.1. Application Unique ID (AUID) 12.1. Application Unique ID (AUID)
This specification defines the "xcap-caps" AUID within the IETF tree, This specification defines the "xcap-caps" AUID within the IETF tree,
via the IANA registration in Section 15. via the IANA registration in Section 15.
12.2. XML Schema 12.2. XML Schema
skipping to change at page 54, line 33 skipping to change at page 55, line 38
<xs:restriction base="xs:string"/> <xs:restriction base="xs:string"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="namespaceType"> <xs:simpleType name="namespaceType">
<xs:annotation> <xs:annotation>
<xs:documentation>Namespace type</xs:documentation> <xs:documentation>Namespace type</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:anyURI"/> <xs:restriction base="xs:anyURI"/>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
12.3. Default Namespace 12.3. Default Document Namespace
The default namespace used in evaluating a URI is The default document namespace used in evaluating a URI is
urn:ietf:params:xml:ns:xcap-caps. urn:ietf:params:xml:ns:xcap-caps.
12.4. MIME Type 12.4. MIME Type
Documents conformant to this schema are known by the MIME type Documents conformant to this schema are known by the MIME type
"application/xcap-caps+xml", registered in Section 15.2.5. "application/xcap-caps+xml", registered in Section 15.2.5.
12.5. Validation Constraints 12.5. Validation Constraints
There are no additional validation constraints associated with this There are no additional validation constraints associated with this
skipping to change at page 55, line 41 skipping to change at page 56, line 46
/resource-lists/users/sip:bill@example.com/index HTTP/1.1 /resource-lists/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/resource-lists+xml Content-Type:application/resource-lists+xml
Host: xcap.example.com Host: xcap.example.com
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends"> <list name="friends">
</list> </list>
</resource-lists> </resource-lists>
Figure 24: New Document
Next, Bill creates an RLS services document defining a single RLS Next, Bill creates an RLS services document defining a single RLS
service referencing this list. This service has a URI of service referencing this list. This service has a URI of
sip:myfriends@example.com (URIs are line-folded for readability): sip:myfriends@example.com (URIs are line-folded for readability):
PUT PUT
/rls-services/users/sip:bill@example.com/index HTTP/1.1 /rls-services/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/rls-services+xml Content-Type:application/rls-services+xml
Host: xcap.example.com Host: xcap.example.com
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 56, line 23 skipping to change at page 57, line 24
<resource-list>http://xcap.example.com/resource-lists/users/ <resource-list>http://xcap.example.com/resource-lists/users/
sip:bill@example.com/index/~~/resource-lists/ sip:bill@example.com/index/~~/resource-lists/
list%5b@name=%22friends%22%5d list%5b@name=%22friends%22%5d
</resource-list> </resource-list>
<packages> <packages>
<package>presence</package> <package>presence</package>
</packages> </packages>
</service> </service>
</rls-services> </rls-services>
Figure 25: RLS Services Example
Next, Bill creates an element in the resource-lists document Next, Bill creates an element in the resource-lists document
(Section 7.4). In particular, he adds an entry to the list: (Section 7.4). In particular, he adds an entry to the list:
PUT PUT
/resource-lists/users/sip:bill@example.com/index /resource-lists/users/sip:bill@example.com/index
/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1 /~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
Content-Type:application/xcap-el+xml Content-Type:application/xcap-el+xml
Host: xcap.example.com Host: xcap.example.com
<entry uri="sip:bob@example.com"> <entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name> <display-name>Bob Jones</display-name>
</entry> </entry>
Figure 26: Resource Lists Document
Next, Bill fetches the document (Section 7.3): Next, Bill fetches the document (Section 7.3):
GET GET
/resource-lists/users/sip:bill@example.com/index HTTP/1.1 /resource-lists/users/sip:bill@example.com/index HTTP/1.1
Figure 27: Fetch Operation
And the result is (note how white space text nodes appear in the And the result is (note how white space text nodes appear in the
document): document):
HTTP/1.1 200 OK HTTP/1.1 200 OK
Etag: "wwhha" Etag: "wwhha"
Content-Type: application/resource-lists+xml Content-Type: application/resource-lists+xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends"> <list name="friends">
<entry uri="sip:bob@example.com"> <entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name> <display-name>Bob Jones</display-name>
</entry></list> </entry></list>
</resource-lists> </resource-lists>
Figure 28: Results of Fetch
Next, Bill adds another entry to the list, which is another list that Next, Bill adds another entry to the list, which is another list that
has three entries. This is another element creation (Section 7.4): has three entries. This is another element creation (Section 7.4):
PUT PUT
/resource-lists/users/sip:bill@example.com/index/~~/ /resource-lists/users/sip:bill@example.com/index/~~/
resource-lists/list%5b@name=%22friends%22%5d/ resource-lists/list%5b@name=%22friends%22%5d/
list%5b@name=%22close-friends%22%5d HTTP/1.1 list%5b@name=%22close-friends%22%5d HTTP/1.1
Content-Type: application/xcap-el+xml Content-Type: application/xcap-el+xml
Host: xcap.example.com Host: xcap.example.com
skipping to change at page 57, line 39 skipping to change at page 58, line 42
<display-name>Joe Smith</display-name> <display-name>Joe Smith</display-name>
</entry> </entry>
<entry uri="sip:nancy@example.com"> <entry uri="sip:nancy@example.com">
<display-name>Nancy Gross</display-name> <display-name>Nancy Gross</display-name>
</entry> </entry>
<entry uri="sip:petri@example.com"> <entry uri="sip:petri@example.com">
<display-name>Petri Aukia</display-name> <display-name>Petri Aukia</display-name>
</entry> </entry>
</list> </list>
Figure 29: Adding an Entry
Then, Bill decides he doesn't want Petri on the list, so he deletes Then, Bill decides he doesn't want Petri on the list, so he deletes
the entry (Section 7.5): the entry (Section 7.5):
DELETE DELETE
/resource-lists/users/sip:bill@example.com/index/ /resource-lists/users/sip:bill@example.com/index/
~~/resource-lists/list/list/ ~~/resource-lists/list/list/
entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1 entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1
Host: xcap.example.com Host: xcap.example.com
Figure 30: Deleting an Entry
Bill decides to check on the URI for Nancy, so he fetches a Bill decides to check on the URI for Nancy, so he fetches a
particular attribute (Section 7.6): particular attribute (Section 7.6):
GET GET
/resource-lists/users/sip:bill@example.com/index/ /resource-lists/users/sip:bill@example.com/index/
~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1 ~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1
Host: xcap.example.com Host: xcap.example.com
Figure 31: Fetching an Attribute
and the server responds: and the server responds:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Etag: "ad88" Etag: "ad88"
Content-Type:application/xcap-att+xml Content-Type:application/xcap-att+xml
"sip:nancy@example.com" "sip:nancy@example.com"
Figure 32: Results of Fetch
14. Security Considerations 14. Security Considerations
Frequently, the data manipulated by XCAP contains sensitive Frequently, the data manipulated by XCAP contains sensitive
information. To avoid eavesdroppers from seeing this information, it information. To avoid eavesdroppers from seeing this information, it
is RECOMMENDED that an admistrator hand out an https URI as the XCAP is RECOMMENDED that an admistrator hand out an https URI as the XCAP
root URI. This will result in TLS-encrypted communications between root URI. This will result in TLS-encrypted communications between
the client and server, preventing any eavesdropping. the client and server, preventing any eavesdropping. Clients MUST
implement TLS, assuring that such URIs will be usable by the client.
Client and server authentication are also important. A client needs Client and server authentication are also important. A client needs
to be sure it is talking to the server it believes it is contacting. to be sure it is talking to the server it believes it is contacting.
Otherwise, it may be given false information, which can lead to Otherwise, it may be given false information, which can lead to
denial of service attacks against a client. To prevent this, a denial of service attacks against a client. To prevent this, a
client SHOULD attempt to upgrade [15] any connections to TLS. client SHOULD attempt to upgrade [15] any connections to TLS.
Similarly, authorization of read and write operations against the Similarly, authorization of read and write operations against the
data is important, and this requires client authentication. As a data is important, and this requires client authentication. As a
result, a server SHOULD challenge a client using HTTP Digest [11] to result, a server SHOULD challenge a client using HTTP Digest [11] to
establish its identity, and this SHOULD be done over a TLS establish its identity, and this SHOULD be done over a TLS
connection. connection. Clients MUST implement digest authentication, assuring
interoperability with servers which challenge the client. Servers
MUST NOT perform basic authentication without a TLS connection to the
client.
Because XCAP is a usage of HTTP and not a separate protocol, it runs Because XCAP is a usage of HTTP and not a separate protocol, it runs
on the same port numbers as HTTP traffic normally does. This makes on the same port numbers as HTTP traffic normally does. This makes
it difficult to apply port-based filtering rules in firewalls to it difficult to apply port-based filtering rules in firewalls to
separate the treatment of XCAP traffic from other HTTP traffic. separate the treatment of XCAP traffic from other HTTP traffic.
However, this problem exists broadly today because HTTP is used to However, this problem exists broadly today because HTTP is used to
access a wide breadth of content, all on the same port, and XCAP access a wide breadth of content, all on the same port, and XCAP
views application configuration documents as just another type of views application configuration documents as just another type of
HTTP content. As such, separate treatment of XCAP traffic from other HTTP content. As such, separate treatment of XCAP traffic from other
HTTP traffic requires firewalls to examine the URL itself. There is HTTP traffic requires firewalls to examine the URL itself. There is
skipping to change at page 66, line 42 skipping to change at page 68, line 4
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
XML Schema: The XML for this schema can be found as the sole content XML Schema: The XML for this schema can be found as the sole content
of Section 11.2. of Section 11.2.
15.4.2. XCAP Capabilities Schema Registration 15.4.2. XCAP Capabilities Schema Registration
URI: urn:ietf:params:xml:schema:xcap-caps URI: urn:ietf:params:xml:schema:xcap-caps
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
XML Schema: The XML for this schema can be found as the sole content XML Schema: The XML for this schema can be found as the sole content
of Section 12.2. of Section 12.2.
16. Acknowledgements 16. Acknowledgements
The author would like to thank Jari Urpalainen, who has contributed The author would like to thank Jari Urpalainen, who has contributed
many important comments and has assisted with edit passes in the many important comments and has assisted with edit passes in the
document. The author would also like to thank Ben Campbell, Eva- document. The author would also like to thank Ben Campbell, Eva-
Maria Leppanen, Hisham Khartabil, Chris Newman, Joel Halpern, , Lisa Maria Leppanen, Hisham Khartabil, Chris Newman, Joel Halpern, , Lisa
Dusseault, Tim Bray, Pete Cordell, Jeroen van Bemmel, Christian Dusseault, Tim Bray, Pete Cordell, Jeroen van Bemmel, Christian
Schmidt, and Spencer Dawkins for their input and comments. A special Schmidt, and Spencer Dawkins for their input and comments. A special
thanks to Ted Hardie for his input and support. thanks to Ted Hardie for his input and support.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., and E. [1] Sperberg-McQueen, C., Maler, E., Bray, T., Paoli, J., and F.
Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", Yergeau, "Extensible Markup Language (XML) 1.0 (Third
W3C REC REC-xml-20040204, February 2004. Edition)", World Wide Web Consortium
Recommendation http://www.w3.org/TR/2004/REC-xml-20040204,
February 2004.
[2] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML [2] Beech, D., Mendelsohn, N., Maloney, M., and H. Thompson, "XML
Schema Part 1: Structures Second Edition", W3C REC REC- Schema Part 1: Structures Second Edition", World Wide Web
xmlschema-1-20041028, October 2004. Consortium Recommendation http://www.w3.org/TR/2004/
REC-xmlschema-1-20041028, October 2004.
[3] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", [3] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",
W3C REC REC-xml-names-19990114, January 1999. World Wide Web Consortium
Recommendation http://www.w3.org/TR/1999/
REC-xml-names-19990114, January 1999.
[4] DeRose, S., Daniel, R., Maler, E., and J. Marsh, "XPointer [4] DeRose, S., Daniel, R., Maler, E., and J. Marsh, "XPointer
xmlns() Scheme", W3C REC REC-xptr-xmlns-20030325, March 2003. xmlns() Scheme", World Wide Web Consortium Recommendation http:
//www.w3.org/TR/2003/REC-xptr-xmlns-20030325, March 2003.
[5] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer [5] Marsh, J., Grosso, P., Walsh, N., and E. Maler, "XPointer
Framework", W3C REC REC-xptr-framework-20030325, March 2003. Framework", World Wide Web Consortium Recommendation http://
www.w3.org/TR/2003/REC-xptr-framework-20030325, March 2003.
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet [8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996. BCP 13, RFC 2048, November 1996.
[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[10] Clark, J. and S. DeRose, "XML Path Language (XPath) Version [10] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", W3C REC REC-xpath-19991116, November 1999. 1.0", World Wide Web Consortium
Recommendation http://www.w3.org/TR/1999/REC-xpath-19991116,
November 1999.
[11] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [11] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[12] Crocker, D. and P. Overell, "Augmented BNF for Syntax [12] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 68, line 29 skipping to change at page 69, line 47
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[17] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [17] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[18] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [18] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[19] Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-c14n- [19] Boyer, J., "Canonical XML Version 1.0", World Wide Web
20010315, March 2001. Consortium
Recommendation http://www.w3.org/TR/2001/REC-xml-c14n-20010315,
March 2001.
17.2. Informative References 17.2. Informative References
[20] Rosenberg, J., "A Presence Event Package for the Session [20] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[21] Roach, A., Rosenberg, J., and B. Campbell, "A Session [21] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", draft-ietf-simple-event-list-07 (work in Resource Lists", draft-ietf-simple-event-list-07 (work in
progress), January 2005. progress), January 2005.
[22] Rosenberg, J., "Extensible Markup Language (XML) Formats for [22] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-05 (work in progress), draft-ietf-simple-xcap-list-usage-05 (work in progress),
February 2005. February 2005.
[23] Grosso, P. and D. Veillard, "XML Fragment Interchange", W3C [23] Grosso, P. and D. Veillard, "XML Fragment Interchange", World
CR CR-xml-fragment-20010212, February 2001. Wide Web Consortium CR CR-xml-fragment-20010212, February 2001,
<http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.
[24] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., [24] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M.,
Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0", W3C Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0",
CR CR-xpath20-20051103, November 2005. World Wide Web Consortium
CR http://www.w3.org/TR/2005/CR-xpath20-20051103,
November 2005.
[25] Newman, C. and J. Myers, "ACAP -- Application Configuration [25] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997. Access Protocol", RFC 2244, November 1997.
[26] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence [26] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000. and Instant Messaging", RFC 2778, February 2000.
[27] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [27] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
 End of changes. 63 change blocks. 
167 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/