Update 2004-05: In February 2004 an updated "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)" Internet Draft was published by the IETF SIMPLE Working Group. See also "IETF SIMPLE Specifications Support Presence-Based IM, Video, and Voice."

[May 29, 2003] The Internet Engineering Task Force (IETF) has announced the publication of three related Internet Drafts describing an XML Configuration Access Protocol (XCAP). The XCAP drafts have been released by the IETF SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) Working Group. XCAP defines "a set of conventions for using HTTP to read, write and modify XML configuration data. XCAP is based heavily on ideas borrowed from the Application Configuration Access Protocol (ACAP), though 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. An XCAP server acts as a repository for collections of XML documents. There will be documents stored for each application. Within each application, there are documents stored for each user. Each user can have a multiplicity of documents for a particular application. To access some component of one of those documents, XCAP defines an algorithm for constructing a URI that can be used to reference that component. Components refer to any subtree of the document, or any attribute for any element within the document. Thus, the HTTP URIs used by XCAP point to pieces of information that are finer grained than the XML document itself."

XCAP Overview

The Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) working group has been developing specifications for subscribing to, and receiving notifications of, user presence. An important aspect of user presence is authorization policy. Indeed, the presence specification requires a Presence Agent (PA) to both authenticate and authorize all subscriptions before accepting them. However, it does not define how the server determines the authorization status of a subscriber. Users can set their authorization policy through web pages or voice response systems. However, there is currently no protocol specified for setting this policy. A protocol for this purpose is called an authorization manipulation protocol.

The SIMPLE group has defined requirements for an authorization manipulation protocol and a presence list manipulation protocol... This document proposes a candidate for the authorization and presence manipulation protocol, called the Extensible Markup Language (XML) Configuration Access Protocol (XCAP).

XCAP supports the needs of any application that needs access to data defined by clients of the application. Each application that makes use of XCAP specifies an application usage (Section 4). This application usage defines the XML schema for the data used by the application, along with other key pieces of information. The principal task of XCAP is to allow clients to read, write, modify, create and delete pieces of that data. These operations are supported using HTTP 1.1.

An XCAP server acts as a repository for collections of XML documents. There will be documents stored for each application. Within each application, there are documents stored for each user. Each user can have a multiplicity of documents for a particular application. To access some component of one of those documents, XCAP defines an algorithm for constructing a URI that can be used to reference that component. Components refer to any subtree of the document, or any attribute for any element within the document. Thus, the HTTP URIs used by XCAP point to pieces of information that are finer grained than the XML document itself.

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

Bibliographic Information

• The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). By Jonathan Rosenberg (dynamicsoft); WWW. IETF SIMPLE Working Group, Internet-Draft. Reference: 'draft-rosenberg-simple-xcap-00'. May 26, 2003, expires November 24, 2003. 29 pages.

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

• An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists. By Jonathan Rosenberg (dynamicsoft); WWW. IETF SIMPLE Working Group, Internet-Draft. Reference: 'draft-rosenberg-simple-xcap-list-usage-00'. May 26, 2003, expires November 24, 2003. 20 pages.

  Abstract: "This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating lists of presentities (also known as buddy lists or rosters). It does so by specifying an XML Schema that contains a list of presentities that a user is interested in watching."

• A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Documents. By Jonathan Rosenberg (dynamicsoft); WWW. IETF SIMPLE Working Group, Internet-Draft. Reference: 'draft-rosenberg-simple-xcap-package-00'. May 26, 2003, expires November 24, 2003. 18 pages.

  Abstract: "This specification defines a Session Initiation Protocol (SIP) event package for finding out about changes to documents managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to manipulate XML documents on a server which contain configuration information for application protocols. Multiple clients can potentially access the same document, in which case the other clients would like to be notified of a change in the document made by another. This event package allows a client to do that."

About the IETF SIMPLE Working Group

"The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) working group "focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group."

"As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard."

"The primary work of this group is to generate:

1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM, and in BCP 41, so that the transport implications of the extension with respect to network congestion are considered in the design.
2. A proposed standard SIP event package and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM.
3. An architecture for the implementation of a traditional buddylist-based instant messaging and presence application with SIP, including for example new mechanisms for message confirmation delivery, indications for when a party is in the process of typing a message, secure buddylist manipulation operations, and the extension of the CPIM presence format to describe typical IM states..." [from the Charter]