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