SIMPLE WG J. Urpalainen Internet-Draft Nokia Intended status: Standards Track July 5, 2007 Expires: January 6, 2008 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) co-operation with HTTP Extensions for Distributed Authoring (WEBDAV) draft-urpalainen-simple-xcap-webdav-03 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 January 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) allows a client to read, write and modify application configuration data, stored in XML format on an HTTP server. HTTP Extensions for Distributed Authoring (WebDAV) provides many useful HTTP extensions for web content authoring. This document describes conventions for the co-operation of XCAP resources with WebDAV. Urpalainen Expires January 6, 2008 [Page 1]
Internet-Draft XCAP with WebDAV July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. WebDAV Extensions to XCAP . . . . . . . . . . . . . . . . . . 3 4.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Locking . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Conditional requests with the If-header . . . . . . . . . 4 4.4. Access Control Lists . . . . . . . . . . . . . . . . . . . 5 4.4.1. Server provisioned ACL after a successful PUT . . . . 6 4.4.2. Server provisioned ACL after a successful MKCOL . . . 10 4.4.3. Privileges . . . . . . . . . . . . . . . . . . . . . . 10 4.4.4. Aggregation of privileges . . . . . . . . . . . . . . 10 4.5. Properties . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5.1. XCAP root directory property . . . . . . . . . . . . . 11 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 6. XCAP Server Capabilities extension . . . . . . . . . . . . . . 12 7. RELAX NG Schemas . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Precondition error element . . . . . . . . . . . . . . . . 12 7.2. XCAP root directory property . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:xcap' . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Urpalainen Expires January 6, 2008 [Page 2]
Internet-Draft XCAP with WebDAV July 2007 1. Introduction The Extensible Markup Language (XML) [2] Configuration Access Protocol (XCAP) [3] was designed to store XML documents on an HTTP server. Also patching of XML document components, i.e. XML elements and attributes can be achieved with basic HTTP PUT and DELETE methods. Thus XML documents contain usually many XCAP resources and access to them is achieved by using a node selector in the path segment of the request URI. The document tree structure is also described by the core XCAP protocol. HTTP Extensions for Distributed Authoring (WebDAV) [4] provides many useful HTTP [6] extensions for web content authoring including many other MIME types than just XML documents. The extension set includes properties, collections, locks and namespace operations of WebDAV resources. With WebDAV access control protocol [7] access to shared resources can easily be allowed or denied. This document describes conventions for XCAP servers utilizing these WebDAV authoring extensions. The aim is to use existing specifications with compatibility in mind, an existing XCAP client can still use resources of the server which complies with the rules described in this document. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14 [1] and indicate requirement levels for compliant implementations. 3. Definitions This document uses terms defined in WebDAV [4], XCAP [3] and WebDAV access control protocol (ACL) [7]. 4. WebDAV Extensions to XCAP In XCAP, the request URI contains a node selector when an XML document component is being updated. This selector value can be used to locate for example, an XML element to be removed from the XML document. WebDAV in general does not utilize this sort of granularity of an XML document. This document does not thus propose such a model mostly because of simplicity and compatibility reasons and instead, all WebDAV features, for example properties and locks Urpalainen Expires January 6, 2008 [Page 3]
Internet-Draft XCAP with WebDAV July 2007 operate only on an XML document level, that is, it is not allowed to set some property of an XML element or lock an XML element along with its descendants. In other words, if the request URI contains an XCAP node selector with e.g. a PROPPATCH or any other WebDAV method, an error may be produced. Especially "locked empty resources" with LOCK method might otherwise be created unless this rule is obeyed. Note: Actual implementations can then easily utilize existing libraries as they can dispatch request handlers to appropriate ones: WebDAV or XCAP according to request URIs and HTTP methods: typically, if the request URI contains a node selector and a node selector separator with GET, PUT or DELETE method, XCAP handlers are used and otherwise requests are passed to WebDAV handlers. These handlers are then free to respond with appropriate formats as there are minimal inter-dependencies. In other words, XCAP features do not overlap with WebDAV ones. 4.1. Collections A collection is a container which references child resources. The core XCAP protocol does not support the creation of collections. WebDAV [4] MKCOL method can then be used to create a collection. A collection can be removed with the DELETE method. This WebDAV property is advertised with the OPTIONS query response by "Class 1" compliance. Note: The current XCAP application usages do not specify collection usages in their user "home directories" and some of them only support only single entities (files). In application usages where it makes sense to support collections it is up to the server to decide whether it is allowed or not. 4.2. Locking Locks complement the conditional (ETag) request usages of XCAP resources as they can temporarily disallow other users from making any changes to users resources. Write locking is an optional feature of a WebDAV server. It is advertised with the OPTIONS query response by "Class 2" compliance. Like properties these are supported only at the XML document level. If locks are supported on the server, before the server applies an XCAP component update, addition or removal, the server has to look for possible locks on the corresponding XML document or ancestor collections. 4.3. Conditional requests with the If-header The If request header defined by [4] is intended to have similar functionality to the If-Match header defined in Section 14.24 of [6]. Urpalainen Expires January 6, 2008 [Page 4]
Internet-Draft XCAP with WebDAV July 2007 However, the If-header handles any state token as well as ETags. This If-header can thus also be used with conditional XCAP requests especially when using lock tokens. If resources are referenced within the If-header, they MUST not contain an XCAP node selector. 4.4. Access Control Lists In terms of WebDAV access control lists, the core XCAP specifies that the owner of a resource has typically <DAV:read> and <DAV:write> access rights. With WebDAV ACLs [7] a more fine-grained privileges can be given to users, especially when sharing resources. The privileges (<DAV:read>, <DAV:write> and so on) are used by access control elements (ACE). Several ACEs are combined into an access control list (ACL). The owners of documents are principals which are manifested to clients as an HTTP resource, identified by a URI. A server that implements both WebDAV and XCAP MUST support the same principal namespace for both WebDAV ACL usage and XCAP user identities (XUI). That is, every valid WebDAV principal MUST also be a XUI, and vice versa. XCAP recommends an XCAP root URI is like "http://xcap.example.com" for a domain "example.com". This document RECOMMENDS that the last path segments of a principal URI is of the form "joe/self" for a user "joe" (XUI), in other words, an XUI represents a collection. It is anticipated that users can create private groups onto these collections, for example then the user "joe" has then <DAV:bind> privilege e.g. to the collection "http://xcap.example.com/principals/joe/". The principal can then create group resources, i.e. group principal resources or other collections into this collection. It should be noted that a collection is not regarded as a principal. The "DAV:group-member- set" property contains then the principal URIs belonging to the group. These group resources may then be referenced by ACEs. Also group principal URIs may be referenced by the "DAV:group-member-set" property allowing thus nested groups. For new created groups of a principal the server MUST provision <DAV:all> privileges to the owner (principal) shown later in this document. If the server does not intend to support user defined groups the user will not be provisioned <DAV:bind> privilege to his/her principal collection so clients trying to create a private principal group URI will be responded with 403 "Forbidden" return code. It is RECOMMENDED that while provisioning users for XCAP application usages, users are given <DAV:all> privileges to their application usage "home directories". This allows users full control to them: creation of sub-directories, setting access control rights and so on. Urpalainen Expires January 6, 2008 [Page 5]
Internet-Draft XCAP with WebDAV July 2007 4.4.1. Server provisioned ACL after a successful PUT After a successful PUT (201) request a new XCAP resource has been created to the server. The server may then create an appropriate initial ACL for the document as the WebDAV ACL [7] specification does not mandate any specific server behavior. In order to ease implementations and to guarantee compatibility with XCAP clients that don't support ACLs, the server MUST thus provision an ACL for the newly created resource which allows <DAV:read> and <DAV:write> access for the owner of the resource. Similarly the servers MUST set the authenticated user the owner of the document, which means mapping of the user ID (XUI) to a principal URI. An example ACL document after the creation of a new XCAP resource: <?xml version="1.0" encoding="UTF-8" ?> <acl xmlns="DAV:"> <ace> <principal> <href>http://xcap.example.com/principals/joe/self</href> </principal> <grant> <privilege><all/></privilege> </grant> </ace> </acl> The client can always request the created ACL with PROPFIND method from the server and update it to his/her likings but ACL unaware clients can still continue updating this new resource. An ACL for a WebDAV resource can be set with the ACL method which always publishes the full access control list. The request URI refers to a HTTP resource and it MUST not contain an XCAP node selector. PROPFIND /resource-lists/users/joe/ Host: xcap.example.com Depth: 1 Content-Type: application/xml Content-Length: xxx <?xml version="1.0" encoding="UTF-8" ?> <propfind xmlns="DAV:"> <prop> <owner/> <acl/> <getetag/> </prop> </propfind> Urpalainen Expires January 6, 2008 [Page 6]
Internet-Draft XCAP with WebDAV July 2007 Response: HTTP/1.1 207 Multi-Status Content-Type: application/xml Content-Length: xxxx <?xml version="1.0" encoding="UTF-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://xcap.example.com/resource-lists/users/joe/</href> <propstat> <prop> <owner> <href>http://xcap.example.com/principals/joe/self</href> </owner> <acl> <ace> <principal> <property><owner/></property> </principal> <grant> <privilege><all/></privilege> </grant> </ace> </acl> <getetag>"cf223434-cc347899"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>http://xcap.example.com/resource-lists/users/joe/index</href> <propstat> <prop> <owner> <href>http://xcap.example.com/principals/joe/self</href> </owner> <acl> <ace> <principal> <href>http://xcap.example.com/principals/joe/self</href> </principal> <grant> <privilege><all/></privilege> </grant> </ace> </acl> <getetag>"de33443434-af343455"</getetag> Urpalainen Expires January 6, 2008 [Page 7]
Internet-Draft XCAP with WebDAV July 2007 </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> An example about giving read access to "friends": ACL /resource-lists/users/joe/index Host: xcap.example.com Depth: 0 Content-Type: application/xml Content-Length: xxx <?xml version="1.0" encoding="UTF-8" ?> <acl xmlns="DAV:"> <ace> <principal> <href>http://xcap.example.com/principals/joe/self</href> </principal> <grant> <privilege><all/></privilege> </grant> </ace> <ace> <principal> <href>http://xcap.example.com/principals/joe/friends</href> </principal> <grant> <privilege><read/></privilege> </grant> </ace> </acl> Response: HTTP/1.1 200 OK And the referenced "friends" group can be queried: PROPFIND /principals/joe/ Host: xcap.example.com Depth: 1 Content-Type: application/xml Urpalainen Expires January 6, 2008 [Page 8]
Internet-Draft XCAP with WebDAV July 2007 Content-Length: xxx <?xml version="1.0" encoding="UTF-8" ?> <propfind xmlns="DAV:"> <prop> <group-membership/> <displayname/> </prop> </propfind> Response: HTTP/1.1 207 Multi-Status Content-Type: application/xml Content-Length: xxxx <?xml version="1.0" encoding="UTF-8" ?> <multistatus xmlns="DAV:"> <response> <href>http://xcap.example.com/principals/joe/</href> <propstat> <prop> <group-membership/> <displayname/> </prop> <status>HTTP/1.1 403 Forbidden</status> </propstat> </response> <response> <href>http://xcap.example.com/principals/joe/self</href> <propstat> <prop> <displayname>Joe Smith</displayname> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <group-membership/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>http://xcap.example.com/principals/joe/friends</href> <propstat> <prop> <displayname>Friends of Joe Smith</displayname> Urpalainen Expires January 6, 2008 [Page 9]
Internet-Draft XCAP with WebDAV July 2007 <group-membership> <href>http://xcap.example.com/principals/lisa/self</href> <href>http://xcap.example.com/principals/jack/self</href> <href>http://xcap.example.com/principals/tom/friends</href> </group-membership> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> 4.4.2. Server provisioned ACL after a successful MKCOL After a successful MKCOL (201) request a new collection has been created to the server. Similar to a successful PUT, the server provisions <DAV:all> privilege to the owner of this new collection and sets the authenticated user the owner of a resource. 4.4.3. Privileges The Appendix B of WebDAV ACL [7] specification lists normative privileges for different methods. This specification extends this table for DELETE method so that <DAV:unbind> privilege on a target resource allows also the unbinding of the resource from the parent collection. Note: In practice this means that if a user has a <DAV:all> or a <DAV:write> privilege on a resource, the user is able to perform a successful DELETE operation. 4.4.4. Aggregation of privileges The chapter 3.12 of WebDAV ACL [7] specification defines some allowed and disallowed aggregation rules for <DAV:read> and <DAV:write> and other privileges. Given these constraints and while it is also possible to query the implemented aggregation model of a server with <DAV:supported-privilege-set> it is RECOMMENDED that <DAV:read> contains only <DAV:read-current-user-privilege-set>, i.e. it does not contain <read-acl> privilege and similarly, <DAV:write> does not contain <write-acl> privilege. <DAV:write> will then contain <DAV: bind>, <DAV:unbind>, <DAV:write-properties> and <DAV:write-content> privileges. Urpalainen Expires January 6, 2008 [Page 10]
Internet-Draft XCAP with WebDAV July 2007 4.5. Properties This document does not introduce any constraints to WebDAV [4] properties except that it is only allowed to set/get properties on the document level. XCAP doesn't describe any way to request or set a property of a resource although it uses ETags for conditional updates. For instance these ETag values can easily be queried with PROPFIND method and the result may contain all resources from a collection. This can for example, be used to maintain a simple sync of remote XCAP documents. The PROPPATCH method sets properties of resources based on qualified names (QName) [8] and "values" of them. The value of a property is usually a text node content but it may also be of mixed type [9]. Note: For example, after a successful PUT of an XML element, an XCAP server has to create a new ETag for the document. This ETag is a WebDAV "live" property which MUST be accessible to a WebDAV handler when the ETag value of a resource is being requested. There is thus an inter-dependency between XCAP and WebDAV handling. 4.5.1. XCAP root directory property Principal properties SHOULD be extended with a new WebDAV property: <xcap-root-directories>. This property will list the XCAP root URIs of a user. The property MAY be protected by servers and SHOULD NOT be returned by PROPFIND DAV:allprop request. The element format is defined by the RELAX NG Schema [5] given in Section 7.2. Note: With the aid of this property and the XCAP Server Capability Application Usage clients can then discover all XCAP resources of a user. An alternative is also to utilize <DAV:principal-match> REPORT query to list all resources of a user once the XCAP root directory is known. 5. Error Handling XCAP defines an XML error response format for 409 (Conflict) responses. The usage of WebDAV introduces some new error responses, most notably for example 423 (Locked) response. However, this does not typically impose any problem as requests are typically orthogonal, i.e. error responses either follow XCAP or WebDAV conventions depending on the request type. Some of the XCAP 409 (Conflict) responses can easily be handled automatically without user intervention. Urpalainen Expires January 6, 2008 [Page 11]
Internet-Draft XCAP with WebDAV July 2007 If WebDAV methods (other than GET, PUT or DELETE) are used with request URIs which contain an otherwise valid XCAP node selector the server MAY respond with 403 (Forbidden). The corresponding precondition error element is defined formally by the RELAX NG Schema [5] given in Section 7.1. 6. XCAP Server Capabilities extension XCAP Server Capabilities application usage defines responses to XCAP clients about the XCAP server capabilities. The format includes the possibility to describe extensions of the server. If Class 1, 2 or 3 WebDAV compatibility is supported, the text node content of the <extension> element MUST contain "DAV1", "DAV2" or "DAV3". If the server supports several of them, each property MUST be reported with separate <extension> elements. If WebDAV ACL is supported the <extension> element contains "DAV ACL". 7. RELAX NG Schemas 7.1. Precondition error element RELAX NG schema in compact format for a precondition error response. default namespace = "urn:ietf:params:xml:ns:xcap-error" # error return webdav-request-to-node-selector = element webdav-request-to-node-selector { anything* } # wildcard for any content anything = element * { mixed { (attribute * { text } | anything)* } } 7.2. XCAP root directory property RELAX NG schema in compact format for the "XCAP-root-directory" property. Urpalainen Expires January 6, 2008 [Page 12]
Internet-Draft XCAP with WebDAV July 2007 default namespace = "DAV:" namespace ns1 = "urn:ietf:params:xml:ns:xcap" # xcap home directory xcap-root-directories = element ns1:xcap-root-directories { element href { xsd:anyURI }* } 8. IANA Considerations 8.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:xcap' URI: urn:ietf:params:xml:ns:xcap Description: This is the XML namespace for XCAP root directory property. Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org> Jari Urpalainen, <jari.urpalainen@nokia.com> XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>XCAP root directory</title> </head> <body> <h1>Namespace for XCAP root directory property</h1> <h2>urn:ietf:params:xml:ns:xcap</h2> <p>See <a href="[[[URL of published RFC]]]"> RFCXXXX</a>.</p> </body> </html> END Urpalainen Expires January 6, 2008 [Page 13]
Internet-Draft XCAP with WebDAV July 2007 9. Security Considerations Security considerations described in XCAP [3], WebDAV [4] and WebDAV ACL [7] are naturally applicable to this specification. Especially using "distributed" authorization rules may be problematic, for example how to build trust over different domains. Also with distributed groups loops might be generated. However, implementations may disallow "distributed" authorization rules altogether by responding with appropriate precondition errors. 10. Acknowledgments The author would like to thank Lisa Dusseault, Eva Leppanen and Julian Reschke for their valuable comments. 11. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation REC-xml-20060816 , August 2006. [3] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [4] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. [5] "RELAX NG Specification", Committee Specification 3 , December 2001. [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [7] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. [8] "Namespaces in XML (Second Edition)", W3C Recommendation REC- xml-names-20060816 , August 2006. [9] "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028 , October 2004. Urpalainen Expires January 6, 2008 [Page 14]
Internet-Draft XCAP with WebDAV July 2007 Author's Address Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland Phone: +358 7180 37686 Email: jari.urpalainen@nokia.com Urpalainen Expires January 6, 2008 [Page 15]
Internet-Draft XCAP with WebDAV July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Urpalainen Expires January 6, 2008 [Page 16]