draft-ietf-webdav-acl-10.txt		draft-ietf-webdav-acl-11.txt
	INTERNET-DRAFT Geoffrey Clemm, IBM		INTERNET-DRAFT Geoffrey Clemm, IBM
	draft-ietf-webdav-acl-10 Anne Hopkins, Microsoft Corporation		draft-ietf-webdav-acl-11 Anne Hopkins, Microsoft Corporatio
	Eric Sedlar, Oracle Corporation		Eric Sedlar, Oracle Corporation
	Jim Whitehead, U.C. Santa Cruz		Jim Whitehead, U.C. Santa Cruz
	Expires September 15, 2003 March 15, 2003		Expires March 10, 2004 September 10, 2003
	WebDAV Access Control Protocol		WebDAV Access Control Protocol
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions of		This document is an Internet-Draft and is subject to all provisions of
	Section 10 of RFC2026.		Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 material		time. It is inappropriate to use Internet- Drafts as reference material
	or to cite them other than as "work in progress."		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.
	Abstract		Abstract
	This document specifies a set of methods, headers, message bodies,		This document specifies a set of methods, headers, message bodies,
	properties, and reports that define Access Control extensions to the		properties, and reports that define Access Control extensions to the
	WebDAV Distributed Authoring Protocol. This protocol permits a client to		WebDAV Distributed Authoring Protocol. This protocol permits a client
	read and modify access control lists that instruct a server whether to		to read and modify access control lists that instruct a server whether
	allow or deny operations upon a resource (such as HyperText Transfer		to allow or deny operations upon a resource (such as HyperText Transfer
	Protocol (HTTP) method invocations) by a given principal. A lightweight		Protocol (HTTP) method invocations) by a given principal. A lightweight
	representation of principals as Web resources supports integration of a		representation of principals as Web resources supports integration of a
	wide range of user management repositories. Search operations allow		wide range of user management repositories. Search operations allow
	discovery and manipulation of principals using human names.		discovery and manipulation of principals using human names.
	This document is a product of the Web Distributed Authoring and		This document is a product of the Web Distributed Authoring and
	Versioning (WebDAV) working group of the Internet Engineering Task		Versioning (WebDAV) working group of the Internet Engineering Task
	Force. Comments on this draft are welcomed, and should be addressed to		Force. Comments on this draft are welcomed, and should be addressed to
	the acl@webdav.org mailing list. Other related documents can be found at		the acl@webdav.org mailing list. Other related documents can be found
	http://www.example.com/acl/, and		at http://www.example.com/acl/, and
	http://www.ics.uci.edu/pub/ietf/webdav/.		http://www.ics.uci.edu/pub/ietf/webdav/.
	Clemm, et al. [Page 1]		Clemm, Hopkins, Sedlar, Whitehead
			[Page 1]
	Table of Contents		Table of Contents
	WEBDAV ACCESS CONTROL PROTOCOL............................1		1 INTRODUCTION.................................................4
			1.1 Terms......................................................6
	STATUS OF THIS MEMO.......................................1		1.2 Notational Conventions.....................................7
	ABSTRACT..................................................1
	TABLE OF CONTENTS.........................................2
	1 INTRODUCTION...........................................4
	1.1 Terms.................................................6
	1.2 Notational Conventions................................7
	2 PRINCIPALS.............................................7		2 PRINCIPALS...................................................7
	3 PRIVILEGES.............................................8		3 PRIVILEGES...................................................8
	3.1 DAV:read Privilege....................................9		3.1 DAV:read Privilege.........................................9
	3.2 DAV:write Privilege...................................9		3.2 DAV:write Privilege........................................9
	3.3 DAV:write-properties.................................10		3.3 DAV:write-properties.......................................9
	3.4 DAV:write-content....................................10		3.4 DAV:write-content.........................................10
	3.5 DAV:unlock...........................................10		3.5 DAV:unlock................................................10
	3.6 DAV:read-acl Privilege...............................11		3.6 DAV:read-acl Privilege....................................10
	3.7 DAV:read-current-user-privilege-set Privilege........11		3.7 DAV:read-current-user-privilege-set Privilege.............10
	3.8 DAV:write-acl Privilege..............................11		3.8 DAV:write-acl Privilege...................................11
	3.9 DAV:delete Privilege.................................11		3.9 DAV:bind Privilege........................................11
	3.10 DAV:all Privilege..................................11		3.10 DAV:unbind Privilege.....................................11
	3.11 Aggregation of Predefined Privileges...............12		3.11 DAV:all Privilege........................................11
			3.12 Aggregation of Predefined Privileges.....................11
	4 PRINCIPAL PROPERTIES..................................12		4 PRINCIPAL PROPERTIES........................................12
	4.1 DAV:alternate-URI-set................................12		4.1 DAV:alternate-URI-set.....................................12
	4.2 DAV:principal-URL....................................13		4.2 DAV:principal-URL.........................................12
	4.3 DAV:group-member-set.................................13		4.3 DAV:group-member-set......................................12
	4.4 DAV:group-membership.................................13		4.4 DAV:group-membership......................................13
	5 ACCESS CONTROL PROPERTIES.............................13		5 ACCESS CONTROL PROPERTIES...................................13
	5.1 DAV:owner............................................14		5.1 DAV:owner.................................................13
	5.1.1 Example: Retrieving DAV:owner....................14		5.1.1 Example: Retrieving DAV:owner..........................13
	5.1.2 Example: An Attempt to Set DAV:owner.............15		5.1.2 Example: An Attempt to Set DAV:owner...................14
	5.2 DAV:supported-privilege-set..........................16		5.2 DAV:supported-privilege-set...............................15
	5.2.1 Example: Retrieving a List of Privileges Supported on a Resource		5.2.1 Example: Retrieving a List of Privileges Supported on
	16		a Resource.............................................16
	5.3 DAV:current-user-privilege-set.......................19		5.3 DAV:current-user-privilege-set............................18
	5.3.1 Example: Retrieving the User's Current Set of Assigned		5.3.1 Example: Retrieving the User's Current Set of Assigned
	Privileges..............................................19		Privileges...................................................19
	5.4 DAV:acl..............................................20		5.4 DAV:acl...................................................20
	5.4.1 ACE Principal....................................20		5.4.1 ACE Principal..........................................20
	5.4.2 ACE Grant and Deny...............................21		5.4.2 ACE Grant and Deny.....................................21
	5.4.3 ACE Protection...................................22		5.4.3 ACE Protection.........................................21
	5.4.4 ACE Inheritance..................................22		5.4.4 ACE Inheritance........................................21
	5.4.5 Example: Retrieving a Resource's Access Control List 22		5.4.5 Example: Retrieving a Resource's Access Control List ..22
	5.5 DAV: acl-restrictions................................24		5.5 DAV: acl-restrictions.....................................23
	5.5.1 DAV:grant-only...................................24		5.5.1 DAV:grant-only.........................................23
			5.5.2 DAV:no-invert ACE Constraint...........................24
			5.5.3 DAV:deny-before-grant..................................24
			5.5.4 Required Principals....................................24
			Example: Retrieving DAV:acl-restrictions............. ...24
			5.6 DAV:inherited-acl-set.....................................25
			5.7 DAV:principal-collection-set..............................25
			5.7.1 Example: Retrieving DAV:principal-collection-set.......26
			5.8 Example: PROPFIND to retrieve access control properties...27
	Clemm, et al. [Page 2]		Clemm, Hopkins, Sedlar, Whitehead [Page 2]
	5.5.2 DAV:no-invert ACE Constraint.....................24		6 ACL EVALUATION..............................................30
	5.5.3 DAV:deny-before-grant............................24
	5.5.4 Required Principals..............................24
	Example: Retrieving DAV:acl-restrictions................25
	5.6 DAV:inherited-acl-set................................26
	5.7 DAV:principal-collection-set.........................26
	5.7.1 Example: Retrieving DAV:principal-collection-set.27
	5.8 Example: PROPFIND to retrieve access control properties28
	6 ACL EVALUATION........................................31		7 ACCESS CONTROL AND EXISTING METHODS.........................31
			7.1 ANY HTTP METHOD...........................................32
			7.1.1 Error Handling.........................................32
			7.2 OPTIONS...................................................32
			7.2.1 Example - OPTIONS......................................33
			7.3 MOVE......................................................33
			7.4 COPY......................................................33
			7.5 LOCK......................................................33
	7 ACCESS CONTROL AND EXISTING METHODS...................32		8 ACCESS CONTROL METHODS......................................33
	7.1 OPTIONS..............................................32		8.1 ACL.......................................................33
	7.1.1 Example - OPTIONS................................32		8.1.1 ACL Preconditions......................................34
	7.2 MOVE.................................................33		8.1.2 Example: the ACL method................................35
	7.3 COPY.................................................33		8.1.3 Example: ACL method failure due to protected ACE
	7.4 LOCK.................................................33		conflict...............................................36
			8.1.4 Example: ACL method failure due to an inherited ACE
			conflict...............................................37
			8.1.5 Example: ACL method failure due to an attempt to set
			grant and deny in a single ACE.........................38
	8 ACCESS CONTROL METHODS................................33		9 ACCESS CONTROL REPORTS......................................39
	8.1 ACL..................................................33		9.1 REPORT Method.............................................39
	8.1.1 ACL Preconditions................................34		9.2 DAV:acl-principal-prop-set Report.........................39
	8.1.2 Example: the ACL method..........................35		9.2.1 Example: DAV:acl-principal-prop-set Report.............40
	8.1.3 Example: ACL method failure due to protected ACE conflict 36		9.3 DAV:principal-match REPORT................................42
	8.1.4 Example: ACL method failure due to an inherited ACE conflict 37		9.3.1 Example: DAV:principal-match REPORT....................43
	8.1.5 Example: ACL method failure due to an attempt to set grant and		9.4 DAV:principal-property-search REPORT......................43
	deny in a single ACE....................................38		9.4.1 Matching...............................................45
			9.4.2 Example: successful DAV:principal-property-search
			REPORT.................................................46
			9.5 DAV:principal-search-property-set REPORT..................48
			9.5.1 Example: DAV:principal-search-property-set REPORT......49
	9 ACCESS CONTROL REPORTS................................39		10 XML PROCESSING............................................50
	9.1 REPORT Method........................................39
	9.2 DAV:acl-principal-prop-set Report....................40
	9.2.1 Example: DAV:acl-principal-prop-set Report.......41
	9.3 DAV:principal-match REPORT...........................42
	9.3.1 Example: DAV:principal-match REPORT..............43
	9.4 DAV:principal-property-search REPORT.................44
	9.4.1 Matching.........................................46
	9.4.2 Example: successful DAV:principal-property-search REPORT 46
	9.4.3 Example: Unsuccessful DAV:principal-property-search REPORT 48
	9.5 DAV:principal-search-property-set REPORT.............49
	9.5.1 Example: DAV:principal-search-property-set REPORT50
	10 XML PROCESSING.......................................51		11 INTERNATIONALIZATION CONSIDERATIONS.......................50
	11 INTERNATIONALIZATION CONSIDERATIONS..................51		12 SECURITY CONSIDERATIONS...................................51
			12.1 Increased Risk of Compromised Users......................51
			12.2 Risks of the DAV:read-acl and
			DAV:current-user-privilege-set Privileges................51
			12.3 No Foreknowledge of Initial ACL..........................52
	12 SECURITY CONSIDERATIONS..............................52		13 AUTHENTICATION............................................52
	12.1 Increased Risk of Compromised Users................52
	12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
	Privileges...............................................53
	12.3 No Foreknowledge of Initial ACL....................53
	13 AUTHENTICATION.......................................54		14 IANA CONSIDERATIONS.......................................52
	14 IANA CONSIDERATIONS..................................54		15 INTELLECTUAL PROPERTY.....................................53
	Clemm, et al. [Page 3]		16 ACKNOWLEDGEMENTS..........................................53
	15 INTELLECTUAL PROPERTY................................54
	16 ACKNOWLEDGEMENTS.....................................55		17 REFERENCES................................................53
			17.1 Normative References.....................................53
	17 REFERENCES...........................................55		Clemm, Hopkins, Sedlar, Whitehead [Page 3]
	17.1 Normative References...............................55		17.2 Informational References.................................54
	17.2 Informational References...........................56
	18 AUTHORS' ADDRESSES...................................57		18 AUTHORS' ADDRESSES........................................55
	19 APPENDICES...........................................58		19 APPENDICES................................................56
	19.1 WebDAV XML Document Type Definition Addendum.......58		19.1 WebDAV XML Document Type Definition Addendum.............56
	19.2 WebDAV Method Privilege Table (Normative)..........60		19.2 WebDAV Method Privilege Table (Normative)................58
	1 INTRODUCTION		1 INTRODUCTION
	The goal of the WebDAV access control extensions is to provide an		The goal of the WebDAV access control extensions is to provide an
	interoperable mechanism for handling discretionary access control		interoperable mechanism for handling discretionary access control
	for content and metadata managed by WebDAV servers. WebDAV access		for content and metadata managed by WebDAV servers. WebDAV access
	control can be implemented on content repositories with security as		control can be implemented on content repositories with security
	simple as that of a UNIX file system, as well as more sophisticated		as simple as that of a UNIX file system, as well as more
	models. The underlying principle of access control is that who you		sophisticated models. The underlying principle of access control
	are determines what operations you can perform on a resource. The		is that who you are determines what operations you can perform on
	"who you are" is defined by a "principal" identifier; users, client		a resource. The "who you are" is defined by a "principal"
	software, servers, and groups of the previous have principal		identifier; users, client software, servers, and groups of the
	identifiers. The "operations you can perform" are determined by a		previous have principal identifiers. The "operations you can
	single "access control list" (ACL) associated with a resource. An		perform" are determined by a single "access control list" (ACL)
	ACL contains a set of "access control entries" (ACEs), where each		associated with a resource. An ACL contains a set of "access
	ACE specifies a principal and a set of privileges that are either		control entries" (ACEs), where each ACE specifies a principal and
	granted or denied to that principal. When a principal submits an		a set of privileges that are either granted or denied to that
	operation (such as an HTTP or WebDAV method) to a resource for		principal. When a principal submits an operation (such as an HTTP
	execution, the server evaluates the ACEs in the ACL to determine if		or WebDAV method) to a resource for execution, the server
	the principal has permission for that operation.		evaluates the ACEs in the ACL to determine if the principal has
			permission for that operation.
	Since every ACE contains the identifier of a principal, client		Since every ACE contains the identifier of a principal, client
	software operated by a human must provide a mechanism for selecting		software operated by a human must provide a mechanism for
	this principal. This specification uses http(s) scheme URLs to		selecting this principal. This specification uses http(s) scheme
	identify principals, which are represented as WebDAV-capable		URLs to identify principals, which are represented as WebDAV-
	resources. There is no guarantee that the URLs identifying		capable resources. There is no guarantee that the URLs identifying
	principals will be meaningful to a human. For example,		principals will be meaningful to a human. For example,
	http://www.example.com/u/256432 and		http://www.example.com/u/256432 and
	http://www.example.com/people/Greg.Stein are both valid URLs that		http://www.example.com/people/Greg.Stein are both valid URLs that
	could be used to identify the same principal. To remedy this, every		could be used to identify the same principal. To remedy this,
	principal resource has the DAV:displayname property containing a		every principal resource has the DAV:displayname property
	human-readable name for the principal.		containing a human-readable name for the principal.
			Since a principal can be identified by multiple URLs, it raises
	Since a principal can be identified by multiple URLs, it raises the		the problem of determining exactly which principal is being
	problem of determining exactly which principal is being referenced		referenced in a given ACE. It is impossible for a client to
	in a given ACE. It is impossible for a client to determine that an		determine that an ACE granting the read privilege to
	ACE granting the read privilege to		http://www.example.com/people/Greg.Stein also affects the
	http://www.example.com/people/Greg.Stein also affects the principal		principal at http://www.example.com/u/256432. That is, a client
	at http://www.example.com/u/256432. That is, a client has no		has no mechanism for determining that two URLs identify the same
	mechanism for determining that two URLs identify the same principal		principal resource. As a result, this specification requires
			clients to use just one of the many possible URLs for a principal
	Clemm, et al. [Page 4]		when creating ACEs. A client can discover which URL to use by
	resource. As a result, this specification requires clients to use		retrieving the DAV:principal-URL property (Section 4.2) from a
	just one of the many possible URLs for a principal when creating		principal resource. No matter which of the principal's URLs is
	ACEs. A client can discover which URL to use by retrieving the		used with PROPFIND, the property always returns the same URL.
	DAV:principal-URL property (Section 4.2) from a principal resource.
	No matter which of the principal's URLs is used with PROPFIND, the
	property always returns the same URL.
			Clemm, Hopkins, Sedlar, Whitehead [Page 4]
	With a system having hundreds to thousands of principals, the		With a system having hundreds to thousands of principals, the
	problem arises of how to allow a human operator of client software		problem arises of how to allow a human operator of client software
	to select just one of these principals. One approach is to use		to select just one of these principals. One approach is to use
	broad collection hierarchies to spread the principals over a large		broad collection hierarchies to spread the principals over a large
	number of collections, yielding few principals per collection. An		number of collections, yielding few principals per collection. An
	example of this is a two level hierarchy with the first level		example of this is a two level hierarchy with the first level
	containing 36 collections (a-z, 0-9), and the second level being		containing 36 collections (a-z, 0-9), and the second level being
	another 36, creating collections /a/a/, /a/b/, ..., /a/z/, such		another 36, creating collections /a/a/, /a/b/, ..., /a/z/, such
	that a principal with last name "Stein" would appear at /s/t/Stein.		that a principal with last name "Stein" would appear at
	In effect, this pre-computes a common query, search on last name,		/s/t/Stein. In effect, this pre-computes a common query, search on
	and encodes it into a hierarchy. The drawback with this scheme is		last name, and encodes it into a hierarchy. The drawback with this
	that it handles only a small set of predefined queries, and		scheme is that it handles only a small set of predefined queries,
	drilling down through the collection hierarchy adds unnecessary		and drilling down through the collection hierarchy adds
	steps (navigate down/up) when the user already knows the		unnecessary steps (navigate down/up) when the user already knows
	principal's name. While organizing principal URLs into a hierarchy		the principal's name. While organizing principal URLs into a
	is a valid namespace organization, users should not be forced to		hierarchy is a valid namespace organization, users should not be
	navigate this hierarchy to select a principal.		forced to navigate this hierarchy to select a principal.
	This specification provides the capability to perform substring		This specification provides the capability to perform substring
	searches over a small set of properties on the resources		searches over a small set of properties on the resources
	representing principals. This permits searches based on last name,		representing principals. This permits searches based on last name,
	first name, user name, job title, etc. Two separate searches are		first name, user name, job title, etc. Two separate searches are
	supported, both via the REPORT method, one to search principal		supported, both via the REPORT method, one to search principal
	resources (DAV:principal-property-search, Section 9.4), the other		resources (DAV:principal-property-search, Section 9.4), the other
	to determine which properties may be searched at all		to determine which properties may be searched at all
	(DAV:principal-search-property-set, Section 9.5).		(DAV:principal-search-property-set, Section 9.5).
			Once a principal has been identified in an ACE, a server
	Once a principal has been identified in an ACE, a server evaluating		evaluating that ACE must know the identity of the principal making
	that ACE must know the identity of the principal making a protocol		a protocol request, and must validate that that principal is who
	request, and must validate that that principal is who they claim to		they claim to be, a process known as authentication. This
	be, a process known as authentication. This specification		specification intentionally omits discussion of authentication, as
	intentionally omits discussion of authentication, as the HTTP		the HTTP protocol already has a number of authentication
	protocol already has a number of authentication mechanisms		mechanisms [RFC2617]. Some authentication mechanism (such as HTTP
	[RFC2617]. Some authentication mechanism (such as HTTP Digest		Digest Authentication, which all WebDAV compliant implementations
	Authentication, which all WebDAV compliant implementations are		are required to support) must be available to validate the
	required to support) must be available to validate the identity of		identity of a principal.
	a principal.
	The following issues are out of scope for this document:		The following issues are out of scope for this document:
			. Access control that applies only to a particular property on
	Access control that applies only to a particular property on a		a resource (excepting the access control properties DAV:acl
	resource (excepting the access control properties DAV:acl and		and DAV:current-user-privilege-set), rather than the entire
	DAV:current-user-privilege-set), rather than the entire resource,		resource,
			. Role-based security (where a role can be seen as a
	Role-based security (where a role can be seen as a dynamically		dynamically defined group of principals),
	defined group of principals),		. Specification of the ways an ACL on a resource is
			initialized,
	Clemm, et al. [Page 5]		. Specification of an ACL that applies globally to all
	Specification of the ways an ACL on a resource is initialized,		resources, rather than to a particular resource.
			. Creation and maintenance of resources representing people or
	Specification of an ACL that applies globally to all resources,
	rather than to a particular resource.
	Creation and maintenance of resources representing people or
	computational agents (principals), and groups of these.		computational agents (principals), and groups of these.
	This specification is organized as follows. Section 1.1 defines key		Clemm, Hopkins, Sedlar, Whitehead [Page 5]
	concepts used throughout the specification, and is followed by a		This specification is organized as follows. Section 1.1 defines
	more in-depth discussion of principals (Section 2), and privileges		key concepts used throughout the specification, and is followed by
	(Section 3). Properties defined on principals are specified in		a more in-depth discussion of principals (Section 2), and
	Section 4, and access control properties for content resources are		privileges (Section 3). Properties defined on principals are
	specified in Section 5. The ways ACLs are to be evaluated is		specified in Section 4, and access control properties for content
	described in section 6. Client discovery of access control		resources are specified in Section 5. The ways ACLs are to be
	capability using OPTIONS is described in Section 7.1. Interactions		evaluated is described in section 6. Client discovery of access
	between access control functionality and existing HTTP and WebDAV		control capability using OPTIONS is described in Section 7.1.
	methods are described in the remainder of Section 7. The access		Interactions between access control functionality and existing
	control setting method, ACL, is specified in Section 8. Four		HTTP and WebDAV methods are described in the remainder of Section
	reports that provide limited server-side searching capabilities are		7. The access control setting method, ACL, is specified in Section
	described in Section 9. Sections on XML processing (Section 10),		8. Four reports that provide limited server-side searching
	Internationalization considerations (Section 11), security		capabilities are described in Section 9. Sections on XML
	considerations (Section 12), and authentication (Section 13) round		processing (Section 10), Internationalization considerations
	out the specification. An appendix (Section 19.1) provides an XML		(Section 11), security considerations (Section 12), and
	Document Type Definition (DTD) for the XML elements defined in the		authentication (Section 13) round out the specification. An
	specification.		appendix (Section 19.1) provides an XML Document Type Definition
			(DTD) for the XML elements defined in the specification.
	1.1 Terms		1.1 Terms
	This draft uses the terms defined in HTTP [RFC2616] and WebDAV		This draft uses the terms defined in HTTP [RFC2616] and WebDAV
	[RFC2518]. In addition, the following terms are defined:		[RFC2518]. In addition, the following terms are defined:
	principal		principal
	A "principal" is a distinct human or computational actor that		A "principal" is a distinct human or computational actor that
	initiates access to network resources. In this protocol, a		initiates access to network resources. In this protocol, a
	principal is an HTTP resource that represents such an actor.		principal is an HTTP resource that represents such an actor.
	group		group
			A "group" is a principal that represents a set of other
	A "group" is a principal that represents a set of other principals.		principals.
	privilege		privilege
	A "privilege" controls access to a particular set of HTTP		A "privilege" controls access to a particular set of HTTP
	operations on a resource.		operations on a resource.
	aggregate privilege		aggregate privilege
	An "aggregate privilege" is a privilege that contains a set of		An "aggregate privilege" is a privilege that contains a set of
	other privileges.		other privileges.
	abstract privilege		abstract privilege
			The modifier "abstract", when applied to a privilege on a
	Clemm, et al. [Page 6]		resource, means the privilege cannot be set in an access control
	The modifier "abstract", when applied to a privilege on a resource,		element (ACE) on that resource .
	means the privilege cannot be set in an access control element
	(ACE) on that resource .
	access control list (ACL)		access control list (ACL)
	An "ACL" is a list of access control elements that define access		An "ACL" is a list of access control elements that define access
	control to a particular resource.		control to a particular resource.
	access control element (ACE)		access control element (ACE)
			An "ACE" either grants or denies a particular set of (non-
			abstract) privileges for a particular principal.
	An "ACE" either grants or denies a particular set of (non-abstract)		Clemm, Hopkins, Sedlar, Whitehead [Page 6]
	privileges for a particular principal.
	inherited ACE		inherited ACE
	An "inherited ACE" is an ACE that is dynamically shared from the		An "inherited ACE" is an ACE that is dynamically shared from the
	ACL of another resource. When a shared ACE changes on the primary		ACL of another resource. When a shared ACE changes on the primary
	resource, it is also changed on inheriting resources.		resource, it is also changed on inheriting resources.
	protected property		protected property
	A "protected property" is one whose value cannot be updated except		A "protected property" is one whose value cannot be updated except
	by a method explicitly defined as updating that specific property.		by a method explicitly defined as updating that specific property.
	In particular, a protected property cannot be updated with a		In particular, a protected property cannot be updated with a
	PROPPATCH request.		PROPPATCH request.
	1.2 Notational Conventions		1.2 Notational Conventions
	The augmented BNF used by this document to describe protocol		The augmented BNF used by this document to describe protocol
	elements is described in Section 2.1 of [RFC2616]. Because this		elements is described in Section 2.1 of [RFC2616]. Because this
	augmented BNF uses the basic production rules provided in Section		augmented BNF uses the basic production rules provided in Section
	skipping to change at line 357		skipping to change at line 326
	by a method explicitly defined as updating that specific property.		by a method explicitly defined as updating that specific property.
	In particular, a protected property cannot be updated with a		In particular, a protected property cannot be updated with a
	PROPPATCH request.		PROPPATCH request.
	1.2 Notational Conventions		1.2 Notational Conventions
	The augmented BNF used by this document to describe protocol		The augmented BNF used by this document to describe protocol
	elements is described in Section 2.1 of [RFC2616]. Because this		elements is described in Section 2.1 of [RFC2616]. Because this
	augmented BNF uses the basic production rules provided in Section		augmented BNF uses the basic production rules provided in Section
	2.2 of [RFC2616], those rules apply to this document as well.		2.2 of [RFC2616], those rules apply to this document as well.
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		in this document are to be interpreted as described in [RFC2119].
	this document are to be interpreted as described in [RFC2119].
	Definitions of XML elements in this document use XML element type		Definitions of XML elements in this document use XML element type
	declarations (as found in XML Document Type Declarations),		declarations (as found in XML Document Type Declarations),
	described in Section 3.2 of [REC-XML]. When an XML element type in		described in Section 3.2 of [REC-XML]. When an XML element type in
	the "DAV:" namespace is referenced in this document outside of the		the "DAV:" namespace is referenced in this document outside of the
	context of an XML fragment, the string "DAV:" will be prefixed to		context of an XML fragment, the string "DAV:" will be prefixed to
	the element name.		the element name.
	2 PRINCIPALS		2 PRINCIPALS
	A principal is a network resource that represents a distinct human		A principal is a network resource that represents a distinct human
	or computational actor that initiates access to network resources.		or computational actor that initiates access to network resources.
	Users and groups are represented as principals in many		Users and groups are represented as principals in many
	implementations; other types of principals are also possible. A URI		implementations; other types of principals are also possible. A
	of any scheme MAY be used to identify a principal resource.		URI of any scheme MAY be used to identify a principal resource.
	Clemm, et al. [Page 7]
	However, servers implementing this specification MUST expose		However, servers implementing this specification MUST expose
	principal resources at an http(s) URL, which is a privileged scheme		principal resources at an http(s) URL, which is a privileged
	that points to resources that have additional properties, as		scheme that points to resources that have additional properties,
	described in Section 4. So, a principal resource can have multiple		as described in Section 4. So, a principal resource can have
	URIs, one of which has to be an http(s) scheme URL. Although an		multiple URIs, one of which has to be an http(s) scheme URL.
	implementation SHOULD support PROPFIND and MAY support PROPPATCH to		Although an implementation SHOULD support PROPFIND and MAY support
	access and modify information about a principal, it is not required		PROPPATCH to access and modify information about a principal, it
	to do so.		is not required to do so.
	A principal resource may be a group, where a group is a principal		A principal resource may be a group, where a group is a principal
	that represents a set of other principals, called the members of		that represents a set of other principals, called the members of
	the group. If a person or computational agent matches a principal		the group. If a person or computational agent matches a principal
	resource that is a member of a group, they also match the group.		resource that is a member of a group, they also match the group.
	Membership in a group is recursive, so if a principal is a member		Membership in a group is recursive, so if a principal is a member
	of group GRPA, and GRPA is a member of group GRPB, then the		of group GRPA, and GRPA is a member of group GRPB, then the
	principal is also a member of GRPB.		principal is also a member of GRPB.
			Clemm, Hopkins, Sedlar, Whitehead [Page 7]
	3 PRIVILEGES		3 PRIVILEGES
	Ability to perform a given method on a resource MUST be controlled		Ability to perform a given method on a resource MUST be controlled
	by one or more privileges. Authors of protocol extensions that		by one or more privileges. Authors of protocol extensions that
	define new HTTP methods SHOULD specify which privileges (by		define new HTTP methods SHOULD specify which privileges (by
	defining new privileges, or mapping to ones below) are required to		defining new privileges, or mapping to ones below) are required to
	perform the method. A principal with no privileges to a resource		perform the method. A principal with no privileges to a resource
	MUST be denied any HTTP access to that resource, unless the		MUST be denied any HTTP access to that resource, unless the
	principal matches an ACE constructed using the DAV:all,		principal matches an ACE constructed using the DAV:all,
	DAV:authenticated, or DAV:unauthenticated pseudo-principals (see		DAV:authenticated, or DAV:unauthenticated pseudo-principals (see
	skipping to change at line 409		skipping to change at line 374
	define new HTTP methods SHOULD specify which privileges (by		define new HTTP methods SHOULD specify which privileges (by
	defining new privileges, or mapping to ones below) are required to		defining new privileges, or mapping to ones below) are required to
	perform the method. A principal with no privileges to a resource		perform the method. A principal with no privileges to a resource
	MUST be denied any HTTP access to that resource, unless the		MUST be denied any HTTP access to that resource, unless the
	principal matches an ACE constructed using the DAV:all,		principal matches an ACE constructed using the DAV:all,
	DAV:authenticated, or DAV:unauthenticated pseudo-principals (see		DAV:authenticated, or DAV:unauthenticated pseudo-principals (see
	Section 5.4.1). Servers MUST report a 403 "Forbidden" error if		Section 5.4.1). Servers MUST report a 403 "Forbidden" error if
	access is denied, except in the case where the privilege restricts		access is denied, except in the case where the privilege restricts
	the ability to know the resource exists, in which case 404 "Not		the ability to know the resource exists, in which case 404 "Not
	Found" may be returned.		Found" may be returned.
	Privileges may be containers of other privileges, in which case		Privileges may be containers of other privileges, in which case
	they are termed "aggregate privileges". If a principal is granted		they are termed "aggregate privileges". If a principal is granted
	or denied an aggregate privilege, it is semantically equivalent to		or denied an aggregate privilege, it is semantically equivalent to
	granting or denying each of the aggregated privileges individually.		granting or denying each of the aggregated privileges
	For example, an implementation may define add-member and remove-		individually. For example, an implementation may define add-
	member privileges that control the ability to add and remove a		member and remove-member privileges that control the ability to
	member of a group. Since these privileges control the ability to		add and remove a member of a group. Since these privileges
	update the state of a group, these privileges would be aggregated		control the ability to update the state of a group, these
	by the DAV:write privilege on a group, and granting the DAV:write		privileges would be aggregated by the DAV:write privilege on a
	privilege on a group would also grant the add-member and remove-		group, and granting the DAV:write privilege on a group would also
	member privileges.		grant the add-member and remove-member privileges.
	Privileges may be declared to be "abstract" for a given resource,		Privileges may be declared to be "abstract" for a given resource,
	in which case they cannot be set in an ACE on that resource.		in which case they cannot be set in an ACE on that resource.
	Aggregate and non-aggregate privileges are both capable of being		Aggregate and non-aggregate privileges are both capable of being
	abstract. Abstract privileges are useful for modeling privileges		abstract. Abstract privileges are useful for modeling privileges
	that otherwise would not be exposed via the protocol. Abstract		that otherwise would not be exposed via the protocol. Abstract
	privileges also provide server implementations with flexibility in		privileges also provide server implementations with flexibility in
	implementing the privileges defined in this specification. For		implementing the privileges defined in this specification. For
	example, if a server is incapable of separating the read resource		example, if a server is incapable of separating the read resource
	capability from the read ACL capability, it can still model the		capability from the read ACL capability, it can still model the
	Clemm, et al. [Page 8]
	DAV:read and DAV:read-acl privileges defined in this specification		DAV:read and DAV:read-acl privileges defined in this specification
	by declaring them abstract, and containing them within a non-		by declaring them abstract, and containing them within a non-
	abstract aggregate privilege (say, read-all) that holds DAV:read,		abstract aggregate privilege (say, read-all) that holds DAV:read,
	and DAV:read-acl. In this way, it is possible to set the aggregate		and DAV:read-acl. In this way, it is possible to set the aggregate
	privilege, read-all, thus coupling the setting of DAV:read and		privilege, read-all, thus coupling the setting of DAV:read and
	DAV:read-acl, but it is not possible to set DAV:read, or DAV:read-		DAV:read-acl, but it is not possible to set DAV:read, or DAV:read-
	acl individually. Since aggregate privileges can be abstract, it is		acl individually. Since aggregate privileges can be abstract, it
	also possible to use abstract privileges to group or organize non-		is also possible to use abstract privileges to group or organize
	abstract privileges. Privilege containment loops are not allowed;		non-abstract privileges. Privilege containment loops are not
	therefore, a privilege MUST NOT contain itself. For example,		allowed; therefore, a privilege MUST NOT contain itself. For
	DAV:read cannot contain DAV:read.		example, DAV:read cannot contain DAV:read.
	The set of privileges that apply to a particular resource may vary		The set of privileges that apply to a particular resource may vary
	with the DAV:resourcetype of the resource, as well as between		with the DAV:resourcetype of the resource, as well as between
	different server implementations. To promote interoperability,		different server implementations. To promote interoperability,
	however, this specification defines a set of well-known privileges		however, this specification defines a set of well-known privileges
	(e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-		(e.g. DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, DAV:read-
	current-user-privilege-set, and DAV:all), which can at least be		current-user-privilege-set, and DAV:all), which can at least be
	used to classify the other privileges defined on a particular		used to classify the other privileges defined on a particular
			Clemm, Hopkins, Sedlar, Whitehead [Page 8]
	resource. The access permissions on null resources (defined in		resource. The access permissions on null resources (defined in
	[RFC2518], Section 3) are solely those they inherit (if any), and		[RFC2518], Section 3) are solely those they inherit (if any), and
	they are not discoverable (i.e., the access control properties		they are not discoverable (i.e., the access control properties
	specified in Section 5 are not defined on null resources). On the		specified in Section 5 are not defined on null resources). On the
	transition from null to stateful resource, the initial access		transition from null to stateful resource, the initial access
	control list is set by the server's default ACL value policy (if		control list is set by the server's default ACL value policy (if
	any).		any).
	Server implementations MAY define new privileges beyond those		Server implementations MAY define new privileges beyond those
	defined in this specification. Privileges defined by individual		defined in this specification. Privileges defined by individual
	implementations MUST NOT use the DAV: namespace, and instead should		implementations MUST NOT use the DAV: namespace, and instead
	use a namespace that they control, such as an http scheme URL.		should use a namespace that they control, such as an http scheme
			URL.
	3.1 DAV:read Privilege		3.1 DAV:read Privilege
	The read privilege controls methods that return information about		The read privilege controls methods that return information about
	the state of the resource, including the resource's properties.		the state of the resource, including the resource's properties.
	Affected methods include GET and PROPFIND. Any implementation-		Affected methods include GET and PROPFIND. Any implementation-
	defined privilege that also controls access to GET and PROPFIND		defined privilege that also controls access to GET and PROPFIND
	must be aggregated under DAV:read—if an ACL grants access to		must be aggregated under DAV:read—if an ACL grants access to
	DAV:read, the client may expect that no other privilege needs to be		DAV:read, the client may expect that no other privilege needs to
	granted to have access to GET and PROPFIND. Additionally, the read		be granted to have access to GET and PROPFIND. Additionally, the
	privilege MUST control the OPTIONS method.		read privilege MUST control the OPTIONS method.
	<!ELEMENT read EMPTY>		<!ELEMENT read EMPTY>
	3.2 DAV:write Privilege		3.2 DAV:write Privilege
	The write privilege controls methods that lock a resource or modify		The write privilege controls methods that lock a resource or
	the content, dead properties, or (in the case of a collection)		modify the content, dead properties, or (in the case of a
	membership of the resource, such as PUT and PROPPATCH. Note that		collection) membership of the resource, such as PUT and PROPPATCH.
	state modification is also controlled via locking (see section 5.3		Note that state modification is also controlled via locking (see
	of [WEBDAV]), so effective write access requires that both write		section 5.3 of [WEBDAV]), so effective write access requires that
	privileges and write locking requirements are satisfied. Any		both write privileges and write locking requirements are
			satisfied. Any implementation-defined privilege that also
	Clemm, et al. [Page 9]		controls access to methods modifying content, dead properties or
	implementation-defined privilege that also controls access to		collection membership must be aggregated under DAV:write, e.g. if
	methods modifying content, dead properties or collection membership		an ACL grants access to DAV:write, the client may expect that no
	must be aggregated under DAV:write, e.g. if an ACL grants access to		other privilege needs to be granted to have access to PUT and
	DAV:write, the client may expect that no other privilege needs to		PROPPATCH.
	be granted to have access to PUT and PROPPATCH.
	<!ELEMENT write EMPTY>		<!ELEMENT write EMPTY>
	3.3 DAV:write-properties		3.3 DAV:write-properties
	The DAV:write-properties privilege controls methods that modify the		The DAV:write-properties privilege controls methods that modify
	dead properties of the resource, such as PROPPATCH. Whether this		the dead properties of the resource, such as PROPPATCH. Whether
	privilege may be used to control access to any live properties is		this privilege may be used to control access to any live
	determined by the implementation. Any implementation-defined		properties is determined by the implementation. Any
	privilege that also controls access to methods modifying dead		implementation-defined privilege that also controls access to
	properties must be aggregated under DAV:write-properties—e.g. if an		methods modifying dead properties must be aggregated under
	ACL grants access to DAV:write-properties, the client can safely		DAV:write-properties—e.g. if an ACL grants access to DAV:write-
	expect that no other privilege needs to be granted to have access		properties, the client can safely expect that no other privilege
	to PROPPATCH.		needs to be granted to have access to PROPPATCH.
			Clemm, Hopkins, Sedlar, Whitehead [Page 9]
	<!ELEMENT write-properties EMPTY>		<!ELEMENT write-properties EMPTY>
	3.4 DAV:write-content		3.4 DAV:write-content
	The DAV:write-content privilege controls methods that modify the		The DAV:write-content privilege controls methods that modify the
	content or (in the case of a collection) membership of the		content or (in the case of a collection) membership of the
	resource, such as PUT and DELETE. Any implementation-defined		resource, such as PUT and DELETE. Any implementation-defined
	privilege that also controls access to content or alteration of		privilege that also controls access to content or alteration of
	collection membership must be aggregated under DAV:write-content—		collection membership must be aggregated under DAV:write-content—
	e.g. if an ACL grants access to DAV:write-content, the client can		e.g. if an ACL grants access to DAV:write-content, the client can
	skipping to change at line 520		skipping to change at line 480
	3.4 DAV:write-content		3.4 DAV:write-content
	The DAV:write-content privilege controls methods that modify the		The DAV:write-content privilege controls methods that modify the
	content or (in the case of a collection) membership of the		content or (in the case of a collection) membership of the
	resource, such as PUT and DELETE. Any implementation-defined		resource, such as PUT and DELETE. Any implementation-defined
	privilege that also controls access to content or alteration of		privilege that also controls access to content or alteration of
	collection membership must be aggregated under DAV:write-content—		collection membership must be aggregated under DAV:write-content—
	e.g. if an ACL grants access to DAV:write-content, the client can		e.g. if an ACL grants access to DAV:write-content, the client can
	safely expect that no other privilege needs to be granted to have		safely expect that no other privilege needs to be granted to have
	access to PUT or DELETE.		access to PUT or DELETE.
	<!ELEMENT write-content EMPTY>		<!ELEMENT write-content EMPTY>
	3.5 DAV:unlock		3.5 DAV:unlock
	The DAV:unlock privilege controls the use of the UNLOCK method by a		The DAV:unlock privilege controls the use of the UNLOCK method by
	principal other than the lock owner (the principal that created a		a principal other than the lock owner (the principal that created
	lock can always perform an UNLOCK). While the set of users who may		a lock can always perform an UNLOCK). While the set of users who
	lock a resource is most commonly the same set of users who may		may lock a resource is most commonly the same set of users who may
	modify a resource, servers may allow various kinds of		modify a resource, servers may allow various kinds of
	administrators to unlock resources locked by others. Any privilege		administrators to unlock resources locked by others. Any privilege
	controlling access by non-lock owners to UNLOCK MUST be aggregated		controlling access by non-lock owners to UNLOCK MUST be aggregated
	under DAV:unlock.		under DAV:unlock.
			A lock owner can always remove a lock by issuing an UNLOCK with
	A lock owner can always remove a lock by issuing an UNLOCK with the		the correct lock token and authentication credentials. That is,
	correct lock token and authentication credentials. That is, even if		even if a principal does not have DAV:unlock privilege, they can
	a principal does not have DAV:unlock privilege, they can still		still remove locks they own. Principals other than the lock owner
	remove locks they own. Principals other than the lock owner can		can remove a lock only if they have DAV:unlock privilege and they
	remove a lock only if they have DAV:unlock privilege and they issue		issue an UNLOCK with the correct lock token. Lock timeout is not
	an UNLOCK with the correct lock token. Lock timeout is not affected		affected by the DAV:unlock privilege.
	by the DAV:unlock privilege.
	Clemm, et al. [Page 10]
	<!ELEMENT unlock EMPTY>		<!ELEMENT unlock EMPTY>
	3.6 DAV:read-acl Privilege		3.6 DAV:read-acl Privilege
	The DAV:read-acl privilege controls the use of PROPFIND to retrieve		The DAV:read-acl privilege controls the use of PROPFIND to
	the DAV:acl property of the resource.		retrieve the DAV:acl property of the resource.
	<!ELEMENT read-acl EMPTY>		<!ELEMENT read-acl EMPTY>
	3.7 DAV:read-current-user-privilege-set Privilege		3.7 DAV:read-current-user-privilege-set Privilege
	The DAV:read-current-user-privilege-set privilege controls the use		The DAV:read-current-user-privilege-set privilege controls the use
	of PROPFIND to retrieve the DAV:current-user-privilege-set property		of PROPFIND to retrieve the DAV:current-user-privilege-set
	of the resource.		property of the resource.
	Clients are intended to use this property to visually indicate in		Clients are intended to use this property to visually indicate in
	their UI items that are dependent on the permissions of a resource,		their UI items that are dependent on the permissions of a
	for example, by graying out resources that are not writeable.		resource, for example, by graying out resources that are not
			writeable.
	This privilege is separate from DAV:read-acl because there is a		This privilege is separate from DAV:read-acl because there is a
	need to allow most users access to the privileges permitted the		need to allow most users access to the privileges permitted the
	current user (due to its use in creating the UI), while the full		current user (due to its use in creating the UI), while the full
			Clemm, Hopkins, Sedlar, Whitehead [Page 10]
	ACL contains information that may not be appropriate for the		ACL contains information that may not be appropriate for the
	current authenticated user. As a result, the set of users who can		current authenticated user. As a result, the set of users who can
	view the full ACL is expected to be much smaller than those who can		view the full ACL is expected to be much smaller than those who
	read the current user privilege set, and hence distinct privileges		can read the current user privilege set, and hence distinct
	are needed for each.		privileges are needed for each.
	<!ELEMENT read-current-user-privilege-set EMPTY>		<!ELEMENT read-current-user-privilege-set EMPTY>
	3.8 DAV:write-acl Privilege		3.8 DAV:write-acl Privilege
	The DAV:write-acl privilege controls use of the ACL method to		The DAV:write-acl privilege controls use of the ACL method to
	modify the DAV:acl property of the resource.		modify the DAV:acl property of the resource.
	<!ELEMENT write-acl EMPTY>		<!ELEMENT write-acl EMPTY>
	3.9 DAV:delete Privilege		3.9 DAV:bind Privilege
	The DAV:delete privilege controls use of the DELETE method on the		The DAV:bind privilege allows a method to add a new member URL to
	specified resource. You must also have DAV:write-content on the		the specified collection (for example via PUT or MKCOL). It is
	collection containing the resource for the DELETE to succeed.		ignored for resources that are not collections.
			<!ELEMENT bind EMPTY>
	<!ELEMENT delete EMPTY>		3.10DAV:unbind Privilege
	3.10DAV:all Privilege		The DAV:unbind privilege allows a method to remove a member URL
			from the specified collection (for example via DELETE or MOVE).
			It is ignored for resources that are not collections.
			<!ELEMENT unbind EMPTY>
			3.11 DAV:all Privilege
	DAV:all is an aggregate privilege that contains the entire set of		DAV:all is an aggregate privilege that contains the entire set of
	privileges that can be applied to the resource.		privileges that can be applied to the resource.
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
	Clemm, et al. [Page 11]		3.12 Aggregation of Predefined Privileges
	3.11Aggregation of Predefined Privileges
	Server implementations are free to aggregate the predefined		Server implementations are free to aggregate the predefined
	privileges (defined above in Sections 3.1-3.9) subject to the		privileges (defined above in Sections 3.1-3.9) subject to the
	following limitations:		following limitations:
	DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl,		DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-acl,
	DAV:write-properties, DAV:write-content, or DAV:read-current-user-		DAV:write-properties, DAV:write-content, or DAV:read-current-user-
	privilege-set.		privilege-set.
	DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl,		DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-acl,
	or DAV:read-current-user-privilege-set.		or DAV:read-current-user-privilege-set.
	DAV:read-current-user-privilege-set MUST NOT contain DAV:write,		DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
	DAV:read, DAV:read-acl, or DAV:write-acl.		DAV:read, DAV:read-acl, or DAV:write-acl.
	DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-		DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
	current-user-privilege-set.		current-user-privilege-set.
	DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-		DAV:read MUST NOT contain DAV:write, DAV:write-acl, DAV:write-
	properties, or DAV:write-content.		properties, or DAV:write-content.
			Clemm, Hopkins, Sedlar, Whitehead [Page 11]
	DAV:write MUST contain DAV:write-properties and DAV:write-content.		DAV:write MUST contain DAV:write-properties and DAV:write-content.
	4 PRINCIPAL PROPERTIES		4 PRINCIPAL PROPERTIES
	Principals are manifested to clients as a WebDAV resource,		Principals are manifested to clients as a WebDAV resource,
	identified by a URL. A principal MUST have a non-empty		identified by a URL. A principal MUST have a non-empty
	DAV:displayname property (defined in Section 13.2 of [RFC2518]),		DAV:displayname property (defined in Section 13.2 of [RFC2518]),
	and a DAV:resourcetype property (defined in Section 13.9 of		and a DAV:resourcetype property (defined in Section 13.9 of
	[RFC2518]). Additionally, a principal MUST report the		[RFC2518]). Additionally, a principal MUST report the
	DAV:principal XML element in the value of the DAV:resourcetype		DAV:principal XML element in the value of the DAV:resourcetype
	skipping to change at line 629		skipping to change at line 583
	4 PRINCIPAL PROPERTIES		4 PRINCIPAL PROPERTIES
	Principals are manifested to clients as a WebDAV resource,		Principals are manifested to clients as a WebDAV resource,
	identified by a URL. A principal MUST have a non-empty		identified by a URL. A principal MUST have a non-empty
	DAV:displayname property (defined in Section 13.2 of [RFC2518]),		DAV:displayname property (defined in Section 13.2 of [RFC2518]),
	and a DAV:resourcetype property (defined in Section 13.9 of		and a DAV:resourcetype property (defined in Section 13.9 of
	[RFC2518]). Additionally, a principal MUST report the		[RFC2518]). Additionally, a principal MUST report the
	DAV:principal XML element in the value of the DAV:resourcetype		DAV:principal XML element in the value of the DAV:resourcetype
	property. The element type declaration for DAV:principal is:		property. The element type declaration for DAV:principal is:
	<!ELEMENT principal EMPTY>		<!ELEMENT principal EMPTY>
	This protocol defines the following additional properties for a		This protocol defines the following additional properties for a
	principal. Since it can be expensive for a server to retrieve		principal. Since it can be expensive for a server to retrieve
	access control information, the name and value of these properties		access control information, the name and value of these properties
	SHOULD NOT be returned by a PROPFIND allprop request (as defined in		SHOULD NOT be returned by a PROPFIND allprop request (as defined
	Section 12.14.1 of [RFC2518]).		in Section 12.14.1 of [RFC2518]).
	4.1 DAV:alternate-URI-set		4.1 DAV:alternate-URI-set
	This protected property, if non-empty, contains the URIs of network		This protected property, if non-empty, contains the URIs of
	resources with additional descriptive information about the		network resources with additional descriptive information about
	principal. This property identifies additional network resources		the principal. This property identifies additional network
	(i.e., it contains one or more URIs) that may be consulted by a		resources (i.e., it contains one or more URIs) that may be
	client to gain additional knowledge concerning a principal. One		consulted by a client to gain additional knowledge concerning a
	expected use for this property is the storage of an LDAP [RFC2255]		principal. One expected use for this property is the storage of an
	scheme URL. A user-agent encountering an LDAP URL could use LDAP		LDAP [RFC2255] scheme URL. A user-agent encountering an LDAP URL
	[RFC2589] to retrieve additional machine-readable directory		could use LDAP [RFC2589] to retrieve additional machine-readable
			directory information about the principal, and display that
	Clemm, et al. [Page 12]		information in its user interface. Support for this property is
	information about the principal, and display that information in		REQUIRED, and the value is empty if no alternate URI exists for
	its user interface. Support for this property is REQUIRED, and the		the principal.
	value is empty if no alternate URI exists for the principal.
	<!ELEMENT alternate-URI-set (href*)>		<!ELEMENT alternate-URI-set (href*)>
	4.2 DAV:principal-URL		4.2 DAV:principal-URL
	A principal may have many URLs, but there must be one "principal		A principal may have many URLs, but there must be one "principal
	URL" that clients can use to uniquely identify a principal. This		URL" that clients can use to uniquely identify a principal. This
	protected property contains the URL that MUST be used to identify		protected property contains the URL that MUST be used to identify
	this principal in an ACL request. Support for this property is		this principal in an ACL request. Support for this property is
	REQUIRED.		REQUIRED.
	<!ELEMENT principal-URL (href)>		<!ELEMENT principal-URL (href)>
	4.3 DAV:group-member-set		4.3 DAV:group-member-set
	This property of a group principal identifies the principals that		This property of a group principal identifies the principals that
	are direct members of this group. Since a group may be a member of		are direct members of this group. Since a group may be a member of
	another group, a group may also have indirect members (i.e. the		another group, a group may also have indirect members (i.e. the
	members of its direct members). A URL in the DAV:group-member-set		members of its direct members). A URL in the DAV:group-member-set
	for a principal MUST be the DAV:principal-URL of that principal.		for a principal MUST be the DAV:principal-URL of that principal.
	<!ELEMENT group-member-set (href*)>		<!ELEMENT group-member-set (href*)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 12]
	4.4 DAV:group-membership		4.4 DAV:group-membership
	This protected property identifies the groups in which the		This protected property identifies the groups in which the
	principal is directly a member. Note that a server may allow a		principal is directly a member. Note that a server may allow a
	group to be a member of another group, in which case the DAV:group-		group to be a member of another group, in which case the
	membership of those other groups would need to be queried in order		DAV:group-membership of those other groups would need to be
	to determine the groups in which the principal is indirectly a		queried in order to determine the groups in which the principal is
	member. Support for this property is REQUIRED.		indirectly a member. Support for this property is REQUIRED.
	<!ELEMENT group-membership (href*)>		<!ELEMENT group-membership (href*)>
	5 ACCESS CONTROL PROPERTIES		5 ACCESS CONTROL PROPERTIES
	This specification defines a number of new properties for WebDAV		This specification defines a number of new properties for WebDAV
	resources. Access control properties may be retrieved just like		resources. Access control properties may be retrieved just like
	other WebDAV properties, using the PROPFIND method. Since it is		other WebDAV properties, using the PROPFIND method. Since it is
	expensive, for many servers, to retrieve access control		expensive, for many servers, to retrieve access control
	information, a PROPFIND allprop request (as defined in Section		information, a PROPFIND allprop request (as defined in Section
	12.14.1 of [RFC2518]) SHOULD NOT return the names and values of the		12.14.1 of [RFC2518]) SHOULD NOT return the names and values of
	properties defined in this section.		the properties defined in this section.
	Access control properties (especially DAV:acl and DAV:inherited-		Access control properties (especially DAV:acl and DAV:inherited-
	acl-set) are defined on the resource identified by the Request-URI		acl-set) are defined on the resource identified by the Request-URI
	of a PROPFIND request. A direct consequence is that if the resource		of a PROPFIND request. A direct consequence is that if the
	is accessible via multiple URI, the value of access control		resource is accessible via multiple URI, the value of access
	properties is the same across these URI.		control properties is the same across these URI.
			HTTP resources that support the WebDAV Access Control Protocol
	Clemm, et al. [Page 13]		MUST contain the following properties. Null resources (described
	HTTP resources that support the WebDAV Access Control Protocol MUST		in Section 3 of [RFC2518]) MUST NOT contain the following
	contain the following properties. Null resources (described in		properties.
	Section 3 of [RFC2518]) MUST NOT contain the following properties.
	5.1 DAV:owner		5.1 DAV:owner
	This protected property identifies a particular principal as being		This protected property identifies a particular principal as being
	the "owner" of the resource. Since the owner of a resource often		the "owner" of the resource. Since the owner of a resource often
	has special access control capabilities (e.g., the owner frequently		has special access control capabilities (e.g., the owner
	has permanent DAV:write-acl privilege), clients might display the		frequently has permanent DAV:write-acl privilege), clients might
	resource owner in their user interface.		display the resource owner in their user interface.
	<!ELEMENT owner (href)>		<!ELEMENT owner (href)>
	5.1.1Example: Retrieving DAV:owner		5.1.1Example: Retrieving DAV:owner
	This example shows a client request for the value of the DAV:owner		This example shows a client request for the value of the DAV:owner
	property from a collection resource with URL		property from a collection resource with URL
	http://www.example.com/papers/. The principal making the request is		http://www.example.com/papers/. The principal making the request
	authenticated using Digest authentication. The value of DAV:owner		is authenticated using Digest authentication. The value of
	is the URL http://www.example.com/acl/users/gstein, wrapped in the		DAV:owner is the URL http://www.example.com/acl/users/gstein,
	DAV:href XML element.		wrapped in the DAV:href XML element.
	>> Request <<		>> Request <<
			Clemm, Hopkins, Sedlar, Whitehead [Page 13]
	PROPFIND /papers/ HTTP/1.1		PROPFIND /papers/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	Depth: 0		Depth: 0
	Authorization: Digest username="jim",		Authorization: Digest username="jim",
	realm="jim@webdav.org", nonce="...",		realm="jim@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	skipping to change at line 757		skipping to change at line 704
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	Clemm, et al. [Page 14]
	<D:owner>		<D:owner>
	<D:href>http://www.example.com/acl/users/gstein</D:href>		<D:href>http://www.example.com/acl/users/gstein</D:href>
	</D:owner>		</D:owner>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	5.1.2Example: An Attempt to Set DAV:owner		5.1.2Example: An Attempt to Set DAV:owner
	skipping to change at line 770		skipping to change at line 716
	<D:href>http://www.example.com/acl/users/gstein</D:href>		<D:href>http://www.example.com/acl/users/gstein</D:href>
	</D:owner>		</D:owner>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	5.1.2Example: An Attempt to Set DAV:owner		5.1.2Example: An Attempt to Set DAV:owner
	The following example shows a client request to modify the value of		The following example shows a client request to modify the value
	the DAV:owner property on the resource with URL		of the DAV:owner property on the resource with URL
	<http://www.example.com/papers>. Since DAV:owner is a protected		<http://www.example.com/papers>. Since DAV:owner is a protected
	property, the server responds with a 207 (Multi-Status) response		property, the server responds with a 207 (Multi-Status) response
	that contains a 403 (Forbidden) status code for the act of setting		that contains a 403 (Forbidden) status code for the act of setting
	DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status		DAV:owner. Section 8.2.1 of [RFC2518] describes PROPPATCH status
	code information, and Section 11 of [RFC2518] describes the Multi-		code information, and Section 11 of [RFC2518] describes the Multi-
	Status response.		Status response.
	>> Request <<		>> Request <<
	PROPPATCH /papers/ HTTP/1.1		PROPPATCH /papers/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
			Clemm, Hopkins, Sedlar, Whitehead [Page 14]
	Content-Length: xxx		Content-Length: xxx
	Depth: 0		Depth: 0
	Authorization: Digest username="jim",		Authorization: Digest username="jim",
	realm="jim@webdav.org", nonce="...",		realm="jim@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:propertyupdate xmlns:D="DAV:">		<D:propertyupdate xmlns:D="DAV:">
	<D:set>		<D:set>
	<D:prop>		<D:prop>
	skipping to change at line 812		skipping to change at line 759
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
	<D:propstat>		<D:propstat>
	Clemm, et al. [Page 15]
	<D:prop><D:owner/></D:prop>		<D:prop><D:owner/></D:prop>
	<D:status>HTTP/1.1 403 Forbidden</D:status>		<D:status>HTTP/1.1 403 Forbidden</D:status>
	<D:responsedescription>		<D:responsedescription>
	Failure to set protected property (DAV:owner)		Failure to set protected property (DAV:owner)
	</D:responsedescription>		</D:responsedescription>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	5.2 DAV:supported-privilege-set		5.2 DAV:supported-privilege-set
	This is a protected property that identifies the privileges defined		This is a protected property that identifies the privileges
	for the resource.		defined for the resource.
	<!ELEMENT supported-privilege-set (supported-privilege*)>		<!ELEMENT supported-privilege-set (supported-privilege*)>
	Each privilege appears as an XML element, where aggregate		Each privilege appears as an XML element, where aggregate
	privileges list as sub-elements all of the privileges that they		privileges list as sub-elements all of the privileges that they
	aggregate.		aggregate.
	<!ELEMENT supported-privilege		<!ELEMENT supported-privilege
	(privilege, abstract?, description, supported-privilege*)>		(privilege, abstract?, description, supported-privilege*)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	An abstract privilege MUST NOT be used in an ACE for that resource.		Clemm, Hopkins, Sedlar, Whitehead [Page 15]
	Servers MUST fail an attempt to set an abstract privilege.		An abstract privilege MUST NOT be used in an ACE for that
			resource. Servers MUST fail an attempt to set an abstract
			privilege.
	<!ELEMENT abstract EMPTY>		<!ELEMENT abstract EMPTY>
	A description is a human-readable description of what this		A description is a human-readable description of what this
	privilege controls access to. Servers MUST indicate the human		privilege controls access to. Servers MUST indicate the human
	language of the description using the xml:lang attribute and SHOULD		language of the description using the xml:lang attribute and
	consider the HTTP Accept-Language request header when selecting one		SHOULD consider the HTTP Accept-Language request header when
	of multiple available languages.		selecting one of multiple available languages.
	<!ELEMENT description #PCDATA>		<!ELEMENT description #PCDATA>
	It is envisioned that a WebDAV ACL-aware administrative client		It is envisioned that a WebDAV ACL-aware administrative client
	would list the supported privileges in a dialog box, and allow the		would list the supported privileges in a dialog box, and allow the
	user to choose non-abstract privileges to apply in an ACE. The		user to choose non-abstract privileges to apply in an ACE. The
	privileges tree is useful programmatically to map well-known		privileges tree is useful programmatically to map well-known
	privileges (defined by WebDAV or other standards groups) into		privileges (defined by WebDAV or other standards groups) into
	privileges that are supported by any particular server		privileges that are supported by any particular server
	implementation. The privilege tree also serves to hide complexity		implementation. The privilege tree also serves to hide complexity
	in implementations allowing large number of privileges to be		in implementations allowing large number of privileges to be
	defined by displaying aggregates to the user.		defined by displaying aggregates to the user.
	5.2.1Example: Retrieving a List of Privileges Supported on a Resource		5.2.1Example: Retrieving a List of Privileges Supported on a Resource
	This example shows a client request for the DAV:supported-		This example shows a client request for the DAV:supported-
	privilege-set property on the resource		privilege-set property on the resource
	Clemm, et al. [Page 16]
	http://www.example.com/papers/. The value of the DAV:supported-		http://www.example.com/papers/. The value of the DAV:supported-
	privilege-set property is a tree of supported privileges (using		privilege-set property is a tree of supported privileges (using
	"[XML Namespace , localname]" to identify each privilege):		"[XML Namespace , localname]" to identify each privilege):
	[DAV:, all] (aggregate, abstract)		[DAV:, all] (aggregate, abstract)
	|		|
	+-- [DAV:, read] (aggregate)		+-- [DAV:, read] (aggregate)
	|		|
	+-- [DAV:, read-acl] (abstract)		+-- [DAV:, read-acl] (abstract)
	+-- [DAV:, read-current-user-privilege-set] (abstract)		+-- [DAV:, read-current-user-privilege-set]
			(abstract)
	|		|
	+-- [DAV:, write] (aggregate)		+-- [DAV:, write] (aggregate)
	|		|
	+-- [DAV:, write-acl] (abstract)		+-- [DAV:, write-acl] (abstract)
	+-- [DAV:, write-properties]		+-- [DAV:, write-properties]
	+-- [DAV:, write-content]		+-- [DAV:, write-content]
	|		|
	+-- [DAV:, unlock]		+-- [DAV:, unlock]
	This privilege tree is not normative (except that it reflects the		This privilege tree is not normative (except that it reflects the
	normative aggregation rules given in Section 3.11), and many		normative aggregation rules given in Section 3.12), and many
	possible privilege trees are possible.		possible privilege trees are possible.
	>> Request <<		>> Request <<
			Clemm, Hopkins, Sedlar, Whitehead [Page 16]
	PROPFIND /papers/ HTTP/1.1		PROPFIND /papers/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	Depth: 0		Depth: 0
	Authorization: Digest username="gclemm",		Authorization: Digest username="gclemm",
	realm="gclemm@webdav.org", nonce="...",		realm="gclemm@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	skipping to change at line 918		skipping to change at line 862
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
	Clemm, et al. [Page 17]
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:supported-privilege-set>		<D:supported-privilege-set>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:all/> </D:privilege>		<D:privilege> <D:all/> </D:privilege>
	<D:abstract/>		<D:abstract/>
	<D:description xml:lang="en">Any operation</D:description>		<D:description xml:lang="en">
			Any operation</D:description>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
	<D:description xml:lang="en">Read any object</D:description>		<D:description xml:lang="en">
			Read any object</D:description>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:read-acl/> </D:privilege>		<D:privilege> <D:read-acl/> </D:privilege>
	<D:abstract/>		<D:abstract/>
	<D:description xml:lang="en">Read ACL</D:description>		<D:description xml:lang="en">
			Read ACL</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege>		<D:privilege>
	<D:read-current-user-privilege-set/>		<D:read-current-user-privilege-set/>
	</D:privilege>		</D:privilege>
	<D:abstract/>		<D:abstract/>
	<D:description xml:lang="en">Read current user privilege		<D:description xml:lang="en">
	set property</D:description>		Read current user privilege set property
			</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	</D:supported-privilege>		</D:supported-privilege>
			Clemm, Hopkins, Sedlar, Whitehead [Page 17]
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:write/> </D:privilege>		<D:privilege> <D:write/> </D:privilege>
	<D:description xml:lang="en">Write any object</D:description>		<D:description xml:lang="en">
			Write any object</D:description>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:write-acl/> </D:privilege>		<D:privilege> <D:write-acl/> </D:privilege>
	<D:description xml:lang="en">Write ACL</D:description>		<D:description xml:lang="en">
			Write ACL</D:description>
	<D:abstract/>		<D:abstract/>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:write-properties/> </D:privilege>		<D:privilege> <D:write-properties/> </D:privilege>
	<D:description xml:lang="en">Write		<D:description xml:lang="en">
	properties</D:description>		Write properties</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:write-content/> </D:privilege>		<D:privilege> <D:write-content/> </D:privilege>
	<D:description xml:lang="en">Write resource		<D:description xml:lang="en">
	content</D:description>		Write resource content</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:unlock/> </D:privilege>		<D:privilege> <D:unlock/> </D:privilege>
	<D:description xml:lang="en">Unlock		<D:description xml:lang="en">
	resource</D:description>		Unlock resource</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	</D:supported-privilege>		</D:supported-privilege>
	</D:supported-privilege-set>		</D:supported-privilege-set>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	Clemm, et al. [Page 18]
	</D:multistatus>		</D:multistatus>
	5.3 DAV:current-user-privilege-set		5.3 DAV:current-user-privilege-set
	DAV:current-user-privilege-set is a protected property containing		DAV:current-user-privilege-set is a protected property containing
	the exact set of privileges (as computed by the server) granted to		the exact set of privileges (as computed by the server) granted to
	the currently authenticated HTTP user. Aggregate privileges and		the currently authenticated HTTP user. Aggregate privileges and
	their contained privileges are listed. A user-agent can use the		their contained privileges are listed. A user-agent can use the
	value of this property to adjust its user interface to make actions		value of this property to adjust its user interface to make
	inaccessible (e.g., by graying out a menu item or button) for which		actions inaccessible (e.g., by graying out a menu item or button)
	the current principal does not have permission. This property is		for which the current principal does not have permission. This
	also useful for determining what operations the current principal		property is also useful for determining what operations the
	can perform, without having to actually execute an operation.		current principal can perform, without having to actually execute
			an operation.
	<!ELEMENT current-user-privilege-set (privilege*)>		<!ELEMENT current-user-privilege-set (privilege*)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	If the current user is granted a specific privilege, that privilege		If the current user is granted a specific privilege, that
	must belong to the set of privileges that may be set on this		privilege must belong to the set of privileges that may be set on
	resource. Therefore, each element in the DAV:current-user-		this resource. Therefore, each element in the DAV:current-user-
			Clemm, Hopkins, Sedlar, Whitehead [Page 18]
	privilege-set property MUST identify a non-abstract privilege from		privilege-set property MUST identify a non-abstract privilege from
	the DAV:supported-privilege-set property.		the DAV:supported-privilege-set property.
	5.3.1Example: Retrieving the User's Current Set of Assigned Privileges		5.3.1Example: Retrieving the User's Current Set of Assigned Privileges
	Continuing the example from Section 5.2.1, this example shows a		Continuing the example from Section 5.2.1, this example shows a
	client requesting the DAV:current-user-privilege-set property from		client requesting the DAV:current-user-privilege-set property from
	the resource with URL http://www.example.com/papers/. The username		the resource with URL http://www.example.com/papers/. The username
	of the principal making the request is "khare", and Digest		of the principal making the request is "khare", and Digest
	authentication is used in the request. The principal with username		authentication is used in the request. The principal with username
	"khare" has been granted the DAV:read privilege. Since the DAV:read		"khare" has been granted the DAV:read privilege. Since the
	privilege contains the DAV:read-acl and DAV:read-current-user-		DAV:read privilege contains the DAV:read-acl and DAV:read-current-
	privilege-set privileges (see Section 5.2.1), the principal with		user-privilege-set privileges (see Section 5.2.1), the principal
	username "khare" can read the ACL property, and the DAV:current-		with username "khare" can read the ACL property, and the
	user-privilege-set property. However, the DAV:all, DAV:read-acl,		DAV:current-user-privilege-set property. However, the DAV:all,
	DAV:write-acl and DAV:read-current-user-privilege-set privileges		DAV:read-acl, DAV:write-acl and DAV:read-current-user-privilege-
	are not listed in the value of DAV:current-user-privilege-set,		set privileges are not listed in the value of DAV:current-user-
	since (for this example) they are abstract privileges. DAV:write is		privilege-set, since (for this example) they are abstract
	not listed since the principal with username "khare" is not listed		privileges. DAV:write is not listed since the principal with
	in an ACE granting that principal write permission.		username "khare" is not listed in an ACE granting that principal
			write permission.
	>> Request <<		>> Request <<
	PROPFIND /papers/ HTTP/1.1		PROPFIND /papers/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	Depth: 0		Depth: 0
	Authorization: Digest username="khare",		Authorization: Digest username="khare",
	realm="khare@webdav.org", nonce="...",		realm="khare@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	Clemm, et al. [Page 19]
	<D:propfind xmlns:D="DAV:">		<D:propfind xmlns:D="DAV:">
	<D:prop>		<D:prop>
	<D:current-user-privilege-set/>		<D:current-user-privilege-set/>
	</D:prop>		</D:prop>
	</D:propfind>		</D:propfind>
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:current-user-privilege-set>		<D:current-user-privilege-set>
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
			Clemm, Hopkins, Sedlar, Whitehead [Page 19]
	</D:current-user-privilege-set>		</D:current-user-privilege-set>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	5.4 DAV:acl		5.4 DAV:acl
	This is a protected property that specifies the list of access		This is a protected property that specifies the list of access
	control entries (ACEs), which define what principals are to get		control entries (ACEs), which define what principals are to get
	what privileges for this resource.		what privileges for this resource.
	<!ELEMENT acl (ace*) >		<!ELEMENT acl (ace*) >
	Each DAV:ace element specifies the set of privileges to be either		Each DAV:ace element specifies the set of privileges to be either
	granted or denied to a single principal. If the DAV:acl property		granted or denied to a single principal. If the DAV:acl property
	is empty, no principal is granted any privilege.		is empty, no principal is granted any privilege.
	<!ELEMENT ace (invert | principal, (grant|deny), protected?, inherited?)>		<!ELEMENT ace (invert | principal, (grant|deny), protected?,
			inherited?)>
	5.4.1ACE Principal		5.4.1ACE Principal
	The DAV:principal element identifies the principal to which this		The DAV:principal element identifies the principal to which this
	ACE applies.		ACE applies.
	<!ELEMENT principal ((href)		<!ELEMENT principal ((href)
	| all | authenticated | unauthenticated		| all | authenticated | unauthenticated
	| property | self)>		| property | self)>
	The current user matches DAV:href only if that user is		The current user matches DAV:href only if that user is
	authenticated as being (or being a member of) the principal		authenticated as being (or being a member of) the principal
	identified by the URL contained by that DAV:href.		identified by the URL contained by that DAV:href.
	Clemm, et al. [Page 20]
	The current user always matches DAV:all.		The current user always matches DAV:all.
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
	The current user matches DAV:authenticated only if authenticated.		The current user matches DAV:authenticated only if authenticated.
	<!ELEMENT authenticated EMPTY>		<!ELEMENT authenticated EMPTY>
	The current user matches DAV:unauthenticated only if not		The current user matches DAV:unauthenticated only if not
	authenticated.		authenticated.
	<!ELEMENT unauthenticated EMPTY>		<!ELEMENT unauthenticated EMPTY>
	DAV:all is the union of DAV:authenticated, and DAV:unauthenticated.		DAV:all is the union of DAV:authenticated, and
	For a given request, the user matches either DAV:authenticated, or		DAV:unauthenticated. For a given request, the user matches either
	DAV:unauthenticated, but not both (that is, DAV:authenticated and		DAV:authenticated, or DAV:unauthenticated, but not both (that is,
	DAV:unauthenticated are disjoint sets).		DAV:authenticated and DAV:unauthenticated are disjoint sets).
	The current user matches a DAV:property principal in a DAV:acl		The current user matches a DAV:property principal in a DAV:acl
	property of a resource only if the value of the identified property		property of a resource only if the value of the identified
	of that resource contains at most one DAV:href XML element, the URI		property of that resource contains at most one DAV:href XML
	value of DAV:href identifies a principal, and the current user is
	authenticated as being (or being a member of) that principal. For
	example, if the DAV:property element contained <DAV:owner/>, the
	current user would match the DAV:property principal only if the
	current user is authenticated as matching the principal identified
	by the DAV:owner property of the resource.
			Clemm, Hopkins, Sedlar, Whitehead [Page 20]
			element, the URI value of DAV:href identifies a principal, and the
			current user is authenticated as being (or being a member of) that
			principal. For example, if the DAV:property element contained
			<DAV:owner/>, the current user would match the DAV:property
			principal only if the current user is authenticated as matching
			the principal identified by the DAV:owner property of the
			resource.
	<!ELEMENT property ANY>		<!ELEMENT property ANY>
	Alternately, some servers may support ACEs applying to those users		Alternately, some servers may support ACEs applying to those users
	NOT matching the current principal, e.g. all users not in a		NOT matching the current principal, e.g. all users not in a
	particular group. This can be done by wrapping the DAV:principal		particular group. This can be done by wrapping the DAV:principal
	element with DAV:invert.		element with DAV:invert.
	<!ELEMENT invert principal>		<!ELEMENT invert principal>
	The current user matches DAV:self in a DAV:acl property of the		The current user matches DAV:self in a DAV:acl property of the
	resource only if that resource is a principal and that principal		resource only if that resource is a principal and that principal
	matches the current user or, if the principal is a group, a member		matches the current user or, if the principal is a group, a member
	of that group matches the current user.		of that group matches the current user.
	<!ELEMENT self EMPTY>		<!ELEMENT self EMPTY>
	5.4.2ACE Grant and Deny		5.4.2ACE Grant and Deny
	Each DAV:grant or DAV:deny element specifies the set of privileges		Each DAV:grant or DAV:deny element specifies the set of privileges
	to be either granted or denied to the specified principal. A		to be either granted or denied to the specified principal. A
	DAV:grant or DAV:deny element of the DAV:acl of a resource MUST		DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
	only contain non-abstract elements specified in the DAV:supported-		only contain non-abstract elements specified in the DAV:supported-
	privilege-set of that resource.		privilege-set of that resource.
	skipping to change at line 1139		skipping to change at line 1085
	5.4.2ACE Grant and Deny		5.4.2ACE Grant and Deny
	Each DAV:grant or DAV:deny element specifies the set of privileges		Each DAV:grant or DAV:deny element specifies the set of privileges
	to be either granted or denied to the specified principal. A		to be either granted or denied to the specified principal. A
	DAV:grant or DAV:deny element of the DAV:acl of a resource MUST		DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
	only contain non-abstract elements specified in the DAV:supported-		only contain non-abstract elements specified in the DAV:supported-
	privilege-set of that resource.		privilege-set of that resource.
	<!ELEMENT grant (privilege+)>		<!ELEMENT grant (privilege+)>
	Clemm, et al. [Page 21]
	<!ELEMENT deny (privilege+)>		<!ELEMENT deny (privilege+)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	5.4.3ACE Protection		5.4.3ACE Protection
	A server indicates an ACE is protected by including the		A server indicates an ACE is protected by including the
	DAV:protected element in the ACE. If the ACL of a resource contains		DAV:protected element in the ACE. If the ACL of a resource
	an ACE with a DAV:protected element, an attempt to remove that ACE		contains an ACE with a DAV:protected element, an attempt to remove
	from the ACL MUST fail.		that ACE from the ACL MUST fail.
	<!ELEMENT protected EMPTY>		<!ELEMENT protected EMPTY>
	5.4.4ACE Inheritance		5.4.4ACE Inheritance
	The presence of a DAV:inherited element indicates that this ACE is		The presence of a DAV:inherited element indicates that this ACE is
	inherited from another resource that is identified by the URL		inherited from another resource that is identified by the URL
	contained in a DAV:href element. An inherited ACE cannot be		contained in a DAV:href element. An inherited ACE cannot be
	modified directly, but instead the ACL on the resource from which		modified directly, but instead the ACL on the resource from which
	it is inherited must be modified.		it is inherited must be modified.
	Note that ACE inheritance is not the same as ACL initialization.		Note that ACE inheritance is not the same as ACL initialization.
	ACL initialization defines the ACL that a newly created resource		ACL initialization defines the ACL that a newly created resource
	will use (if not specified). ACE inheritance refers to an ACE that
	is logically shared - where an update to the resource containing an
	ACE will affect the ACE of each resource that inherits that ACE.
	The method by which ACLs are initialized or by which ACEs are
	inherited is not defined by this document.
			Clemm, Hopkins, Sedlar, Whitehead [Page 21]
			will use (if not specified). ACE inheritance refers to an ACE
			that is logically shared - where an update to the resource
			containing an ACE will affect the ACE of each resource that
			inherits that ACE. The method by which ACLs are initialized or by
			which ACEs are inherited is not defined by this document.
	<!ELEMENT inherited (href)>		<!ELEMENT inherited (href)>
	5.4.5Example: Retrieving a Resource's Access Control List		5.4.5Example: Retrieving a Resource's Access Control List
	Continuing the example from Sections 5.2.1 and 5.3.1, this example		Continuing the example from Sections 5.2.1 and 5.3.1, this example
	shows a client requesting the DAV:acl property from the resource		shows a client requesting the DAV:acl property from the resource
	with URL http://www.example.com/papers/. There are two ACEs defined		with URL http://www.example.com/papers/. There are two ACEs
	in this ACL:		defined in this ACL:
	ACE #1: The group identified by URL		ACE #1: The group identified by URL
	http://www.example.com/acl/groups/maintainers (the group of site		http://www.example.com/acl/groups/maintainers (the group of site
	maintainers) is granted DAV:write privilege. Since (for this		maintainers) is granted DAV:write privilege. Since (for this
	example) DAV:write contains the DAV:write-acl privilege (see		example) DAV:write contains the DAV:write-acl privilege (see
	Section 5.2.1), this means the "maintainers" group can also modify		Section 5.2.1), this means the "maintainers" group can also modify
	the access control list.		the access control list.
	ACE #2: All principals (DAV:all) are granted the DAV:read		ACE #2: All principals (DAV:all) are granted the DAV:read
	privilege. Since (for this example) DAV:read contains DAV:read-acl		privilege. Since (for this example) DAV:read contains DAV:read-acl
	and DAV:read-current-user-privilege-set, this means all users		and DAV:read-current-user-privilege-set, this means all users
	(including all members of the "maintainers" group) can read the		(including all members of the "maintainers" group) can read the
	DAV:acl property and the DAV:current-user-privilege-set property.		DAV:acl property and the DAV:current-user-privilege-set property.
	>> Request <<		>> Request <<
	PROPFIND /papers/ HTTP/1.1		PROPFIND /papers/ HTTP/1.1
	Clemm, et al. [Page 22]
	Host: www.example.com		Host: www.example.com
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	Depth: 0		Depth: 0
	Authorization: Digest username="masinter",		Authorization: Digest username="masinter",
	realm="webdav.org", nonce="...",		realm="webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>
	<D:propfind xmlns:D="DAV:">		<D:propfind xmlns:D="DAV:">
	<D:prop>		<D:prop>
	<D:acl/>		<D:acl/>
	</D:prop>		</D:prop>
	</D:propfind>		</D:propfind>
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
			Clemm, Hopkins, Sedlar, Whitehead [Page 22]
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:acl>		<D:acl>
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.example.com/acl/groups/maintainers</D:href>		<D:href>http://www.example.com/acl/groups/maintainers</D:href>
	</D:principal>		</D:principal>
	<D:grant>		<D:grant>
	<D:privilege> <D:write/> </D:privilege>		<D:privilege> <D:write/> </D:privilege>
	</D:grant>		</D:grant>
	skipping to change at line 1247		skipping to change at line 1188
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
	</D:grant>		</D:grant>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	Clemm, et al. [Page 23]
	5.5 DAV: acl-restrictions		5.5 DAV: acl-restrictions
	This protected property defines the types of ACLs supported by this		This protected property defines the types of ACLs supported by
	server, to avoid clients needlessly getting errors. When a client		this server, to avoid clients needlessly getting errors. When a
	tries to set an ACL via the ACL method, the server may reject the		client tries to set an ACL via the ACL method, the server may
	attempt to set the ACL as specified. The following properties		reject the attempt to set the ACL as specified. The following
	indicate the restrictions the client must observe before setting an		properties indicate the restrictions the client must observe
	ACL:		before setting an ACL:
	<grant-only> Deny ACEs are not supported		<grant-only> Deny ACEs are not supported
	<no-invert> Inverted ACEs are not supported		<no-invert> Inverted ACEs are not supported
	<deny-before-grant> All deny ACEs must occur before any grant		<deny-before-grant> All deny ACEs must occur before any grant
	ACEs		ACEs
	<required-principal> Indicates which principals are		<required-principal> Indicates which principals are
	required to be present		required to be present
	<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-grant?,		<!ELEMENT acl-restrictions (grant-only?, no-invert?, deny-before-
	required-principal?)>		grant?, required-principal?)>
	5.5.1DAV:grant-only		5.5.1DAV:grant-only
	This element indicates that ACEs with deny clauses are not allowed.		This element indicates that ACEs with deny clauses are not
			allowed.
			Clemm, Hopkins, Sedlar, Whitehead [Page 23]
	<!ELEMENT grant-only EMPTY>		<!ELEMENT grant-only EMPTY>
	5.5.2DAV:no-invert ACE Constraint		5.5.2DAV:no-invert ACE Constraint
	This element indicates that ACEs with the <invert> element are not		This element indicates that ACEs with the <invert> element are not
	allowed.		allowed.
	<!ELEMENT no-invert EMPTY>		<!ELEMENT no-invert EMPTY>
	5.5.3DAV:deny-before-grant		5.5.3DAV:deny-before-grant
	This element indicates that all deny ACEs must precede all grant		This element indicates that all deny ACEs must precede all grant
	ACEs.		ACEs.
	<!ELEMENT deny-before-grant EMPTY>		<!ELEMENT deny-before-grant EMPTY>
	5.5.4Required Principals		5.5.4Required Principals
	The required principal elements identify which principals must have		The required principal elements identify which principals must
	an ACE defined in the ACL.		have an ACE defined in the ACL.
	<!ELEMENT required-principal		<!ELEMENT required-principal
	(all? | authenticated? | unauthenticated? | self? | href* | property*)>		(all? | authenticated? | unauthenticated? | self? | href* |
			property*)>
	Clemm, et al. [Page 24]
	For example, the following element requires that the ACL contain a		For example, the following element requires that the ACL contain a
	DAV:owner property ACE:		DAV:owner property ACE:
	<D:required-principal xmlns:D="DAV:">		<D:required-principal xmlns:D="DAV:">
	<D:property> <D:owner/> </D:property>		<D:property> <D:owner/> </D:property>
	</D:required-principal>		</D:required-principal>
	Example: Retrieving DAV:acl-restrictions		Example: Retrieving DAV:acl-restrictions
	In this example, the client requests the value of the DAV:acl-		In this example, the client requests the value of the DAV:acl-
	restrictions property. Digest authentication provides credentials		restrictions property. Digest authentication provides credentials
	for the principal operating the client.		for the principal operating the client.
	skipping to change at line 1328		skipping to change at line 1262
	Depth: 0		Depth: 0
	Authorization: Digest username="srcarter",		Authorization: Digest username="srcarter",
	realm="srcarter@webdav.org", nonce="...",		realm="srcarter@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:propfind xmlns:D="DAV:">		<D:propfind xmlns:D="DAV:">
	<D:prop>		<D:prop>
	<D:acl-restrictions/>		<D:acl-restrictions/>
	</D:prop>		</D:prop>
			Clemm, Hopkins, Sedlar, Whitehead [Page 24]
	</D:propfind>		</D:propfind>
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:acl-restrictions>		<D:acl-restrictions>
	<D:principal-only-one-ace/>		<D:principal-only-one-ace/>
	<D:required-principal>		<D:required-principal>
	<D:all/>		<D:all/>
	</D:required-principal>		</D:required-principal>
	</D:acl-restrictions>		</D:acl-restrictions>
	Clemm, et al. [Page 25]
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	<D:response>		<D:response>
	</D:multistatus>		</D:multistatus>
	5.6 DAV:inherited-acl-set		5.6 DAV:inherited-acl-set
	This protected property contains a set of URLs that identify other		This protected property contains a set of URLs that identify other
	resources that also control the access to this resource. To have a		resources that also control the access to this resource. To have
	privilege on a resource, not only must the ACL on that resource		a privilege on a resource, not only must the ACL on that resource
	(specified in the DAV:acl property of that resource) grant the		(specified in the DAV:acl property of that resource) grant the
	privilege, but so must the ACL of each resource identified in the		privilege, but so must the ACL of each resource identified in the
	DAV:inherited-acl-set property of that resource. Effectively, the		DAV:inherited-acl-set property of that resource. Effectively, the
	privileges granted by the current ACL are ANDed with the privileges		privileges granted by the current ACL are ANDed with the
	granted by each inherited ACL.		privileges granted by each inherited ACL.
	<!ELEMENT inherited-acl-set (href*)>		<!ELEMENT inherited-acl-set (href*)>
	5.7 DAV:principal-collection-set		5.7 DAV:principal-collection-set
	This protected property of a resource contains a set of URLs that		This protected property of a resource contains a set of URLs that
	identify the root collections that contain the principals that are		identify the root collections that contain the principals that are
	available on the server that implements this resource. A WebDAV		available on the server that implements this resource. A WebDAV
	Access Control Protocol user agent could use the contents of		Access Control Protocol user agent could use the contents of
	DAV:principal-collection-set to retrieve the DAV:displayname		DAV:principal-collection-set to retrieve the DAV:displayname
	property (specified in Section 13.2 of [RFC2518]) of all principals		property (specified in Section 13.2 of [RFC2518]) of all
	on that server, thereby yielding human-readable names for each		principals on that server, thereby yielding human-readable names
	principal that could be displayed in a user interface.		for each principal that could be displayed in a user interface.
	<!ELEMENT principal-collection-set (href*)>		<!ELEMENT principal-collection-set (href*)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 25]
	Since different servers can control different parts of the URL		Since different servers can control different parts of the URL
	namespace, different resources on the same host MAY have different		namespace, different resources on the same host MAY have different
	DAV:principal-collection-set values. The collections specified in		DAV:principal-collection-set values. The collections specified in
	the DAV:principal-collection-set MAY be located on different hosts		the DAV:principal-collection-set MAY be located on different hosts
	from the resource. The URLs in DAV:principal-collection-set SHOULD		from the resource. The URLs in DAV:principal-collection-set SHOULD
	be http or https scheme URLs. For security and scalability reasons,		be http or https scheme URLs. For security and scalability
	a server MAY report only a subset of the entire set of known		reasons, a server MAY report only a subset of the entire set of
	principal collections, and therefore clients should not assume they		known principal collections, and therefore clients should not
	have retrieved an exhaustive listing. Additionally, a server MAY		assume they have retrieved an exhaustive listing. Additionally, a
	elect to report none of the principal collections it knows about,		server MAY elect to report none of the principal collections it
	in which case the property value would be empty.		knows about, in which case the property value would be empty.
	The value of DAV:principal-collection-set gives the scope of the		The value of DAV:principal-collection-set gives the scope of the
	DAV:principal-property-search REPORT (defined in Section 9.4).		DAV:principal-property-search REPORT (defined in Section 9.4).
	Clients use the DAV:principal-property-search REPORT to populate		Clients use the DAV:principal-property-search REPORT to populate
	their user interface with a list of principals. Therefore, servers		their user interface with a list of principals. Therefore, servers
	that limit a client's ability to obtain principal information will		that limit a client's ability to obtain principal information will
	interfere with the client's ability to manipulate access control		interfere with the client's ability to manipulate access control
	Clemm, et al. [Page 26]
	lists, due to the difficulty of getting the URL of a principal for		lists, due to the difficulty of getting the URL of a principal for
	use in an ACE.		use in an ACE.
	5.7.1Example: Retrieving DAV:principal-collection-set		5.7.1Example: Retrieving DAV:principal-collection-set
	In this example, the client requests the value of the		In this example, the client requests the value of the
	DAV:principal-collection-set property on the collection resource		DAV:principal-collection-set property on the collection resource
	identified by URL http://www.example.com/papers/. The property		identified by URL http://www.example.com/papers/. The property
	contains the two URLs, http://www.example.com/acl/users/ and		contains the two URLs, http://www.example.com/acl/users/ and
	http://www.example.com/acl/groups/, both wrapped in DAV:href XML		http://www.example.com/acl/groups/, both wrapped in DAV:href XML
	skipping to change at line 1438		skipping to change at line 1368
	realm="yarong@webdav.org", nonce="...",		realm="yarong@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:propfind xmlns:D="DAV:">		<D:propfind xmlns:D="DAV:">
	<D:prop>		<D:prop>
	<D:principal-collection-set/>		<D:principal-collection-set/>
	</D:prop>		</D:prop>
	</D:propfind>		</D:propfind>
			Clemm, Hopkins, Sedlar, Whitehead [Page 26]
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/papers/</D:href>		<D:href>http://www.example.com/papers/</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:principal-collection-set>		<D:principal-collection-set>
	<D:href>http://www.example.com/acl/users/</D:href>		<D:href>http://www.example.com/acl/users/</D:href>
	Clemm, et al. [Page 27]
	<D:href>http://www.example.com/acl/groups/</D:href>		<D:href>http://www.example.com/acl/groups/</D:href>
	</D:principal-collection-set>		</D:principal-collection-set>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	5.8 Example: PROPFIND to retrieve access control properties		5.8 Example: PROPFIND to retrieve access control properties
	The following example shows how access control information can be		The following example shows how access control information can be
	retrieved by using the PROPFIND method to fetch the values of the		retrieved by using the PROPFIND method to fetch the values of the
	DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-		DAV:owner, DAV:supported-privilege-set, DAV:current-user-
	set, and DAV:acl properties.		privilege-set, and DAV:acl properties.
	>> Request <<		>> Request <<
	PROPFIND /top/container/ HTTP/1.1		PROPFIND /top/container/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	Depth: 0		Depth: 0
	Authorization: Digest username="ejw",		Authorization: Digest username="ejw",
	realm="users@foo.org", nonce="...",		realm="users@foo.org", nonce="...",
	uri="/top/container/", response="...", opaque="..."		uri="/top/container/", response="...", opaque="..."
	skipping to change at line 1493		skipping to change at line 1421
	<D:owner/>		<D:owner/>
	<D:supported-privilege-set/>		<D:supported-privilege-set/>
	<D:current-user-privilege-set/>		<D:current-user-privilege-set/>
	<D:acl/>		<D:acl/>
	</D:prop>		</D:prop>
	</D:propfind>		</D:propfind>
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
			Clemm, Hopkins, Sedlar, Whitehead [Page 27]
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus		<D:multistatus
	xmlns:D="DAV:"		xmlns:D="DAV:"
	xmlns:A="http://www.example.com/acl/"> <D:response>		xmlns:A="http://www.example.com/acl/"> <D:response>
	<D:href>http://www.example.com/top/container/</D:href>		<D:href>http://www.example.com/top/container/</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:owner>		<D:owner>
	<D:href>http://www.example.com/users/gclemm</D:href> </D:owner>		<D:href>http://www.example.com/users/gclemm</D:href>
			</D:owner>
	<D:supported-privilege-set>		<D:supported-privilege-set>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:all/> </D:privilege>		<D:privilege> <D:all/> </D:privilege>
	Clemm, et al. [Page 28]
	<D:abstract/>		<D:abstract/>
	<D:description xml:lang="en">Any operation</D:description>		<D:description xml:lang="en">Any operation</D:description>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
	<D:description xml:lang="en">Read any object</D:description>		<D:description xml:lang="en">Read any
			object</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:write/> </D:privilege>		<D:privilege> <D:write/> </D:privilege>
	<D:abstract/>		<D:abstract/>
	<D:description xml:lang="en">Write any object</D:description>		<D:description xml:lang="en">Write any
			object</D:description>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <A:create/> </D:privilege>		<D:privilege> <A:create/> </D:privilege>
	<D:description xml:lang="en">Create an object</D:description>		<D:description xml:lang="en">Create an
			object</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <A:update/> </D:privilege>		<D:privilege> <A:update/> </D:privilege>
	<D:description xml:lang="en">Update an object</D:description>		<D:description xml:lang="en">Update an
			object</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <A:delete/> </D:privilege>		<D:privilege> <A:unbind/> </D:privilege>
	<D:description xml:lang="en">Delete an object</D:description>		<D:description xml:lang="en">Remove binding to an
			object</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:read-acl/> </D:privilege>		<D:privilege> <D:read-acl/> </D:privilege>
	<D:description xml:lang="en">Read the ACL</D:description>		<D:description xml:lang="en">Read the
			ACL</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:write-acl/> </D:privilege>		<D:privilege> <D:write-acl/> </D:privilege>
	<D:description xml:lang="en">Write the ACL</D:description>		<D:description xml:lang="en">Write the
			ACL</D:description>
	</D:supported-privilege>		</D:supported-privilege>
			Clemm, Hopkins, Sedlar, Whitehead [Page 28]
	</D:supported-privilege>		</D:supported-privilege>
	</D:supported-privilege-set>		</D:supported-privilege-set>
	<D:current-user-privilege-set>		<D:current-user-privilege-set>
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
	<D:privilege> <D:read-acl/> </D:privilege>		<D:privilege> <D:read-acl/> </D:privilege>
	</D:current-user-privilege-set>		</D:current-user-privilege-set>
	<D:acl>		<D:acl>
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.example.com/users/esedlar</D:href>		<D:href>http://www.example.com/users/esedlar</D:href>
	skipping to change at line 1564		skipping to change at line 1502
	<D:privilege> <D:write/> </D:privilege>		<D:privilege> <D:write/> </D:privilege>
	<D:privilege> <D:read-acl/> </D:privilege> </D:grant>		<D:privilege> <D:read-acl/> </D:privilege> </D:grant>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.example.com/groups/marketing</D:href>		<D:href>http://www.example.com/groups/marketing</D:href>
	</D:principal>		</D:principal>
	<D:deny>		<D:deny>
	<D:privilege> <D:read/> </D:privilege> </D:deny>		<D:privilege> <D:read/> </D:privilege> </D:deny>
	</D:ace>		</D:ace>
	Clemm, et al. [Page 29]
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:property> <D:owner/> </D:property> </D:principal>		<D:property> <D:owner/> </D:property> </D:principal>
	<D:grant>		<D:grant>
	<D:privilege> <D:read-acl/> </D:privilege>		<D:privilege> <D:read-acl/> </D:privilege>
	<D:privilege> <D:write-acl/> </D:privilege> </D:grant>		<D:privilege> <D:write-acl/> </D:privilege> </D:grant>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:principal> <D:all/> </D:principal>		<D:principal> <D:all/> </D:principal>
	<D:grant>		<D:grant>
	<D:privilege> <D:read/> </D:privilege></D:grant>		<D:privilege> <D:read/> </D:privilege></D:grant>
	<D:inherited>		<D:inherited>
	<D:href>http://www.example.com/top</D:href> </D:inherited>		<D:href>http://www.example.com/top</D:href>
			</D:inherited>
	</D:ace> </D:acl>		</D:ace> </D:acl>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat> </D:response> </D:multistatus>		</D:propstat> </D:response> </D:multistatus>
	The value of the DAV:owner property is a single DAV:href XML		The value of the DAV:owner property is a single DAV:href XML
	element containing the URL of the principal that owns this		element containing the URL of the principal that owns this
	resource.		resource.
	The value of the DAV:supported-privilege-set property is a tree of		The value of the DAV:supported-privilege-set property is a tree of
	supported privileges (using "[XML Namespace , localname]" to		supported privileges (using "[XML Namespace , localname]" to
	identify each privilege):		identify each privilege):
			Clemm, Hopkins, Sedlar, Whitehead [Page 29]
	[DAV:, all] (aggregate, abstract)		[DAV:, all] (aggregate, abstract)
	|		|
	+-- [DAV:, read]		+-- [DAV:, read]
	+-- [DAV:, write] (aggregate, abstract)		+-- [DAV:, write] (aggregate, abstract)
	|		|
	+-- [http://www.example.com/acl, create]		+-- [http://www.example.com/acl, create]
	+-- [http://www.example.com/acl, update]		+-- [http://www.example.com/acl, update]
	+-- [http://www.example.com/acl, delete]		+-- [http://www.example.com/acl, delete]
	+-- [DAV:, read-acl]		+-- [DAV:, read-acl]
	+-- [DAV:, write-acl]		+-- [DAV:, write-acl]
	skipping to change at line 1607		skipping to change at line 1544
	+-- [http://www.example.com/acl, create]		+-- [http://www.example.com/acl, create]
	+-- [http://www.example.com/acl, update]		+-- [http://www.example.com/acl, update]
	+-- [http://www.example.com/acl, delete]		+-- [http://www.example.com/acl, delete]
	+-- [DAV:, read-acl]		+-- [DAV:, read-acl]
	+-- [DAV:, write-acl]		+-- [DAV:, write-acl]
	The DAV:current-user-privilege-set property contains two		The DAV:current-user-privilege-set property contains two
	privileges, DAV:read, and DAV:read-acl. This indicates that the		privileges, DAV:read, and DAV:read-acl. This indicates that the
	current authenticated user only has the ability to read the		current authenticated user only has the ability to read the
	resource, and read the DAV:acl property on the resource.		resource, and read the DAV:acl property on the resource.
	The DAV:acl property contains a set of four ACEs:		The DAV:acl property contains a set of four ACEs:
	ACE #1: The principal identified by the URL		ACE #1: The principal identified by the URL
	http://www.example.com/users/esedlar is granted the DAV:read,		http://www.example.com/users/esedlar is granted the DAV:read,
	DAV:write, and DAV:read-acl privileges.		DAV:write, and DAV:read-acl privileges.
	ACE #2: The principals identified by the URL		ACE #2: The principals identified by the URL
	http://www.example.com/groups/marketing are denied the DAV:read		http://www.example.com/groups/marketing are denied the DAV:read
	privilege. In this example, the principal URL identifies a group.		privilege. In this example, the principal URL identifies a group.
	Clemm, et al. [Page 30]
	ACE #3: In this ACE, the principal is a property principal,		ACE #3: In this ACE, the principal is a property principal,
	specifically the DAV:owner property. When evaluating this ACE, the		specifically the DAV:owner property. When evaluating this ACE, the
	value of the DAV:owner property is retrieved, and is examined to		value of the DAV:owner property is retrieved, and is examined to
	see if it contains a DAV:href XML element. If so, the URL within		see if it contains a DAV:href XML element. If so, the URL within
	the DAV:href element is read, and identifies a principal. In this		the DAV:href element is read, and identifies a principal. In this
	ACE, the owner is granted DAV:read-acl, and DAV:write-acl		ACE, the owner is granted DAV:read-acl, and DAV:write-acl
	privileges.		privileges.
	ACE #4: This ACE grants the DAV:all principal (all users) the		ACE #4: This ACE grants the DAV:all principal (all users) the
	DAV:read privilege. This ACE is inherited from the resource		DAV:read privilege. This ACE is inherited from the resource
	http://www.example.com/top, the parent collection of this resource.		http://www.example.com/top, the parent collection of this
			resource.
	6 ACL EVALUATION		6 ACL EVALUATION
	WebDAV ACLs are evaluated in similar manner as ACLs on Windows NT		WebDAV ACLs are evaluated in similar manner as ACLs on Windows NT
	and in NFSv4 [NFSV4]). An ACL is evaluated to determine whether or		and in NFSv4 [NFSV4]). An ACL is evaluated to determine whether
	not access will be granted for a WebDAV request. ACEs are		or not access will be granted for a WebDAV request. ACEs are
	maintained in a particular order, and are evaluated until all of		maintained in a particular order, and are evaluated until all of
	the permissions required by the current request have been granted,		the permissions required by the current request have been granted,
	at which point the ACL evaluation is terminated and access is		at which point the ACL evaluation is terminated and access is
	granted. If, during ACL evaluation, a <deny> ACE (matching the		granted. If, during ACL evaluation, a <deny> ACE (matching the
	current user) is encountered for a privilege which has not yet been		current user) is encountered for a privilege which has not yet
	granted, the ACL evaluation is terminated and access is denied.		been granted, the ACL evaluation is terminated and access is
	Failure to have all required privileges granted results in access		denied. Failure to have all required privileges granted results
	being denied.		in access being denied.
	Note that the semantics of many other existing ACL systems may be		Note that the semantics of many other existing ACL systems may be
	represented via this mechanism, by mixing deny and grant ACEs. For		represented via this mechanism, by mixing deny and grant ACEs.
	example, consider the standard "rwx" privilege scheme used by UNIX.		For example, consider the standard "rwx" privilege scheme used by
	In this scheme, if the current user is the owner of the file,		UNIX. In this scheme, if the current user is the owner of the
	access is granted if the corresponding privilege bit is set and		file, access is granted if the corresponding privilege bit is set
	denied if not set, regardless of the permissions set on the file’s		and denied if not set, regardless of the permissions set on the
	group and for the world. An ACL for UNIX permissions of "r--rw-r--
	"might be constructed like:
			Clemm, Hopkins, Sedlar, Whitehead [Page 30]
			file’s group and for the world. An ACL for UNIX permissions of
			"r--rw-r--"might be constructed like:
	<D:acl>		<D:acl>
	<D:ace>		<D:ace>
	<D:principal><D:property><D:owner/></D:property></D:principal>		<D:principal><D:property>
			<D:owner/></D:property></D:principal>
	<D:grant><D:privilege><D:read/></D:privilege></D:grant>		<D:grant><D:privilege><D:read/></D:privilege></D:grant>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:principal><D:property><D:owner/></D:property></D:principal>		<D:principal><D:property>
			<D:owner/> </D:property></D:principal>
	<D:deny><D:privilege><D:all/></D:privilege></D:deny>		<D:deny><D:privilege><D:all/></D:privilege></D:deny>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:principal><D:property><D:group/></D:property></D:principal>		<D:principal><D:property>
			<D:group/> </D:property></D:principal>
	<D:grant><D:privilege><D:read/></D:privilege>		<D:grant><D:privilege><D:read/></D:privilege>
	<D:privilege><D:write/></D:privilege></D:grant>		<D:privilege><D:write/></D:privilege></D:grant>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:principal><D:property><D:group/></D:property></D:principal>		<D:principal><D:property>
			<D:group/> </D:property></D:principal>
	Clemm, et al. [Page 31]
	<D:deny><D:privilege><D:all/></D:privilege></D:deny>		<D:deny><D:privilege><D:all/></D:privilege></D:deny>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:principal><D:all></D:principal>		<D:principal><D:all></D:principal>
	<D:grant><D:privilege><D:read/></D:privilege></D:grant>		<D:grant><D:privilege><D:read/></D:privilege></D:grant>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
	and the <acl-restrictions> would be defined as:		and the <acl-restrictions> would be defined as:
	<D:no-invert/><D:principal-only-one-ace/>		<D:no-invert/><D:principal-only-one-ace/>
	<D:required-principal>		<D:required-principal>
	<D:all/>		<D:all/>
	<D:property><D:owner/></D:property>		<D:property><D:owner/></D:property>
	<D:property><D:group/><D:group/>		<D:property><D:group/><D:group/>
	</D:required-principal>		</D:required-principal>
	Note that the client can still get errors from a UNIX server in		Note that the client can still get errors from a UNIX server in
	spite of obeying the <acl-restrictions>, including <D:allowed-		spite of obeying the <acl-restrictions>, including <D:allowed-
	principal> (adding an ACE specifying a principal other than the		principal> (adding an ACE specifying a principal other than the
	ones in the ACL above) or <D:ace-conflict> (by trying to reorder		ones in the ACL above) or <D:ace-conflict> (by trying to reorder
	the ACEs in the example above), as these particular implementation		the ACEs in the example above), as these particular implementation
	semantics are too complex to be captured with the simple (but		semantics are too complex to be captured with the simple (but
	general) declarative restrictions.		general) declarative restrictions.
	7 ACCESS CONTROL AND EXISTING METHODS		7 ACCESS CONTROL AND EXISTING METHODS
	skipping to change at line 1701		skipping to change at line 1634
	ones in the ACL above) or <D:ace-conflict> (by trying to reorder		ones in the ACL above) or <D:ace-conflict> (by trying to reorder
	the ACEs in the example above), as these particular implementation		the ACEs in the example above), as these particular implementation
	semantics are too complex to be captured with the simple (but		semantics are too complex to be captured with the simple (but
	general) declarative restrictions.		general) declarative restrictions.
	7 ACCESS CONTROL AND EXISTING METHODS		7 ACCESS CONTROL AND EXISTING METHODS
	This section defines the impact of access control functionality on		This section defines the impact of access control functionality on
	existing methods.		existing methods.
	7.1 OPTIONS		Clemm, Hopkins, Sedlar, Whitehead [Page 31]
			7.1 ANY HTTP METHOD
			7.1.1 Error Handling
			The WebDAV ACL mechanism requires the usage of HTTP method
			"preconditions" as described in section 1.6 of RFC3253 for ALL
			HTTP methods. All HTTP methods have an additional precondition
			called DAV:need-privileges. If an HTTP method fails due to
			insufficient privileges, the response body to the "403 Forbidden"
			error MUST contain the <DAV:error> element, which in turn contains
			the <DAV:need-privileges> element, which contains one or more
			<DAV:resource> elements indicating which resource had insufficient
			privileges, and what the lacking privileges were:
			<!ELEMENT need-privileges (resource)* >
			<!ELEMENT resource ( href , privilege ) >
			Since some methods require multiple permissions on multiple
			resources, this information is needed to resolve any ambiguity.
			There is no requirement that all privilege violations be reported—
			for implementation reasons, some servers may only report the first
			privilege violation. For example:
			>> Request <<
			MOVE /a/b/ HTTP/1.1
			Host: www.example.com
			Destination: http://www.example.com/c/d
			>> Response <<
			HTTP/1.1 403 Forbidden
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<D:error xmlns:D="DAV:">
			<D:need-privileges>
			<D:resource>
			<D:href>/a</D:href>
			<D:privilege><D:unbind/></D:privilege>
			</D:resource>
			<D:resource>
			<D:href>/c</D:href>
			<D:privilege><D:bind/></D:privilege>
			</D:resource>
			</D:need-privileges>
			</D:error>
			7.2 OPTIONS
	If the server supports access control, it MUST return "access-		If the server supports access control, it MUST return "access-
	control" as a field in the DAV response header from an OPTIONS		control" as a field in the DAV response header from an OPTIONS
	request on any resource implemented by that server. A value of		request on any resource implemented by that server. A value of
	"access-control" in the DAV header MUST indicate that the server		"access-control" in the DAV header MUST indicate that the server
			Clemm, Hopkins, Sedlar, Whitehead [Page 32]
	supports all MUST level requirements and REQUIRED features		supports all MUST level requirements and REQUIRED features
	specified in this document.		specified in this document.
	7.1.1Example - OPTIONS		7.2.1 Example - OPTIONS
	>> Request <<		>> Request <<
	OPTIONS /foo.html HTTP/1.1		OPTIONS /foo.html HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Length: 0		Content-Length: 0
	>> Response <<		>> Response <<
	Clemm, et al. [Page 32]
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	DAV: 1, 2, access-control		DAV: 1, 2, access-control
	Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL		Allow: OPTIONS, GET, PUT, PROPFIND, PROPPATCH, ACL
	In this example, the OPTIONS response indicates that the server		In this example, the OPTIONS response indicates that the server
	supports access control and that /foo.html can have its access		supports access control and that /foo.html can have its access
	control list modified by the ACL method.		control list modified by the ACL method.
	7.2 MOVE		7.3 MOVE
	When a resource is moved from one location to another due to a MOVE		When a resource is moved from one location to another due to a
	request, the non-inherited and non-protected ACEs in the DAV:acl		MOVE request, the non-inherited and non-protected ACEs in the
	property of the resource MUST NOT be modified, or the MOVE request		DAV:acl property of the resource MUST NOT be modified, or the MOVE
	fails. Handling of inherited and protected ACEs is intentionally		request fails. Handling of inherited and protected ACEs is
	undefined to give server implementations flexibility in how they		intentionally undefined to give server implementations flexibility
	implement ACE inheritance and protection.		in how they implement ACE inheritance and protection.
	7.3 COPY		7.4 COPY
	The DAV:acl property on the resource at the destination of a COPY		The DAV:acl property on the resource at the destination of a COPY
	MUST be the same as if the resource was created by an individual		MUST be the same as if the resource was created by an individual
	resource creation request (e.g. MKCOL, PUT). Clients wishing to		resource creation request (e.g. MKCOL, PUT). Clients wishing to
	preserve the DAV:acl property across a copy need to read the		preserve the DAV:acl property across a copy need to read the
	DAV:acl property prior to the COPY, then perform an ACL operation		DAV:acl property prior to the COPY, then perform an ACL operation
	on the new resource at the destination to restore, insofar as this		on the new resource at the destination to restore, insofar as this
	is possible, the original access control list.		is possible, the original access control list.
	7.4 LOCK		7.5 LOCK
	A lock on a resource ensures that only the lock owner can modify		A lock on a resource ensures that only the lock owner can modify
	ACEs that are not inherited and not protected (these are the only		ACEs that are not inherited and not protected (these are the only
	ACEs that a client can modify with an ACL request). A lock does not		ACEs that a client can modify with an ACL request). A lock does
	protect inherited or protected ACEs, since a client cannot modify		not protect inherited or protected ACEs, since a client cannot
	them with an ACL request on that resource.		modify them with an ACL request on that resource.
	8 ACCESS CONTROL METHODS		8 ACCESS CONTROL METHODS
	8.1 ACL		8.1 ACL
	The ACL method modifies the access control list (which can be read		The ACL method modifies the access control list (which can be read
	via the DAV:acl property) of a resource. Specifically, the ACL		via the DAV:acl property) of a resource. Specifically, the ACL
			Clemm, Hopkins, Sedlar, Whitehead [Page 33]
	method only permits modification to ACEs that are not inherited,		method only permits modification to ACEs that are not inherited,
	and are not protected. An ACL method invocation modifies all non-		and are not protected. An ACL method invocation modifies all non-
	inherited and non-protected ACEs in a resource's access control		inherited and non-protected ACEs in a resource's access control
	list to exactly match the ACEs contained within in the DAV:acl XML		list to exactly match the ACEs contained within in the DAV:acl XML
	element (specified in Section 5.4) of the request body. An ACL		element (specified in Section 5.4) of the request body. An ACL
	request body MUST contain only one DAV:acl XML element. Unless the		request body MUST contain only one DAV:acl XML element. Unless the
	non-inherited and non-protected ACEs of the DAV:acl property of the		non-inherited and non-protected ACEs of the DAV:acl property of
			the resource can be updated to be exactly the value specified in
	Clemm, et al. [Page 33]		the ACL request, the ACL request MUST fail.
	resource can be updated to be exactly the value specified in the
	ACL request, the ACL request MUST fail.
	It is possible that the ACEs visible to the current user in the		It is possible that the ACEs visible to the current user in the
	DAV:acl property may only be a portion of the complete set of ACEs		DAV:acl property may only be a portion of the complete set of ACEs
	on that resource. If this is the case, an ACL request only modifies		on that resource. If this is the case, an ACL request only
	the set of ACEs visible to the current user, and does not affect		modifies the set of ACEs visible to the current user, and does not
	any non-visible ACE.		affect any non-visible ACE.
	In order to avoid overwriting DAV:acl changes by another client, a		In order to avoid overwriting DAV:acl changes by another client, a
	client SHOULD acquire a WebDAV lock on the resource before		client SHOULD acquire a WebDAV lock on the resource before
	retrieving the DAV:acl property of a resource that it intends on		retrieving the DAV:acl property of a resource that it intends on
	updating.		updating.
			Implementation Note: Two common operations are to add or remove
	Implementation Note: Two common operations are to add or remove an		an ACE from an existing access control list. To accomplish
	ACE from an existing access control list. To accomplish this, a		this, a client uses the PROPFIND method to retrieve the value
	client uses the PROPFIND method to retrieve the value of the		of the DAV:acl property, then parses the returned access
	DAV:acl property, then parses the returned access control list to		control list to remove all inherited and protected ACEs (these
	remove all inherited and protected ACEs (these ACEs are tagged with		ACEs are tagged with the DAV:inherited and DAV:protected XML
	the DAV:inherited and DAV:protected XML elements). In the remaining		elements). In the remaining set of non-inherited, non-protected
	set of non-inherited, non-protected ACEs, the client can add or		ACEs, the client can add or remove one or more ACEs before
	remove one or more ACEs before submitting the final ACE set in the		submitting the final ACE set in the request body of the ACL
	request body of the ACL method.		method.
	8.1.1ACL Preconditions		8.1.1ACL Preconditions
	An implementation MUST enforce the following constraints on an ACL		An implementation MUST enforce the following constraints on an ACL
	request. If the constraint is violated, a 403 (Forbidden) or 409		request. If the constraint is violated, a 403 (Forbidden) or 409
	(Conflict) response MUST be returned and the indicated XML element		(Conflict) response MUST be returned and the indicated XML element
	MUST be returned as a child of a top level DAV:error element in an		MUST be returned as a child of a top level DAV:error element in an
	XML response body.		XML response body.
	Though these status elements are generally expressed as empty XML		Though these status elements are generally expressed as empty XML
	elements (and are defined as EMPTY in the DTD), implementations MAY		elements (and are defined as EMPTY in the DTD), implementations
	return additional descriptive XML elements as children of the		MAY return additional descriptive XML elements as children of the
	status element. Clients MUST be able to accept children of these		status element. Clients MUST be able to accept children of these
	status elements. Clients that do not understand the additional XML		status elements. Clients that do not understand the additional XML
	elements should ignore them.		elements should ignore them.
	(DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST		(DAV:no-ace-conflict): The ACEs submitted in the ACL request MUST
	NOT conflict with each other. This is a catchall error code		NOT conflict with each other. This is a catchall error code
	indicating that an implementation-specific ACL restriction has been		indicating that an implementation-specific ACL restriction has
	violated.		been violated.
	(DAV:no-protected-ace-conflict): The ACEs submitted in the ACL		(DAV:no-protected-ace-conflict): The ACEs submitted in the ACL
	request MUST NOT conflict with the protected ACEs on the resource.		request MUST NOT conflict with the protected ACEs on the resource.
	For example, if the resource has a protected ACE granting DAV:write		For example, if the resource has a protected ACE granting
	to a given principal, then it would not be consistent if the ACL		DAV:write to a given principal, then it would not be consistent if
	request submitted an ACE denying DAV:write to the same principal.
			Clemm, Hopkins, Sedlar, Whitehead [Page 34]
			the ACL request submitted an ACE denying DAV:write to the same
			principal.
	(DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL		(DAV:no-inherited-ace-conflict): The ACEs submitted in the ACL
	request MUST NOT conflict with the inherited ACEs on the resource.		request MUST NOT conflict with the inherited ACEs on the resource.
	For example, if the resource inherits an ACE from its parent		For example, if the resource inherits an ACE from its parent
	Clemm, et al. [Page 34]
	collection granting DAV:write to a given principal, then it would		collection granting DAV:write to a given principal, then it would
	not be consistent if the ACL request submitted an ACE denying		not be consistent if the ACL request submitted an ACE denying
	DAV:write to the same principal. Note that reporting of this error		DAV:write to the same principal. Note that reporting of this error
	will be implementation-dependent. Implementations MUST either		will be implementation-dependent. Implementations MUST either
	report this error or allow the ACE to be set, and then let normal		report this error or allow the ACE to be set, and then let normal
	ACE evaluation rules determine whether the new ACE has any impact		ACE evaluation rules determine whether the new ACE has any impact
	on the privileges available to a specific principal.		on the privileges available to a specific principal.
	(DAV:limited-number-of-aces): The number of ACEs submitted in the		(DAV:limited-number-of-aces): The number of ACEs submitted in the
	ACL request MUST NOT exceed the number of ACEs allowed on that		ACL request MUST NOT exceed the number of ACEs allowed on that
	resource. However, ACL-compliant servers MUST support at least one		resource. However, ACL-compliant servers MUST support at least
	ACE granting privileges to a single principal, and one ACE granting		one ACE granting privileges to a single principal, and one ACE
	privileges to a group.		granting privileges to a group.
	(DAV:deny-before-grant): All non-inherited deny ACEs MUST precede		(DAV:deny-before-grant): All non-inherited deny ACEs MUST precede
	all non-inherited grant ACEs.		all non-inherited grant ACEs.
	(DAV:grant-only): The ACEs submitted in the ACL request MUST NOT		(DAV:grant-only): The ACEs submitted in the ACL request MUST NOT
	include a deny ACE. This precondition applies only when the ACL		include a deny ACE. This precondition applies only when the ACL
	restrictions of the resource include the DAV:grant-only constraint		restrictions of the resource include the DAV:grant-only constraint
	(defined in Section 5.5.1).		(defined in Section 5.5.1).
	(DAV:no-invert): The ACL request MUST NOT include a DAV:invert		(DAV:no-invert): The ACL request MUST NOT include a DAV:invert
	element. This precondition applies only when the ACL semantics of		element. This precondition applies only when the ACL semantics
	the resource includes the DAV:no-invert constraint (defined in		of the resource includes the DAV:no-invert constraint (defined in
	Section 6.3.4).		Section 6.3.4).
	(DAV:no-abstract): The ACL request MUST NOT attempt to grant or		(DAV:no-abstract): The ACL request MUST NOT attempt to grant or
	deny an abstract privilege (see Section 5.2).		deny an abstract privilege (see Section 5.2).
	(DAV:not-supported-privilege): The ACEs submitted in the ACL		(DAV:not-supported-privilege): The ACEs submitted in the ACL
	request MUST be supported by the resource.		request MUST be supported by the resource.
	(DAV:missing-required-principal): The result of the ACL request		(DAV:missing-required-principal): The result of the ACL request
	MUST have at least one ACE for each principal identified in a		MUST have at least one ACE for each principal identified in a
	DAV:required-principal XML element in the ACL semantics of that		DAV:required-principal XML element in the ACL semantics of that
	resource (see Section 5.5.4).		resource (see Section 5.5.4).
	(DAV:recognized-principal): Every principal URL in the ACL request		(DAV:recognized-principal): Every principal URL in the ACL request
	MUST identify a principal resource.		MUST identify a principal resource.
	(DAV:allowed-principal): The principals specified in the ACEs		(DAV:allowed-principal): The principals specified in the ACEs
	submitted in the ACL request MUST be allowed as principals for the		submitted in the ACL request MUST be allowed as principals for the
	resource. For example, a server where only authenticated principals		resource. For example, a server where only authenticated
	can access resources would not allow the DAV:all or		principals can access resources would not allow the DAV:all or
	DAV:unauthenticated principals to be used in an ACE, since these		DAV:unauthenticated principals to be used in an ACE, since these
	would allow unauthenticated access to resources.		would allow unauthenticated access to resources.
	8.1.2Example: the ACL method		8.1.2Example: the ACL method
	In the following example, user "fielding", authenticated by		In the following example, user "fielding", authenticated by
	information in the Authorization header, grants the principal		information in the Authorization header, grants the principal
	identified by the URL http://www.example.com/users/esedlar (i.e.,		identified by the URL http://www.example.com/users/esedlar (i.e.,
	Clemm, et al. [Page 35]		Clemm, Hopkins, Sedlar, Whitehead [Page 35]
	the user "esedlar") read and write privileges, grants the owner of		the user "esedlar") read and write privileges, grants the owner of
	the resource read-acl and write-acl privileges, and grants everyone		the resource read-acl and write-acl privileges, and grants
	read privileges.		everyone read privileges.
	>> Request <<		>> Request <<
	ACL /top/container/ HTTP/1.1		ACL /top/container/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx		Content-Length: xxxx
	Authorization: Digest username="fielding",		Authorization: Digest username="fielding",
	realm="users@foo.org", nonce="...",		realm="users@foo.org", nonce="...",
	uri="/top/container/", response="...", opaque="..."		uri="/top/container/", response="...", opaque="..."
	skipping to change at line 1932		skipping to change at line 1899
	>> Response <<		>> Response <<
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	8.1.3Example: ACL method failure due to protected ACE conflict		8.1.3Example: ACL method failure due to protected ACE conflict
	In the following request, user "fielding", authenticated by		In the following request, user "fielding", authenticated by
	information in the Authorization header, attempts to deny the		information in the Authorization header, attempts to deny the
	principal identified by the URL		principal identified by the URL
	http://www.example.com/users/esedlar (i.e., the user "esedlar")		http://www.example.com/users/esedlar (i.e., the user "esedlar")
	write privileges. Prior to the request, the DAV:acl property on the		write privileges. Prior to the request, the DAV:acl property on
	resource contained a protected ACE (see Section 5.4.3) granting		the resource contained a protected ACE (see Section 5.4.3)
	DAV:owner the DAV:read and DAV:write privileges. The principal		granting DAV:owner the DAV:read and DAV:write privileges. The
	Clemm, et al. [Page 36]
	identified by URL http://www.example.com/users/esedlar is the owner
	of the resource. The ACL method invocation fails because the
	submitted ACE conflicts with the protected ACE, thus violating the
	semantics of ACE protection.
			Clemm, Hopkins, Sedlar, Whitehead [Page 36]
			principal identified by URL http://www.example.com/users/esedlar
			is the owner of the resource. The ACL method invocation fails
			because the submitted ACE conflicts with the protected ACE, thus
			violating the semantics of ACE protection.
	>> Request <<		>> Request <<
	ACL /top/container/ HTTP/1.1		ACL /top/container/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx		Content-Length: xxxx
	Authorization: Digest username="fielding",		Authorization: Digest username="fielding",
	realm="users@foo.org", nonce="...",		realm="users@foo.org", nonce="...",
	uri="/top/container/", response="...", opaque="..."		uri="/top/container/", response="...", opaque="..."
	skipping to change at line 1981		skipping to change at line 1947
	<D:error xmlns:D="DAV:">		<D:error xmlns:D="DAV:">
	<D:no-protected-ace-conflict/>		<D:no-protected-ace-conflict/>
	</D:error>		</D:error>
	8.1.4Example: ACL method failure due to an inherited ACE conflict		8.1.4Example: ACL method failure due to an inherited ACE conflict
	In the following request, user "ejw", authenticated by information		In the following request, user "ejw", authenticated by information
	in the Authorization header, tries to change the access control		in the Authorization header, tries to change the access control
	list on the resource http://www.example.com/top/index.html. This		list on the resource http://www.example.com/top/index.html. This
	resource has two inherited ACEs.		resource has two inherited ACEs.
	Inherited ACE #1 grants the principal identified by URL		Inherited ACE #1 grants the principal identified by URL
	http://www.example.com/users/ejw (i.e., the user "ejw")		http://www.example.com/users/ejw (i.e., the user "ejw")
	http://www.example.com/privs/write-all and DAV:read-acl privileges.		http://www.example.com/privs/write-all and DAV:read-acl
	On this server, http://www.example.com/privs/write-all is an		privileges. On this server, http://www.example.com/privs/write-all
	aggregate privilege containing DAV:write, and DAV:write-acl.		is an aggregate privilege containing DAV:write, and DAV:write-acl.
	Inherited ACE #2 grants principal DAV:all the DAV:read privilege.		Inherited ACE #2 grants principal DAV:all the DAV:read privilege.
	Clemm, et al. [Page 37]
	The request attempts to set a (non-inherited) ACE, denying the		The request attempts to set a (non-inherited) ACE, denying the
	principal identified by the URL http://www.example.com/users/ejw		principal identified by the URL http://www.example.com/users/ejw
	(i.e., the user "ejw") DAV:write permission. This conflicts with		(i.e., the user "ejw") DAV:write permission. This conflicts with
	inherited ACE #1. Note that the decision to report an inherited ACE
	conflict is specific to this server implementation. Another server
	implementation could have allowed the new ACE to be set, and then
	used normal ACE evaluation rules to determine whether the new ACE
	has any impact on the privileges available to a principal.
			Clemm, Hopkins, Sedlar, Whitehead [Page 37]
			inherited ACE #1. Note that the decision to report an inherited
			ACE conflict is specific to this server implementation. Another
			server implementation could have allowed the new ACE to be set,
			and then used normal ACE evaluation rules to determine whether the
			new ACE has any impact on the privileges available to a principal.
	>> Request <<		>> Request <<
	ACL /top/index.html HTTP/1.1		ACL /top/index.html HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx		Content-Length: xxxx
	Authorization: Digest username="ejw",		Authorization: Digest username="ejw",
	realm="users@foo.org", nonce="...",		realm="users@foo.org", nonce="...",
	uri="/top/index.html", response="...", opaque="..."		uri="/top/index.html", response="...", opaque="..."
	skipping to change at line 2031		skipping to change at line 1994
	HTTP/1.1 403 Forbidden		HTTP/1.1 403 Forbidden
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:error xmlns:D="DAV:">		<D:error xmlns:D="DAV:">
	<D:no-inherited-ace-conflict xmlns:D="DAV:"/>		<D:no-inherited-ace-conflict xmlns:D="DAV:"/>
	</D:error>		</D:error>
	8.1.5Example: ACL method failure due to an attempt to set grant and deny in a		8.1.5 Example: ACL method failure due to an attempt to set grant and
	single ACE.		deny in a single ACE.
	In this example, user "ygoland", authenticated by information in		In this example, user "ygoland", authenticated by information in
	the Authorization header, tries to change the access control list		the Authorization header, tries to change the access control list
	on the resource http://www.example.com/diamond/engagement-ring.gif.		on the resource http://www.example.com/diamond/engagement-
	The ACL request includes a single, syntactically and semantically		ring.gif. The ACL request includes a single, syntactically and
	incorrect ACE, which attempts to grant the group identified by the		semantically incorrect ACE, which attempts to grant the group
	URL http://www.example.com/users/friends DAV:read privilege and		identified by the URL http://www.example.com/users/friends
	deny the principal identified by URL		DAV:read privilege and deny the principal identified by URL
	http://www.example.com/users/ygoland-so (i.e., the user "ygoland-		http://www.example.com/users/ygoland-so (i.e., the user "ygoland-
	so") DAV:read privilege. However, it is illegal to have multiple		so") DAV:read privilege. However, it is illegal to have multiple
	principal elements, as well as both a grant and deny element in the		principal elements, as well as both a grant and deny element in
	same ACE, so the request fails due to poor syntax.		the same ACE, so the request fails due to poor syntax.
	Clemm, et al. [Page 38]
	>> Request <<		>> Request <<
	ACL /diamond/engagement-ring.gif HTTP/1.1		ACL /diamond/engagement-ring.gif HTTP/1.1
			Clemm, Hopkins, Sedlar, Whitehead [Page 38]
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx		Content-Length: xxxx
	Authorization: Digest username="ygoland",		Authorization: Digest username="ygoland",
	realm="users@foo.org", nonce="...",		realm="users@foo.org", nonce="...",
	uri="/diamond/engagement-ring.gif", response="...", opaque="..."		uri="/diamond/engagement-ring.gif", response="...",
			opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:acl xmlns:D="DAV:">		<D:acl xmlns:D="DAV:">
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.example.com/users/friends</D:href>		<D:href>http://www.example.com/users/friends</D:href>
	</D:principal>		</D:principal>
	<D:grant><D:read/></D:grant>		<D:grant><D:read/></D:grant>
	<D:principal>		<D:principal>
	<D:href>http://www.example.com/users/ygoland-so</D:href>		<D:href>http://www.example.com/users/ygoland-so</D:href>
	skipping to change at line 2084		skipping to change at line 2048
	Content-Length: 0		Content-Length: 0
	Note that if the request had been divided into two ACEs, one to		Note that if the request had been divided into two ACEs, one to
	grant, and one to deny, the request would have been syntactically		grant, and one to deny, the request would have been syntactically
	well formed.		well formed.
	9 ACCESS CONTROL REPORTS		9 ACCESS CONTROL REPORTS
	9.1 REPORT Method		9.1 REPORT Method
	The REPORT method (defined in Section 3.6 of [RFC3253]) provides an		The REPORT method (defined in Section 3.6 of [RFC3253]) provides
	extensible mechanism for obtaining information about a resource.		an extensible mechanism for obtaining information about a
	Unlike the PROPFIND method, which returns the value of one or more		resource. Unlike the PROPFIND method, which returns the value of
	named properties, the REPORT method can involve more complex		one or more named properties, the REPORT method can involve more
	processing. REPORT is valuable in cases where the server has access		complex processing. REPORT is valuable in cases where the server
	to all of the information needed to perform the complex request		has access to all of the information needed to perform the complex
	(such as a query), and where it would require multiple requests for		request (such as a query), and where it would require multiple
	the client to retrieve the information needed to perform the same		requests for the client to retrieve the information needed to
	request.		perform the same request.
	A server that supports the WebDAV Access Control Protocol MUST		A server that supports the WebDAV Access Control Protocol MUST
	support the DAV:expand-property report (defined in Section 3.8 of		support the DAV:expand-property report (defined in Section 3.8 of
	[RFC3253]).		[RFC3253]).
	Clemm, et al. [Page 39]
	9.2 DAV:acl-principal-prop-set Report		9.2 DAV:acl-principal-prop-set Report
	The DAV:acl-principal-prop-set report returns, for all principals		The DAV:acl-principal-prop-set report returns, for all principals
	in the DAV:acl property (of the Request-URI) that are identified by		in the DAV:acl property (of the Request-URI) that are identified
	http(s) URLs or by a DAV:property principal, the value of the		by http(s) URLs or by a DAV:property principal, the value of the
	properties specified in the REPORT request body. In the case where
	a principal URL appears multiple times, the DAV:acl-principal-prop-
	set report MUST return the properties for that principal only once.
	Support for this report is REQUIRED.
			Clemm, Hopkins, Sedlar, Whitehead [Page 39]
			properties specified in the REPORT request body. In the case where
			a principal URL appears multiple times, the DAV:acl-principal-
			prop-set report MUST return the properties for that principal only
			once. Support for this report is REQUIRED.
	One expected use of this report is to retrieve the human readable		One expected use of this report is to retrieve the human readable
	name (found in the DAV:displayname property) of each principal		name (found in the DAV:displayname property) of each principal
	found in an ACL. This is useful for constructing user interfaces		found in an ACL. This is useful for constructing user interfaces
	that show each ACE in a human readable form.		that show each ACE in a human readable form.
	Marshalling		Marshalling
	The request body MUST be a DAV:acl-principal-prop-set XML element.		The request body MUST be a DAV:acl-principal-prop-set XML element.
	<!ELEMENT acl-principal-prop-set ANY>		<!ELEMENT acl-principal-prop-set ANY>
	ANY value: a sequence of one or more elements, with at most one DAV:prop		ANY value: a sequence of one or more elements, with at most one
	element.		DAV:prop element.
	prop: see RFC 2518, Section 12.11		prop: see RFC 2518, Section 12.11
	This report is only defined when the Depth header has value "0";		This report is only defined when the Depth header has value "0";
	other values result in a 400 (Bad Request) error response. Note		other values result in a 400 (Bad Request) error response. Note
	that [RFC3253], Section 3.6, states that if the Depth header is not		that [RFC3253], Section 3.6, states that if the Depth header is
	present, it defaults to a value of "0".		not present, it defaults to a value of "0".
	The response body for a successful request MUST be a		The response body for a successful request MUST be a
	DAV:multistatus XML element (i.e., the response uses the same		DAV:multistatus XML element (i.e., the response uses the same
	format as the response for PROPFIND). In the case where there are		format as the response for PROPFIND). In the case where there are
	no response elements, the returned multistatus XML element is		no response elements, the returned multistatus XML element is
	empty.		empty.
	multistatus: see RFC 2518, Section 12.9		multistatus: see RFC 2518, Section 12.9
	The response body for a successful DAV:acl-principal-prop-set		The response body for a successful DAV:acl-principal-prop-set
	REPORT request MUST contain a DAV:response element for each		REPORT request MUST contain a DAV:response element for each
	principal identified by an http(s) URL listed in a DAV:principal		principal identified by an http(s) URL listed in a DAV:principal
	XML element of an ACE within the DAV:acl property of the resource		XML element of an ACE within the DAV:acl property of the resource
	identified by the Request-URI.		identified by the Request-URI.
	Postconditions:		Postconditions:
	(DAV:number-of-matches-within-limits): The number of matching		(DAV:number-of-matches-within-limits): The number of matching
	principals must fall within server-specific, predefined limits. For		principals must fall within server-specific, predefined limits.
	example, this condition might be triggered if a search		For example, this condition might be triggered if a search
	specification would cause the return of an extremely large number		specification would cause the return of an extremely large number
	of responses.		of responses.
	Clemm, et al. [Page 40]
	9.2.1Example: DAV:acl-principal-prop-set Report		9.2.1Example: DAV:acl-principal-prop-set Report
	Resource http://www.example.com/index.html has an ACL with three		Resource http://www.example.com/index.html has an ACL with three
	ACEs:		ACEs:
	ACE #1: All principals (DAV:all) have DAV:read and DAV:read-		ACE #1: All principals (DAV:all) have DAV:read and DAV:read-
	current-user-privilege-set access.		current-user-privilege-set access.
	ACE #2: The principal identified by		ACE #2: The principal identified by
	http://www.example.com/people/gstein (the user "gstein") is granted		http://www.example.com/people/gstein (the user "gstein") is
	DAV:write, DAV:write-acl, DAV:read-acl privileges.		granted DAV:write, DAV:write-acl, DAV:read-acl privileges.
			Clemm, Hopkins, Sedlar, Whitehead [Page 40]
	ACE #3: The group identified by		ACE #3: The group identified by
	http://www.example.com/groups/authors (the "authors" group) is		http://www.example.com/groups/authors (the "authors" group) is
	granted DAV:write and DAV:read-acl privileges.		granted DAV:write and DAV:read-acl privileges.
	The following example shows a DAV:acl-principal-prop-set report		The following example shows a DAV:acl-principal-prop-set report
	requesting the DAV:displayname property. It returns the value of		requesting the DAV:displayname property. It returns the value of
	DAV:displayname for resources http://www.example.com/people/gstein		DAV:displayname for resources http://www.example.com/people/gstein
	and http://www.example.com/groups/authors , but not for DAV:all,		and http://www.example.com/groups/authors , but not for DAV:all,
	since this is not an http(s) URL.		since this is not an http(s) URL.
	>> Request <<		>> Request <<
	REPORT /index.html HTTP/1.1		REPORT /index.html HTTP/1.1
	Host: www.example.com		Host: www.example.com
	skipping to change at line 2204		skipping to change at line 2156
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/people/gstein</D:href>		<D:href>http://www.example.com/people/gstein</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:displayname>Greg Stein</D:displayname>		<D:displayname>Greg Stein</D:displayname>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	Clemm, et al. [Page 41]
	</D:response>		</D:response>
	<D:response>		<D:response>
	<D:href>http://www.example.com/groups/authors</D:href>		<D:href>http://www.example.com/groups/authors</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:displayname>Site authors</D:displayname>		<D:displayname>Site authors</D:displayname>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
			Clemm, Hopkins, Sedlar, Whitehead [Page 41]
	9.3 DAV:principal-match REPORT		9.3 DAV:principal-match REPORT
	The DAV:principal-match REPORT is used to identify all members (at		The DAV:principal-match REPORT is used to identify all members (at
	any depth) of the collection identified by the Request-URI that		any depth) of the collection identified by the Request-URI that
	match the current user. In particular, if the collection contains		are principals and that match the current user. In particular, if
	principals, the report can be used to identify all members of the		the collection contains principals, the report can be used to
	collection that match the current user. Alternatively, if the		identify all members of the collection that match the current
	collection contains resources that have a property that identifies		user. Alternatively, if the collection contains resources that
	a principal (e.g. DAV:owner), the report can be used to identify		have a property that identifies a principal (e.g. DAV:owner), the
	all members of the collection whose property identifies a principal		report can be used to identify all members of the collection whose
	that matches the current user. For example, this report can return		property identifies a principal that matches the current user. For
	all of the resources in a collection hierarchy that are owned by		example, this report can return all of the resources in a
	the current user. Support for this report is REQUIRED.		collection hierarchy that are owned by the current user. Support
			for this report is REQUIRED.
	Marshalling:		Marshalling:
	The request body MUST be a DAV:principal-match XML element.		The request body MUST be a DAV:principal-match XML element.
	<!ELEMENT principal-match ((principal-property | self), prop?)>		<!ELEMENT principal-match ((principal-property | self), prop?)>
	<!ELEMENT principal-property ANY>		<!ELEMENT principal-property ANY>
	ANY value: an element whose value identifies a property. The expectation is		ANY value: an element whose value identifies a property. The
	the value of the named property typically contains an href element that		expectation is the value of the named property typically contains
	contains the URI of a principal		an href element that contains the URI of a principal
	<!ELEMENT self EMPTY>		<!ELEMENT self EMPTY>
	prop: see RFC 2518, Section 12.11		prop: see RFC 2518, Section 12.11
	This report is only defined when the Depth header has value "0";		This report is only defined when the Depth header has value "0";
	other values result in a 400 (Bad Request) error response. Note		other values result in a 400 (Bad Request) error response. Note
	that [RFC3253], Section 3.6, states that if the Depth header is not		that [RFC3253], Section 3.6, states that if the Depth header is
	present, it defaults to a value of "0".		not present, it defaults to a value of "0".
	The response body for a successful request MUST be a		The response body for a successful request MUST be a
	DAV:multistatus XML element. In the case where there are no		DAV:multistatus XML element. In the case where there are no
	response elements, the returned multistatus XML element is empty.		response elements, the returned multistatus XML element is empty.
	multistatus: see RFC 2518, Section 12.9		multistatus: see RFC 2518, Section 12.9
	The response body for a successful DAV:principal-match REPORT		The response body for a successful DAV:principal-match REPORT
	request MUST contain a DAV:response element for each member of the		request MUST contain a DAV:response element for each member of the
	collection that matches the current user. When the DAV:principal-		collection that matches the current user. When the DAV:principal-
	Clemm, et al. [Page 42]
	property element is used, a match occurs if the current user is		property element is used, a match occurs if the current user is
	matched by the principal identified by the URI found in the		matched by the principal identified by the URI found in the
	DAV:href element of the property identified by the DAV:principal-		DAV:href element of the property identified by the DAV:principal-
	property element. When the DAV:self element is used in a		property element. When the DAV:self element is used in a
	DAV:principal-match report issued against a group, it matches the		DAV:principal-match report issued against a group, it matches the
	group if a member identifies the same principal as the current		group if a member identifies the same principal as the current
	user.		user.
	If DAV:prop is specified in the request body, the properties		If DAV:prop is specified in the request body, the properties
	specified in the DAV:prop element MUST be reported in the		specified in the DAV:prop element MUST be reported in the
	DAV:response elements.		DAV:response elements.
			Clemm, Hopkins, Sedlar, Whitehead [Page 42]
	9.3.1Example: DAV:principal-match REPORT		9.3.1Example: DAV:principal-match REPORT
	The following example identifies the members of the collection		The following example identifies the members of the collection
	identified by the URL http://www.example.com/doc that are owned by		identified by the URL http://www.example.com/doc that are owned by
	the current user. The current user ("gclemm") is authenticated		the current user. The current user ("gclemm") is authenticated
	using Digest authentication.		using Digest authentication.
	>> Request <<		>> Request <<
	REPORT /doc/ HTTP/1.1		REPORT /doc/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Authorization: Digest username="gclemm",		Authorization: Digest username="gclemm",
	realm="gclemm@webdav.org", nonce="...",		realm="gclemm@webdav.org", nonce="...",
	uri="/papers/", response="...", opaque="..."		uri="/papers/", response="...", opaque="..."
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxxx		Content-Length: xxxx
	Depth: 0		Depth: 0
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	skipping to change at line 2313		skipping to change at line 2256
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:">		<D:multistatus xmlns:D="DAV:">
	<D:response>		<D:response>
	<D:href>http://www.example.com/doc/foo.html</D:href>		<D:href>http://www.example.com/doc/foo.html</D:href>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:response>		</D:response>
	<D:response>		<D:response>
	<D:href>http://www.example.com/doc/img/bar.gif</D:href>		<D:href>http://www.example.com/doc/img/bar.gif</D:href>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:response>		</D:response>
	Clemm, et al. [Page 43]
	</D:multistatus>		</D:multistatus>
	9.4 DAV:principal-property-search REPORT		9.4 DAV:principal-property-search REPORT
	The DAV:principal-property-search REPORT performs a search for all		The DAV:principal-property-search REPORT performs a search for all
	principals whose properties contain character data that matches the		principals whose properties contain character data that matches
	search criteria specified in the request. One expected use of this		the search criteria specified in the request. One expected use of
	report is to discover the URL of a principal associated with a		this report is to discover the URL of a principal associated with
	given person or group by searching for them by name. This is done		a given person or group by searching for them by name. This is
	by searching over DAV:displayname, which is defined on all		done by searching over DAV:displayname, which is defined on all
	principals.		principals.
			The actual search method (exact matching vs. substring matching
			vs, prefix-matching, case-sensitivity) deliberately is left to the
	The actual search method (exact matching vs. substring matching vs,		Clemm, Hopkins, Sedlar, Whitehead [Page 43]
	prefix-matching, case-sensitivity) deliberately is left to the
	server implementation to allow implementation on a wide set of		server implementation to allow implementation on a wide set of
	possible user management systems. In cases where the implementation		possible user management systems. In cases where the
	of DAV:principal-property-search is not constrained by the		implementation of DAV:principal-property-search is not constrained
	semantics of an underlying user management repository, preferred		by the semantics of an underlying user management repository,
	default semantics are caseless substring matches.		preferred default semantics are caseless substring matches.
	For implementation efficiency, servers do not typically support		For implementation efficiency, servers do not typically support
	searching on all properties. A client can discover the set of		searching on all properties. A search requesting properties that
	searchable properties by using the DAV:principal-search-property-		are not searchable for a particular principal will not match that
	set REPORT, defined in Section 9.5.		principal.
	Support for the DAV:principal-property-search report is REQUIRED.		Support for the DAV:principal-property-search report is REQUIRED.
			Implementation Note: The value of a WebDAV property is a
	Implementation Note: The value of a WebDAV property is a sequence		sequence of well-formed XML, and hence can include any
	of well-formed XML, and hence can include any character in the		character in the Unicode/ISO-10646 standard, that is, most
	Unicode/ISO-10646 standard, that is, most known characters in human		known characters in human languages. Due to the idiosyncrasies
	languages. Due to the idiosyncrasies of case mapping across human		of case mapping across human languages, implementation of case-
	languages, implementation of case-insensitive matching is non-		insensitive matching is non-trivial. Implementors of servers
	trivial. Implementors of servers that do perform substring matching		that do perform substring matching are strongly encouraged to
	are strongly encouraged to consult [CaseMap], especially Section		consult [CaseMap], especially Section 2.3 ("Caseless
	2.3 ("Caseless Matching"), for guidance when implementing their		Matching"), for guidance when implementing their case-
	case-insensitive matching algorithms.		insensitive matching algorithms.
			Implementation Note: Some implementations of this protocol will
	Implementation Note: Some implementations of this protocol will use		use an LDAP repository for storage of principal metadata. The
	an LDAP repository for storage of principal metadata. The schema		schema describing each attribute (akin to a WebDAV property) in
	describing each attribute (akin to a WebDAV property) in an LDAP		an LDAP repository specifies whether it supports case-sensitive
	repository specifies whether it supports case-sensitive or caseless		or caseless searching. One of the benefits of leaving the
	searching. One of the benefits of leaving the search method to the		search method to the discretion of the server implementation is
	discretion of the server implementation is the default LDAP		the default LDAP attribute search behavior can be used when
	attribute search behavior can be used when implementing the		implementing the DAV:principal-property-search report.
	DAV:principal-property-search report.
	Marshalling:		Marshalling:
	The request body MUST be a DAV:principal-property-search XML		The request body MUST be a DAV:principal-property-search XML
	element containing a search specification and an optional list of		element containing a search specification and an optional list of
	properties. For every principal that matches the search		properties. For every principal that matches the search
	specification, the response will contain the value of the requested		specification, the response will contain the value of the
	properties on that principal.		requested properties on that principal.
	Clemm, et al. [Page 44]
	<!ELEMENT principal-property-search		<!ELEMENT principal-property-search
	((property-search+), prop?, apply-to-principal-collection-set?) >		((property-search+), prop?, apply-to-principal-collection-set?) >
	By default, the report searches all members (at any depth) of the		By default, the report searches all members (at any depth) of the
	collection identified by the Request-URI. If DAV:apply-to-		collection identified by the Request-URI. If DAV:apply-to-
	principal-collection-set is specified in the request body, the		principal-collection-set is specified in the request body, the
	request is applied instead to each collection identified by the		request is applied instead to each collection identified by the
	DAV:prinicipal-collection-set property of the resource identified		DAV:prinicipal-collection-set property of the resource identified
	by the Request-URI.		by the Request-URI.
			The DAV:property-search element contains a prop element
	The DAV:property-search element contains a prop element enumerating		enumerating the properties to be searched and a match element,
	the properties to be searched and a match element, containing the		containing the search string.
	search string.
	<!ELEMENT property-search (prop, match) >		<!ELEMENT property-search (prop, match) >
	prop: see RFC 2518, Section 12.11		prop: see RFC 2518, Section 12.11
			Clemm, Hopkins, Sedlar, Whitehead [Page 44]
	<!ELEMENT match #PCDATA >		<!ELEMENT match #PCDATA >
	Multiple property-search elements or multiple elements within a		Multiple property-search elements or multiple elements within a
	DAV:prop element will be interpreted with a logical AND.		DAV:prop element will be interpreted with a logical AND.
	This report is only defined when the Depth header has value "0";		This report is only defined when the Depth header has value "0";
	other values result in a 400 (Bad Request) error response. Note		other values result in a 400 (Bad Request) error response. Note
	that [RFC3253], Section 3.6, states that if the Depth header is not		that [RFC3253], Section 3.6, states that if the Depth header is
	present, it defaults to a value of "0".		not present, it defaults to a value of "0".
	The response body for a successful request MUST be a		The response body for a successful request MUST be a
	DAV:multistatus XML element. In the case where there are no		DAV:multistatus XML element. In the case where there are no
	response elements, the returned multistatus XML element is empty.		response elements, the returned multistatus XML element is empty.
	multistatus: see RFC 2518, Section 12.9		multistatus: see RFC 2518, Section 12.9
	The response body for a successful DAV:principal-property-search		The response body for a successful DAV:principal-property-search
	REPORT request MUST contain a DAV:response element for each		REPORT request MUST contain a DAV:response element for each
	principal whose property values satisfy the search specification		principal whose property values satisfy the search specification
	given in DAV:principal-property-search.		given in DAV:principal-property-search.
			The response body for an unsuccessful DAV:principal-property-
	The response body for an unsuccessful DAV:principal-property-search		search REPORT request MUST contain, after the XML element
	REPORT request MUST contain, after the XML element indicating the		indicating the failed precondition or postcondition, a DAV:prop
	failed precondition or postcondition, a DAV:prop element containing		element containing the property that caused the pre/postcondition
	the property that caused the pre/postcondition to fail.		to fail.
	If DAV:prop is specified in the request body, the properties		If DAV:prop is specified in the request body, the properties
	specified in the DAV:prop element MUST be reported in the		specified in the DAV:prop element MUST be reported in the
	DAV:response elements.		DAV:response elements.
	Preconditions:		Preconditions:
			None
	(DAV:property-must-be-searchable): All properties specified in the
	DAV:principal-property-search REPORT must be searchable.
	Postconditions:		Postconditions:
	Clemm, et al. [Page 45]
	(DAV:number-of-matches-within-limits): The number of matching		(DAV:number-of-matches-within-limits): The number of matching
	principals must fall within server-specific, predefined limits. For		principals must fall within server-specific, predefined limits.
	example, this condition might be triggered if a search		For example, this condition might be triggered if a search
	specification would cause the return of an extremely large number		specification would cause the return of an extremely large number
	of responses.		of responses.
	9.4.1Matching		9.4.1Matching
	There are several cases to consider when matching strings. The		There are several cases to consider when matching strings. The
	easiest case is when a property value is "simple" and has only		easiest case is when a property value is "simple" and has only
	character information item content (see [REC-XML-INFOSET]). For		character information item content (see [REC-XML-INFOSET]). For
	example, the search string "julian" would match the DAV:displayname		example, the search string "julian" would match the
	property with value "Julian Reschke". Note that the on-the-wire		DAV:displayname property with value "Julian Reschke". Note that
	marshalling of DAV:displayname in this case is:		the on-the-wire marshalling of DAV:displayname in this case is:
	<D:displayname xmlns:D="DAV:">Julian Reschke</D:displayname>		<D:displayname xmlns:D="DAV:">Julian Reschke</D:displayname>
	The name of the property is encoded into the XML element		The name of the property is encoded into the XML element
	information item, and the character information item content of the		information item, and the character information item content of
	property is "Julian Reschke".		the property is "Julian Reschke".
			Clemm, Hopkins, Sedlar, Whitehead [Page 45]
	A more complicated case occurs when properties have mixed content		A more complicated case occurs when properties have mixed content
	(that is, compound values consisting of multiple child element		(that is, compound values consisting of multiple child element
	items, other types of information items, and character information		items, other types of information items, and character information
	item content). Consider the property "aprop" in the namespace		item content). Consider the property "aprop" in the namespace
	"http://www.example.com/props/", marshalled as:		"http://www.example.com/props/", marshalled as:
	<W:aprop xmlns:W="http://www.example.com/props/">		<W:aprop xmlns:W="http://www.example.com/props/">
	{cdata 0}<W:elem1>{cdata 1}</W:elem1>		{cdata 0}<W:elem1>{cdata 1}</W:elem1>
	<W:elem2>{cdata 2}</W:elem2>{cdata 3}		<W:elem2>{cdata 2}</W:elem2>{cdata 3}
	</W:aprop>		</W:aprop>
	In this case, matching is performed on each individual contiguous		In this case, matching is performed on each individual contiguous
	sequence of character information items. In the example above, a		sequence of character information items. In the example above, a
	search string would be compared to the four following strings:		search string would be compared to the four following strings:
	{cdata 0}		{cdata 0}
	{cdata 1}		{cdata 1}
	{cdata 2}		{cdata 2}
	{cdata 3}		{cdata 3}
	That is, four individual matches would be performed, one each for		That is, four individual matches would be performed, one each for
	{cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.		{cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
	9.4.2Example: successful DAV:principal-property-search REPORT		9.4.2Example: successful DAV:principal-property-search REPORT
	skipping to change at line 2474		skipping to change at line 2396
	{cdata 3}		{cdata 3}
	That is, four individual matches would be performed, one each for		That is, four individual matches would be performed, one each for
	{cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.		{cdata 0}, {cdata 1}, {cdata 2}, and {cdata 3}.
	9.4.2Example: successful DAV:principal-property-search REPORT		9.4.2Example: successful DAV:principal-property-search REPORT
	In this example, the client requests the principal URLs of all		In this example, the client requests the principal URLs of all
	users whose DAV:displayname property contains the substring "doE"		users whose DAV:displayname property contains the substring "doE"
	and whose "title" property in the namespace		and whose "title" property in the namespace
	Clemm, et al. [Page 46]
	"http://BigCorp.com/ns/" (that is, their professional title)		"http://BigCorp.com/ns/" (that is, their professional title)
	contains "Sales". In addition, the client requests five properties		contains "Sales". In addition, the client requests five
	to be returned with the matching principals:		properties to be returned with the matching principals:
	In the DAV: namespace: displayname		In the DAV: namespace: displayname
	In the http://www.example.com/ns/ namespace: department, phone,		In the http://www.example.com/ns/ namespace: department, phone,
	office, salary		office, salary
	The response shows that two principal resources meet the search		The response shows that two principal resources meet the search
	specification, "John Doe" and "Zygdoebert Smith". The property		specification, "John Doe" and "Zygdoebert Smith". The property
	"salary" in namespace "http://www.example.com/ns/" is not returned,		"salary" in namespace "http://www.example.com/ns/" is not
	since the principal making the request does not have sufficient		returned, since the principal making the request does not have
	access permissions to read this property.		sufficient access permissions to read this property.
	>> Request <<		>> Request <<
	REPORT /users/ HTTP/1.1		REPORT /users/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset=utf-8		Content-Type: text/xml; charset=utf-8
	Content-Length: xxxx		Content-Length: xxxx
	Depth: 0		Depth: 0
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:principal-property-search xmlns:D="DAV:">		<D:principal-property-search xmlns:D="DAV:">
	<D:property-search>		<D:property-search>
	<D:prop>		<D:prop>
	skipping to change at line 2504		skipping to change at line 2420
	Content-Type: text/xml; charset=utf-8		Content-Type: text/xml; charset=utf-8
	Content-Length: xxxx		Content-Length: xxxx
	Depth: 0		Depth: 0
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:principal-property-search xmlns:D="DAV:">		<D:principal-property-search xmlns:D="DAV:">
	<D:property-search>		<D:property-search>
	<D:prop>		<D:prop>
	<D:displayname/>		<D:displayname/>
	</D:prop>		</D:prop>
			Clemm, Hopkins, Sedlar, Whitehead [Page 46]
	<D:match>doE</D:match>		<D:match>doE</D:match>
	</D:property-search>		</D:property-search>
	<D:property-search>		<D:property-search>
	<D:prop xmlns:B="http://www.example.com/ns/">		<D:prop xmlns:B="http://www.example.com/ns/">
	<B:title/>		<B:title/>
	</D:prop>		</D:prop>
	<D:match>Sales</D:match>		<D:match>Sales</D:match>
	</D:property-search>		</D:property-search>
	<D:prop xmlns:B="http://www.example.com/ns/">		<D:prop xmlns:B="http://www.example.com/ns/">
	<D:displayname/>		<D:displayname/>
	skipping to change at line 2527		skipping to change at line 2445
	<B:salary/>		<B:salary/>
	</D:prop>		</D:prop>
	</D:principal-property-search>		</D:principal-property-search>
	>> Response <<		>> Response <<
	HTTP/1.1 207 Multi-Status		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml; charset=utf-8		Content-Type: text/xml; charset=utf-8
	Content-Length: xxxx		Content-Length: xxxx
	Clemm, et al. [Page 47]
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:multistatus xmlns:D="DAV:" xmlns:B="http://BigCorp.com/ns/">		<D:multistatus xmlns:D="DAV:" xmlns:B="http://BigCorp.com/ns/">
	<D:response>		<D:response>
	<D:href>http://www.example.com/users/jdoe</D:href>		<D:href>http://www.example.com/users/jdoe</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:displayname>John Doe</D:displayname>		<D:displayname>John Doe</D:displayname>
	<B:department>Widget Sales</B:department>		<B:department>Widget Sales</B:department>
	<B:phone>234-4567</B:phone>		<B:phone>234-4567</B:phone>
	<B:office>209</B:office>		<B:office>209</B:office>
	skipping to change at line 2557		skipping to change at line 2474
	</D:response>		</D:response>
	<D:response>		<D:response>
	<D:href>http://www.example.com/users/zsmith</D:href>		<D:href>http://www.example.com/users/zsmith</D:href>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<D:displayname>Zygdoebert Smith</D:displayname>		<D:displayname>Zygdoebert Smith</D:displayname>
	<B:department>Gadget Sales</B:department>		<B:department>Gadget Sales</B:department>
	<B:phone>234-7654</B:phone>		<B:phone>234-7654</B:phone>
	<B:office>114</B:office>		<B:office>114</B:office>
	</D:prop>		</D:prop>
			Clemm, Hopkins, Sedlar, Whitehead [Page 47]
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	</D:propstat>		</D:propstat>
	<D:propstat>		<D:propstat>
	<D:prop>		<D:prop>
	<B:salary/>		<B:salary/>
	</D:prop>		</D:prop>
	<D:status>HTTP/1.1 403 Forbidden</D:status>		<D:status>HTTP/1.1 403 Forbidden</D:status>
	</D:propstat>		</D:propstat>
	</D:response>		</D:response>
	</D:multistatus>		</D:multistatus>
	9.4.3Example: Unsuccessful DAV:principal-property-search REPORT
	In this example, the client requests a search on the non-searchable
	property "phone" in the namespace "http://www.example.com/ns/".
	The response is a 403 (Forbidden), with a response body containing
	a DAV:property-must-be-searchable XML element as the value of a
	DAV:error XML element.
	>> Request <<
	REPORT /users/ HTTP/1.1
	Clemm, et al. [Page 48]
	Host: www.example.com
	Content-Type: text/xml; charset=utf-8
	Content-Length: xxxx
	Depth: 0
	<?xml version="1.0" encoding="utf-8" ?>
	<D:principal-property-search xmlns:D="DAV:">
	<D:property-search>
	<D:prop xmlns:B="http://www.example.com/ns/">
	<B:phone/>
	</D:prop>
	<D:match>232</D:match>
	</D:property-search>
	</D:principal-property-search>
	>> Response <<
	HTTP/1.1 403 Forbidden
	Content-Type: text/xml; charset=utf-8
	Content-Length: xxxx
	<?xml version="1.0" encoding="utf-8" ?>
	<D:error xmlns:D="DAV:">
	<D:property-must-be-searchable>
	<D:prop xmlns:B="http://www.example.com/ns/">
	<B:phone/>
	</D:prop>
	</D:property-must-be-searchable>
	</D:error>
	9.5 DAV:principal-search-property-set REPORT		9.5 DAV:principal-search-property-set REPORT
	The DAV:principal-search-property-set REPORT identifies those		The DAV:principal-search-property-set REPORT identifies those
	properties that may be searched using the DAV:principal-property-		properties that may be searched using the DAV:principal-property-
	search REPORT (defined in Section 9.4).		search REPORT (defined in Section 9.4).
	Servers MUST support the DAV:principal-search-property-set REPORT		Servers MUST support the DAV:principal-search-property-set REPORT
	on all collections identified in the value of a DAV:principal-		on all collections identified in the value of a DAV:principal-
	collection-set property.		collection-set property.
	An access control protocol user agent could use the results of the		An access control protocol user agent could use the results of the
	DAV:principal-search-property-set REPORT to present a query		DAV:principal-search-property-set REPORT to present a query
	interface to the user for retrieving principals.		interface to the user for retrieving principals.
	Support for this report is REQUIRED.		Support for this report is REQUIRED.
	Implementation Note: Some clients will have only limited screen		Implementation Note: Some clients will have only limited screen
	real estate for the display of lists of searchable properties. In		real estate for the display of lists of searchable properties.
	this case, a user might appreciate having the most frequently		In this case, a user might appreciate having the most
	searched properties be displayed on-screen, rather than having to		frequently searched properties be displayed on-screen, rather
	scroll through a long list of searchable properties. One mechanism		than having to scroll through a long list of searchable
			properties. One mechanism for signaling the most frequently
	Clemm, et al. [Page 49]		searched properties is to return them towards the start of a
	for signaling the most frequently searched properties is to return		list of properties. A client can then preferentially display
	them towards the start of a list of properties. A client can then		the list of properties in order, increasing the likelihood that
	preferentially display the list of properties in order, increasing		the most frequently searched properties will appear on-screen,
	the likelihood that the most frequently searched properties will		and will not require scrolling for their selection.
	appear on-screen, and will not require scrolling for their
	selection.
	Marshalling:		Marshalling:
			The request body MUST be an empty DAV:principal-search-property-
	The request body MUST be an empty DAV:principal-search-property-set		set XML element.
	XML element.
	This report is only defined when the Depth header has value "0";		This report is only defined when the Depth header has value "0";
	other values result in a 400 (Bad Request) error response. Note		other values result in a 400 (Bad Request) error response. Note
	that [RFC3253], Section 3.6, states that if the Depth header is not		that [RFC3253], Section 3.6, states that if the Depth header is
	present, it defaults to a value of "0".		not present, it defaults to a value of "0".
	The response body MUST be a DAV:principal-search-property-set XML		The response body MUST be a DAV:principal-search-property-set XML
	element, containing a DAV:principal-search-property XML element for		element, containing a DAV:principal-search-property XML element
	each property that may be searched with the DAV:principal-property-		for each property that may be searched with the DAV:principal-
	search REPORT. A server MAY limit its response to just a subset of		property-search REPORT. A server MAY limit its response to just a
	the searchable properties, such as those likely to be useful to an		subset of the searchable properties, such as those likely to be
	interactive access control client.		useful to an interactive access control client.
	<!ELEMENT principal-search-property-set (principal-search-property*) >
	Each DAV:principal-search-property XML element contains exactly one		Clemm, Hopkins, Sedlar, Whitehead [Page 48]
	searchable property, and a description of the property.		<!ELEMENT principal-search-property-set (principal-search-
			property*) >
			Each DAV:principal-search-property XML element contains exactly
			one searchable property, and a description of the property.
	<!ELEMENT principal-search-property (prop, description) >		<!ELEMENT principal-search-property (prop, description) >
	The DAV:prop element contains one principal property on which the		The DAV:prop element contains one principal property on which the
	server is able to perform a DAV:principal-property-search REPORT.		server is able to perform a DAV:principal-property-search REPORT.
	prop: see RFC 2518, Section 12.11		prop: see RFC 2518, Section 12.11
	The description element is a human-readable description of what		The description element is a human-readable description of what
	information this property represents. Servers MUST indicate the		information this property represents. Servers MUST indicate the
	human language of the description using the xml:lang attribute and		human language of the description using the xml:lang attribute and
	SHOULD consider the HTTP Accept-Language request header when		SHOULD consider the HTTP Accept-Language request header when
	selecting one of multiple available languages.		selecting one of multiple available languages.
	<!ELEMENT description #PCDATA >		<!ELEMENT description #PCDATA >
	9.5.1Example: DAV:principal-search-property-set REPORT		9.5.1Example: DAV:principal-search-property-set REPORT
	In this example, the client determines the set of searchable		In this example, the client determines the set of searchable
	principal properties by requesting the DAV:principal-search-		principal properties by requesting the DAV:principal-search-
	property-set REPORT on the root of the server's principal URL		property-set REPORT on the root of the server's principal URL
	collection set, identified by http://www.example.com/users/.		collection set, identified by http://www.example.com/users/.
	>> Request <<		>> Request <<
	Clemm, et al. [Page 50]
	REPORT /users/ HTTP/1.1		REPORT /users/ HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Content-Type: text/xml; charset="utf-8"		Content-Type: text/xml; charset="utf-8"
	Content-Length: xxx		Content-Length: xxx
	Accept-Language: en, de		Accept-Language: en, de
	Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ=		Authorization: BASIC d2FubmFtYWs6cGFzc3dvcmQ=
	Depth: 0		Depth: 0
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:principal-search-property-set xmlns:D="DAV:"/>		<D:principal-search-property-set xmlns:D="DAV:"/>
	skipping to change at line 2714		skipping to change at line 2575
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:principal-search-property-set xmlns:D="DAV:">		<D:principal-search-property-set xmlns:D="DAV:">
	<D:principal-search-property>		<D:principal-search-property>
	<D:prop>		<D:prop>
	<D:displayname/>		<D:displayname/>
	</D:prop>		</D:prop>
	<D:description xml:lang="en">Full name</D:description>		<D:description xml:lang="en">Full name</D:description>
	</D:principal-search-property>		</D:principal-search-property>
	<D:principal-search-property>		<D:principal-search-property>
			Clemm, Hopkins, Sedlar, Whitehead [Page 49]
	<D:prop xmlns:B="http://BigCorp.com/ns/">		<D:prop xmlns:B="http://BigCorp.com/ns/">
	<B:title/>		<B:title/>
	</D:prop>		</D:prop>
	<D:description xml:lang="en">Job title</D:description>		<D:description xml:lang="en">Job title</D:description>
	</D:principal-search-property>		</D:principal-search-property>
	</D:principal-search-property-set>		</D:principal-search-property-set>
	10 XML PROCESSING		10 XML PROCESSING
	Implementations of this specification MUST support the XML element		Implementations of this specification MUST support the XML element
	ignore rule, as specified in Section 23.3.2 of [RFC2518], and the		ignore rule, as specified in Section 23.3.2 of [RFC2518], and the
	XML Namespace recommendation [REC-XML-NAMES].		XML Namespace recommendation [REC-XML-NAMES].
			Note that use of the DAV namespace is reserved for XML elements
	Note that use of the DAV namespace is reserved for XML elements and		and property names defined in a standards-track or Experimental
	property names defined in a standards-track or Experimental IETF		IETF RFC.
	RFC.
	11 INTERNATIONALIZATION CONSIDERATIONS		11 INTERNATIONALIZATION CONSIDERATIONS
	In this specification, the only human-readable content can be found		In this specification, the only human-readable content can be
	in the description XML element, found within the DAV:supported-		found in the description XML element, found within the
	privilege-set property. This element contains a human-readable		DAV:supported-privilege-set property. This element contains a
	description of the capabilities controlled by a privilege. As a		human-readable description of the capabilities controlled by a
	result, the description element must be capable of representing		privilege. As a result, the description element must be capable
			of representing descriptions in multiple character sets. Since
	Clemm, et al. [Page 51]		the description element is found within a WebDAV property, it is
	descriptions in multiple character sets. Since the description		represented on the wire as XML [REC-XML], and hence can leverage
	element is found within a WebDAV property, it is represented on the		XML's language tagging and character set encoding capabilities.
	wire as XML [REC-XML], and hence can leverage XML's language		Specifically, XML processors at minimum must be able to read XML
	tagging and character set encoding capabilities. Specifically, XML		elements encoded using the UTF-8 [UTF-8] encoding of the ISO 10646
	processors at minimum must be able to read XML elements encoded		multilingual plane. XML examples in this specification demonstrate
	using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual		use of the charset parameter of the Content-Type header, as
	plane. XML examples in this specification demonstrate use of the		defined in [RFC3023], as well as the XML "encoding" attribute,
	charset parameter of the Content-Type header, as defined in		which together provide charset identification information for MIME
	[RFC3023], as well as the XML "encoding" attribute, which together		and XML processors. Futhermore, this specification requires server
	provide charset identification information for MIME and XML
	processors. Futhermore, this specification requires server
	implementations to tag description fields with the xml:lang		implementations to tag description fields with the xml:lang
	attribute (see Section 2.12 of [REC-XML]), which specifies the		attribute (see Section 2.12 of [REC-XML]), which specifies the
	human language of the description. Additionally, server		human language of the description. Additionally, server
	implementations should take into account the value of the Accept-		implementations should take into account the value of the Accept-
	Language HTTP header to determine which description string to		Language HTTP header to determine which description string to
	return.		return.
			For XML elements other than the description element, it is
	For XML elements other than the description element, it is expected		expected that implementations will treat the property names,
	that implementations will treat the property names, privilege		privilege names, and values as tokens, and convert these tokens
	names, and values as tokens, and convert these tokens into human-		into human-readable text in the user's language and character set
	readable text in the user's language and character set when		when displayed to a person. Only a generic WebDAV property
	displayed to a person. Only a generic WebDAV property display		display utility would display these values in their raw form to a
	utility would display these values in their raw form to a human		human user.
	user.
	For error reporting, we follow the convention of HTTP/1.1 status		For error reporting, we follow the convention of HTTP/1.1 status
	codes, including with each status code a short, English description		codes, including with each status code a short, English
	of the code (e.g., 200 (OK)). While the possibility exists that a		description of the code (e.g., 200 (OK)). While the possibility
	poorly crafted user agent would display this message to a user,
	internationalized applications will ignore this message, and
	display an appropriate message in the user's language and character
	set.
			Clemm, Hopkins, Sedlar, Whitehead [Page 50]
			exists that a poorly crafted user agent would display this message
			to a user, internationalized applications will ignore this
			message, and display an appropriate message in the user's language
			and character set.
	Further internationalization considerations for this protocol are		Further internationalization considerations for this protocol are
	described in the WebDAV Distributed Authoring protocol		described in the WebDAV Distributed Authoring protocol
	specification [RFC2518].		specification [RFC2518].
	12 SECURITY CONSIDERATIONS		12 SECURITY CONSIDERATIONS
	Applications and users of this access control protocol should be		Applications and users of this access control protocol should be
	aware of several security considerations, detailed below. In		aware of several security considerations, detailed below. In
	addition to the discussion in this document, the security		addition to the discussion in this document, the security
	considerations detailed in the HTTP/1.1 specification [RFC2616],		considerations detailed in the HTTP/1.1 specification [RFC2616],
	the WebDAV Distributed Authoring Protocol specification [RFC2518],		the WebDAV Distributed Authoring Protocol specification [RFC2518],
	and the XML Media Types specification [RFC3023] should be		and the XML Media Types specification [RFC3023] should be
	considered in a security analysis of this protocol.		considered in a security analysis of this protocol.
	12.1Increased Risk of Compromised Users		12.1Increased Risk of Compromised Users
	In the absence of a mechanism for remotely manipulating access		In the absence of a mechanism for remotely manipulating access
	control lists, if a single user's authentication credentials are		control lists, if a single user's authentication credentials are
	Clemm, et al. [Page 52]
	compromised, only those resources for which the user has access		compromised, only those resources for which the user has access
	permission can be read, modified, moved, or deleted. With the		permission can be read, modified, moved, or deleted. With the
	introduction of this access control protocol, if a single		introduction of this access control protocol, if a single
	compromised user has the ability to change ACLs for a broad range		compromised user has the ability to change ACLs for a broad range
	of other users (e.g., a super-user), the number of resources that		of other users (e.g., a super-user), the number of resources that
	could be altered by a single compromised user increases. This risk		could be altered by a single compromised user increases. This risk
	can be mitigated by limiting the number of people who have write-		can be mitigated by limiting the number of people who have write-
	acl privileges across a broad range of resources.		acl privileges across a broad range of resources.
	12.2Risks of the DAV:read-acl and DAV:current-user-privilege-set Privileges		12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
			Privileges
	The ability to read the access privileges (stored in the DAV:acl		The ability to read the access privileges (stored in the DAV:acl
	property), or the privileges permitted the currently authenticated		property), or the privileges permitted the currently authenticated
	user (stored in the DAV:current-user-privilege-set property) on a		user (stored in the DAV:current-user-privilege-set property) on a
	resource may seem innocuous, since reading an ACL cannot possibly		resource may seem innocuous, since reading an ACL cannot possibly
	affect the resource's state. However, if all resources have world-		affect the resource's state. However, if all resources have world-
	readable ACLs, it is possible to perform an exhaustive search for		readable ACLs, it is possible to perform an exhaustive search for
	those resources that have inadvertently left themselves in a		those resources that have inadvertently left themselves in a
	vulnerable state, such as being world-writeable. In particular, the		vulnerable state, such as being world-writeable. In particular,
	property retrieval method PROPFIND, executed with Depth infinity on		the property retrieval method PROPFIND, executed with Depth
	an entire hierarchy, is a very efficient way to retrieve the		infinity on an entire hierarchy, is a very efficient way to
	DAV:acl or DAV:current-user-privilege-set properties. Once found,		retrieve the DAV:acl or DAV:current-user-privilege-set properties.
	this vulnerability can be exploited by a denial of service attack		Once found, this vulnerability can be exploited by a denial of
	in which the open resource is repeatedly overwritten. Alternately,		service attack in which the open resource is repeatedly
	writeable resources can be modified in undesirable ways.		overwritten. Alternately, writeable resources can be modified in
			undesirable ways.
	To reduce this risk, read-acl privileges should not be granted to		To reduce this risk, read-acl privileges should not be granted to
	unauthenticated principals, and restrictions on read-acl and read-		unauthenticated principals, and restrictions on read-acl and read-
	current-user-privilege-set privileges for authenticated principals		current-user-privilege-set privileges for authenticated principals
	should be carefully analyzed when deploying this protocol. Access		should be carefully analyzed when deploying this protocol. Access
			Clemm, Hopkins, Sedlar, Whitehead [Page 51]
	to the current-user-privilege-set property will involve a tradeoff		to the current-user-privilege-set property will involve a tradeoff
	of usability versus security. When the current-user-privilege-set		of usability versus security. When the current-user-privilege-set
	is visible, user interfaces are expected to provide enhanced		is visible, user interfaces are expected to provide enhanced
	information concerning permitted and restricted operations, yet		information concerning permitted and restricted operations, yet
	this information may also indicate a vulnerability that could be		this information may also indicate a vulnerability that could be
	exploited. Deployment of this protocol will need to evaluate this		exploited. Deployment of this protocol will need to evaluate this
	tradeoff in light of the requirements of the deployment		tradeoff in light of the requirements of the deployment
	environment.		environment.
	12.3No Foreknowledge of Initial ACL		12.3No Foreknowledge of Initial ACL
	In an effort to reduce protocol complexity, this protocol		In an effort to reduce protocol complexity, this protocol
	specification intentionally does not address the issue of how to		specification intentionally does not address the issue of how to
	manage or discover the initial ACL that is placed upon a resource		manage or discover the initial ACL that is placed upon a resource
	when it is created. The only way to discover the initial ACL is to		when it is created. The only way to discover the initial ACL is to
	create a new resource, then retrieve the value of the DAV:acl		create a new resource, then retrieve the value of the DAV:acl
	property. This assumes the principal creating the resource also has		property. This assumes the principal creating the resource also
	been granted the DAV:read-acl privilege.		has been granted the DAV:read-acl privilege.
	As a result, it is possible that a principal could create a		As a result, it is possible that a principal could create a
	resource, and then discover that its ACL grants privileges that are		resource, and then discover that its ACL grants privileges that
	undesirable. Furthermore, this protocol makes it possible (though		are undesirable. Furthermore, this protocol makes it possible
			(though unlikely) that the creating principal could be unable to
	Clemm, et al. [Page 53]		modify the ACL, or even delete the resource. Even when the ACL can
	unlikely) that the creating principal could be unable to modify the		be modified, there will be a short period of time when the
	ACL, or even delete the resource. Even when the ACL can be		resource exists with the initial ACL before its new ACL can be
	modified, there will be a short period of time when the resource		set.
	exists with the initial ACL before its new ACL can be set.
	Several factors mitigate this risk. Human principals are often		Several factors mitigate this risk. Human principals are often
	aware of the default access permissions in their editing		aware of the default access permissions in their editing
	environments and take this into account when writing information.		environments and take this into account when writing information.
	Furthermore, default privilege policies are usually very		Furthermore, default privilege policies are usually very
	conservative, limiting the privileges granted by the initial ACL.		conservative, limiting the privileges granted by the initial ACL.
	13 AUTHENTICATION		13 AUTHENTICATION
	Authentication mechanisms defined for use with HTTP and WebDAV also		Authentication mechanisms defined for use with HTTP and WebDAV
	apply to this WebDAV Access Control Protocol, in particular the		also apply to this WebDAV Access Control Protocol, in particular
	Basic and Digest authentication mechanisms defined in [RFC2617].		the Basic and Digest authentication mechanisms defined in
	Implementation of the ACL spec requires that Basic authentication,		[RFC2617]. Implementation of the ACL spec requires that Basic
	if used, MUST only be supported over secure transport such as TLS.		authentication, if used, MUST only be supported over secure
			transport such as TLS.
	14 IANA CONSIDERATIONS		14 IANA CONSIDERATIONS
	This document uses the namespace defined by [RFC2518] for XML		This document uses the namespace defined by [RFC2518] for XML
	elements. That is, this specification uses the "DAV:" URI		elements. That is, this specification uses the "DAV:" URI
	namespace, previously registered in the URI schemes registry. All		namespace, previously registered in the URI schemes registry. All
	other IANA considerations mentioned in [RFC2518] are also		other IANA considerations mentioned in [RFC2518] are also
	applicable to this specification.		applicable to this specification.
			Clemm, Hopkins, Sedlar, Whitehead [Page 52]
	15 INTELLECTUAL PROPERTY		15 INTELLECTUAL PROPERTY
	The following notice is copied from RFC 2026, section 10.4, and		The following notice is copied from RFC 2026, section 10.4, and
	describes the position of the IETF concerning intellectual property		describes the position of the IETF concerning intellectual
	claims made against this document.		property claims made against this document.
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use other technology described in		pertain to the implementation or use other technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on		has made any effort to identify any such rights. Information on
	the IETF's procedures with respect to rights in standards-track and		the IETF's procedures with respect to rights in standards-track
	standards-related documentation can be found in BCP-11. Copies of		and standards-related documentation can be found in BCP-11. Copies
	claims of rights made available for publication and any assurances		of claims of rights made available for publication and any
	of licenses to be made available, or the result of an attempt made		assurances of licenses to be made available, or the result of an
	to obtain a general license or permission for the use of such		attempt made to obtain a general license or permission for the use
	proprietary rights by implementers or users of this specification		of such proprietary rights by implementers or users of this
	can be obtained from the IETF Secretariat.		specification can be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention
	The IETF invites any interested party to bring to its attention any		any copyrights, patents or patent applications, or other
	copyrights, patents or patent applications, or other proprietary		proprietary rights that may cover technology that may be required
	rights that may cover technology that may be required to practice		to practice this standard. Please address the information to the
			IETF Executive Director.
	Clemm, et al. [Page 54]
	this standard. Please address the information to the IETF
	Executive Director.
	16 ACKNOWLEDGEMENTS		16 ACKNOWLEDGEMENTS
	This protocol is the collaborative product of the WebDAV ACL design		This protocol is the collaborative product of the WebDAV ACL
	team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry Lind, Sean		design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry
	Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead. The authors		Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim Whitehead.
	are grateful for the detailed review and comments provided by Jim		The authors are grateful for the detailed review and comments
	Amsden, Dylan Barrell, Gino Basso, Murthy Chintalapati, Lisa		provided by Jim Amsden, Dylan Barrell, Gino Basso, Murthy
	Dusseault, Stefan Eissing, Tim Ellison, Yaron Goland, Dennis		Chintalapati, Lisa Dusseault, Stefan Eissing, Tim Ellison, Yaron
	Hamilton, Laurie Harper, Eckehard Hermann, Ron Jacobs, Chris		Goland, Dennis Hamilton, Laurie Harper, Eckehard Hermann, Ron
	Knight, Remy Maucherat, Larry Masinter, Joe Orton, Peter Raymond,		Jacobs, Chris Knight, Remy Maucherat, Larry Masinter, Joe Orton,
	Julian Reschke, and Keith Wannamaker. We thank Keith Wannamaker for		Peter Raymond, Julian Reschke, and Keith Wannamaker. We thank
	the initial text of the principal property search sections. Prior		Keith Wannamaker for the initial text of the principal property
	work on WebDAV access control protocols has been performed by Yaron		search sections. Prior work on WebDAV access control protocols has
	Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff.		been performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard
	We would like to acknowledge the foundation laid for us by the		Palmer, and Jon Radoff. We would like to acknowledge the
	authors of the DeltaV, WebDAV and HTTP protocols upon which this		foundation laid for us by the authors of the DeltaV, WebDAV and
	protocol is layered, and the invaluable feedback from the WebDAV		HTTP protocols upon which this protocol is layered, and the
	working group.		invaluable feedback from the WebDAV working group.
	17 REFERENCES		17 REFERENCES
	17.1Normative References		17.1Normative References
	[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels." RFC 2119, BCP 14, March, 1997.		Requirement Levels." RFC 2119, BCP 14, March, 1997.
	[REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible		[REC-XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible
	Markup Language (XML)." World Wide Web Consortium Recommendation		Markup Language (XML)." World Wide Web Consortium Recommendation
	REC-xml.http://www.w3.org/TR/REC-xml		REC-xml.http://www.w3.org/TR/REC-xml
			Clemm, Hopkins, Sedlar, Whitehead [Page 53]
	[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in		[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in
	XML" World Wide Web Consortium Recommendation REC-xml-names.		XML" World Wide Web Consortium Recommendation REC-xml-names.
	http://www.w3.org/TR/REC-xml-names/		http://www.w3.org/TR/REC-xml-names/
	[RFC3253] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead,		[RFC3253] G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead,
	"Versioning Extensions to WebDAV." RFC 3253, March 2002.		"Versioning Extensions to WebDAV." RFC 3253, March 2002.
	[REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World		[REC-XML-INFOSET] J. Cowan, R. Tobin, "XML Information Set." World
	Wide Web Consortium Recommendation REC-xml-infoset.		Wide Web Consortium Recommendation REC-xml-infoset.
	http://www.w3.org/TR/xml-infoset/		http://www.w3.org/TR/xml-infoset/
	[RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.		[RFC2616] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L.
	Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer		Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer
	Protocol -- HTTP/1.1." RFC 2616, June, 1999.		Protocol -- HTTP/1.1." RFC 2616, June, 1999.
			[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence,
	[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.		P. Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
	Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
	Digest Access Authentication." RFC 2617, June, 1999.		Digest Access Authentication." RFC 2617, June, 1999.
	Clemm, et al. [Page 55]
	[RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.		[RFC2518] Y. Goland, E. Whitehead, A. Faizi, S. R. Carter, D.
	Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC		Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV." RFC
	2518, February, 1999.		2518, February, 1999.
	[RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL		[RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL
	scheme." RFC 2368, July, 1998.		scheme." RFC 2368, July, 1998.
			[RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types."
	[RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC		RFC 3023, January, 2001.
	3023, January, 2001.
	[RFC3010] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.		[RFC3010] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.
	Beame, M. Eisler, D.Noveck "NFS version 4 Protocol." RFC 3010,		Beame, M. Eisler, D.Noveck "NFS version 4 Protocol." RFC 3010,
	December 2000.		December 2000.
			[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
	[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and		and ISO 10646." RFC 2279, January, 1998.
	ISO 10646." RFC 2279, January, 1998.
	17.2Informational References		17.2Informational References
	[RFC2026] S.Bradner, "The Internet Standards Process - Revision 3."		[RFC2026] S.Bradner, "The Internet Standards Process - Revision
	RFC 2026, BCP 9. Harvard, October, 1996.		3." RFC 2026, BCP 9. Harvard, October, 1996.
	[RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.		[RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.
	Netscape, December, 1997.		Netscape, December, 1997.
	[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory		[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
	Access Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode,		Access Protocol (v3)." RFC 2251. Critical Angle, Netscape, Isode,
	December, 1997.		December, 1997.
	[CaseMap] M. Davis, "Case Mappings", Unicode Standard Annex #21,		[CaseMap] M. Davis, "Case Mappings", Unicode Standard Annex #21,
	March 26, 2001. http://www.unicode.org/unicode/reports/tr21		March 26, 2001. http://www.unicode.org/unicode/reports/tr21
	Clemm, et al. [Page 56]		Clemm, Hopkins, Sedlar, Whitehead [Page 54]
	18 AUTHORS' ADDRESSES		18 AUTHORS' ADDRESSES
	Geoffrey Clemm		Geoffrey Clemm
	IBM		IBM
	20 Maguire Road		20 Maguire Road
	Lexington, MA 02421		Lexington, MA 02421
	Email: geoffrey.clemm@us.ibm.com		Email: geoffrey.clemm@us.ibm.com
	Anne Hopkins		Anne Hopkins
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: annehop@microsoft.com		Email: annehop@microsoft.com
	Eric Sedlar		Eric Sedlar
	Oracle Corporation		Oracle Corporation
	500 Oracle Parkway		500 Oracle Parkway
	Redwood Shores, CA 94065		Redwood Shores, CA 94065
	Email: eric.sedlar@oracle.com		Email: eric.sedlar@oracle.com
	Jim Whitehead		Jim Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	Dept. of Computer Science		Dept. of Computer Science
	Baskin Engineering		Baskin Engineering
	1156 High Street		1156 High Street
	Santa Cruz, CA 95064		Santa Cruz, CA 95064
	Email: ejw@cse.ucsc.edu		Email: ejw@cse.ucsc.edu
	skipping to change at line 3026		skipping to change at line 2856
	Email: eric.sedlar@oracle.com		Email: eric.sedlar@oracle.com
	Jim Whitehead		Jim Whitehead
	U.C. Santa Cruz		U.C. Santa Cruz
	Dept. of Computer Science		Dept. of Computer Science
	Baskin Engineering		Baskin Engineering
	1156 High Street		1156 High Street
	Santa Cruz, CA 95064		Santa Cruz, CA 95064
	Email: ejw@cse.ucsc.edu		Email: ejw@cse.ucsc.edu
	Clemm, et al. [Page 57]		Clemm, Hopkins, Sedlar, Whitehead [Page 55]
	19 APPENDICES		19 APPENDICES
	19.1WebDAV XML Document Type Definition Addendum		19.1WebDAV XML Document Type Definition Addendum
	All XML elements defined in this Document Type Definition (DTD)		All XML elements defined in this Document Type Definition (DTD)
	belong to the DAV namespace. This DTD should be viewed as an		belong to the DAV namespace. This DTD should be viewed as an
	addendum to the DTD provided in [RFC2518], section 23.1.		addendum to the DTD provided in [RFC2518], section 23.1.
	<!-- Privileges -->		<!-- Privileges -->
	<!ELEMENT read EMPTY>		<!ELEMENT read EMPTY>
	<!ELEMENT write EMPTY>		<!ELEMENT write EMPTY>
	<!ELEMENT write-properties EMPTY>		<!ELEMENT write-properties EMPTY>
	<!ELEMENT write-content EMPTY>		<!ELEMENT write-content EMPTY>
	<!ELEMENT unlock EMPTY>		<!ELEMENT unlock EMPTY>
	<!ELEMENT read-acl EMPTY>		<!ELEMENT read-acl EMPTY>
	<!ELEMENT read-current-user-privilege-set EMPTY>		<!ELEMENT read-current-user-privilege-set EMPTY>
	<!ELEMENT write-acl EMPTY>		<!ELEMENT write-acl EMPTY>
	skipping to change at line 3076		skipping to change at line 2905
	<!ELEMENT supported-privilege		<!ELEMENT supported-privilege
	(privilege, abstract?, description, supported-privilege*)>		(privilege, abstract?, description, supported-privilege*)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	<!ELEMENT abstract EMPTY>		<!ELEMENT abstract EMPTY>
	<!ELEMENT description #PCDATA>		<!ELEMENT description #PCDATA>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	<!-- DAV:current-user-privilege-set Property (Section 5.3) -->		<!-- DAV:current-user-privilege-set Property (Section 5.3) -->
	Clemm, et al. [Page 58]
	<!ELEMENT current-user-privilege-set (privilege*)>		<!ELEMENT current-user-privilege-set (privilege*)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 56]
	<!-- DAV:acl Property (Section 5.4) -->		<!-- DAV:acl Property (Section 5.4) -->
	<!ELEMENT acl (ace)* >		<!ELEMENT acl (ace)* >
	<!ELEMENT ace (invert | principal, (grant|deny), protected?, inherited?)>		<!ELEMENT ace (invert | principal, (grant|deny), protected?,
			inherited?)>
	<!ELEMENT invert principal>		<!ELEMENT invert principal>
	<!ELEMENT principal ((href, prop?)		<!ELEMENT principal ((href, prop?)
	| all | authenticated | unauthenticated		| all | authenticated | unauthenticated
	| property | self)>		| property | self)>
	<!ELEMENT prop (see [RFC2518], section 12.11)>		<!ELEMENT prop (see [RFC2518], section 12.11)>
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
	<!ELEMENT authenticated EMPTY>		<!ELEMENT authenticated EMPTY>
	<!ELEMENT unauthenticated EMPTY>		<!ELEMENT unauthenticated EMPTY>
	skipping to change at line 3114		skipping to change at line 2944
	<!-- DAV:inherited-acl-set Property (Section 5.6) -->		<!-- DAV:inherited-acl-set Property (Section 5.6) -->
	<!ELEMENT inherited-acl-set (href*)>		<!ELEMENT inherited-acl-set (href*)>
	<!-- DAV:principal-collection-set Property (Section 5.6) -->		<!-- DAV:principal-collection-set Property (Section 5.6) -->
	<!ELEMENT principal-collection-set (href*)>		<!ELEMENT principal-collection-set (href*)>
	<!-- DAV:acl-semantics Property (Section 6) -->		<!-- DAV:acl-semantics Property (Section 6) -->
	<!ELEMENT acl-semantics (ace-combination?, ace-ordering?, allowed-ace?,		<!ELEMENT acl-semantics (ace-combination?, ace-ordering?, allowed-
	required-principal?)>		ace?, required-principal?)>
	<!ELEMENT ace-combination		<!ELEMENT ace-combination
	(first-match | all-grant-before-any-deny | specific-deny-overrides-grant)>		(first-match | all-grant-before-any-deny | specific-deny-
			overrides-grant)>
	<!ELEMENT first-match EMPTY>		<!ELEMENT first-match EMPTY>
	<!ELEMENT all-grant-before-any-deny EMPTY>		<!ELEMENT all-grant-before-any-deny EMPTY>
	<!ELEMENT specific-deny-overrides-grant EMPTY>		<!ELEMENT specific-deny-overrides-grant EMPTY>
	<!ELEMENT ace-ordering (deny-before-grant)? >		<!ELEMENT ace-ordering (deny-before-grant)? >
	<!ELEMENT deny-before-grant EMPTY>		<!ELEMENT deny-before-grant EMPTY>
			Clemm, Hopkins, Sedlar, Whitehead [Page 57]
	<!ELEMENT allowed-ace (grant-only |		<!ELEMENT allowed-ace (grant-only |
	Clemm, et al. [Page 59]
	no-invert)*>		no-invert)*>
	<!ELEMENT grant-only EMPTY>		<!ELEMENT grant-only EMPTY>
	<!ELEMENT no-invert EMPTY>		<!ELEMENT no-invert EMPTY>
	<!ELEMENT required-principal		<!ELEMENT required-principal
	(all? | authenticated? | unauthenticated? | self? | href* |property*)>		(all? | authenticated? | unauthenticated? | self? | href*
			|property*)>
	<!-- ACL method preconditions (Section 8.1.1) -->		<!-- ACL method preconditions (Section 8.1.1) -->
	<!ELEMENT no-ace-conflict EMPTY>		<!ELEMENT no-ace-conflict EMPTY>
	<!ELEMENT no-protected-ace-conflict EMPTY>		<!ELEMENT no-protected-ace-conflict EMPTY>
	<!ELEMENT no-inherited-ace-conflict EMPTY>		<!ELEMENT no-inherited-ace-conflict EMPTY>
	<!ELEMENT limited-number-of-aces EMPTY>		<!ELEMENT limited-number-of-aces EMPTY>
	<!ELEMENT no-abstract EMPTY>		<!ELEMENT no-abstract EMPTY>
	<!ELEMENT not-supported-privilege EMPTY>		<!ELEMENT not-supported-privilege EMPTY>
	<!ELEMENT missing-required-principal EMPTY>		<!ELEMENT missing-required-principal EMPTY>
	<!ELEMENT recognized-principal EMPTY>		<!ELEMENT recognized-principal EMPTY>
	<!ELEMENT allowed-principal EMPTY>		<!ELEMENT allowed-principal EMPTY>
	<!-- REPORTs (Section 9) -->		<!-- REPORTs (Section 9) -->
	<!ELEMENT acl-principal-prop-set ANY>		<!ELEMENT acl-principal-prop-set ANY>
	ANY value: a sequence of one or more elements, with at most one DAV:prop		ANY value: a sequence of one or more elements, with at most one
	element.		DAV:prop element.
	<!ELEMENT principal-match ((principal-property | self), prop?)>		<!ELEMENT principal-match ((principal-property | self), prop?)>
	<!ELEMENT principal-property ANY>		<!ELEMENT principal-property ANY>
	ANY value: an element whose value identifies a property. The expectation is		ANY value: an element whose value identifies a property. The
	the value of the named property typically contains an href element that		expectation is the value of the named property typically contains
	contains the URI of a principal		an href element that contains the URI of a principal
	<!ELEMENT self EMPTY>		<!ELEMENT self EMPTY>
	<!ELEMENT principal-property-search ((property-search+), prop?) >		<!ELEMENT principal-property-search ((property-search+), prop?) >
	<!ELEMENT property-search (prop, match) >		<!ELEMENT property-search (prop, match) >
	<!ELEMENT match #PCDATA >		<!ELEMENT match #PCDATA >
	<!ELEMENT principal-search-property-set (principal-search-property*) >		<!ELEMENT principal-search-property-set (principal-search-
			property*) >
	<!ELEMENT principal-search-property (prop, description) >		<!ELEMENT principal-search-property (prop, description) >
	19.2WebDAV Method Privilege Table (Normative)		19.2WebDAV Method Privilege Table (Normative)
	The following table of WebDAV methods (as defined in RFC 2518, 2616, and		The following table of WebDAV methods (as defined in RFC 2518, 2616,
	3253) clarifies which privileges are required for access for each		and 3253) clarifies which privileges are required for access for each
	method. Note that the privileges listed, if denied, MUST cause access		method. Note that the privileges listed, if denied, MUST cause access
	to be denied. However, given that a specific implementation MAY define		to be denied. However, given that a specific implementation MAY define
	an additional custom privilege to control access to existing methods,		an additional custom privilege to control access to existing methods,
	having all of the indicated privileges does not mean that access will be		having all of the indicated privileges does not mean that access will
	granted. Note that lack of the indicated privileges does not imply that
	access will be denied, since a particular implementation may use a sub-
	privilege aggregated under the indicated privilege to control access.
	Clemm, et al. [Page 60]		Clemm, Hopkins, Sedlar, Whitehead [Page 58]
	Privileges required refer to the current resource being processed unless		be granted. Note that lack of the indicated privileges does not imply
	otherwise specified.		that access will be denied, since a particular implementation may use a
			sub-privilege aggregated under the indicated privilege to control
			access. Privileges required refer to the current resource being
			processed unless otherwise specified.
	METHOD PRIVILEGES		METHOD PRIVILEGES
	GET <D:read>		GET <D:read>
	HEAD <D:read>		HEAD <D:read>
	OPTIONS <D:read>		OPTIONS <D:read>
	PUT <D:write-content> (on parent coll if resource		PUT (target exists) <D:write-content> on target resource
	doesn't already exist, or on existing resource		PUT (no target exists) <D:bind> on parent collection of target
	otherwise)
	PROPPATCH <D:write-properties>		PROPPATCH <D:write-properties>
	ACL <D:write-acl>		ACL <D:write-acl>
	PROPFIND <D:read> (plus <read-acl> and		PROPFIND <D:read> (plus <D:read-acl> and
	<read-current-user-privilege-set> as needed)		<D:read-current-user-privilege-set> as needed)
	COPY <D:read>, <D:write-content> on target collection		COPY (target exists) <D:read>, <D:write-content> and <D:write-
	MOVE (no target exists) <D:write-content> on source&target coll, plus		properties> on target resource
	<dav:read>		COPY (no target exists) <D:read>, <D:bind> on target collection
	on the resource being moved MAY be required		MOVE (no target exists) <D:unbind> on source collection and <D:bind>
	MOVE (target exists) As above, plus <D:delete> on the resource to be		on target collection
	overwritten		MOVE (target exists) As above, plus <D:unbind> on the target
	DELETE <D:delete>, <D:write-content> on parent collection		collection
	LOCK <D:write-content>		DELETE <D:unbind> on parent collection
	MKCOL <D:write-content> (on parent coll)		LOCK (target exists) <D:write-content>
			LOCK (no target exists) <D:bind> on parent collection
			MKCOL <D:bind> on parent collection
	UNLOCK <D:unlock>		UNLOCK <D:unlock>
	CHECKOUT <D:write>		CHECKOUT <D:write-properties >
	CHECKIN <D:write>		CHECKIN <D:write-properties >
	REPORT <D:read> (on all referenced resources)		REPORT <D:read> (on all referenced resources)
	VERSION-CONTROL <D:write>		VERSION-CONTROL <D:write-properties>
	MERGE <D:write-content>		MERGE <D:write-content>
	MKWORKSPACE <D:write-content> on parent collection		MKWORKSPACE <D:write-content> on parent collection
	BASELINE-CONTROL <D:write>		BASELINE-CONTROL <D:write-properties> and <D:write-content>
	MKACTIVITY <D:write-content> on parent collection		MKACTIVITY <D:write-content> on parent collection
			Clemm, Hopkins, Sedlar, Whitehead [Page 59]
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/