SIMPLE WG R. Mahy Internet-Draft Airespace Expires: August 2, 2005 Feb 2005 An alternative to XML Configuration Access Protocol (XCAP) for manipulating resource lists and authorization lists, Using HyperText Transport Protocol (HTTP) extensions for Distributed Authoring and Versioning (DAV) draft-mahy-simple-xcap-alternative-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes an alternative to XCAP (XML Configuration Access Protocol) for manipulating SIMPLE resource and authorization lists using WebDAV. This alternative is motivated by initial performance data that suggest that when XCAP Servers verify requests satisfy a required property of HTTP (idempotency), performance may Mahy Expires August 2, 2005 [Page 1] Internet-Draft A WebDAV alternative to XCAP Feb 2005 drop non-trivially. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A WebDAV Based Approach . . . . . . . . . . . . . . . . . . . 4 2.1 Operations on entire lists or rulesets . . . . . . . . . . 5 2.2 Operations on individual entries or rules . . . . . . . . 8 2.3 Pipelined operations on multiple entries or rules . . . . 9 3. Conclusion and recommendations: . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 7.2 Informational References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Mahy Expires August 2, 2005 [Page 2] Internet-Draft A WebDAV alternative to XCAP Feb 2005 1. Introduction XCAP [1] (XML [5] Configuration Access Protocol) was originally designed as a generic configuration protocol for many purposes. While this vision is very compelling, some of the originally intended users of this technology (ex: conference policy control [12]) selected other approaches which do not use a document metaphor for their data. Currently XCAP usages are defined only for resource lists [2] and authorization lists [3]. As a protocol layered on top of HTTP [8], XCAP requests must be idempotent. This requires an XCAP Server to check if each modification request is idempotent or not. Initial implementation experience with these usages of XCAP suggests that there may be substantial performance penalties verifying the idempotent nature of PUT requests in XCAP. This document describes an alternative that uses a small subset of ordinary WebDAV [9] extensions to HTTP. This approach has the advantage that implementors can use off-the-shelf web servers and WebDAV client libraries. The extraordinary flexibility of XCAP is somewhat limited by the requirement that XCAP uses HTTP request, which must be idempotent. Since XCAP uses XPath [7] expressions and XML document fragments, it is possible that a client could submit a request which is not idempotent. The XCAP server needs to check if a request is idempotent before accepting or rejecting it. Initial implementation experience suggests that verifying the idempotency property is extremely performance intensive. The time required to process an insert operation in one implementation with and without this verification step varies by several orders of magnitude. In practice the full flexibility of XCAP is rarely needed by current XCAP usages. XCAP clients 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. The primary requirement which motivated 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. Typically operations will operate either on an entire list, or on individual entries in a list. Similarly, an authorization list or "ruleset" consist of individual "rule" elements. Typically clients will manipulate whole rulesets or individual rules. Instead this document describes an approach where standard WebDAV servers are used. Document fragments representing "rule" and "entry" elements are represented by specific WebDAV resources. Entire XML Mahy Expires August 2, 2005 [Page 3] Internet-Draft A WebDAV alternative to XCAP Feb 2005 documents representing "ruleset" elements and "list" elements are easily represented using dynamically generated documents from specific collections. 2. A WebDAV Based Approach Briefly, WebDAV describes resources, collections, and properties. In a typical file system, resources are represented as files or directories, collections are represented as directories, and properties are specific pieces of metadata associated with a resource. However, WebDAV does not maintain rigid requirements about the representation of resources. In practice, many resources and even collections are dynamically generated. By definition collections are simply resources which can contain other resources. A URL referring to a collection always ends in a slash "/". The key to the approach described in this document is that XML documents that are designed for use with XCAP are described as collections. Individual resources, and even other collections are represented inside such a collection. Schema with potentially a large number of similar objects are split so that some subparts of the schema are represented as ordinary resources, and others are represented as collections. This approach is similar to the pattern used by CalDAV [13]. This document provides two specific schema mappings described below. For resource lists: Elements "resource-list" and "list" are modeled as collections. Elements which are direct children of a list element (such as "entry", "external", "entry-ref", and "display-name" elements) are modeled as non-collection resources The resource name of the collection corresponding to "list" elements is the name of the list. The resource name of the collection representing the root of the document is "resource-list". The resource name of "entry", "entry-ref", or "external" element is the "uri", "ref", or "anchor" attribute of that element (respectively). Other attributes of "resource-list", "list", and of the direct children of a list element are modeled as WebDAV properties. For common policy documents: The element "ruleset" is modeled as a collection All direct children of a "ruleset" element ("rule" elements) are modeled as non-collection resources The "id" attribute of a "rule" element is its resource name. Mahy Expires August 2, 2005 [Page 4] Internet-Draft A WebDAV alternative to XCAP Feb 2005 The resource name of a ruleset can have any name. WebDAV does not specify the specific behavior for GET, PUT, and POST operations on collections. In practice, most implementations allow for configurable or programmable handling of these operations for a specific subtree in the URL hierarchy. Many implementations use the Content-Type header as a hint to indicate how to process actions on collections. This approach can be implemented easily on existing web servers very easily. Non-collection resources can be handled with almost no new code, except to verify that the schema is correct when content is created or changed. PUT requests to a collection can be transformed into existing methods available on the server, by breaking the collection up into individual resources. GET requests on a collection can be transformed into a simple aggregation of the resources accessible through existing methods available on the server. This document suggests using GET, PUT, and other operations on a collection, to read or write a valid XML document at the corresponding level in the hierarchy. [TODO: Describe schema mapping in terms on an XPath or an XML Expression.] Note that sort order of collection can be specified using WebDAV ordered collections [14]. 2.1 Operations on entire lists or rulesets To create or modify an entire XML document which is accessible with subhierarchy, the client just generates a PUT request with the entire document. In this example, the client creates several resource lists. In this case, the client uses the If-None-Match header to make sure no content exists yet at this URI. Mahy Expires August 2, 2005 [Page 5] Internet-Draft A WebDAV alternative to XCAP Feb 2005 PUT /resource-lists/ If-None-Match: * Content-Type: application/resource-list+xml Bill Doe Close Friends Joe Smith Nancy Gross Marketing Later, the client can fetch the entire document or a list at any level of the hierarchy by sending a GET request for the corresponding resource name for the collection. Here the client fetches just the "close-friends" list. Mahy Expires August 2, 2005 [Page 6] Internet-Draft A WebDAV alternative to XCAP Feb 2005 GET /resource-list/Amigos/close-friends/ HTTP/1.1 Content-Type: application/resource-lists+xml HTTP/1.1 200 OK Content-Type: application/resource-lsits+xml Close Friends Joe Smith Nancy Gross Marketing Similarly, the client can use the PUT request to replace a whole subtree or create a new list, or DELETE to delete a new list. PUT /resource-lists/enemies/ If-None-Match: * Content-Type: application/resource-list+xml DELETE /resource-lists/enemies/ If-Match: 329fj3 Deptch: infinity MKCOL /resource-lists/enemies/ Mahy Expires August 2, 2005 [Page 7] Internet-Draft A WebDAV alternative to XCAP Feb 2005 The MKCOL request would cause the server to create an empty collection and initialize it with default values. The example below would create a new list at the top level with the name attribute set to "enemies". The MOVE and COPY requests would operate as expected, allowing a client to rename a list, move a list, or copy a list from one URI to another. Finally, the client could use PROPFIND and PROPPATCH to read and write WebDAV properties. Below, the client queries the xml:lang attribute on the "Amigos" collection. PROPFIND /resource-lists/Amigos/ HTTP/1.1 Depth: 1 Content-Type: text/xml HTTP/1.1 200 OK Content-Type: text/xml es 2.2 Operations on individual entries or rules Operations on individual entries, entry-refs, and rules are similarly easy. GET /resource-lists/Amigos/close-friends/sip:joe@example.com Content-Type: application/xml HTTP/1.1 200 OK Content-Type: application/xml Joe Smith Mahy Expires August 2, 2005 [Page 8] Internet-Draft A WebDAV alternative to XCAP Feb 2005 To insert into a collection, the client selects a name for the resource according to the rules in the schema mapping, and uses the If-None-Match header to insure that there is no existing resource with that same name. Modification of a specific resource is similar. PUT /rulesets/pres/03489qdf8sd If-None-Match: * Content-Type: application/xml PUT /resource-lists/Amigos/sip:fred@example.com If-None-Match: * Content-Type: application/xml Deleting, renaming, moving, and copying individual resources all work as expected. 2.3 Pipelined operations on multiple entries or rules Occasionally, a client would like to add, delete, or modify multiple snippets of a document while avoiding either multiple roundtrips or operating on the entire document. Using HTTP Pipelining, a client can send several requests in succession without waiting for a roundtrip. This works very well for insert operations, and works fine for modifications and deletions if the frequency of simultaneous modification of the overall document is low. 3. Conclusion and recommendations: The SIP/SIMPLE community needs to immediately examine implementation performance of XCAP Servers with idempotency verification in realistic environments. If initial performance data is representative of production systems, the community should investigate switching to another approach for list management. If performance impact of idempotency verification is less than one order of magnitude, the community this author recommends continuing with XCAP. 4. Security Considerations This document discusses two HTTP-based alternatives for manipulating Mahy Expires August 2, 2005 [Page 9] Internet-Draft A WebDAV alternative to XCAP Feb 2005 configuration documents with the same schema. The security properties of the two approaches are expected to be extremely similar, and the security considerations discussed in XCAP therefore apply. Clients and servers implementing this approach MUST implement HTTP over TLS [10] and HTTP Digest authentication [11]. Note that by using WebDAV, clients may take advantage of WebDAV Access Control [15] to set access control for relevant WebDAV resources. 5. IANA Considerations This document requires no action by IANA. 6. Acknowledgments Thanks for Lisa Dusseault for reviewing this document. 7. References 7.1 Normative References [1] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-05 (work in progress), November 2004. [2] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-04 (work in progress), October 2004. [3] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-01 (work in progress), October 2004. [4] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-03 (work in progress), October 2004. [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, . Mahy Expires August 2, 2005 [Page 10] Internet-Draft A WebDAV alternative to XCAP Feb 2005 [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [9] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [11] 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. 7.2 Informational References [12] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01 (work in progress), October 2004. [13] Dusseault, L., "Calendar Server Extensions for WebDAV (CalDAV)", draft-dusseault-caldav-04 (work in progress), December 2004. [14] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003. [15] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. Author's Address Rohan Mahy Airespace 110 Nortech Pkwy San Jose, CA 95134 USA EMail: rohan@ekabal.com Mahy Expires August 2, 2005 [Page 11] Internet-Draft A WebDAV alternative to XCAP Feb 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 August 2, 2005 [Page 12]