The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
Extracted elements (27)
Application usage schemas SHOULD include a unique index attribute on any element that can repeat within a parent, because without one only positional selection is available—requiring clients to cache the full document to construct predicates. URIs make good indexes but XCAP matches them by lexical string equality, not functional URI equivalence, which application usages must account for.
Schemas SHOULD be designed so that common operations require a single HTTP request. When a design forces two sequential PUTs (e.g., remove from old permission list, add to new one), it introduces failure windows where another client's interleaving modification can corrupt state and force the client to undo prior changes using entity tags.
XCAP maps XML document sub-trees directly to HTTP URIs rather than defining a new protocol, so existing HTTP infrastructure (proxies, caches, conditional requests, authentication) can be reused. The canonical form with comments of XML determines logical equivalence, ensuring consistent semantics regardless of physical serialization differences such as attribute ordering.
The node selector is syntactically a valid XPath 1.0 expression, but XCAP uses XPath 2.0-style namespace expansion: unprefixed attribute QNames are in no namespace, and the default document namespace applies only to unprefixed element names. Each step must resolve to exactly one element, which is more restrictive than general XPath multi-node contexts. Namespace declarations within elements cannot be used as attribute predicates (e.g., '@xmlns=...' never matches).
A server MUST allow documents that contain elements from namespaces unknown to the server; it cannot schema-validate such content and will only verify that the XML is well-formed.
All application usages MUST define a default document namespace URI used when evaluating XCAP URIs. This default applies only to URI evaluation, not to namespace resolution within XML documents themselves.
All XCAP documents MUST be encoded using UTF-8. This constraint cannot be overridden by an application usage.
All XCAP servers MUST implement HTTP Digest authentication and HTTP over TLS (RFC 2818). It is RECOMMENDED that administrators configure an HTTPS URI as the XCAP root URI so that digest client authentication occurs over TLS.
An application usage specification MUST document: AUID, XML schema, default document namespace, MIME type, validation constraints, data semantics, naming conventions, resource interdependencies, and authorization policies.
An XCAP server MUST be explicitly configured for each application usage it handles. If the URI refers to an unknown application usage, an unrecognized XUI, or an unsupported extension-selector, the server MUST reject the request with 404 (Not Found).
For SIP-based systems, it is RECOMMENDED that the XUI equal the user's Address-of-Record (AOR). A SIP User Agent SHOULD assume its XUI equals its AOR if no XUI is explicitly provisioned, since SIP URI characters not allowed in HTTP path segments (such as '?' and '/') MUST be percent-encoded.
POST operations against HTTP URIs representing XCAP resources are not defined. XCAP resources are not processing scripts; an XCAP server MUST return an appropriate error for POST requests directed at XCAP resources.
When creating or replacing an XML element, the PUT request MUST carry Content-Type 'application/xcap-el+xml'. When creating or replacing an attribute, the request MUST carry Content-Type 'application/xcap-att+xml'. Document-level PUTs MUST use the MIME type defined by the application usage.
XCAP clients MUST NOT depend on servers to maintain referential integrity. Clients are responsible for making all appropriate document changes to preserve referential integrity across XCAP resources.
XCAP PUT and DELETE requests MUST satisfy GET(PUT(x))==x idempotency: the URI in a PUT must select the resource just inserted, and a DELETE URI must match nothing after deletion. The server rejects violations with 409 and a 'cannot-insert' error condition.
An XCAP URI is constructed by concatenating the XCAP root URI, a document selector, the node selector separator ('~~'), a percent-encoded node selector, and an optional query component containing xmlns() namespace bindings. The node selector separator SHOULD NOT itself be percent-encoded; %7E%7E and ~~ are equivalent.
Conditional PUT and DELETE operations use HTTP If-Match / If-None-Match headers with entity tags. All resources within a single XML document share the same entity tag; the Etag returned in a successful PUT or DELETE response reflects the updated document-level entity tag, enabling cache synchronization without a separate GET.
Namespace bindings for node selector evaluation are encoded in the URI query component as xpointer xmlns() expressions (e.g., '?xmlns(a=urn:test:ns)'). If no query component is present, only the application usage's default document namespace is defined. A server MUST ignore xpointer expressions not from the xmlns() scheme.
The document selector begins with the AUID, followed by either 'global' or 'users'. Under 'users', the next path segment MUST be the XUI (percent-encoded if necessary). The final path segment identifies the document. Subdirectories are permitted but NOT RECOMMENDED; there MUST NOT be a document with the same name as a sub-directory.
The node selector grammar selects a single XML element, attribute, or namespace bindings via steps that match by expanded element name (by-name), position predicate (by-pos), attribute value predicate (by-attr), or combinations. Each intermediate step MUST resolve to exactly one element. The terminal selector may be an attribute selector ('@att-name') or namespace selector ('namespace::*').
The XCAP Capabilities application usage (AUID: xcap-caps, MIME type: application/xcap-caps+xml) allows a client to query which application usages and extensions a server supports by performing a GET on the global tree of the xcap-caps application usage.
When a server rejects a PUT with 409 (Conflict), it MAY return an application/xcap-error+xml body (namespace urn:ietf:params:xml:ns:xcap-error) providing a structured error element. Defined error types include 'schema-validation-error', 'cannot-insert', 'uniqueness-failure', 'constraint-failure', 'not-xml-frag', 'not-xml-att-value', 'no-parent', and 'not-well-formed'.
XCAP defines positional insertion by constructing a node selector of the form 'parent/*[position][@attr=value]'. The attribute predicate ensures the selector is a no-match against the current document (triggering creation), while it would match the new element after insertion. Positional deletion without a unique attribute predicate is allowed only when the target element is the last among its siblings.
Five MIME types are registered: application/xcap-el+xml (XML element body), application/xcap-att+xml (XML attribute value), application/xcap-ns+xml (namespace bindings), application/xcap-error+xml (conflict/error responses), and application/xcap-caps+xml (server capabilities). Two URN sub-namespaces are also registered: urn:ietf:params:xml:ns:xcap-error and urn:ietf:params:xml:ns:xcap-caps.
IANA creates an 'XCAP Application Unique IDs' registry. AUIDs in the IETF namespace are registered by publication of a standards-track RFC per the guidelines in Section 15. Vendor-proprietary AUIDs use a reverse-domain-name prefix (e.g., 'com.example.foo') and do not require IANA registration.
The default authorization policy permits each user to read, modify, and delete only the documents under their own home directory. Any user may read documents in the global tree, but only explicitly provisioned trusted users may modify global documents. Application usages may override this default.
XCAP data typically contains sensitive per-user configuration such as presence authorization policies and contact lists. Servers MUST implement both HTTP Digest and HTTPS/TLS; deploying an HTTPS XCAP root URI is strongly recommended to protect credentials and user data in transit.