Chapter 18 - Service Configuration in the IMS pot

Chapter 18
Service Configuration in the IMS
Chapter 17 provided a description of the protocols at the user’s disposal for configuring
services on the Internet. We saw that the service configuration architecture assumes an XML
document stored on a server. The client retrieves a copy of the XML document, makes
changes to it, and sends the delta back to the server.
In IMS, the architecture for service configuration architecture is developed around the
XML Document Management (XDM) arc hitecture created by the Open Mobile Alliance
(OMA) in the XDM [244] set of specifications. XDM allows a user to modify XML
documents stored in remote network servers. It also allows the local copy of those XML
documents in the IMS terminal to be synchronized with the copy stored in network servers,
so that if the user makes changes to one XML document from a given IMS terminal, other
terminals are updated with the latest changes. Last, the XDM architecture also provides
limited support for searches of information stored in these XML documents.
18.1 XDM architecture
Let us describe the XDM architecture with the help of Figure 18.1. The XDM architecture
assumes a terminal that implements the role of an XCAP client, and one or more servers,
called XDM servers, that implement the role of XCAP servers. XML documents are stored
in any of the servers and kept synchronized with the copy in the client. When a user wants to
change a configuration setting in a ser vice, such as addin g a friend to a presence list, the user
changes the local copy of the XML document in the client and sends the change to the server,
which applies it, and stores an updated version of the XML configuration document.
The XDM architecture introduces the following concepts.
XDM client (XDMC). This is an XCAP client running in the IMS terminal. The XDMC
implements the core XDM features and some application-specific features.
Aggregation proxy. This is an HTTP proxy that is configured as an HTTP reverse proxy.
The Aggregation Proxy authenticates the XDMC towards an XDMS. It may also ro ute
XCAP requests towards an XDMS or towards an Aggregation Proxy located in remote
network. It also routes search requests towards the Search proxy. When receiving
responses, it can compress the body of the response.
´ı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
390
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
Figure 18.1: XDM architecture
Search proxy. This is an HTTP proxy that processes search requests received from XDMCs
towards XDMSs or remote Aggregation Proxies. On received responses, the Search
proxy combines the results of the responses received from XDMSs and remote
Aggregation Proxies before forwarding them to the XDMC.
Shared XDM servers. XDM servers (XMDSs) that are used by several applications. Shared
XDMSs are effectively XCAP servers. There are specialized shared XDMSs: shared
list XDMS, shared group XDMS, shared profile XDMS, and shared policy XDMS.
XDMSs. This is an application-specific server for service configuration purposes. Effec-
tively, XDMSs are XCAP servers that serve a single application.
Most of the interfaces of the XDM architecture are implemented with XCAP. This is the
case of the interfaces XDM-3, XDM-4, XDM-8. However, interfaces XDM-1 and XDM-2 are
used for subscription to changes in XML documents, based on the XCAP event package for
SIP. Consequently, XDM-1 and XDM-2 are SIP interfaces. Interfaces XDM-5, XDM-6, XDM-
7,andXDM-9 implement the Limited XQuery over HTTP protocol. Unnamed interfaces in
Figure 18.1 are defined by their respective applications, but they typically consist of XCAP,
SIP for subscriptions to XCAP event packages, and Limited XQuery over HTTP.
The XDM architecture considers different applications that can be customers o f the XDM
service (or enabler, as it is called by the OMA). For example, the presence service is a
customer of XDM, because the list of watchers, the authorization policies, etc., are all stored
in XML documents managed b y XDM. Other services that use XDM include Push-to-talk
18.2. DOWNLOADING AN XML DOCUMENT, ATTRIBUTE, OR ELEMENT
391
over Cellular and PSTN/ISDN simulation services. Owing to this diversity of customers of
XDM, the XDM architecture considers the existence of d ifferent XDM servers, each one

perhaps specialized in serving a given application. An XDMS is a logical representation of
the service configuration aspects of a service or application. In real products, it is expected
that XDM servers are integrated into the specific server (e.g., presence server, PoC server,
etc.).
Similarly, XDMCs are not really new entities, but just the logical representation of an
XDM client in an IMS terminal.
18.2 Downloading an XML Document, Attribute, or Element
When an XDMC wants to receive an XML document, or a part of it, e.g., an attribute
or element, it invokes the HTTP GET request in XCAP. The basic HTTP GET operation
according to the XDM architecture is shown with the help of Figure 18.2. The XDMC
sends an HTTP GET request (1) to the Aggregation Proxy. It is assumed that the address
of the Aggregation Proxy is pre-provisioned in the IMS terminal. An example of this
HTTP GET request (1) is shown in Figure 18.3. The Request-URI is set to the part of the
XCAP URI that is identified in HTTP, thus, excluding the host name. Of relevance in the
HTTP GET request is the inclusion of an X-3GPP-Intended-Identity header field that
is populated with the identity that the user wants to present to the Aggregation Proxy. The
HTTP X-3GPP-Intended-Identity header field is specified in 3GPP TS 24.109 [9] and
contains a SIP Public User Identity of the user. This Public User Identity is also present as a
username in the XCAP URI of the GET request.
Figure 18.2: XDM: basic GET operation
GET /resource-lists/users/sip:/index HTTP/1.1
Host: xdm.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 04 Mar 2008 22:10:45 GMT
X-3GPP-Intended-Identity: "sip:"
Accept-Encoding: gzip
Figure 18.3: HTTP GET request (1)
392
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
The Aggregation Proxy first needs to authenticate the user. There are several approaches

to authenticate a user. One of them consist of using the Generic Authentication Architecture
(GAA, specified in 3GPP TS 33.22 2 [15]). Essentially, GAA uses HTTP over TLS (specified
in RFC 4346 [121]), for security purposes, and then either a certificate in the client or a share
password. So, if GAA is used, all of the authentication takes place at the TLS level and not
at the HTTP level.
However, Figure 18.2 shows another authentication mechanism based on HTTP Digest
Authentication (specified in RFC 2617 [145]). The Aggregation Proxy receives an HTTP
GET request (1) and issues a 401 (Unauthorized) response (2) that contains a challenge in the
WWW-Authenticate header field. As a minimum, the challenge contains the realm where the
user will be authenticated, and a nonce, which is a random value that prevents against replay
attacks. An example of this 401 (Unauthorized) response is shown in Figure 18.4.
HTTP/1.1 401 Unauthorized
Server: XDM-proxy/OMA2.0
Date: Thu, 04 Mar 2008 22:10:46 GMT
WWW-Authenticate: Digest realm="home1.com", qop=auth-int,
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
Content-Length: 0
Figure 18.4: HTTP 401 (Unauthorized) response (2)
The IMS terminal receives the 401 (Unauthorized) response (2), extracts the challenge,
computes the response to that challenge (considering the username, realm, password, and
nonce), and generates a second HTTP GET request (3) that contains that response to the
challenge in the Authorization header field. An example of th is HTTP GET request (3) is
shown in Figure 18.5.
GET /resource-lists/users/sip:/index HTTP/1.1
Host: xdm.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 04 Mar 2008 22:10:49 GMT
X-3GPP-Intended-Identity: "sip:"
Authorization: Digest realm="home1.com", qop=auth-int,
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

username="sip:", nc=00000001,
uri="/resource-lists/users/sip:/index",
response="2c8ee200cec7f6e966c932a9242554e4",
cnonce="3bb96fe6e98a02ccb4555609c1b1bb56"
Figure 18.5: HTTP GET request (3)
The Aggregation Proxy, upon receiving of this new HTTP GET request (3) that
contains the credentials, first evaluates the response to the presented challenge and computes
if it matches the response provided by the XDMC. If the response to the challenge
is correct, then it removes the Authorization header field and continues processing
the request. The Aggregation Proxy adds its own Via header field, and preserves the
X-3GPP-Intended-Identity header field. Then it inspects the Request-URI, d etermines,
18.3. DIRECTORY RETRIEVAL
393
based on the Application Unique ID (AUID), the actual server that is responsible for serving
the request, and forwards the HTTP GET request (4) to that server. In the example, the AUID
is set to resource-list; the Shared List XDMS is responsible for that application, thus is
the recipient of the HTTP GET request (4). An example o f the forwarded request is shown in
Figure 18.6.
GET /resource-lists/users/sip:/index HTTP/1.1
Host: xdm.home1.com
Via: HTTP/1.1 proxy.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 04 Mar 2008 22:10:50 GMT
X-3GPP-Intended-Identity: "sip:"
Figure 18.6: HTTP GET request (4)
The Shared List XDMS then provides the requested XML document, element, or attribute
in a 200 (OK) response (5), and forwards the response back to the Aggregation Proxy. An
example of this response is shown in Figure 18.7.
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0

Date: Thu, 04 Mar 2008 22:10:50 GMT
Etag: "asd92d092"
Content-Type: application/resource-lists+xml
Content-Length: 238
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="family">
<entry uri="sip:"/>
<entry uri="sip:/>
</list>
</resource-lists>
Figure 18.7: 200 (OK) response (5)
The Aggregation Proxy then compresses the body of the 200 (OK) response, i.e., the
XML document, according to any of the supported algorithms specified by the XDMC in the
HTTP GET request (3). It also adds an Authentication-Infoheader field that contains the
next nonce that the XDMC can use in a future HTTP request (so, future requests can directly
include the response to a challenge and avoid one round trip). Then it forwards it back to the
XDMC. An example of this response is shown in Figure 18.8.
18.3 Directory Retrieval
Sometimes users may need to retrieve all of their XML configuration do c uments that pertain
to one or more application usages. This might be the case, for example, if the user is
configuring a new IMS terminal. The XDM arch itecture offers a mechanism to do perform
394
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0
Via: HTTP/1.1 proxy.home1.com
Date: Thu, 04 Mar 2008 22:10:51 GMT
Etag: "asd92d092"
Authentication-Info: nextnonce="2a219bcb2ad25ae32cbe280c249f"

Content-Encoding: gzip
Content-Type: application/resource-lists+xml
Content-Length: 159
[binary compressed data]
Figure 18.8: 200 (OK) response (6)
this type of operation. The mechanism is briefly described in Figure 18.9, which for the sake
of brevity shows only two shared XDMSs.
Figure 18.9: Directory retrieval with XDM
According to Figure 18.9, when the XDMC wants to obtain a directory retrieval for
one or more applications, the XDMC sends an HTTP GET request (1) to its Aggregation
Proxy. Figure 18.9 assumes that the user is in possession of the next nonce value, obtained
in a previous HTTP operation, so the XDMC can compose a response to a challenge to
authenticate towards the Aggregation Proxy. An example of this HTTP request (1) is shown
in Figure 18.10.
What makes the HTTP GET request (1) in Figure 18.10 different, so that it is
interpreted as a directory retrieval operation? The Request-URI, which partially contains
the URI of the resource, is the key. The Request-URI contains a special AUID
called “org.openmobilealliance.xcap-directory”, which indicates the d irectory
retrieval operation. In addition, the Request-URI refers to a special document called
“directory.xml” which is available under the user’s tree. The OMA defines the structure
of the XML document “directory.xml” in the XDM specification [245].
The Aggregation Proxy, once it has verified the identity of the user, forwards th e GET
request (2, 3) to each of the XDMSs. Then, each XDMS returns a 200 (OK) response (4, 5)
that contains a “directory.xml” document that lists all of the XML documents belonging
to that user and stored in that server for that application usage. An example of one of the
18.3. DIRECTORY RETRIEVAL
395
GET /org.openmobilealliance.xcap-directory/users/sip:
/directory.xml HTTP/1.1
Host: xdm.home1.com

User-Agent: XDM-client/OMA2.0
Date: Thu, 05 Mar 2008 22:10:49 GMT
X-3GPP-Intended-Identity: "sip:"
Authorization: Digest realm="home1.com", qop=auth-int,
nonce="102b98b7102dd2f0e8b11d0f600bfb0c789",
username="sip:", nc=00000002,
uri="/org.openmobilealliance.xcap-directory/users
/sip:/directory.xml",
response="3a59fff43373a95592464948595c2e45",
cnonce="abc123e6e98a02251455360951b1a900"
Figure 18.10: Directory retrieval: HTTP GET request (1)
200 (OK) response (5) is shown in Figure 18.11. The “directory.xml” is identified with a
MIME type of vnd.oma.xcap-directory+xml.
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0
Date: Thu, 05 Mar 2008 22:10:52 GMT
Etag: "9sda09s"
Content-Type: application/vnd.oma.xcap-directory+xml
Content-Length: 432
<?xml version="1.0" encoding="UTF-8"?>
<xcap-directory xmlns="urn:oma:xml:xdm:xcap-directory" >
<folder auid="groups">
<entry uri=" />/users/sip:/family" etag="2098ds" />
<entry uri=" />/users/sip:/co-workers" etag="39s09s" />
</folder>
</xcap-directory>
Figure 18.11: Directory retrieval: 200 (OK) response (5)
The Aggregation Proxy waits sufficient time to receive all of the responses and then
combines all the received “directory.xml” documents into a single one, which is included
in a 200 (OK) response (6) to the XDMC (see Figure 18.12). Each folder element contains

an auid attribute that indicates the application usage to which the included data pertains.
This allows the XDMC to distinguish the application usages for which the user has XML
documents, and the list of documents of each application usage.
XDM not only allows a user to retrieve a directory of all of their documents stored in all
servers, but also allows all user documents pertaining to a given XCAP application usage to
be retrieved. This is done with a smart trick: XCAP allows a single element to be requested
that is part of an XML document; the XDMC requests the folder element of the requested
396
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0
Date: Thu, 05 Mar 2008 22:10:55 GMT
Etag: "x98w2k920"
Authentication-Info: nextnonce="3a2154334ce3409fd24e26872024"
Content-Type: application/vnd.oma.xcap-directory+xml
Content-Length: 599
<?xml version="1.0" encoding="UTF-8"?>
<xcap-directory xmlns="urn:oma:xml:xdm:xcap-directory" >
<folder auid="groups">
<entry uri=" />/users/sip:/family" etag="2098ds" />
<entry uri=" />/users/sip:/co-workers" etag="39s09s" />
</folder>
<folder auid="resource-lists">
<entry uri=" />/sip:/index" etag="0s982k" />
</folder>
</xcap-directory>
Figure 18.12: Directory retrieval: Aggregated 200 (OK) response (6)
application u sage which is included in the overall directory.xml document. The flow is
shown in Figure 18.13.
Figure 18.13: Directory retrieval with XDM for a given XCAP application usage

The XDMC sends an HTTP GET (1) whose Request-URI includes the pointer to the
folder element whose auid attribute matches the requested application usage in the
directory.xml document. In order to request a fraction of the directory.xml document,
the Request-URI also contains the special AUID
org.openmobilealliance.xcap-directory
as well as the special file “directory.xml”. Figure 18.14 shows an example of this HTTP
GET request (1). The notation
/xcap-directory/folder%5b@auid=%22resource-lists%22%5d
18.4. DATA SEARCH WITH XDM
397
is an escaped representation of
/xcap-directory/folder[@auid="resource-lists"]
which is the XCAP mechanism to indicate the folder element whose auid attribute is set
to the value resource-lists.
GET /org.openmobilealliance.xcap-directory/users/sip:
/directory.xml/~~/xcap-directory
/folder%5b@auid=%22resource-lists%22%5d HTTP/1.1
Host: xdm.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 18 Mar 2008 00:14:33 GMT
X-3GPP-Intended-Identity: "sip:"
Authorization: Digest realm="home1.com", qop=auth-int,
nonce="a126802384820945208bp98c0808e0f8021",
username="sip:", nc=00000003,
uri="/org.openmobilealliance.xcap-directory
/users/sip:/directory.xml
/~~/xcap-directory
/folder%5b@auid=%22resource-lists%22%5d",
response="2143cc17309a58b37459b3745b38bb39",
cnonce="c2948330a8530498d43309835d942531"

Figure 18.14: Directory retrieval of a specific application usage: HTTP GET request (1)
Upon receiving this HTTP GET request (1), th e Aggregation Proxy verifies the credentials
included in the request, and forwards the request (2) to the appropriate server. The address
of this server depends on the application usage. In this case, the Shared List XDMS is
responsible for the resource-list application usage. The Shared List XDMS builds an
XCAP document that contains the request element. This is a special XCAP MIME type
application/xcap-el+xml that is used to denote an element of an XML document, as
opposed to the complete XML document. Figure 18.15 shows an example of this 200 (OK)
response (3). The Aggregation Proxy merely forwards this response to the XDMC (4).
18.4 Data Search with XDM
XDM provides a limited search function, allowing XDMCs to search for data remotely stored
in XDMSs. The search sequence flow is shown in Figure 18.16. In general, search requests
originated in an XDMC are sent to an Aggregation Proxy, which forwards it to an appropriate
Search Proxy, which further forwards it to the appropriate XDMS. As usually, the architecture
defines functional elements that, in real implementations, can be combined in single boxes.
So, it is appropriate to combine the Aggregation Proxy and the Search Proxy into the same
physical equipment. Then, the actual search takes place in the XDMS, which returns the
results of the search operation in an HTTP response.
When an XDMC wishes to search some data in one or more remotely stored XML
document, the XDMC creates an HTTP POST request (1) that contains all of the details
required to perform the search. This POST request encodes some d etails of the search
operation in the Request-URI, but the complete detailed parameters of the search are included
398
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0
Date: Thu, 18 Mar 2008 00:14:35 GMT
Etag: "209d29d"
Content-Type: application/xcap-el+xml
Content-Length: 428

<?xml version="1.0" encoding="UTF-8"?>
<xcap-directory xmlns="urn:oma:xml:xdm:xcap-directory" >
<folder auid="groups">
<entry uri=" />/users/sip:/family" etag="9203" />
<entry uri=" />/users/sip:/co-workers" etag="0293" />
</folder>
</xcap-directory>
Figure 18.15: Directory retrieval of a specific application usage: 200 (OK) response (3)
in a special XML document called the Search XML document, which is included as a body
of the POST request. The search function reuses the XQuery 1.0 specification [88]. XQuery
provides mechanisms to extract and manipulate data from XML documents. In the context of
XDM Search operations, XQuery expressions are included in Search XML documents which
are transported in HTTP POST requests.
One of the parameters that characterize the search operation consists of the list of
input documents where the search takes place. The document or documents where
the search takes place can be composed of either all documents of all users pertain-
ing to a given XCAP application u sage, all documents pertaining to a given applica-
tion usage and a given user, or a particular document. For example, let AUID be
the AUID, sip: a Public User Identity, and mylist.xml an XML docu-
ment. If the search takes place over all documents stored under the “users” directory
of the AUID, the document list is encoded as “[AUID]/users/”; if the search is re-
stricted to Alice’s documents for the AUID application, then the search is encoded as
“[AUID]/users/sip:/”; finally, if the search is restricted to a single
user’s document, then the list of documents is enco ded with the following pattern:
“[AUID]/users/sip:/mylist.xml”.
So, where is this document list encoded in HTTP? It is encoded in two different p laces:
in the Search XML document that is included in the HTTP POST request (1), and in the
target parameter of the Request-URI of the same HTTP POST request (1). The reason for
encoding the r equest in two places is twofold: on the one side, the Search XML document
contains very detailed and extensive information of the search parameter, more than just

the input documents, so, this justifies the presence of search documents in the Search XML
body; on the other side, the Search Proxy requires knowledge of the AUID and the user’s
name for routing the HTTP POST request (1) to the appropriate XDMS. Making this routing
information accessible, e.g., in a parameter of the Request-URI makes things easy for the
Search Proxy that, otherwise, would need to open the body and parse the Search XML
document to route the HTTP POST request (1).
18.4. DATA SEARCH WITH XDM
399
Figure 18.16: Searching data with XDM
Let us continue the description of the search request included in the HTTP POST
request (1) with the help of the HTTP POST request example of Figure 18.17.
According to this figure, the Request-URI contains a special minted AUID set to the string
“org.openmobilealliance.search”. This allows the Aggregation Proxy to identify this
request as a search request and forward it to the Search Proxy. In addition, the Request-URI
contains a target parameter whose main purpose is to aid the Search Proxy in routing the
HTTP POST request to the appropriate XDMS. A second optional domain restricts the search
query to either the home domain, any other particular domain, or all remote domains. The
domain parameter defaults to the “home”value.
In order to construct a search query, the XDMC creates an HTTP POST request addressed,
in the Request-URI, to a specially constructed URI that identifies the search operation and the
main search parameters. In Figure 18.17 the Request-URI is set to
/org.openmobilealliance.search?
target=org.openmobilealliance.user-profile/users/
The first part of the Request-URI,setto“/org.openmobilealliance.search”, merely
indicates that this is a search request, and it is later used by the Aggregation Proxy to route
the request to a Search Proxy. The target parameter indicates the collection of documents
where the search takes place, including the AUID, which is set to the user-profile AUID
defined by the OMA. The target parameter is used by the Search Proxy to route the request
to the appropriate XDMS.
The core parameters of the search are included in the Search XML document, which

is identified with a MIME type of “application/vnd.oma-search+xml”. Let us take
a closer look at the Search document with the help of the example in Figure 18.17. A
Search XML document contains a root element search-set element that contains a single
search element, which contains either a request or response element. The example
of Figure 18.17 shows a request element, this is a request for data. Non-error responses
contain a response element instead. The request element contains a query element
that contains a limited or simplified XQuery expression according to the W3C XQuery 1.0
specification [88]. The XQuery expression is enclosed in the CDATA section of the Search
XML document.
The XQuery expression begins with a preamble indicating the XQuery version number,
and it defines a default namespace. Then it contains a simple “for” iteration loo p that selects
the collection of documents that serve as input to the search. In the example in Figure 18.17
400
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
POST /org.openmobilealliance.search?
target=org.openmobilealliance.user-profile/users/ HTTP/1.1
Host: xdm.home1.com
User-Agent: XDM-client/OMA2.0
Date: Thu, 21 Mar 2008 23:35:23 GMT
X-3GPP-Intended-Identity: "sip:"
Authorization: Digest realm="home1.com", qop=auth-int,
nonce="a126802384820945208bp98c0808e0f8021",
username="sip:", nc=00000003,
uri="/org.openmobilealliance.search?
target=org.openmobilealliance.user-profile/users/",
response="390982098203984e0a84d0c410792ee0",
cnonce="1a893b098385c674eef845098cc50a86"
Accept-Encoding: gzip
Content-Type: application/vnd.oma-search+xml
Content-Length: 647

<?xml version="1.0" encoding="UTF-8"?>
<search-set xmlns="urn:oma:xml:xdm:search">
<search id="12098123">
<request>
<query>
<![CDATA[
xquery version "1.0";
declare default element
namespace "urn:oma:xml:xdm:user-profile";
for $x in
collection("org.openmobilealliance.user-profile/users/")
/user-profiles/user-profile
where ($x/profession/title="Engineer") and
($x/address/country="ES")
return
<user-profile>{$x/@uri}{$x/display-name}</user-profile>
]]>
</query>
</request>
</search>
</search-set>
Figure 18.17: Search operation: HTTP POST request (1)
18.4. DATA SEARCH WITH XDM
401
HTTP/1.1 200 OK
Server: XDM-serv/OMA2.0
Date: Thu, 21 Mar 2008 23:35:30 GMT
Etag: "32092"
Content-Type: application/vnd.oma-search+xml
Content-Length: 537

<?xml version="1.0" encoding="UTF-8"?>
<search-set xmlns="urn:oma:xml:xdm:search"
xmlns:up="urn:oma:xml:xdm:user-profile">
<search id="12098123">
<response>
<up:user-profile uri="sip:">
<up:display-name>Miguel Garcia</up:display-name>
</up:user-profile>
<up:user-profile uri="sip:">
<up:display-name>Gonzalo Camarillo</up:display-name>
</up:user-profile>
</response>
</search>
</search-set>
Figure 18.18: Search operation: HTTP 200 (OK) response (4)
the value selects all of the documents for all users pertaining to the User Profile application
usage stored under the “users” tree in the Shared Profile XDMS, and for each document,
the element user-profile, which is a child of the user-profiles element, is selected.
Note that this information is also present in the target parameter of the Request-URI of the
HTTP POST request, however, there it is only used for routing purposes.
The Search XML document then includes a “where” clause tha t indicates the condition
that, in case it is evaluated as true, selects the data. In the example, the condition is set to
those entries in the document where the data contains a profession element that includes a
title element set to “Engineer”andtheaddress element contains a country element set
to “ES”. So, in human parlance, the Search documen t of Figure 18.17 is searching for a list
of Spanish engineers across all of the user’s documents of the User Profile application usage.
Last, the “return” clause specifies what should be returned in the response. In the example,
the URI and display name of each match is returned.
Let us continue with the description of the sequence flow of Figure 18.16. The XDMC
sends the HTTP POST request (1) to its Aggregation Proxy, which first verifies the credentials

included in the Authorization header, and then inspect the Request-URI. Sin ce the
Request-URI contains an indication of a search request, the Aggregation proxy forwards
the HTTP POST request (2) to a Search proxy. The Search Proxy inspects the target
and domain parameters of the Request-URI for routing the request. This target parameter
contains the application usage for the request, so the Search Proxy is able to determine, upon
looking into an internal table, which is the XDMS responsible for that application usage.
In the example in Figure 18.17, the User Profile application usage is indicated, so the Search
402
CHAPTER 18. SERVICE CONFIGURATION IN THE IMS
Figure 18.19: Subscription to changes in XML documents
Proxy forwards the HTTP POST request (3) to the Shared Profile XDMS. If the Request-URI
had included a domain parameter set to a value different than the default value “home”, the
Search Proxy would have forwarded the HTTP POST request to a remote Aggregation Proxy.
The Search Proxy can also forward the request to different servers, including different servers
located in different domains.
When the Shared Profile XDMS (or any other appropriate XDMS) receives the HTTP
POST request (3), it inspects the Search XML document to establish the parameters of the
search operation and the presentation of the results. The XDMS g enerates a 200 (OK)
response (4) that contains a Search XML document. The Search XML document contains
a response element that contains the list of matches formatted according to the return
clause of the XQuery request. Figure 18.18 shows an example of the data returned by the
Shared Profile XDMS.
The HTTP 200 (OK) response (4) is routed back to the Search Proxy. If the request was
forwarded to several servers, the Search Proxy would collect all of the data from the different
servers and aggregate it into a single response. Then, the Search Proxy forwards the HTTP
18.5. SUBSCRIBING TO CHANGES IN XML DOCUMENTS
403
200 (OK) response (5) to the Aggregation Proxy. The Aggregation Proxy can compress the
payload, if supported by the XDMC, but in any case, it forwards the response (6) to the
XDMC. The XDMC now parses the data and presents it to the user.

18.5 Subscribing to Changes in XML Documents
XDM also provides a subscription/notification mechanism to changes in XML documents
stored in any of the XDMSs. The mechanism is a straight application of the XCAP-Diff
event package that we described in Section 17.6.
Consider the example in Figure 18.19. The SUBSCRIBE request (1) contains the list
of documents to which subscriptions are required, as well as an indication of the desired
“diff processing” model (see Section 17.6 for a detailed description of the “diff processing”
model). An initial XCAP-Diff document is included in the NOTIFY request (7). When
a document changes, a new XCAP-Diff document contains the list of changes a second
NOTIFY request (13).