SIMPLE WG R. Mahy Internet-Draft Plantronics Expires: September 4, 2006 March 3, 2006 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-02.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 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an alternative to XCAP (XML Configuration Access Protocol) for manipulating SIMPLE resource and authorization lists using WebDAV. XCAP and WebDAV are similar in that they are both usages of HTTP. Since servers could support both simultaneously, WebDAV support is a logical progression from XCAP for clients that require locking, version control, document moves or Mahy Expires September 4, 2006 [Page 1] Internet-Draft A WebDAV alternative to XCAP March 2006 other features of WebDAV. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. A WebDAV Based Approach . . . . . . . . . . . . . . . . . . . 3 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 . . . . 10 3. Comparison of URLs in XCAP and WebDAV . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7.2 Informational References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Mahy Expires September 4, 2006 [Page 2] Internet-Draft A WebDAV alternative to XCAP March 2006 1. Introduction XCAP [1] (XML [6] 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 [13]) 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]. XCAP is layered on top of HTTP [9], and uses XPath [8] expressions and XML document fragments to hierarchically access 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 [7]. 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 HTTP servers with WebDAV [10] extensions are used. Document fragments representing "rule" and "entry" elements are represented by specific WebDAV resources. Entire XML documents representing "ruleset" elements and "list" elements are easily represented using dynamically generated documents from specific collections. XCAP operations are limited to single inserts, modifications, and deletions; and XCAP has no concept of transactions or locking. WebDAV supports moves, renames, locking, versioning, inherent access control, and a framework to store supplementary metadata. Where clients require these additional features (especially locking), or when a client already implements WebDAV for calendaring or more traditional file sharing applications, WebDAV becomes a logical alternative to XCAP for resource-lists and ruleset maintenance. 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 Mahy Expires September 4, 2006 [Page 3] Internet-Draft A WebDAV alternative to XCAP March 2006 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 [14]. This document provides two specific schema mappings described below. For resource lists: 1. Elements "resource-lists" and "list" are collections. 2. The resource name of the collection representing the root of the document is "resource-lists". 3. The resource name of the collection corresponding to "list" elements is the name of the list. 4. Each "entry" element is an ordinary non-collection resource. Each "external" element is a WebDAV redirectref resource [5] whose reftarget property points to a "list" collection. Each "entry-ref" element is a WebDAV redirect resource whose reftarget property points to an "entry" resource. 5. Anywhere the "display-name" element appears, it is represented as a WebDAV property. 6. The resource name of an "entry" element is its "uri" attribute. The resource name of an "entry-ref" element is the "uri" attribute of the entry resource at the targetref. Likewise, the resource name of an "external" element is the "name" attribute of the entry resource at the targetref. 7. Other attributes of "resource-lists", "list", and of the direct children of a list element are modeled as WebDAV properties. For common policy documents: 1. The element "ruleset" is modeled as a collection 2. All direct children of a "ruleset" element ("rule" elements) are modeled as non-collection resources 3. The "id" attribute of a "rule" element is its resource name. 4. 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 Mahy Expires September 4, 2006 [Page 4] Internet-Draft A WebDAV alternative to XCAP March 2006 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. Note that sort order of collection can be specified using WebDAV ordered collections [15]. 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 September 4, 2006 [Page 5] Internet-Draft A WebDAV alternative to XCAP March 2006 PUT /resource-lists/ If-None-Match: * Content-Type: application/resource-lists+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 September 4, 2006 [Page 6] Internet-Draft A WebDAV alternative to XCAP March 2006 GET /resource-list/Amigos/close-friends/ HTTP/1.1 Content-Type: application/resource-lists+xml HTTP/1.1 200 OK Content-Type: application/resource-lists+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 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 September 4, 2006 [Page 7] Internet-Draft A WebDAV alternative to XCAP March 2006 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 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 September 4, 2006 [Page 8] Internet-Draft A WebDAV alternative to XCAP March 2006 Operations on entry-ref and external elements use redirectref resources. MKREDIRECTREF /resource-lists/Coworkers/sip:fred@example.com Content-Type: text/xml; charset="utf-8" /resource-lists/Amigos/work/sip:fred@example.com HTTP/1.1 201 Created GET /resource-lists/Coworkers/sip:fred@example.com HTTP/1.1 302 Found Redirect-Ref: /resource-lists/Amigos/work/sip:fred@example.com MKREDIRECTREF /resource-lists/Coworkers/myteam Content-Type: text/xml; charset="utf-8" /resource-lists/dreamteam/ HTTP/1.1 201 Created GET /resource-lists/Coworkers/myteam/ HTTP/1.1 302 Found Redirect-Ref: /resource-lists/dreamteam/ GET /resource-lists/Coworkers/ HTTP/1.1 200 OK Content-Type: application/resource-lists+xml Mahy Expires September 4, 2006 [Page 9] Internet-Draft A WebDAV alternative to XCAP March 2006 Bill Doe myteam 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. Mahy Expires September 4, 2006 [Page 10] Internet-Draft A WebDAV alternative to XCAP March 2006 3. Comparison of URLs in XCAP and WebDAV Below are portions of the http: URL used to access certain parts of the same resource-list or ruleset using XCAP and WebDAV. XCAP WebDAV http://example.com/ http://example.com/lists/~bob/ resource-lists/ OR users/bob/ http://example.com/~bob/lists/ ~~/resource-lists/ list[@name="Amigos"]/ Amigos/ entry[@uri="sip:alice@example.com"] sip:alice@example.com ruleset[@name="privacy-rules"]/ privacy-rules/ rule[@id="1234"] 1234 4. Security Considerations This document discusses two HTTP-based alternatives for manipulating 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 [11] and HTTP Digest authentication [12]. Note that by using WebDAV, clients may take advantage of WebDAV Access Control [16] to set access control for relevant WebDAV resources. 5. IANA Considerations This document requires no action by IANA. 6. Acknowledgments Thanks to 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-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), Mahy Expires September 4, 2006 [Page 11] Internet-Draft A WebDAV alternative to XCAP March 2006 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-06 (work in progress), October 2005. [5] Whitehead, J., "Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources", draft-ietf-webdav-redirectref-protocol-13 (work in progress), October 2005. [6] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, . [7] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [8] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", W3C Recommendation xpath, November 1999, . [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [10] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999. [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [12] 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 [13] Khartabil, H., "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01 (work in progress), October 2004. [14] Dusseault, L., "Calendaring Extensions to WebDAV (CalDAV)", Mahy Expires September 4, 2006 [Page 12] Internet-Draft A WebDAV alternative to XCAP March 2006 draft-dusseault-caldav-09 (work in progress), December 2005. [15] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol", RFC 3648, December 2003. [16] 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 Plantronics 345 Encincal Street Santa Cruz, CA USA Email: rohan@ekabal.com Mahy Expires September 4, 2006 [Page 13] Internet-Draft A WebDAV alternative to XCAP 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 4, 2006 [Page 14]