An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package
Extracted elements (26)
Reliable transfer of NOTIFY messages is required because out-of-order events would cause document state divergence and subsequent patches would fail or have unintended consequences. This is why the notifier must wait for 200-OK before sending the next NOTIFY.
The 'xcap-patching' mode preserves the full HTTP ETag change history while 'aggregate' optimizes bandwidth by collapsing multiple version transitions into one. However, 'aggregate' mode can cause initial synchronization failures with rapidly changing resources because base XCAP does not support document version history retrievals.
The XCAP server will usually be co-located with the SIP notifier, so the subscriber MAY use relative XCAP Request-URIs. Because relative Request-URIs are allowed, the notifier MUST know how to resolve these against the correct XCAP Root URI value.
To avoid initial sync difficulties with 'aggregate' mode, subscribers MAY start the subscription with 'xcap-patching' mode, then refresh with 'aggregate' after initial sync is achieved. A subscriber can revert between modes at any time.
A notifier MUST NOT send a new NOTIFY request to the same dialog unless a successful 200-response has been received for the last sent NOTIFY request. If the NOTIFY request fails due to a timeout, the notifier MUST remove the subscription.
During unconditional re-subscriptions, the subscriber MUST stamp the received state of all previous resources as stale. If a conditional re-subscription is successful, the subscriber MUST preserve the current state of resources unless the subscribed URI list has changed.
Each URL in the subscription body MUST be an HTTP URL that identifies a collection, an XCAP document, or an XCAP component. Collection URLs MUST have a trailing forward slash '/', and the client MUST NOT subscribe to namespaces.
If a diff format cannot be applied due to patch processing or programming errors, the subscriber SHOULD refresh the subscription and disable patching by setting 'diff-processing' to 'no-patching'. The subscriber SHOULD NOT reply with a non-200 response since the notifier cannot make corrections.
If the subscription does not contain the 'diff-processing' header field parameter, the notifier MUST default to the 'no-patching' mode.
In all modes, the notifier MUST maintain the chronological order of XCAP changes. If several changes to a given resource are presented in a single notification, the chronological update order MUST be preserved in the XML document order of the notification body.
Notifiers MUST be aware of XCAP Default Document Namespaces for Application Usages when they locate unprefixed qualified XCAP elements. Namespace prefixes of XCAP Node Selectors in SUBSCRIBE bodies MUST be properly resolved to namespace URIs per RFC 4825.
Notifiers MUST support the 'no-patching' mode as a baseline for interoperability. The 'xcap-patching' and 'aggregate' modes are optional but SHOULD be supported.
Notifiers of an 'xcap-diff' event package SHOULD NOT generate notifications for a single subscription at a rate of more than once every five seconds.
The notifier MUST NOT use a more complex diff-processing mode than the one chosen by the subscriber. From least to most complex: 'no-patching', 'xcap-patching', 'aggregate'. The notifier may respond to an 'aggregate' request using any mode, but cannot reply to an 'xcap-patching' subscription using the 'aggregate' mode.
The notifier MUST support XCAP component subscriptions, and the first NOTIFY MUST contain the URLs of the documents and XCAP component contents that are part of the subscription.
The 'sel' selector values of the XCAP diff format MUST be octet-by-octet equivalent to the relevant 'uri' parameter values of the <entry> element of the 'resource-list' document, except for collection selections.
The subscriber MUST NOT use hierarchical lists or <entry-ref> references in the SUBSCRIBE body. If the subscription body contains elements or attributes the notifier does not understand, the notifier MUST ignore them.
This specification allows only a single dialog to be constructed from an initial SUBSCRIBE request. If the subscriber receives forked responses to a SUBSCRIBE, the subscriber MUST apply the procedures in Section 4.4.9 of RFC 3265 for handling non-allowed forked requests.
When the notifier receives a re-subscription, it MUST re-send the current full XML diff content unless the subscriber has requested a conditional subscription (RFC 5839) using the Suppress-If-Match header field. If a match to the previous state is not found, the NOTIFY MUST contain the full XML diff state.
The 'diff-processing' Event header field parameter allows subscribers to indicate a preference for how the notifier signals document change notifications. Possible values are 'no-patching', 'xcap-patching', and 'aggregate', with formal ABNF grammar defined. This parameter is a subscriber hint; the notifier may respond using a simpler mode but MUST NOT use a more complex one.
The event package name is 'xcap-diff'. This value appears in the Event header field present in SUBSCRIBE and NOTIFY requests, as specified by RFC 3265.
The NOTIFY body format is 'application/xcap-diff+xml' (default) or a format listed in the SUBSCRIBE Accept header. The XCAP diff format can include subscribed XCAP component contents, document URIs, ETag values, and XML-Patch-Ops patching instructions.
The SUBSCRIBE body is an XCAP resource-list document (application/resource-lists+xml) containing a flat list of XCAP request URIs as <entry> elements. Subsequent SUBSCRIBE refreshes MAY change the URI list, in which case the notifier MUST use the new list.
IANA registered a new event package 'xcap-diff' of type 'package' in the SIP Event Types Namespace registry, with contact IETF Real-time Applications <[email protected]> and reference RFC 5875.
Notifiers MUST authenticate 'xcap-diff' event package subscribers using normal SIP authentication mechanisms (e.g., Digest per RFC 3261 Section 22). Notifiers MUST be aware of XCAP User Identifiers (XUI) and how to unambiguously map authenticated SIP identities to XUIs. Notifiers MUST obey XCAP authorization rules when signalling resource changes, meaning a resource for which an authenticated user does not have read privilege MUST NOT be included in the XCAP diff format.
The mechanism used for conveying xcap-diff event information MUST ensure integrity and SHOULD ensure confidentiality. End-to-end S/MIME SHOULD be used; if unavailable, TLS between elements is RECOMMENDED for hop-by-hop authentication and encryption. Denial-of-service risks include subscriptions to long URI lists, pending subscriptions to non-existent components, and extreme diff-generation optimization algorithms.