Publication of Partial Presence Information
Extracted elements (19)
The compositor does not keep a record of applied patches, so there is no rollback to an earlier version when a partial publication expires; instead, the entire full state is cleared. This simplifies compositor state management at the cost of requiring a new full-state publication after expiry.
The partial PIDF format (RFC 5262) contains a 'version' attribute that could serve for versioning, but the RFC deliberately chose not to introduce an additional versioning mechanism. Using both entity-tags (from RFC 3903) and the PIDF version attribute would add ambiguity and a potentially undefined error case if the two mechanisms contradicted each other.
Server support for partial publication can be discovered by the PUA either via an explicit OPTIONS query (checking the Accept header in the response) or by trial-and-error after receiving a 415 error response to an attempted partial publication.
Entities supporting the partial publication extension MUST support the 'application/pidf-diff+xml' content type defined in RFC 5262, in addition to the baseline 'application/pidf+xml' content type.
For a modifying publication containing <pidf-diff>, the compositor MUST apply the included patch operations in sequence against its locally stored presence document. If the publication is an initial publication with <pidf-diff>, it MUST be rejected with an appropriate error response such as 400 (Invalid Partial Publication).
If a publication carrying partial presence information expires without the PUA refreshing it, the compositor MUST clear the entire full state publication (no rollback to earlier versions).
If any other errors are encountered before the entire partial publication (including all patch operations) is completely processed, the compositor MUST reject with 500 (Server Internal Error) and revert to its original locally stored presence information.
If errors are encountered before the entire <pidf-full> publication is completely processed, the compositor MUST reject the request with a 500 (Server Internal Error) response and revert to its original locally stored presence information.
If the compositor encounters errors while processing the 'application/pidf-diff+xml' document, it MUST reject the request with a 400 (Bad Request) response, and MAY include diagnostics in the body using error condition elements from RFC 5261 Section 5.1.
If the initial PUBLISH request returns a 415 (Unsupported Media Type), the PUA MUST follow normal procedures for handling a 400-class response per RFC 3261 Section 8.1.3.5, and SHOULD retry the publication using the default 'application/pidf+xml' content type.
If the size of the delta state becomes more than the size of the full state, the PUA SHOULD instead send a modifying publication carrying full state, unless this size comparison is not possible.
The PUA SHOULD batch several patch operations in a single PUBLISH request to reduce unnecessary network traffic.
To construct a full-state publication, the Content-Type header field in the PUBLISH request MUST be set to 'application/pidf-diff+xml', and the body MUST be populated with a <pidf-full> root element including the 'entity' attribute.
To construct a partial publication, the Content-Type MUST be 'application/pidf-diff+xml', the body MUST use a <pidf-diff> root element with the 'entity' attribute, and patch operations MUST be constructed in sequence as defined in RFC 5262.
When processing a <pidf-full> document, the compositor MUST take the received presence document as the local presence document, replacing any previous publications.
The compositor maintains a per-resource record for each publication indexed by entity-tag. The entity-tag is assigned by the compositor and returned in the response; the PUA uses the SIP-If-Match header with this entity-tag to identify which publication a modifying request targets.
The partial publication mechanism uses the 'application/pidf-diff+xml' content type (RFC 5262) with two root elements: <pidf-full> for full-state publications and <pidf-diff> for state-delta publications. The initial publication always carries full state via <pidf-full>; modifying publications may use either.
The <pidf-diff> element contains patch operations: <add> for adding new elements or attributes, <replace> for replacing changed elements or attributes, and <remove> for indicating removal of elements or attributes.
This specification relies entirely on the security model of RFC 3903 (SIP Event State Publication). All security considerations identified in RFC 3903 apply in entirety; this specification adds no new security considerations.