This document describes an "xcap-diff" SIP event package, with the aid
of which clients can receive notifications of the partial changes of
Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
resources. The initial synchronization and document updates are based
on using the XCAP-Diff format. XCAP (RFC 4825) is a protocol that
allows clients to manipulate XML documents stored on a server. These
XML documents serve as configuration information for application
protocols. As an example, RFC 4662 resource list subscriptions (also
known as presence lists) allow a client to have a single SIP subscription
to a list of users, where the list is maintained on a server. The server
will obtain presence for those users and report it back to the client.
Another specification, "Extensible Markup Language (XML) Document Format
for Indicating a Change in XML Configuration Access Protocol (XCAP)
Resources" defines a data format which can convey the fact that an XML
document managed by XCAP has changed. This data format is an XML document
format, called an XCAP diff document. This format can indicate that a
document has changed, and provide its previous and new entity tags. It
can also optionally include a set of patch operations which indicate
how to transform the document from the version prior to the change, to
the version after it. As defined in this XCAP Diff Event Package memo,
an "XCAP Component" is an XML element or an attribute, which can be
updated or retrieved with the XCAP protocol. "Aggregating" means that
while XCAP clients update only a single XCAP component at a time, several
of these modifications can be aggregated together with the XML-Patch-Ops
semantics. When a client starts an "xcap-diff" subscription it may not
be aware of all the individual XCAP documents it is subscribing to.
This can, for instance happen when a user subscribes to his/her
collection of a given XCAP Application Usage where several different
clients update the same XCAP documents. The initial notification can
give the list of these documents which the authenticated user is allowed
to read. The references and the strong ETag values of these documents
are shown so that a client can separately fetch the actual document
contents with the HTTP protocol. After these document retrievals, the
subsequent SIP notifications can contain patches to these documents by
using XML-Patch-Ops semantics. While the initial document synchronization
is based on separate HTTP retrievals of full documents, XML elements
or attributes can be received "in-band", that is straight within the
'xcap-diff' notification format.
No comments:
Post a Comment