Chapter 17 - Service Conﬁguration on the Internet

Chia sẻ: Nguyễn Văn Chiến | Ngày: | Loại File: PDF | Số trang:18

Thêm vào BST

Báo xấu

73
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Many services require a mechanism for allowing users to manage their service conﬁguration. 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 conﬁgure a dial-out or dial-in list of participants, their privileges (who can speak or who can send or receive which media type), and so on.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chapter 17 - Service Conﬁguration on the Internet

Chapter 17 Service Conﬁguration on the Internet Many services require a mechanism for allowing users to manage their service conﬁguration. 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 conﬁgure a dial-out or dial-in list of participants, their privileges (who can speak or who can send or receive which media type), and so on. All of these use cases share many commonalities: a user has to perform non-real-time operations on a server to manipulate one or more documents that conﬁgure or personalize their instance of the service. Usually the user creates a conﬁguration 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 document. In some other cases the user changes their usual terminal and uses a different one, so they may ﬁrst need to download a fresh copy of the current conﬁguration document, make some changes, and upload it (either complete or a part of it) to the server. Typically, conﬁguration documents are highly structured. Owing to this, the trend nowadays is to use the Extensible Markup Language (XML) (speciﬁed 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 conﬁguration documents are effectively XML documents, but how are they sent to and received from the server that stores them? The XML Conﬁguration Access Protocol (XCAP) solves this vacuum. 17.1 The XML Conﬁguration Access Protocol (XCAP) The problem of document management can be depicted in its most simpliﬁed way as in Figure 17.1. A user creates an XML document in his 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 (speciﬁed in RFC 2616 [144]) provides a good baseline, since it provides The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı © 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 372 Terminal server Figure 17.1: Overview of Document Management the POST and PUT methods for transferring ﬁles 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 small piece of an existing XML document. For instance, when a user wants to add a “buddy” to his list of 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 modiﬁed 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 (speciﬁed 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. XCAP HTTP TCP IP Figure 17.2: The XCAP protocol stack XCAP provides a client with the means to read, write, and modify XML application conﬁguration 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 deﬁnes 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 deﬁnes the rules that govern how
17.1. THE XML CONFIGURATION ACCESS PROTOCOL (XCAP) 373 modiﬁcation 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 original XML schema. In addition, XCAP also deﬁnes 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:alice@example.com/friends.xml HTTP/1.1 Host: xcap.example.com Content-Type: application/resource-lists+xml Content-Length: 460 Bob Cynthia Figure 17.3: Example of an XCAP operation XCAP deﬁnes 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 speciﬁed 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 speciﬁed 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 conﬁguration of XML documents stored in a server. We have also seen that there are a several applications that utilize XCAP. For example, in the presence service, presentities use XCAP to control whether watchers can see all
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 374 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 conﬁgure the list of participants of the conference. In general, whenever there is a need to conﬁgure conﬁguration application data, such as a list remotely stored in XML format, XCAP is a good protocol to fulﬁll these needs. Owing to this versatility XCAP introduces the concept of an application usage. An application usage deﬁnes how a particular application uses XCAP to interact with the XCAP server. For instance, each of the previously mentioned applications of XCAP (presence list management, authorization policies, and conference list management) constitutes an application usage on its own. Each application usage is identiﬁed by an AUID (Application Unique ID) that uniquely identiﬁes 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 deﬁned a number of XCAP application usages related to the presence service. XCAP application usage for resource lists. Speciﬁed in RFC 4826 [273], provides the means to manipulate resource lists that are typically used as presence lists. XCAP application usage for presence authorization. Deﬁned 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. Speciﬁed in RFC 4827 [175], allows users to perform hard state manipulation of presence data, i.e., set the presence status by conﬁguration (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 conﬁguring applications. Usually, the application conﬁguration 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 protocol 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 ﬁle named ims.xml. Let us use this example to further illustrate a few concepts. The ﬁrst line of the document is the XML declaration that deﬁnes 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. , and terminates with a closing tag that contains a slash ’/’ and the name of the element, e.g. . The 3G IP Multimedia Subsystem (IMS) Merging the Internet and the cellular worlds Gonzalo Camarillo Miguel A. Garcia-Martin John Wiley and Sons, Ltd Figure 17.5: Example of an XML document: ims.xml XML elements can contain other child elements, processing instructions, namespace 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 IP 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, is an empty element. Last, XML elements can contain attributes that further characterize the element, typically by deﬁning its metadata. In Figure 17.5, the book element contains three attributes: xmlns, isbn, and edition. 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 predeﬁned 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 speciﬁc to the type of data that the XML document represents, are typically deﬁned in separate additional documents, for example, in Document Type Deﬁnition (DTD)
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 376 documents, XML schema documents or RelaxNG documents. An XML document is said to be valid when it meets the constraints deﬁned in the DTD, XML schema, RelaxNG, or any other document that deﬁnes 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 conﬂicts 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 problem, XML introduces the concept of namespaces, which are speciﬁed in the W3C Recommendation “Namespaces in XML 1.1 (Second Edition)” [92]. A namespace 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 belong to two different XML schemas. So, the namespace provides the XML document with a context where the document makes sense. Namespaces are identiﬁed by International Resource Identiﬁers (IRI), speciﬁed in RFC 3987 [125]. In the case of IETF documents, IRIs are usually URNs, speciﬁed in RFC 3986 [86], and they are registered under the tree urn:ietf:params:xml:ns. A URN is a persistent name that identiﬁes 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 of 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 unpreﬁxed element. Additional namespaces are mapped to a preﬁx, so it is easier to distinguish those elements that belong to other non-default namespaces. Let us illustrate the concept with the example of Figure 17.6, which is an exten- sion of our XML document for representing books. The document now deﬁnes 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 preﬁx belongs to that namespace. A second namespace named “urn:org:miguel:classification” is declared. This second namespace is mapped to the preﬁx “cl”, so any XML element (and attributes of it) preﬁxed with “cl” belongs to that namespace. So, the example shows the elements class, technical, internet, telecom, and wireless 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 identiﬁed with a URI. Actually,
17.3. HTTP URIS THAT IDENTIFY XCAP RESOURCES 377 The 3G IP Multimedia Subsystem Merging the Internet and the cellular worlds Gonzalo Camarillo Miguel A. Garcia-Martin John Wiley and Sons, Ltd 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 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 http://xcap.example.com/root/bibliography/users/sip:miguel@example.com /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 identiﬁes the hierarchy 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”
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 378 XCAP application usage. Then, there are one of two possible subtrees, which identify either the “global” subtree or the “users” subtree, and are identiﬁed 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:miguel@example.com”, 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 named “ims.xml” of the “bibliography” application usage; the “ims.xml” document is located in the user directory “sip:miguel@example.com”. 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 identiﬁes 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 ﬁeld 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, so a ’[’ 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. http://xcap.example.com/root/bibliography/users/sip:miguel@example.com /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, modiﬁed, or fetched. Let us take a deeper look at these operations and how 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 request identiﬁes the XML document that is to be created (if it previously did not exist) or replaced (if it existed). The XML document to be created or replaced is attached to the request as a MIME
17.4. XCAP OPERATIONS 379 body, and it is identiﬁed by a Content-Type header ﬁeld with the value deﬁned 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:miguel@example.com/ims.xml HTTP/1.1 Host: xcap.example.com Content-Type: application/bibliography+xml The 3G IP Multimedia Subsystem Merging the Internet and the cellular worlds Gonzalo Camarillo Miguel A. Garcia-Martin John Wiley and Sons, Ltd 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 document, 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 modiﬁed. The Content-Type header ﬁeld 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, in the “ims.xml” document. PUT /root/bibliography/users/sip:miguel@example.com/ims.xml/ ~~/book/keywords HTTP/1.1 Host: xcap.example.com Content-Type: application/xcap-el+xml IMS multimedia 3G 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.
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 380 17.4.2 Delete Operations To delete an XML document, 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 application usage, i.e., it must be compliant with the XML Schema that 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:miguel@example.com/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 ﬁrst 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 identiﬁed 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 resource15. So, we can consider an entity tag as a sort of ﬁngerprint of a resource. Entity tags are transported in ETag header ﬁelds that are part of HTTP responses. Figure 17.13 depicts a couple of HTTP requests where the corresponding responses contains an ETag header ﬁeld. 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 ﬁeld whose value identiﬁes 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, however, 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 ﬁeld 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 identiﬁed 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 identiﬁed 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 ﬁeld that contains the entity tag of the cached copy of the content. If the resource has not been modiﬁed with respect to that value of the entity tag, the server responds with a 304 (Not Modiﬁed) 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 ﬁeld containing the entity tag of the cached version of 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 ﬁeld 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
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 382 Figure 17.14: HTTP conditional requests answers with a 200 (OK) response that includes an ETag header ﬁeld that contains the newly 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”, then it will send a PUT request (5) that contains the If-Match header ﬁeld 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 identiﬁed by the resource. The server answers with a 200 (OK) response that contains an ETag header ﬁeld 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 ﬁrst XCAP client will not be notiﬁed 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 document. 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 the accuracy required by many applications, unless the polling interval is kept short, in which case the XCAP overhead trafﬁc might become non-negligible. Furthermore, typically a user might be managing dozens of XML documents, so it is certainly not efﬁcient to poll each document periodically to ﬁnd out if it has changed. Another more accurate solution is offered by the combination of two speciﬁcations: The XCAP Diff Event Package, speciﬁed in the Internet-Draft “An XCAP Diff Event Package” [312] and the XCAP Diff Format, speciﬁed in the Internet-Draft “An XCAP Document Format for Indicating A Change in XCAP Resources” [291]. These two speciﬁcations jointly provide a subscription/notiﬁcation 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 speciﬁes 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 notiﬁcation 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 notiﬁcation 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 of 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 ﬂexibility 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, attributes, etc., of the subscription. This list of XML 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 notiﬁcation to the subscriber.
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 384 This resource list is included as a MIME body in the SUBSCRIBE request that creates the subscription. The SUBSCRIBE request sets an Event header ﬁeld to the name of the event package: xcap-diff. The Event 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 notiﬁcations. There are three possible values of the diff-processing parameter: “no-patching”, “xcap-patching”, and “aggregate”. The value “no-patching” in the diff-processing parameter tells the server that the client is interested in being informed when a document, element, attribute, etc., has changed. If the notiﬁcation describes a change in the value of an XML element or attribute, the new value of the changed element or attribute is included in the notiﬁcation. However, if the subscription is made towards an XML document, and something in that document changes, the new document is not sent in the notiﬁcation. Instead, only the new entity tag of that changed XML document is included in the notiﬁcation. 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” in the diff-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 notiﬁed 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” in the diff-processing parameter makes the server to provide the initial and ﬁnal values of the change in an XML document, element, or attribute, but not the intermediate values that the resource had in between initial and ﬁnal value. Figure 17.15 shows an example of an Event header ﬁeld used to subscribe to changes of XML documents. Event: xcap-diff; diff-processing=xcap-patching Figure 17.15: Event header ﬁeld 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 notiﬁed, 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 ﬁrst veriﬁes 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 simpliﬁed the authentication mechanism). Then the XCAP/SIP server creates an initial XCAP-Diff document that contains 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:colleagues@example.com 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 element, both with the old version (identiﬁed with the previous-etag entity tag attribute) and the new version (identiﬁed 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.
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 386 SUBSCRIBE sip:xcap.example.com SIP/2.0 Via: SIP/2.0/UDP pc55.example.com;branch:z9hG4bKn9s66 From: Alice ;tag=d9sjopo To: Bob Call-ID: 29d9s@pc55.example.com CSeq: 392 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: xcap-diff; diff-processing=aggregate Accept: application/xcap-diff+xml Contact: Content-Type: application/resource-lists+xml Content-Length: 376 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 modiﬁcations 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 beneﬁcial to develop a language for expressing the changes that a document suffered from one version to another one. XML patch operations, speciﬁed in the Internet-Draft “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors” [311] provides exactly that functionality. The speciﬁcation deﬁnes 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 of 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 patching process is graphically illustrated in Figure 17.20. An existing XML document is identiﬁed with an entity tag “1”. An XML patch operations document describes the operations that need to be applied to the 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 , , or elements, respectively, in an XML patch operations document. Each patch operation can be applied to either an element, attribute, namespace,
17.7. XML PATCH OPERATIONS 387 presence Figure 17.18: Initial XCAP-Diff document included in a NOTIFY request (3) Figure 17.19: Subsequent XCAP-Diff document included in a NOTIFY request (5)
CHAPTER 17. SERVICE CONFIGURATION ON THE INTERNET 388 Figure 17.20: XML patching operations comment, text, or processing instruction. A sel attribute indicates the selector, i.e., the target 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 element with a new one. The XML patch operations document contains a single operation: replace. The sel attribute describes the hierarchy of the document: ﬁrst, go the book element, then to the title element, and ﬁnally, select the whole text (the value) in it. The 3G IP Multimedia Subsystem (IMS) Figure 17.21: XML patch 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.