An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources
Extracted elements (28)
Content indirection (RFC 4483) was considered but rejected as the basis for change notifications because it uses a MIME Content-ID rather than an HTTP entity tag, making it impossible for clients to determine whether a reported change was caused by their own prior operation or by another concurrent XCAP client. The XCAP diff format exposes previous- and new-ETags explicitly to address this.
Requiring multiple <document> elements for the same document to be applicable in document order (rather than requiring clients to sort them) is a deliberate simplification to reduce implementation complexity in diff clients.
XML canonical form with comments (W3C C14N) is specified as the basis for determining logical equivalence when patching locally cached XCAP documents, because XML documents that are application-equivalent may differ in physical representation.
Patch operation elements <add>, <replace>, and <remove> reuse the corresponding types defined in RFC 5261. Namespace resolving rules for these elements follow Section 4.2.1 of RFC 5261.
The 'sel' attribute of <element> and <attribute> elements uses XCAP Node Selector conventions (Section 6.4 of RFC 4825) including namespace prefix resolution rules; without a namespace prefix in an element selector, the XCAP Default Document Namespace MUST be applied.
A diff client MUST apply a resource state change only if entity tag values match with octet-by-octet equivalence per the state table. If inconsistencies or errors are noticed, the diff client SHOULD tear down the session.
A diff notifier MAY skip intermediate document versions (e.g., for rapidly changing resources) but MUST always report changes consistently so the diff client can correctly update the latest state (content and ETag) of locally cached resources.
All namespace declarations needed by a located XML element MUST exist within the xcap-diff document. Namespace prefixes of QNames remain as in the source XCAP document.
Diff notifiers MUST obey XCAP authorization rules by following read privilege rules when notifying authenticated diff clients of changes. Transport SHOULD be secured by encryption.
If the change being reported is removal of a document, only the 'previous-etag' attribute MUST be included and the 'new-etag' attribute MUST NOT be present in the <document> element.
Multiple <document> elements referencing the same document MUST be applicable in the document order given; patches MUST be applied in that order, eliminating any need for clients to sort them.
State changes of an XCAP document MUST be delivered reliably from diff notifier to diff client in chronological order. If an XCAP diff delivery is lost, the diff session MUST be torn down.
The XCAP Node Selector in the 'sel' attribute of <element> MUST always locate a unique node. When the located element content cannot be presented (e.g., payload too large), the <element> element MUST NOT have any child nodes.
Unknown extension elements or attributes in places where the XML schema allows them MUST be ignored by the diff client, enabling forward-compatible extensibility.
When the XCAP diff format is transported via the SIP event package, end-to-end S/MIME SHOULD be used. If unavailable, TLS between elements is RECOMMENDED for hop-by-hop authentication and encryption.
When using an unreliable transport with retransmissions, the application protocol MUST ensure that duplicate XCAP diff deliveries are dropped.
XCAP diff documents MUST be well-formed XML and SHOULD be valid per the schema. They MUST be based on XML 1.0 and MUST be encoded using UTF-8.
The <attribute> element reports the existing value of an XCAP document attribute. It has a mandatory 'sel' attribute (percent-encoded relative URI) and an optional boolean 'exists' attribute; its text node child carries the attribute value.
The <body-not-changed> element inside a <document> element indicates that only the ETag changed but document content is semantically unchanged. It is mutually exclusive with patch operation elements (<add>, <replace>, <remove>).
The <document> element reports changes to a specific XCAP document. It has one mandatory attribute 'sel' (relative path reference from xcap-root) and two optional attributes 'new-etag' and 'previous-etag' (strings) representing the entity tags after and before the change respectively.
The <element> element reports the existing content of an XCAP document element. It has a mandatory 'sel' attribute (percent-encoded relative URI) and an optional boolean 'exists' attribute; absence of 'exists' implies the element is present, and its child is the located XML element.
The root element <xcap-diff> carries a mandatory 'xcap-root' attribute (anyURI) identifying the XCAP root URI for all changed documents reported in the document. A single XCAP diff document can only represent changes within one XCAP root.
Registers the 'application/xcap-diff+xml' MIME type for XCAP diff documents. The optional charset parameter and encoding considerations follow application/xml (RFC 3023). File extension is '.xdf'.
Registers the XML namespace URN 'urn:ietf:params:xml:ns:xcap-diff' per RFC 3688 for identifying XCAP diff documents and their elements.
Registers the XML schema URI 'urn:ietf:params:xml:schema:xcap-diff' per RFC 3688; the schema content is the normative XML Schema defined in Section 4 of this document.
Very frequent XCAP document updates and/or many diff clients per subscribed resource create a Denial-of-Service attack surface on servers processing XCAP diff documents. Efficient patch processing and throttling are recommended mitigations.
XCAP diff documents convey document content changes; if the underlying XCAP document requires confidentiality, integrity, or authentication, the same requirements apply to the diff format and its transport. Confidential XCAP documents are typically protected by TLS per RFC 4825.
The <document> element state table encodes five distinct resource-change semantics via presence/absence of 'previous-etag', 'new-etag', and patch children: (a) patch included, (b) patch omitted/external retrieval, (c) ETag-only change via <body-not-changed>, (d) resource created, (e) resource removed (only 'previous-etag' present).