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:alice@home1.com/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:alice@home1.com" 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:alice@home1.com/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:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", username="sip:alice@home1.com", nc=00000001, uri="/resource-lists/users/sip:alice@home1.com/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:alice@home1.com/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:alice@home1.com" 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:daddy.joe@home1.com"/> <entry uri="sip:mom.berta@home1.com/> </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:alice@home1.com /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:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="102b98b7102dd2f0e8b11d0f600bfb0c789", username="sip:alice@home1.com", nc=00000002, uri="/org.openmobilealliance.xcap-directory/users /sip:alice@home1.com/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="http://xdm.home1.com/org.openmobilealliance.groups /users/sip:alice@home1.com/family" etag="2098ds" /> <entry uri="http://xdm.home1.com/org.openmobilealliance.groups /users/sip:alice@home1.com/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="http://xdm.home1.com/org.openmobilealliance.groups /users/sip:alice@home1.com/family" etag="2098ds" /> <entry uri="http://xdm.home1.com/org.openmobilealliance.groups /users/sip:alice@home1.com/co-workers" etag="39s09s" /> </folder> <folder auid="resource-lists"> <entry uri="http://xdm.home1.com/resource-lists/users /sip:alice@home1.com/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:alice@home1.com /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:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="a126802384820945208bp98c0808e0f8021", username="sip:alice@home1.com", nc=00000003, uri="/org.openmobilealliance.xcap-directory /users/sip:alice@home1.com/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="http://xdm.home1.com/org.openmobilealliance.groups /users/sip:alice@home1.com/family" etag="9203" /> <entry uri="http://xdm.home1.com/org.openmobilealliance.groups /users/sip:alice@home1.com/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:alice@home1.com 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:alice@home1.com/”; 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:alice@home1.com/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). [...]... 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. .. 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. .. 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 Since 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... 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 that 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... 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:alice@home1.com" Authorization: Digest realm="home1.com", qop=auth-int, nonce="a126802384820945208bp98c0808e0f8021",.. .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... 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... 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. .. “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. .. profession element that includes a title element set to “Engineer” and the address element contains a country element set to “ES” So, in human parlance, the Search document 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 . 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. 22:10:45 GMT X-3GPP-Intended-Identity: "sip:alice@home1.com" Accept-Encoding: gzip Figure 18. 3: HTTP GET request (1) 392 CHAPTER 18. SERVICE CONFIGURATION IN THE IMS The Aggregation. 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: