An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents
Extracted elements (17)
Multiple XCAP clients (on different physical devices) may manipulate the same presence document on the XCAP server, but this still produces only one input to the event state compositor, distinguishing XCAP-based manipulation from per-PUA SIP PUBLISH soft state.
PIDF is chosen as the presence document format because the event state compositor already must support it for SIP PUBLISH, avoiding the need for a separate format.
SIP PUBLISH creates soft state that expires after a negotiated lifetime, making it unsuitable for presence state that should persist without active devices. XCAP is chosen as a complementary mechanism for device-independent, permanent presence state manipulation.
Three use cases motivate persistent XCAP-based presence: (1) person-related state during periods with no active devices (e.g., vacation), (2) advertising always-available services like email/MMS/SMS without requiring a constantly-active publishing device, and (3) setting default state in the absence of any actively-publishing device.
XCAP-based presence state and SIP PUBLISH-based presence state are completely separated as individual inputs to the event state compositor; how the compositor combines them is a matter of compositor policy outside the scope of this specification.
Since the SIP PUBLISH specification already requires the event state compositor to construct overall presence state from multiple (potentially non-orthogonal or conflicting) inputs, adding XCAP-based input imposes no new requirements on compositor functionality.
It is RECOMMENDED that administrators of XCAP servers use an HTTPS URI as the XCAP root services' URI so that digest client authentication occurs over TLS.
The presence document MUST be located under the 'users' tree, using filename 'index' (e.g., http://xcap.example.com/pidf-manipulation/users/sip:[email protected]/index).
The XCAP server MUST store only a single XCAP manipulated presence document for each user.
XCAP servers MUST implement HTTP Digest authentication (RFC 2617) and MUST implement HTTP over TLS (RFC 2818), per the XCAP base specification, to ensure confidentiality and integrity of presence document manipulation operations.
The authorization policy defaults to allowing only the document owner (user) to read, write, or modify their own presence document. Privileged-user access policies are outside the scope of this specification.
The MIME type for the pidf-manipulation XCAP application usage is 'application/pidf+xml', consistent with the PIDF document format.
The XCAP Application Usage ID (AUID) for this usage is 'pidf-manipulation', registered in the IETF tree. It uniquely identifies this XCAP application usage for manipulating PIDF-based presence documents.
The XCAP-manipulated presence document is stored under the 'users' tree in the XCAP document hierarchy and serves as a single, persistent input to the event state compositor, separate from soft state published via SIP PUBLISH.
The XML schema for manipulated presence information is defined by PIDF (RFC 3863). The XCAP default document namespace is 'urn:ietf:params:xml:ns:pidf'. PIDF extensions (RPID, CIPID, timed presence, UA capabilities) may also be used.
This document registers a new XCAP Application Usage ID (AUID) named 'pidf-manipulation' in the IANA XCAP AUID registry. It defines how XCAP is used to manipulate the contents of PIDF-based presence documents.
A presence document may contain highly sensitive information; only authorized clients must be able to manipulate it, and its delivery to watchers must follow relevant authorization policies.