SIMPLE                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: April 16, 2007                                 October 13, 2006


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 maps XML document sub-trees and element attributes
   to HTTP URIs, so that these components can be directly accessed by
   HTTP.





Rosenberg                Expires April 16, 2007                 [Page 1]

Internet-Draft                    XCAP                      October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Application Usages . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Application Unique ID (AUID) . . . . . . . . . . . . . . .  7
     5.2.  Default Document Namespace . . . . . . . . . . . . . . . .  8
     5.3.  Data Validation  . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10
     5.5.  Naming Conventions . . . . . . . . . . . . . . . . . . . . 10
     5.6.  Resource Interdependencies . . . . . . . . . . . . . . . . 11
     5.7.  Authorization Policies . . . . . . . . . . . . . . . . . . 12
     5.8.  Data Extensibility . . . . . . . . . . . . . . . . . . . . 12
     5.9.  Documenting Application Usages . . . . . . . . . . . . . . 13
     5.10. Guidelines for Creating Application Usages . . . . . . . . 13
   6.  URI Construction . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  XCAP Root  . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.2.  Document Selector  . . . . . . . . . . . . . . . . . . . . 16
     6.3.  Node Selector  . . . . . . . . . . . . . . . . . . . . . . 18
     6.4.  Namespace Bindings for the Selector  . . . . . . . . . . . 23
   7.  Client Operations  . . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  Create or Replace a Document . . . . . . . . . . . . . . . 25
     7.2.  Delete a Document  . . . . . . . . . . . . . . . . . . . . 26
     7.3.  Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26
     7.4.  Create or Replace an Element . . . . . . . . . . . . . . . 26
     7.5.  Delete an Element  . . . . . . . . . . . . . . . . . . . . 28
     7.6.  Fetch an Element . . . . . . . . . . . . . . . . . . . . . 29
     7.7.  Create or Replace an Attribute . . . . . . . . . . . . . . 30
     7.8.  Delete an Attribute  . . . . . . . . . . . . . . . . . . . 31
     7.9.  Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31
     7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 32
     7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32
   8.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . . 34
     8.1.  POST Handling  . . . . . . . . . . . . . . . . . . . . . . 35
     8.2.  PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35
       8.2.1.  Locating the Parent  . . . . . . . . . . . . . . . . . 35
       8.2.2.  Verifying Document Content . . . . . . . . . . . . . . 36
       8.2.3.  Creation . . . . . . . . . . . . . . . . . . . . . . . 37
       8.2.4.  Replacement  . . . . . . . . . . . . . . . . . . . . . 41
       8.2.5.  Validation . . . . . . . . . . . . . . . . . . . . . . 42
       8.2.6.  Conditional Processing . . . . . . . . . . . . . . . . 43
       8.2.7.  Resource Interdependencies . . . . . . . . . . . . . . 44
     8.3.  GET Handling . . . . . . . . . . . . . . . . . . . . . . . 44
     8.4.  DELETE Handling  . . . . . . . . . . . . . . . . . . . . . 45
     8.5.  Managing Etags . . . . . . . . . . . . . . . . . . . . . . 46
   9.  Cache Control  . . . . . . . . . . . . . . . . . . . . . . . . 46



Rosenberg                Expires April 16, 2007                 [Page 2]

Internet-Draft                    XCAP                      October 2006


   10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 47
   11. Detailed Conflict Reports  . . . . . . . . . . . . . . . . . . 47
     11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 48
     11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 49
   12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 53
     12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 54
     12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 54
     12.3. Default Document Namespace . . . . . . . . . . . . . . . . 55
     12.4. MIME Type  . . . . . . . . . . . . . . . . . . . . . . . . 55
     12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 55
     12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 56
     12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 56
     12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 56
     12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 56
   13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 59
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
     15.1. XCAP Application Unique IDs  . . . . . . . . . . . . . . . 60
     15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 61
       15.2.1. application/xcap-el+xml MIME Type  . . . . . . . . . . 61
       15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 62
       15.2.3. application/xcap-ns+xml MIME Type  . . . . . . . . . . 63
       15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 64
       15.2.5. application/xcap-caps+xml MIME Type  . . . . . . . . . 65
     15.3. URN Sub-Namespace Registrations  . . . . . . . . . . . . . 66
       15.3.1. urn:ietf:params:xml:ns:xcap-error  . . . . . . . . . . 66
       15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 66
     15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 67
       15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 67
       15.4.2. XCAP Capabilities Schema Registration  . . . . . . . . 67
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 68
     17.2. Informative References . . . . . . . . . . . . . . . . . . 70
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71
   Intellectual Property and Copyright Statements . . . . . . . . . . 72















Rosenberg                Expires April 16, 2007                 [Page 3]

Internet-Draft                    XCAP                      October 2006


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.

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

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


2.  Overview of Operation

   Each application (where an application refers to a use case that
   implies a collection of data and associated semantics) that makes use
   of XCAP specifies an application usage (Section 5).  This application
   usage defines the XML schema [2] for the data used by the
   application, along with other key pieces of information.  The
   principal task of XCAP is to allow clients to read, write, modify,



Rosenberg                Expires April 16, 2007                 [Page 4]

Internet-Draft                    XCAP                      October 2006


   create and delete pieces of that data.  These operations are
   supported using HTTP/1.1 [6].  An XCAP server acts as a repository
   for collections of XML documents.  There will be documents stored for
   each application.  Within each application, there are documents
   stored for each user.  Each user can have a multiplicity of documents
   for a particular application.  To access some component of one of
   those documents, XCAP defines an algorithm for constructing a URI
   that can be used to reference that component.  Components refer to
   any element or attribute within the document.  Thus, the HTTP URIs
   used by XCAP point to a document, or to pieces of information that
   are finer grained than the XML document itself.  An HTTP resource
   which follows the naming conventions and validation constraints
   defined here is called an XCAP resource.

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

   XML documents which are equivalent for the purposes of many
   applications may differ in their physical representation.  With XCAP
   resources, the canonical form with comments [19] of an XML document
   determines the logical equivalence.  In other words, the canonical
   specification determines, how significant whitespace MUST be
   processed and for example, that new inserted attributes may appear in
   any order within the physical representation.


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


4.  Definitions

   The following terms are used throughout this document: