SIMPLE WG R. Mahy Internet-Draft Plantronics Expires: September 6, 2006 March 5, 2006 A profile of the XML Configuration Access Protocol (XCAP) for manipulating resource lists and authorization lists draft-mahy-simple-xcap-profile-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a profile of XCAP (XML Configuration Access Protocol) for manipulating SIMPLE resource lists and common policy rule sets. While XCAP allows access to arbitrary XML document subtrees, most XCAP implementations only need access to documents at the specific points in the XML schema described by this profile. Mahy Expires September 6, 2006 [Page 1] Internet-Draft XCAP Resource-List Profile March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Profile for XCAP Resource Lists . . . . . . . . . . . . . . 3 3. Profile for Common Policy Documents . . . . . . . . . . . . 6 4. A note about server validation . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Mahy Expires September 6, 2006 [Page 2] Internet-Draft XCAP Resource-List Profile March 2006 1. Introduction XCAP [1] (XML [5] Configuration Access Protocol) is a generic configuration protocol layered on top of HTTP [8]. It uses XPath [7] expressions and XML document fragments to hierarchically access arbitrary subtrees of an XML document. In practice the full flexibility of XCAP is often not needed by currently standardized usages of XCAP. XCAP clients implementing these usages are unlikely to independently access the deepest nodes of an XML schema [6]. Typically, clients just need access to one or two levels of hierarchy inside an XML document. A major requirement which motivated the development of XCAP was the requirement for some clients (especially wireless devices) to manipulate individual peers ("buddies") in a presence list. These peers are represented by "entry" elements in a resource list [2]. Typically operations will operate either on an entire list, or on individual entries in a list. Similarly, a presence authorization list [3] is a common policy [4] document or "ruleset" that consists of individual "rule" elements. Typically clients will only manipulate whole rulesets or individual rules. This document describes a Profile of XCAP which only accesses XCAP documents at specific places in the XML document hierarchy. XCAP Clients are encouraged to perform XCAP operations on groups or individual resource-list entries, and on individual rules, but not to access arbitrarily deep elements of the XCAP hierarchy. This profile has two implementation benefits. Clients restricted to this profile can easily construct XCAP URIs without using an XPath library. Servers could optimize to this profile such that in-profile request have greatly simplified schema validation requirements. Note: In some places in this document, an XPath expression, an HTTP URI or an XML attribute is "split" across multiple lines This is done only to meet formatting requirements of this document. Line splitting is not allowed "on the wire". 2. Profile for XCAP Resource Lists When manipulating resource lists, requests within this profile are limited so that XCAP clients only present XCAP URIs which manipulate an entire resource-list XML document or one of the following specific parent elements. a single resource-list "list" element, accessed by its "name" attribute, at any level of the document hierarchy up to the maximum nesting depth. Mahy Expires September 6, 2006 [Page 3] Internet-Draft XCAP Resource-List Profile March 2006 an individual "entry" element accessed by its "uri" attribute an individual "external" element accessed by its "anchor" attribute an individual "entry-ref" element accessed by its "ref" attribute For the purposes of this profile, the maximum nesting depth for a "list" element is 8. A "list" element which is the immediate child of the "resource-lists" element has a depth of 1. A "list" element at depth 8 is allowed, but if an XCAP client presents an XCAP URI which includes a "list" element accessed at depth 9 or greater, the request is not a profile-compliant request. Performing XCAP operations on an XCAP URI with no path separator ("/~~") and no node selector refers to an entire XML resource-list document, including the preamble. Performing XCAP operations using one of these XPath expressions as the XCAP node selector refers to an XML subtree which includes the referenced node and all its decendants. resource-lists | |- list | |- entry | |- entry-ref | |- entry | |- external | |- list | |- entry | |- entry |- list |- entry |- entry For example, the following XPath expressions are all valid within this profile for the provided example document. Mahy Expires September 6, 2006 [Page 4] Internet-Draft XCAP Resource-List Profile March 2006 Valid XPath expression in this profile resource-lists/list[@name="Amigos"] resource-lists/list[@name="Amigos"]/entry[@uri="sip:bob@example.com"] resource-lists/list[@name="Amigos"]/entry-ref[@ref="aaaa"] resource-lists/list[@name="Amigos"]/list[@name="close-friends"] resource-lists/list[@name="Amigos"]/list[@name="close-friends"] \ /entry[@uri="sip:joe@example.com"] resource-lists/list[@name="Amigos"]/list[@name="close-friends"] \ /external[@anchor="bbbb"] Example Document Bill Doe Close Friends Joe Smith Nancy Gross Marketing The BNF for a resource list Node Selector (XPath expression) which corresponds to this profile, is given below. Mahy Expires September 6, 2006 [Page 5] Internet-Draft XCAP Resource-List Profile March 2006 rl-node-sel = "resource-lists/" 1*16group [res-item] group = "list" LSQ "@name=" DQUOT list-name DQUOT RSQ "/" res-item = entry / entry-ref / external entry = "entry" LSQ "@uri=" DQUOT uri DQUOT RSQ entry-ref = "entry-ref" LSQ "@ref=" DQUOT uri DQUOT RSQ external = "external" LSQ "@anchor=" DQUOT uri DQUOT RSQ DQUOT = %22 ; <"> character, must be % encoded in URI LSQ = %5b ; [ character, must be % encoded in URI RSQ = %5d ; ] character, must be % encoded in URI 3. Profile for Common Policy Documents When manipulating common policy documents, request within this profile limit XCAP clients so they only present XCAP URIs which manipulate an entire common policy XML document or an individual "rule" element accessed by its "id" attribute". For example, the following XPath expression is legal under this profile. ruleset/rule[@id="f3gr2j"] Below is the BNF for a common policy document node selector (XPath expression). cp-node-sel = "ruleset/rule" LSQ "@id=" DQUOT id DQOUT RSQ DQUOT = %22 ; <"> character, must be % encoded in URI LSQ = %5b ; [ character, must be % encoded in URI RSQ = %5d ; ] character, must be % encoded in URI 4. A note about server validation An XCAP server attempting to validate an XML subtree starting from an individual list, entry, entry-ref, external element can merely sandwich the provided XML document fragment inside an XML header and a "test" list element, and pass the resulting XML to a validator library. For example the following header and footer snippets are suitable. Mahy Expires September 6, 2006 [Page 6] Internet-Draft XCAP Resource-List Profile March 2006 HEADER FOOTER Likewise, an XCAP server attempting to validate an XML subtree starting from an individual rule element can merely sandwich the provided XML document fragment inside an XML header and a top-level ruleset element, as shown in this example. HEADER FOOTER resource-lists | |- list | |- entry | |- entry-ref | |- entry | |- external | |- list | |- entry | |- entry |- list |- entry |- entry 5. Security Considerations This document discusses a profile of XCAP (itself a usage of HTTP). Mahy Expires September 6, 2006 [Page 7] Internet-Draft XCAP Resource-List Profile March 2006 The security considerations of XCAP naturally apply to this document as well. In addition, servers which implement this profile may take advantage of the simplified URI grammar to use regular expressions within a server. Extra care should be taken when implementing escape encoding and decoding to prevent clients from using maliciously crafted URIs to cause an unauthorized side effect. Clients and servers implementing this approach MUST implement HTTP over TLS [9] and HTTP Digest authentication [10]. 6. IANA Considerations This document requires no action by IANA. 7. Normative References [1] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-08 (work in progress), October 2005. [2] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005. [3] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-04 (work in progress), October 2005. [4] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-07 (work in progress), February 2006. [5] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, . [6] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [7] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", W3C Recommendation xpath, November 1999, . [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Mahy Expires September 6, 2006 [Page 8] Internet-Draft XCAP Resource-List Profile March 2006 [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [10] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Author's Address Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA USA Email: rohan@ekabal.com Mahy Expires September 6, 2006 [Page 9] Internet-Draft XCAP Resource-List Profile March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mahy Expires September 6, 2006 [Page 10]