Common Profile for Presence (CPP)
Extracted elements (21)
CPP defines an abstract interoperability layer so that gateways between diverse presence protocols can carry a common payload without each protocol needing direct knowledge of the others. The choice of concrete encoding strategy (key/value, binary, nested containers) is left to each presence service, as long as the abstract operations are faithfully realized.
CPP deliberately defines only minimum-necessary attributes for interoperability; presence protocol functions corresponding to CPP operations may carry additional information that will not be mapped by CPP gateways. This minimalism allows diverse protocols to comply without constraining their richer native feature sets.
The subscription-identifier (SubscriptID) is potentially long-lived, so its values should be intrinsically globally unique over time — not merely unique among operations sent to or from a particular WATCHER and PRESENTITY pair. This prevents collisions across the lifetime of a presence service.
Address mappings that place special information into the pres: address local-part MUST use the meta-syntax defined in RFC 2846. Source-route mapping (placing the original address into the local part and naming the gateway in the domain part) is technically viable but has a history of operational problems and should be hidden from end-users.
CPP assumes that compliant presence protocols provide reliable message delivery; there are no application-layer message delivery assurance provisions in the CPP specification itself.
Applications that send notification operations through a CPP gateway MUST support the PIDF format (RFC 3863) in order to maintain end-to-end security properties. Applications MAY support other content formats.
Certificates used for S/MIME presence operations SHOULD contain a subjectAltName field with the PRES URI of their subject, for reference integrity purposes. Such certificates may also contain other identifiers specific to particular presence protocols.
Compliant implementations SHOULD follow the guidelines for dereferencing URIs given in RFC 3861 to determine the next hop for forwarding an operation, by resolving the domain name portion of the service destination.
CPP gateways MUST be capable of relaying the body of a notification operation between supported presence protocols without needing to modify or inspect the content.
When end-to-end security is required, the notify operation MUST use PIDF, and MUST secure the PIDF MIME body with S/MIME using encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS SignedData).
PRESENTITIES and WATCHERs are both identified using the PRES URI scheme, e.g., 'pres:[email protected]'. There is no distinct identifier type for watchers versus presentities.
SUBSCRIBE 0 with an existing SubscriptID terminates a subscription (there is no independent UNSUBSCRIBE operation). SUBSCRIBE 0 with a new SubscriptID performs a one-time fetch of presence information (there is no independent FETCH operation). In both cases a notify is generated and may be discarded by the watcher.
The notify operation has three attributes (watcher, target, TransID) plus content (PRESENCE INFORMATION). The watcher and target values are identical to those in the triggering subscribe operation. There is no application response to the notify operation defined in CPP.
The response operation has three attributes: status (success or failure), TransID (matching the subscribe operation's TransID), and duration (actual seconds the subscription will be active, which may differ from the requested duration).
The subscribe operation has five attributes: watcher (identifier of the WATCHER), target (identifier of the PRESENTITY), duration (maximum seconds the subscription should be active, may be zero), SubscriptID (reference to the subscription used for unsubscribing), and TransID (unique correlation identifier). Gateways MUST handle TransIDs and SubscriptIDs up to 40 bytes in length.
IANA has assigned the 'pres' URI scheme for designating an Internet resource that is a PRESENTITY or WATCHER. The scheme is registered under the IETF tree with IETF maintaining change control.
CPP gateways MUST be compliant with the minimum security requirements of all presence protocols with which they interface. The introduction of gateways creates new risks: end-to-end confidentiality and integrity can only be preserved if a common presence format (PIDF) is supported by all interfacing protocols.
Implementations MAY use AES as an encryption algorithm but are REQUIRED to support only the baseline algorithms mandated by S/MIME and CMS. AES is preferred as it best suits the capabilities of many platforms.
Subscribe flow: application sends subscribe → service responds with response (success/failure) → on success, service immediately sends notify → for non-zero duration, service sends notify on each presence change until duration expires. Cancellation: application sends subscribe with duration=0 and existing SubscriptID → triggers a final notify (which watcher may discard) → service responds.
Subscribe operation processing: (1) invalid watcher/target → failure response; (2) access control denies → failure response; (3) non-zero duration with duplicate in-progress subscription → failure response; (4) otherwise → success response + immediate notify + continued notifies for subscription duration on presence changes.
The PRES URI syntax follows mailto: URI syntax (RFC 2368). ABNF: PRES-URI = 'pres:' [ to ] [ headers ]; to = mailbox (RFC 2822 encoded mailbox); headers = '?' header *('&' header); header = hname '=' hvalue where hname and hvalue are *uric (any URL-valid character per RFC 2396).