SIMPLE WG R. Mahy Internet-Draft SIP Edge LLC Expires: April 20, 2006 October 17, 2005 A profile of the XML Configuration Access Protocol (XCAP) for manipulating resource lists and authorization lists draft-mahy-simple-xcap-profile-00.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 April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 April 20, 2006 [Page 1] Internet-Draft XCAP Resource-List Profile October 2005 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 April 20, 2006 [Page 2] Internet-Draft XCAP Resource-List Profile October 2005 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 rarely 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 can perform XCAP operations on groups or individual resource- list entries, and on individual rules, but cannot 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 restricted to this profile can greatly simplify their 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, this profile restricts XCAP clients so they 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. an individual "entry" element accessed by its "uri" attribute Mahy Expires April 20, 2006 [Page 3] Internet-Draft XCAP Resource-List Profile October 2005 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 an XCAP client which supports this profile MUST NOT present an XCAP URI which includes a "list" element accessed at depth 9 or greater. 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 for the provided example document. Mahy Expires April 20, 2006 [Page 4] Internet-Draft XCAP Resource-List Profile October 2005 Valid XPath expression in this profile resource-lists/list[@name="Amigos"] resource-lists/list[@name="Amigos"]/entry[@uri="sip:bill@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 April 20, 2006 [Page 5] Internet-Draft XCAP Resource-List Profile October 2005 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, this profile restricts 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 April 20, 2006 [Page 6] Internet-Draft XCAP Resource-List Profile October 2005 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 April 20, 2006 [Page 7] Internet-Draft XCAP Resource-List Profile October 2005 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 mailiciously 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-07 (work in progress), June 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-03 (work in progress), July 2005. [4] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-05 (work in progress), July 2005. [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 April 20, 2006 [Page 8] Internet-Draft XCAP Resource-List Profile October 2005 [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 SIP Edge LLC Email: rohan@ekabal.com Mahy Expires April 20, 2006 [Page 9] Internet-Draft XCAP Resource-List Profile October 2005 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 (2005). 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 April 20, 2006 [Page 10]