Chapter 17 - Service Configuration on the Internet pdf

Chapter 17
Service Configuration on the
Internet
Many services require a mechanism for allowing users to manage their service configuration.
For example, a presence server requires presentities (users) to authorize which watchers can
see their presence information. A Push-to-talk over Cellular (PoC) service requires users to
create and manage groups. Likewise a conference may require users to configure a dial-out
or dial-in list o f participants, their privileges (who can speak or who can send or receive
which media type), and so on. All of th ese use cases share many commonalities: a user has
to perform non-real-time operations on a server to manipulate one or more documents that
configure or personalize their instance of the service.
Usually the user creates a configuration document locally in their terminal and then
uploads it to a server. Sometimes, the user just needs to make a small change to an existing
document, so it is not worth uploading the complete document. Instead, it is desireable to
have the capability to update part of the documen t. In some other cases the user changes their
usual terminal and uses a different one, so they may first need to download a fresh copy of
the current configuration document, make some changes, and upload it (either complete or a
part of it) to the ser ver.
Typically, configuration documents are highly structured. Owing to this, the trend
nowadays is to use the Extensible Markup Language (XML) (specified by the World Wide
Web Consortium in the W3C recommendation XML 1.1 [93]), for formatting documents that
personalize the instance of the service.
So, we know that configuration documents are effectively XML documents, but how are
they sent to and received from the server that stores them? The XML Configuration Access
Protocol (XCAP) solves this vacuum.
17.1 The XML Configuration Access Protocol (XCAP)
The problem of document management can be depicted in its most simplified way as in
Figure 17.1. A user creates an XML document in h is computer and wants to upload it to a
server. The server will use the document at a later time to produce a personalized instance of
the service.
The problem to be solved requires designing a protocol that allows such an upload

procedure. HTTP (specified in RFC 2616 [144]) provides a good baseline, since it provides
´ıa- M ar t´ın
The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition
Gonzalo Camarillo and Miguel A. Garc
© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1
372
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
server
Terminal
Figure 17.1: Overview of Document Management
the POST and PUT methods for transferring files from the client to the server. It also contains
a GET method for downloading a document from the server. However, there are additional
requirements that prevent the usage of HTTP. For example, on many occasions users just
need to modify a sm a ll piece of an existing XML document. For instance, when a u ser wants
to add a “buddy” to his list o f friends in the presence service: the user just wants to edit a few
bytes of a potentially large document. It is not worth uploading the whole XML document
again, since the document is mostly unchanged, just the modified content. HTTP alone does
not offer that functionality.
The IETF decided then to develop a set of conventions and rules for using HTTP to upload
and download complete or portions of XML documents to and from a server. This resulted in
the creation of XCAP (specified in RFC 4825 [277]). XCAP is, therefore, not a new protocol,
but a set of conventions for using HTTP for managing remotely stored XML documents.
Figure 17.2 shows a schematic representation of the protocol stack used by XCAP.
HTTP
TCP
XCAP
IP
Figure 17.2: The XCAP protocol stack
XCAP provides a client with the means to read, write, and modify XML application
configuration data remotely stored on a server. This includes, for example, modifying the list

of users in a presence list, authorization policies (e.g., a list of authorized watchers) or the list
of participants in a conference. XCAP does not control the user interface (e.g., the graphical
representation of the list), rather, it focuses on the data structure.
XCAP defines conventions that map XML documents and their components (e.g.,
elements, attributes) to HTTP URIs. Therefore, XCAP provides a unique way to represent an
XML document or a component with an HTTP URI. It also defines the rules that govern how
17.1. THE XML CONFIGURATION ACCESS PROTOCOL (XCAP)
373
modification of one resource affects another. This means that XCAP allows users to modify
an XML document, but still the resulting document has to be compliant with the or iginal
XML schema. In addition, XCAP also defines the basic authorization policies associated
with access to resources.
XCAP implements a set of operations that are mapped to regular HTTP 1.1 methods. The
operations also set some HTTP headers to a particular value. XCAP provides the client with
the operations that can manipulate the whole XML document, an arbitrary XML element of
the document, or an arbitrary XML attribute of an element. For each of these levels, XCAP
provides the means for creating, deleting, modifying, replacing, and fetching. So combining
all together, XCAP provides the means to create, delete, modify, replace or fetch a complete
XML document, an element, or an attribute.
Figure 17.3 shows an example of an XCAP request in which Alice is sending an HTTP
PUT request to create a new presence list. We provide details of how to manipulate presence
lists in Chapter 19. For the time being, just notice that XCAP is merely HTTP and XML with
some additional rules. We are going to describe the basics of XML in Section 17.2.
PUT /pr-lists/users/sip:/friends.xml HTTP/1.1
Host: xcap.example.com
Content-Type: application/resource-lists+xml
Content-Length: 460
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists
xmlns="urn:ietf:params:xml:ns:resource-lists">

<list name="family" uri="sip:">
<entry name="Bob" uri="sip:">
<display-name>Bob</display-name>
</entry>
<entry name="Cynthia" uri="sip:">
<display-name>Cynthia</display-name>
</entry>
</list>
</resource-lists>
Figure 17.3: Example of an XCAP operation
XCAP defines two functional elements: an XCAP client and an XCAP server. They
are depicted in Figure 17.4. An XCAP client is an HTTP 1.1 compliant client that supports
the rules and conventions specified by XCAP; it sends HTTP requests and receives HTTP
responses. An XCAP server is an HTTP 1.1 compliant server that also supports the rules and
conventions specified by XCAP; it receives HTTP requests and generates HTTP responses.
17.1.1 XCAP Application Usage
As explained in the previous section, XCAP is a generic protocol that can be used for a
number of purposes related to application data configuration of XML documents stored in a
server. We have also seen that there are a several applications that utilize XCAP. For example,
in the pre sence service, presentities use XCAP to con trol whether watchers can see all
374
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
Figure 17.4: XCAP functional elements
or part of the presence information (watcher authorization is described in greater detail in
Section 19.14). In a centralized conference service, the creator of a dial-out conference can
use XCAP to configure the list of participants of the conference. In general, whenever there
is a need to configure configuration application data, such as a list r emotely stored in XML
format, XCAP is a good protocol to fulfill these needs.
Owing to this versatility XCAP introduces the concept of an application usage.An
application usage defines how a particular application uses XCAP to interact with the XCAP

server. For instance, each of the p reviously mentioned applications of XCAP (presence
list m anagement, authorization policies, and conference list management) constitutes an
application usage on its own. Each application usage is identified by an AUID (Application
Unique ID) that uniquely identifies the application usage. There are two types of AUIDs:
standard (i.e., application usages standardized in the IETF) and vendor-proprietary (i.e.,
private application usages).
The IETF has defined a number of XCAP application usages related to the presence
service.
XCAP application usage for resource lists. Specified in RFC 4826 [273], provides the
means to manipulate r esource lists that are typically used as presence lists.
XCAP application usage for presence authorization. Defined in RFC 5025 [276], allows
a client to specify presence authorization rules, i.e., the set of rules that grants
certain watchers the permissions to access certain subsets of the presentity’s presence
information.
XCAP application usage for manipulating presence documents. Specified in RFC 4827
[175], allows users to perform hard state manipulation of presence data, i.e., set
the presence status by configuration (i.e., using XCAP), as opposed to the soft state
manipulation performed through the more common presence publication, i.e., using
the SIP PUBLISH method.
17.2 An Overview of XML
XML documents constitute a very important aspect for configur ing applications. Usually,
the application configuration data are stored in XML format, therefore, XML documents (or
portions of them) are transported between the client and the server. While there is extensive
literature on XML, we provide a high-level overview that allows readers to better understand
the p rotocol used for manipulating XML documents.
17.2. AN OVERVIEW OF XML
375
XML documents are text-based documents and, thus, are human-readable. XML
documents contain a structured representation of data, but the document itself does not do
anything. Therefore, an XML document merely provides the means to represent structured

data.
The XML document in Figure 17.5 contains the representation of the data pertaining to
the second edition of this book, which we assume is stored in a file named ims.xml.Let
us use this example to further illustrate a few concepts. The first line of the document is
the XML declaration that defines the XML version and the encoding used in the document.
Then, the data that constitute the tree follow through the following lines. Each node in the
tree is called an XML element. XML elements start with the name of the element enclosed in
angle brackets, e.g. <book>, and terminates with a closing tag that contains a slash ’/’ and
the name of the element, e.g. </book>.
<?xml version="1.0" encoding="UTF-8"?>
<book xmlns="urn:org:miguel:book"
isbn="0470018186" edition="2">
<title>The 3G IP Multimedia Subsystem (IMS)</title>
<subtitle>Merging the Internet and the cellular worlds</subtitle>
<author id="1">Gonzalo Camarillo</author>
<author id="2">Miguel A. Garcia-Martin</author>
<publisher>John Wiley and Sons, Ltd</publisher>
</book>
Figure 17.5: Example of an XML document: ims.xml
XML elements can contain other child elements, processing instructions, n amespace
declarations, comments, and text nodes. In the example in Figure 17.5, the book element
contains the title, subtitle, and so on, child elements.
XML elements usually contain a text node that represents a value. In the example in
Figure 17.5, the value of the title element is “The 3G I P Multimedia Subsystem (IMS)”.
XML elements can be also empty, in which case, a compact notation can indicate the
beginning and end tags of the empty element by including a slash ’/’ at the end of the element
name. For example, <test/> is an empty element.
Last, XML elements can contain attributes that further characterize the element, typically
by defining its metadata. In Figure 17.5, the book element contains three attributes: xmlns,
isbn,andedition. Unlike elements, attributes cannot be empty and can only appear once

in a given element.
XML is extensible, so new elements and attributes can be added whenever they are
needed. This is, perhaps, the most important property of XML.
An XML document is said to be well formed when it meets the basic constraints for all
XML documents. For example, each open tag has a closing tag (except for the compact
notation of empty elements); the names of the attributes are unique; elements are properly
nested; attributes values must be quoted, etc.
Sometimes XML documents need to be drafted according to a predefined structure that
provides additional constraints of the data. In the example of Figure 17.5, there should not be
two title elements, but there can be several author elements. All of these constraints,
which are specific to the type of data that the XML document represents, are typically
defined in separate additional documents, for example, in Document Type Definition (DTD)
376
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
documents, XML schema documents or RelaxNG documents. An XML document is said to
be valid when it meets the constraints defined in the DTD, XML schema, RelaxNG, or any
other document that d efines the constraints.
17.2.1 XML Namespaces
When XML designers create XML documents, they need to give names to the XML elements
and attributes of the document. It is easy to foresee that sooner or later there will be conflicts
in the names given to XML elements and attributes, e.g., two designers could create the book
element in different documents, each one with a different structure and syntax. Furthermore,
if these two book elements were part of the same XML document as sibling nodes, then it
would not be possible to determine which is which.
To solve this p roblem, XML introduces the concept of namespaces, which are specified in
the W3C Recommendation “Namespaces in XML 1.1 (Second Edition)” [ 92]. A n amespace
is an abstract space where names pertaining to XML elements and attributes belong to. By
making namespaces globally unique, it is possible to differentiate, e.g., two book elements
that b elong to two different XML schemas. So, the namespace provides the XML document
with a context where the document makes sense.

Namespaces are identified by International Resource Identifiers (IRI), specified in
RFC 3987 [125]. In the case of IETF documents, IRIs are usually URNs, specified in
RFC 3986 [86], and they are registered under the tree urn:ietf:params:xml:ns.AURNis
a persistent name that identifies a resource independently of its location. An XML document
must indicate at least one namespace where the elements, attributes, etc. belong, but it is
also possible, and it is actually very common, to create an XML document that contains
elements and attributes belonging to different namespaces. Usually, a namespace declaration
is included in the root element o f the document, indicating all of the namespaces used in the
document. The declaration is made in xmlns attributes that modify the root element. The
namespace declaration typically contains the default namespace and additional namespaces
used throughout the document. The default namespace applies to any unprefixed element.
Additional namespaces are mapped to a prefix, so it is easier to distinguish those elements
that belong to other non-default namespaces.
Let us illustr ate the concept with the example of Figure 17.6, which is an exten-
sion of our XML document for representing books. The document now defines two
namespaces with the “ xmlns” attributes of the book element. The default namespace
is “urn:org:miguel:book”. Any element that is not prepended by a prefix belongs to
that namespace. A second namespace named “urn:org:miguel:classification”is
declared. This second namespace is mapped to the prefix “cl”, so any XML element (and
attributes of it) prefixed with “cl” belongs to that namespace. So, the example shows
the elements class, technical, internet, telecom,andwireless that belong to the
“urn:org:miguel:classification” namespace. We can also see that some of these
elements are, in fact, empty XML elements, since the element tag serves as both opening
and closing tag.
17.3 HTTP URIs that Identify XCAP Resources
We have discussed earlier that XCAP is used to manage remotely stored XML documents.
XCAP is able to manage XML documents, XML elements, XML element values, and XML
attributes. Each of them is considered a resource and it is identified with a URI. Actually,
17.3. HTTP URIS THAT IDENTIFY XCAP RESOURCES
377

<?xml version="1.0" encoding="UTF-8"?>
<book xmlns="urn:org:miguel:book"
xmlns:cl="urn:org:miguel:classification"
isbn="0470018186" edition="2">
<title>The 3G IP Multimedia Subsystem</title>
<subtitle>Merging the Internet and the cellular worlds</subtitle>
<author id="1">Gonzalo Camarillo</author>
<author id="2">Miguel A. Garcia-Martin</author>
<publisher>John Wiley and Sons, Ltd</publisher>
<cl:class>
<cl:technical true="yes"/>
<cl:internet true="yes"/>
<cl:telecom true="yes"/>
<cl:wireless true="yes"/>
</cl:class>
</book>
Figure 17.6: Various namespaces in an XML document
since XCAP is not a new protocol, but a set of conventions to use HTTP for managing XML
documents, there are no XCAP URIs, but rather, HTTP URIs that represent XCAP resources.
Let us take a closer look at the mechanism that XCAP utilizes to identify resources.
Figure 17.7 shows a schematic representation of an HTTP URI that represents an XCAP
resource, while Figure 17.8 shows an example of it. Actually, the example in Figure 17.8
represents the id attribute whose value is “2” of the <author> element that we saw in
Figure 17.5.
XCAP resource = XCAP root
+ document selector
[+ node selector separator]
[+ node selector]
[+ query]
Figure 17.7: Construction of HTTP URIs that represent XCAP resources

/>/ims.xml/~~/book/author[@id="2"]
Figure 17.8: An HTTP URI that represents an XCAP resource
The HTTP URI represented in Figure 17.8 starts with the HTTP URI scheme, “http://”,
followed by the hostname of the server, “xcap.example.com”, and XCAP root locator,
“/root”. All three form the XCAP root URI that identifies th e hierarch y where XCAP
services are located in the HTTP server. So, in the example, the XCAP root URI indicates an
HTTP protocol operation on a server called “xcap.example.com” on a (potentially virtual)
directory called “/root”.
The XCAP root URI is followed by a document selector, which starts with the
application usage to which the document pertains, in the example, the “bibliography”
378
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
XCAP application usage. Then, there are one of two possible subtrees, which identify
either the “global” subtree or the “users” subtree, and are identified with the literals
global or users, respectively. The global subtree contains all of the documents where
data is set by all users. The “users” subtree contains documents that apply to a particular
user. The name of the user follows the users subtree, so, the example in Figure 17.8
refers to user “sip:”, so the URI is referring to a document owned
by that user. Then the actual XML document follows, in the example, “ims.xml”.
To summarize: Figure 17.8 is selecting an XML document n amed “ims.xml”ofthe
“bibliography” application usage; the “ims.xml” document is located in the user directory
“sip:”.
The document selector is followed by double tilde characters “∼∼”, which are called
the node selector separators and are used to separate the document selector from the node
selector which follows. The node selector identifies an XML element, attribute, etc. within
the selected document. In the example in Figure 17.8 the node selector points to the book
element and its child author element whose attribute “id” has the value “2”. This is denoted
as “/book/author[@id="2"]”.
Last, an optional query component can be concatenated to the HTTP URI that represents
an XCAP resource. This is used, for example, when XML namespaces have to be included

in the URI. In most cases, the query component is not needed because the default namespace
for the application usage is assumed.
Usually HTTP URIs that represent XCAP resources are included in the Request-URI
of HTTP requests. The encoding rules of the Request-URI field in an HTTP request does
not allow the presence of some characters, such as square brackets. Owing to this, special
characters are percent-encoded in Request-URIs,soa’[’ character is encoded as a ’%5b’,
a ’]’ character is encoded as ’%5d’, and the double quotes ’"’ as ’%22’. Therefore, when
the example of an HTTP URI that we saw in Figure 17.8 is included in a Request-URI,it
yields the percent-encoded HTTP URI of Figure 17.9.
/>/ims.xml/~~/book/author%5b@id=%222%22%5d
Figure 17.9: A percent-encoded HTTP URI representing an XCAP resource
17.4 XCAP Operations
As we indicated earlier, XCAP allows an XCAP client to do different types of operations in
a remote XML document. XCAP operations are mapped to HTTP requests, whose Request-
URI values indicate the resource (document, element, attribute) that are to be created, deleted,
replaced, modified, or fetched. Let us take a deeper look at these operations and h ow they are
mapped to HTTP 1.1 requests.
17.4.1 Create or Replace Operations
To create a new XML document in a remote server or to replace an existing one, an XCAP
client invokes the HTTP PUT method. The Request-URI in the HTTP PUT reque st identifies
the XML document that is to be created (if it previously did not exist) or replaced (if it
existed). The XML document to b e created or replaced is attached to the r equest as a MIME
17.4. XCAP OPERATIONS
379
body, and it is identified by a Content-Type header field with the value defined by the
application usage. Figure 17.10 shows an example of an XCAP operation that creates or
replaces an “ims.xml” document.
PUT /root/bibliography/users/sip:/ims.xml HTTP/1.1
Host: xcap.example.com
Content-Type: application/bibliography+xml

<?xml version="1.0" encoding="UTF-8"?>
<book xmlns="urn:org:miguel:book"
isbn="0470018186" edition="2">
<title>The 3G IP Multimedia Subsystem</title>
<subtitle>Merging the Internet and the cellular worlds</subtitle>
<author id="1">Gonzalo Camarillo</author>
<author id="2">Miguel A. Garcia-Martin</author>
<publisher>John Wiley and Sons, Ltd</publisher>
</book>
Figure 17.10: Creating or replacing a complete XML document
If the XCAP client wishes to create or replace a single element or attribute of an existing
XML d ocument, the operation is similar: the XCAP client invokes the HTTP PUT method
with a Request-URI that points to the XML element or attribute that is to be created or
modified. The Content-Type header field is set to either “application/xcap-el+xml”
or “application/xcap-att+xml”, depending on whether the operation affects an element
or an attribute, respectively. The PUT request then contains an XML body that includes the
element or attribute to be created or replaced. For example, Figure 17.11 inserts a keywords
element as a child element of book,inthe“ims.xml” document.
PUT /root/bibliography/users/sip:/ims.xml/
~~/book/keywords HTTP/1.1
Host: xcap.example.com
Content-Type: application/xcap-el+xml
<keywords>
<keyword>IMS</keyword>
<keyword>multimedia</keyword>
<keyword>3G</keyword>
</keywords>
Figure 17.11: Adding an element to an XML document
Since both create and replace operations are mapped onto the same HTTP request, there
must be a way to differentiate them. There is, and it is very simple: if the node selector does

not match an existing element, then it is a create operation; if the node selector selects an
existing element within the document, then it is a replace operation.
380
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
17.4.2 Delete Operations
To delete an XML do c ument, element, or attribute in a remote server, an XCAP client creates
a DELETE HTTP request. The Request-URI uniquely selects the document, element, or
attribute to be deleted. Upon reception of the DELETE method, the server deletes the
document or attribute. If it is an element, it deletes the element with all of its attributes and
child elements. The resulting document must still be in conformance with the app lication
usage, i.e., it must be c ompliant with the XML Schema th at determines which elements and
attributes are mandatory and optional and further constraints, otherwise, the server will not
honor the delete request. Figure 17.12 shows an example of a delete operation that removes
the “ims.xml” document from the server.
DELETE /root/bibliography/users/sip:/ims.xml HTTP/1.1
Host: xcap.example.com
Figure 17.12: Deleting an XML document
17.4.3 Fetching Operations
There are many cases in which an XCAP client needs to fetch an existing document, element,
or attribute, that is remotely stored. For example, if a user is using a new terminal, he
most likely does not have any of the XML documents that he created earlier with a different
terminal. In this case, before he manipulates his data, he must first fetch existing documents
from the server.
To fetch a document, element, or attribute, the client creates an HTTP GET request.
This requires that the XCAP client has knowledge of the name of the XML document. The
Request-URI selects the document, element, or attribute to be fetched. The server will reply
in a 200 (OK) response that contains a MIME body. If a full XML document was requested,
the response contains the document. If an element or attribute was requested, the response
contains the requested element or attribute, properly identified with a Content-Type header.
17.5 Entity Tags and Conditional Operations

The concept of entity tags is not new to XCAP, since it is inherited from HTTP, so we need to
go back to HTTP for a proper description. An entity tag is an opaque string of characters that
is associated to the contents of a resource, for example, a web page. If the resource (e.g, the
web page) changes its contents, e.g., due to an update, then the HTTP server creates a new
entity tag for such resource
15
. So, we can consider an entity tag as a sort of fingerprint of a
resource.
Entity tags are transpor ted in ETag header fields that are part of HTTP responses.
Figure 17.13 depicts a couple of HTTP requests where the corresponding responses contains
an ETag header field. A client invokes the HTTP GET method to request a given resource (1).
The HTTP server answers with a 200 (OK) response (2) that contains the requested content,
as a MIME body, and an ETag header field whose value identifies the served version of the
content. When the content changes, perhaps due to some external action, the server assigns
a new entity tag. If, later, the client (or any other client) requests the same resource (3 ),
15
Creation of entity tags is optional for HTTP servers, ho wever, it is mandatory for XCAP servers
17.5. ENTITY TAGS AND CONDITIONAL OPERATIONS
381
Figure 17.13: Entity tags in HTTP
the server returns the new value of the entity tag in the ETag header field of the 200 (OK)
response (4), along with the MIME body of the content.
Entity tags are key to perform conditional HTTP requests, and by extension, conditional
XCAP operations. Let us take a look at the need for conditional HTTP requests with the
help of Figure 17.14. Assume the client depicted in Figure 17.13, which has issued the
GET requests depicted in Figure 17.13. The client has stored a cached copy of the content
identified by the Request-URI of the last GET request. The entity tag associated to that
version of the content is “2”, since this was the value returned in the ETag header of the
last 200 (OK) response. Now the clients wants to retrieve the content identified by the same
Request-URI, if it has been updated with respect to the cached version. Otherwise, it would

be a waste of bandwidth to download the same content. So, according to Figure 17.14, the
client sends a GET request (1) indicating the URI of the resource. The GET request also
includes an If-None-Match header field that con tains the entity tag of the cached copy of
the c ontent. If the resour ce has not been modified with respect to that value of the entity tag,
the server responds with a 304 (Not Modified) response, which does not include the content.
This allows the client to periodically poll the server for changes of a given resource, without
wasting much bandwidth in unnecessary unchanged content.
Now, let us assume that the client wants to modify the contents of the resource, assuming
that the client has cached the latest version of the content. This is implemented with a
conditional PUT request (3) that includes an If-Match header field containing the entity
tag of the cached version o f the content. The PUT request also contains a MIME body with
the new desired content. The server receives the request, and compares the value of the entity
tag in the If-Match header field with that of the stored version. If they match, then it means
both the server and the client are synchronized, and the PUT request is executed, meaning
that the MIME body included in the PUT request replaces the existing content. The server
382
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
Figure 17.14: HTTP conditional requests
answers with a 200 (OK) response that includes an ETag header field that contains the n ewly
allocated entity tag for the new version of the content, “3”.
Let us assume now that the content changes due to some external interaction, perhaps
due to another client PUT request, or some manually updated data. The server allocates a
new entity tag for that version of the content, “4”. If our client now wants to update the
content, thinking that the latest known entity tag of the content is “3”, the n it will send a PUT
request (5) that contains the If-Match header field set to “3” along with a MIME body of
the new desired content. However, “3” is not the latest entity tag of the content, so the server
does not execute the conditional PUT request. Rather, it answers with a 412 (Precondition
Failed) response. At this point in time, the only thing that the client can do to synchronize
the content with that of the server, is to issue an unconditional GET request (7) to retrieve
the contents identified by the resource. The server answers with a 200 (OK) response that

contains an ETag header field with the value of the entity tag, “4”, along with a MIME body
that contains the latest version of the content.
All of the HTTP conditional requests are directly applicable to XCAP, as conditional
operations, since XCAP uses HTTP as an underlying protocol. XCAP conditional operations
are very useful. For example, before adding a friend to a presence list, the client should
make sure that they have the latest version of the presence list, otherwise, an unconditional
17.6. SUBSCRIPTIONS TO CHANGES IN XML DOCUMENTS
383
insertion of a new friend could produce undesired results. On the other hand, conditional fetch
operations make sure that the content is only downloaded from the server if it has changed
with respect to the version stored in the client, avoiding an unnecessary waste of bandwidth.
17.6 Subscriptions to Changes in XML Documents
We indicated earlier that any authorized user can modify a given XML document from any
XCAP client. Therefore, it is possible for an XCAP client to retrieve an XML document, e.g.,
a list of friends in a presence list, and store it into memory. Later, another XCAP client might
retrieve the same document, modify the list by adding or deleting friends to it, and upload
the changes to the XCAP server. The first XCAP client will not be notified of the changes
made by the second XCAP client. This creates a problem in typical situations where an XML
document is accessed from different devices, such as a computer and a mobile device.
A possible solution to overcome this problem consists of periodically performing a
conditional fetch operation on the XML document. This effectively minimizes the risk of
getting stalled with an outdated XML do c ument. The maximum time a client could have
an outdated XML document is equal to the period of the polling interval. While polling is
a solution, it does not offer th e accuracy required by many applications, unless the polling
interval is kept short, in which case the XCAP overhead traffic might become non-negligible.
Furthermore, typically a user might be managing dozens of XML documents, so it is certainly
not efficient to poll each document p eriodically to find out if it has changed.
Another more accurate solution is o ffered by the combination of two specifications:
The XCAP Diff Event Package, specified in the Internet-Draft “An XCAP Diff Event
Package” [312] and the XCAP Diff Format, specified in the Internet-Draft “An XCAP

Document Format for Indicating A Change in XCAP Resources” [291]. These two
specifications jointly provide a subscription/notification mechanism for getting one or more
XML documents synchronized with those stored in an XCAP server. The former provides
the general behavior for an event package; the latter specifies an XCAP-Diff XML document
format that is able to express the changes occurred in XML documents. The mechanism,
therefore, uses SIP and the SIP-event notification framework to keep XCAP documents
synchronized. Since the mechanism is based on subscriptions, whenever there is a change
in an XML document, the server sends a notification to all subscribers indicating the details
of the change.
The XCAP-Diff mechanism allows the terminal to subscribe not only to changes to the
whole XML document, but also to changes in a particular element or attribute o f an XML
document. Furthermore, the subscriber can issue a subscription for a collection of XML
documents, elements, attributes, even those pertaining to different XML documents. So,
a single subscription can manage the synchronization of several documents, elements, or
attributes pertaining to XML documents stored in the server. This wide range of different
subscriptions, varying from an element or attribute, passing through a whole document, and
ending in all readable documents stored in the server, provides the required flexibility to meet
all of the possible deployment requirements.
The subscription to the xcap-diff event package requires some means to indicate the list
of XML documents, elements, attr ibutes, etc., of the subscription. This list of X ML resources
is contained in another XML document called a resource list. The resource list contains
a collection of URLs that represent XCAP resources or collections of XML documents
for which subscription to the changes in them provokes a notification to the subscriber.
384
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
This resource list is included as a MIME body in the SUBSCRIBE request that creates the
subscription.
The SUBSCRIBE request sets an Event header field to the name of the event package:
xcap-diff.TheEvent header value is also accompanied by a diff-processing
parameter that indicates to the server how it should express the differences between two

versions of the document. The value in this parameter determines the actual content and
format of future notifications. There are three possible values of the diff-processing
parameter: “no-patching”, “xcap-patching”, and “aggregate”.
The value “no-patching”inthediff-processing parameter tells the server that the
client is interested in being informed when a document, element, attribute, etc., has changed.
If the n otification describes a ch ange in the value of an XML element or attribute, the new
value of the changed element or attribute is included in the notification. However, if the
subscription is made towards an XML document, and something in that document changes,
the new document is not sent in the notification. Instead, only the new entity tag of that
changed XML document is included in the notification. If the XCAP client wishes to retrieve
the XML document, it would need to invoke an XCAP retrieve operation to receive the new
version of the document.
The value “xcap-patching”inthediff-processing parameter, which is the default
value, indicates to the server that the client is interested in receiving the actual changes in
XML documents, elements, attributes, etc., along with the values of the entity tags (ETag)
of those resources. The value “xcap-patching” provides a sequence of all changes that the
resource has suffered from the time it was last notified until the current time, offering the
possibility to re-create all intermediate values that the resource had until the current time.
Finally, the value “aggregate”inthediff-processing parameter makes the server
to provide the initial and final values of the change in an XML document, element, or
attribute, but not the intermediate values that the resource had in between initial and final
value. Figure 17.15 shows an example of an Event header field used to subscribe to changes
of XML documents.
Event: xcap-diff; diff-processing=xcap-patching
Figure 17.15: Event header field in a SUBSCRIBE request
Figure 17.16 depicts the operation of the XCAP Diff event package and its format.
An XCAP/SIP client creates a regular SIP subscription to the xcap-diff event package
by sending a SIP SUBSCRIBE request (1) to the XCAP/SIP server. This SUBSCRIBE
request (1) contains a resource list that describes the XML documents, elements, attributes,
etc., for which changes in them should be notified, as indicated earlier. An example of

this SUBSCRIBE request (1) is shown in Figure 17.17. The Request-URI is set to the
SIP URI of the server. The body of the SUBSCRIBE request contains a resource list that
provides the URIs of each of the resources for which a subscription to changes is wanted.
In the example of Figure 17.17 there are three URIs, corresponding to all of the documents
pertaining to the pidf-manipulation XCAP application usage, the index of documents of
the resource-lists XCAP application usage, and an element of the rls-services XCAP
application usage.
The XCAP/SIP server receives the SUBSCRIBE request (1), generates and 200 (OK)
response (2), and then examines the body included in the SUBSCRIBE request (1). For each
requested resource to be monitored, it first verifies the requested documents for which the
17.6. SUBSCRIPTIONS TO CHANGES IN XML DOCUMENTS
385
Figure 17.16: Subscription to changes in XML documents
user has read permission (here we have simplified the authentication mechanism). Then the
XCAP/SIP server creates an initial XCAP-Diff document that c ontains the references to the
subscribed resources (documents, elements, or attributes) including all of the data required to
create an HTTP URI for retrieving them, along with the current entity tags. Then the server
includes this XCAP-Diff document in a NOTIFY request (3). Figure 17.18 shows an example
of an initial XCAP-Diff document included in the NOTIFY request (3) of Figure 17.16,
which includes data about a single document in the pidf-manipulation XCAP application
usage, the requested document in the resource-lists XCAP application usage, and the
element sip: in the rls-services application usage. For
each reference to an XML document, element, or attribute included in the body of the
NOTIFY request, the value of the entity tag is included. When the terminal receives the
NOTIFY request (3), it can verify whether it has a cached copy of the same version of
documents, owing to the presence of the entity tag of each document. If it does not have
that version of the documents, then the terminal does an unconditional fetch operation on the
URI of the document to retrieve that base version.
If at a later time, any of the documents change, perhaps because another authorized
user makes a change in the document, the server sends a NOTIFY request (5) that contains

another XCAP-Diff document. The XCAP-Diff document lists the affected document in the
<document> element, both with the old version (identified with the previous-etag entity
tag attribute) and the new version (identified with the new-etag entity tag attribute). For
example, assume that the index document of the pidf-manipulation application usage
has changed. The NOTIFY request (5) contains an XCAP-Diff document that lists the
changed document along with its new entity-tag. This is illustrated in Figure 17.19.
386
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
SUBSCRIBE sip:xcap.example.com SIP/2.0
Via: SIP/2.0/UDP pc55.example.com;branch:z9hG4bKn9s66
From: Alice <sip:>;tag=d9sjopo
To: Bob <sip:xcap.example.com>
Call-ID:
CSeq: 392 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: xcap-diff; diff-processing=aggregate
Accept: application/xcap-diff+xml
Contact: <sip:>
Content-Type: application/resource-lists+xml
Content-Length: 376
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="pidf-manipulation/"/>
<entry uri="resource-lists/users/sip:/index"/>
<entry uri="rls-services/users/sip:/index/
~~/*/service%5b@uri=’sip:’%5d"/>
</list>
</resource-lists>

Figure 17.17: SUBSCRIBE request (1)
17.7 XML Patch Operations
There are many occasions when the initial version of an XML document evolves, owing
to modifications in the document. For example, if a user is adding one more friend to a
presence list, most likely he is modifying an existing XML document to add a new XML
element. In those cases, it is beneficial to develop a language for expressing the changes
that a document suffered from one version to another one. XML patch operations, specified
in the Internet-Draft “An Extensible Markup Language (XML) Patch Operations Framework
Utilizing XML Path Language (XPath) Selectors” [311] provides exactly that functionality.
The specification defines the format of XML Patch Operations documents, which as one
can expect, are XML documents that offer a set of conventions to express changes incurred
in other XML documents. The recipient o f an XML patch operations document can apply
those “patches” to an existing document and obtain, as a result, a new version of the XML
document.
The p atching process is graphically illustrated in Figure 17.20 . An existing XML
document is identified with an entity tag “1”. An XML patch operations document describes
the operations that need to be applied to th e XML document with entity tag “1”. When those
operations are executed, the result is another version of the XML document, which receives
a different entity tag (“2” in the example).
There are three patch operations: add, replace, and remove. Each of them is represented
in an <add>, <replace>,or<remove> elements, respectively, in an XML patch operations
document. Each patch operation can be applied to either an element, attribute, namespace,
17.7. XML PAT CH OPERATIONS
387
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root=" /><document new-etag="3ba8spp03"
sel="pidf-manipulation/users/sip:/index"/>
<document new-etag="39dnsa21"
sel="resource-lists/users/sip:/index"/>

<xd:element sel="rls-services/users/sip:/index/
~~/*/service%5b@uri=’sip:’%5d"
xmlns:xd="urn:ietf:params:xml:ns:xcap-diff"
xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists">
<service uri="sip:">
<list name="marketing">
<rl:entry uri="sip:"/>
<rl:entry uri="sip:"/>
<rl:entry uri="sip:"/>
</list>
<packages>
<package>presence</package>
</packages>
</service>
</xd:element>
</xcap-diff>
Figure 17.18: Initial XCAP-Diff document included in a NOTIFY request (3)
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root=" /><document previous-etag="3ba8spp03"
new-etag="b8s8b91FG"
sel="pidf-manipulation/users/sip:/index"/>
</xcap-diff>
Figure 17.19: Subsequent XCAP-Diff document included in a NOTIFY request (5)
388
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET
Figure 17.20: XML p atching operations
comment, text, or processing instruction. A sel attribute indicates the selector,i.e.,thetarget
of the change. The process is intuitive: the value of the sel attribute traverses the hierarchy

of the XML document until it reaches the target.
Let us assume our favorite XML document, “ims.xml”, included in Figure 17.5. Let us
assume that we want to change the title of the book so that it includes the IMS acronym in it.
We can apply the patches of the XML patch operations document contained in Figure 17.21 to
replace the <title> element with a new one. The XML patch operations document contains
a single operation: replace. The sel attribute describes the hierarchy of the document: first,
go the book element, then to the title element, and finally, select the whole text (the value)
in it.
<?xml version="1.0" encoding="UTF-8"?>
<p:diff xmlns="urn:org:miguel:book"
xmlns:p="urn:ietf:params:xml:ns:diff">
<p:replace sel="book/title/text()">
The 3G IP Multimedia Subsystem (IMS)
</p:replace>
</p:diff>
Figure 17.21: XML p atch operations document
There is an immediate advantage of XML patch operations over XCAP: XML patch
operations allows a series of multiple operations that can affect different elements or attributes
of the XML document to be pipelined. However, XCAP allows a single operation on a single
object (element, attribute, or document). The consequence is that XML patch operations
can express complex sequences of operations, while if the same set of operations were to be
performed with XCAP, it would require an XCAP request per operation.