SIMPLE WG J. Urpalainen Internet-Draft Nokia Research Center Expires: December 11, 2006 June 9, 2006 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) co-operation with HTTP Extensions for Distributed Authoring (WEBDAV) draft-urpalainen-simple-xcap-webdav-00 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 December 11, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 December 11, 2006 [Page 1]
Internet-Draft XCAP with WebDAV June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. WebDAV Extensions to XCAP . . . . . . . . . . . . . . . . . . 3 4.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Properties . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Locking . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Other WebDAV methods . . . . . . . . . . . . . . . . . . . 5 4.5. Access Control Lists . . . . . . . . . . . . . . . . . . . 5 4.5.1. Server provisioned ACL after a successful PUT . . . . 6 4.5.2. Server provisioned ACL after a successful MKCOL . . . 7 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 7 6. XCAP Server Capabilities extension . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Urpalainen Expires December 11, 2006 [Page 2]
Internet-Draft XCAP with WebDAV June 2006 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 [5] 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 [6] 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 (ACP) [6]. 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. While it is feasible in some cases to have this sort of granularity, this document does not propose such a model mostly because of simplicity and compatibility reasons. Urpalainen Expires December 11, 2006 [Page 3]
Internet-Draft XCAP with WebDAV June 2006 Instead, all WebDAV features, for example properties and locks operate 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 is 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 much overlap with WebDAV ones. 4.1. Collections The core XCAP protocol does not support the creation of collections. WebDAV [4] MKCOL method can then be used to create a collection. With the DELETE method a collection can be removed. 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. 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 resources. The PROPPATCH method sets properties of resources based on QNames [7] and "values" of them. The value of a property is usually a text node content but it may also be of mixed type [8]. Urpalainen Expires December 11, 2006 [Page 4]
Internet-Draft XCAP with WebDAV June 2006 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.3. Locking 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. Note that "lost updates" described in chapter 7.2 [4] are less likely as clients may be updating different parts of XML documents although doing conditional updates always is certainly preferred in general. 4.4. Other WebDAV methods With any other WebDAV methods when accessing XCAP resources, the request URI may not contain an XCAP node selector. 4.5. Access Control Lists In terms of WebDAV access control lists, the core XCAP specifies that the owner of a resource has read and write access rights. With WebDAV ACP [6] a more fine-grained privileges can be given to resources, especially when sharing resources. The privileges ("DAV: read", "DAV:write" and so on) are used by access control elements (ACE). Several ACEs are combined with access control lists (ACL). The owners of documents are principals which are manifested to clients as a WebDAV resource, identified by a URI. WebDAV ACP does not mandate a body for principal resources, only properties are meaningful. It is thus RECOMMENDED that principals have a base URI like "http://principals.example.com/" for a domain "example.com". For a user "joe" the principal URI is then "http://principals.example.com/joe/self". It is anticipated that users can create groups for ACL definitions onto their collections, for example user "joe" has then "DAV:bind" privilege to the collection "http://principals.example.com/joe/". The principal can then create empty group resources or collections with arbitrary names into this collection. 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 Urpalainen Expires December 11, 2006 [Page 5]
Internet-Draft XCAP with WebDAV June 2006 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. Note: XCAP recommends a root URI like "http://xcap.example.com" for a domain "example.com". In theory, principals could be defined as an XCAP application usage, but XCAP application usages have constraints on the body that are not needed for WebDAV ACP principals. 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. 4.5.1. Server provisioned ACL after a successful PUT After a successful PUT (201) request a new XCAP resource has been created to the server. WebDAV ACP [6] specification is quite liberal about the server behavior. In order to ease implementations and to guarantee compatibility with XCAP clients that don't support ACLs, the server MUST provision an ACL for the newly created resource which allows read and 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 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://principals.example.com/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 WebDAV resource then and as with other use cases it MUST not contain an XCAP node selector. Urpalainen Expires December 11, 2006 [Page 6]
Internet-Draft XCAP with WebDAV June 2006 PROPFIND /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" ?> <propfind xmlns="DAV:"> <prop></owner></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:D="DAV:"> <response> <href>http://xcap.example.com/resource-lists/users/joe/index</href> <propstat> <prop> <owner> <href>http://principals.example.com/joe/self</href> </owner> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> 4.5.2. Server provisioned ACL after a successful MKCOL After a successful MKCOL (201) request a new collection has been created to the server. Once again, WebDAV ACP [6] is then quite liberal about the server behavior. Similar to a successful PUT, the server provisions "DAV:all" privilege to the owner of this new collection. 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 Urpalainen Expires December 11, 2006 [Page 7]
Internet-Draft XCAP with WebDAV June 2006 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. If WebDAV methods are used with request URIs which contain an otherwise valid XCAP node selector the server SHOULD respond with 501 (Not Implemented). 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 ACP is supported the <extension> element contains "DAV ACL". 7. IANA Considerations This document does not require any action from IANA. 8. Security Considerations Security considerations described in XCAP [3], WebDAV [4] and WebDAV ACP [6] are naturally also applicable to this specification. Especially using distributed authorization rules may be problematic, for example how to build trust over different domains. Using groups for external "black lists" might reveal unwanted information if they don't keep resources in sync always. Also with distributed groups loops might be generated. However, implementations may disallow distributed authorization rules altogether by responding with appropriate ACL precondition errors. 9. 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 (Third Edition)", W3C Recommendation REC-xml-20040204 , February 2004. [3] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Urpalainen Expires December 11, 2006 [Page 8]
Internet-Draft XCAP with WebDAV June 2006 draft-ietf-simple-xcap-11, May 2006. [4] Dusseault, L., "HTTP Extensions for Distributed Authoring - WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in progress), June 2006. [5] 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. [6] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. [7] "Namespaces in XML", W3C Recommendation REC-xml-names-19990114 , January 1999. [8] "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028 , October 2004. Urpalainen Expires December 11, 2006 [Page 9]
Internet-Draft XCAP with WebDAV June 2006 Author's Address Jari Urpalainen Nokia Research Center Itamerenkatu 11-13 Helsinki 00180 Finland Phone: +358 7180 37686 Email: jari.urpalainen@nokia.com Urpalainen Expires December 11, 2006 [Page 10]
Internet-Draft XCAP with WebDAV June 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. Urpalainen Expires December 11, 2006 [Page 11]