draft-ietf-webdav-acl-05.txt		draft-ietf-webdav-acl-06.txt
	INTERNET-DRAFT Geoffrey Clemm, Rational Software		INTERNET-DRAFT Geoffrey Clemm, Rational Software
	draft-ietf-webdav-acl-05 Anne Hopkins, Microsoft Corporation		draft-ietf-webdav-acl-06 Anne Hopkins, Microsoft Corporation
	Eric Sedlar, Oracle Corporation		Eric Sedlar, Oracle Corporation
	Jim Whitehead, U.C. Santa Cruz		Jim Whitehead, U.C. Santa Cruz
	Expires July 21, 2001 April 23, 2001		Expires December 21, 2001 June 21, 2001
	WebDAV Access Control Protocol		WebDAV Access Control Protocol
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with
	provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering
	Force (IETF), its areas, and its working groups. Note that other groups		Task Force (IETF), its areas, and its working groups. Note that
	may also distribute working documents as Internet-Drafts.		other groups 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
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other documents
	time. It is inappropriate to use Internet- Drafts as reference material		at any time. It is inappropriate to use Internet- Drafts as
	or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document specifies a set of methods, headers, and message bodies		This document specifies a set of methods, headers, and message
	that define the WebDAV Access Control extensions to the HTTP/1.1		bodies that define Access Control extensions to the WebDAV
	protocol. This protocol permits a client to remotely read and modify		Distributed Authoring Protocol. This protocol permits a client to
	access control lists that instruct a server whether to grant or deny		remotely read and modify access control lists that instruct a server
	operations upon a resource (such as HTTP method invocations) by a given		whether to grant or deny operations upon a resource (such as HTTP
	principal.		method invocations) by a given principal.
	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
	the acl@webdav.org mailing list. Other related documents can be found at		to the acl@webdav.org mailing list. Other related documents can be
	http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/.		found at http://www.webdav.org/acl/, and
			http://www.ics.uci.edu/pub/ietf/webdav/.
	Clemm, Hopkins, Sedlar, Whitehead [Page 1]		Clemm, Hopkins, Sedlar, Whitehead [Page 1]
	Table of Contents		Table of Contents
	1 INTRODUCTION......................................................4		1 INTRODUCTION...................................................4
	1.1 Terms...........................................................5		1.1 Terms.......................................................5
	1.2 Notational Conventions..........................................6		1.2 Notational Conventions......................................6
	2 PRINCIPALS........................................................6		2 PRINCIPALS.....................................................6
	3 PRIVILEGES........................................................6		3 PRIVILEGES.....................................................7
	3.1 DAV:read Privilege..............................................7		3.1 DAV:read Privilege..........................................8
	3.2 DAV:write Privilege.............................................7		3.2 DAV:write Privilege.........................................8
	3.3 DAV:read-acl Privilege..........................................8		3.3 DAV:read-acl Privilege......................................9
	3.4 DAV:read-cuprivset Privilege....................................8		3.4 DAV:read-current-user-privilege-set Privilege...............9
	3.5 DAV:write-acl Privilege.........................................8		3.5 DAV:write-acl Privilege.....................................9
	3.6 DAV:all Privilege...............................................8		3.6 DAV:all Privilege...........................................9
			3.7 Aggregation of Predefined Privileges........................9
	4 PRINCIPAL PROPERTIES..............................................8		4 PRINCIPAL PROPERTIES..........................................10
	4.1 DAV:is-principal................................................9		4.1 DAV:alternate-URL..........................................10
	4.2 DAV:alternate-URL...............................................9
	5 ACCESS CONTROL PROPERTIES.........................................9		5 ACCESS CONTROL PROPERTIES.....................................10
	5.1 DAV:owner.......................................................9		5.1 DAV:owner..................................................11
	5.2 DAV:supported-privilege-set....................................10		5.1.1 Example: Retrieving DAV:owner............................11
	5.3 DAV:current-user-privilege-set.................................11		5.1.2 Example: An Attempt to Set DAV:owner.....................12
	5.4 DAV:acl........................................................11		5.2 DAV:supported-privilege-set................................13
	5.4.1 ACE Principal...............................................11		5.2.1 Example: Retrieving a List of Privileges Supported on a
	5.4.2 ACE Grant and Deny..........................................13		Resource.................................................14
	5.4.3 ACE Protection..............................................13		5.3 DAV:current-user-privilege-set.............................15
	5.4.4 ACE Inheritance.............................................13		5.3.1 Example: Retrieving the User's Current Set of Assigned
	5.5 DAV:acl-semantics..............................................13		Privileges...............................................16
	5.6 DAV:principal-collection-set...................................14		5.4 DAV:acl....................................................17
	5.7 Example: PROPFIND to retrieve access control properties........14		5.4.1 ACE Principal............................................17
			5.4.2 ACE Grant and Deny.......................................18
			5.4.3 ACE Protection...........................................18
			5.4.4 ACE Inheritance..........................................18
			5.4.5 Example: Retrieving a Resource's Access Control List.....19
			5.5 DAV:acl-semantics..........................................20
			5.5.1 Example: Retrieving DAV:acl-semantics....................21
			5.6 DAV:principal-collection-set...............................22
			5.6.1 Example: Retrieving DAV:principal-collection-set.........22
			5.7 Example: PROPFIND to retrieve access control properties....23
	6 ACL SEMANTICS....................................................17		6 ACL SEMANTICS.................................................27
	6.1 ACE Combination................................................17		6.1 ACE Combination............................................27
	6.1.1 DAV:first-match ACE Combination.............................18		6.1.1 DAV:first-match ACE Combination..........................27
	6.1.2 DAV:all-grant-before-any-deny ACE Combination...............18		6.1.2 DAV:all-grant-before-any-deny ACE Combination............27
	6.1.3 DAV:specific-deny-overrides-grant ACE Combination...........18		6.1.3 DAV:specific-deny-overrides-grant ACE Combination........27
	6.2 ACE Ordering...................................................18		6.2 ACE Ordering...............................................28
	6.2.1 DAV:deny-before-grant ACE Ordering..........................18		6.2.1 DAV:deny-before-grant ACE Ordering.......................28
	6.3 Required Principals............................................18		6.3 Allowed ACE................................................28
			6.3.1 DAV:principal-only-one-ace ACE Constraint................28
			6.3.2 DAV:grant-only ACE Constraint............................28
			6.4 Required Principals........................................28
	7 ACCESS CONTROL AND EXISTING METHODS..............................19		Clemm, Hopkins, Sedlar, Whitehead [Page 2]
	7.1 OPTIONS........................................................19		7 ACCESS CONTROL AND EXISTING METHODS...........................29
	7.1.1 Example - OPTIONS...........................................19		7.1 OPTIONS....................................................29
			7.1.1 Example - OPTIONS........................................29
			7.2 MOVE.......................................................29
			7.3 COPY.......................................................29
	8 ACCESS CONTROL METHODS...........................................19		8 ACCESS CONTROL METHODS........................................29
	8.1 ACL............................................................19		8.1 ACL........................................................29
	8.1.1 ACL Preconditions...........................................20		8.1.1 ACL Preconditions........................................30
	8.1.2 Example: the ACL method.....................................20		8.1.2 Example: the ACL method..................................31
	8.1.3 Example: ACL method failure due to omission of protected ACE21		8.1.3 Example: ACL method failure due to protected ACE
	8.1.4 Example: ACL method failure due to inherited ACEs preceding		conflict ................................................32
	non-inherited ACEs................................................22		8.1.4 Example: ACL method failure due to an inherited ACE
			conflict ................................................33
			8.1.5 Example: ACL method failure due to an attempt to set
			grant and deny in a single ACE ..........................34
	Clemm, Hopkins, Sedlar, Whitehead [Page 2]		9 ACCESS CONTROL REPORTS........................................35
	8.1.5 Example: ACL method failure due to an attempt to set grant and		9.1 REPORT Method..............................................35
	deny in a single ACE..............................................23		9.2 DAV:acl-principal-props Report.............................36
			9.2.1 Example: DAV:acl-principal-props Report..................36
			9.3 DAV:principal-match REPORT.................................37
			9.3.1 Example: DAV:principal-match REPORT......................38
	9 INTERNATIONALIZATION CONSIDERATIONS..............................24		10 XML PROCESSING..............................................39
	10 SECURITY CONSIDERATIONS........................................25		11 INTERNATIONALIZATION CONSIDERATIONS.........................39
	10.1 Increased Risk of Compromised Users...........................25
	10.2 Risks of the read-acl and cuprivset Privileges................25
	11 AUTHENTICATION.................................................26		12 SECURITY CONSIDERATIONS.....................................40
			12.1 Increased Risk of Compromised Users........................40
			12.2 Risks of the DAV:read-acl and DAV:current-user-privilege-set
			Privileges.................................................40
			12.3 No Foreknowledge of Initial ACL............................41
	12 IANA CONSIDERATIONS............................................26		13 AUTHENTICATION..............................................41
	13 INTELLECTUAL PROPERTY..........................................26		14 IANA CONSIDERATIONS.........................................42
	14 ACKNOWLEDGEMENTS...............................................26		15 INTELLECTUAL PROPERTY.......................................42
	15 REFERENCES.....................................................27		16 ACKNOWLEDGEMENTS............................................42
	15.1 Normative References..........................................27
	15.2 Informational References......................................28
	16 AUTHORS' ADDRESSES.............................................28		17 REFERENCES..................................................43
			17.1 Normative References.......................................43
			17.2 Informational References...................................43
	17 APPENDICIES....................................................28		18 AUTHORS' ADDRESSES..........................................43
	17.1 XML Document Type Definition..................................28
	Clemm, Hopkins, Sedlar, Whitehead [Page 3]		19 APPENDICIES.................................................44
			19.1 XML Document Type Definition...............................44
			20 NOTE TO RFC EDITOR..........................................46
			Clemm, Hopkins, Sedlar, Whitehead [Page 3]
	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
	interoperable mechanism for handling discretionary access control		an interoperable mechanism for handling discretionary access
	for content in WebDAV servers. WebDAV access control can be		control for content in WebDAV servers. WebDAV access control
	implemented on content repositories with security as simple as that		can be implemented on content repositories with security as
	of a UNIX file system, as well as more sophisticated models. The		simple as that of a UNIX file system, as well as more
	underlying principle of access control is that who you are		sophisticated models. The underlying principle of access
	determines how you can access a resource. The "who you are" is		control is that who you are determines how you can access a
	defined by a "principal" identifier; users, client software,		resource. The "who you are" is defined by a "principal"
	servers, and groups of the previous have principal identifiers. The		identifier; users, client software, servers, and groups of the
	"how" is determined by a single "access control list" (ACL)		previous have principal identifiers. The "how" is determined by
	associated with a resource. An ACL contains a set of "access		a single "access control list" (ACL) associated with a
	control entries" (ACEs), where each ACE specifies a principal and a		resource. An ACL contains a set of "access control entries"
	set of privileges that are either granted or denied to that		(ACEs), where each ACE specifies a principal and a set of
	principal. When a principal submits an operation (such as an HTTP		privileges that are either granted or denied to that principal.
	or WebDAV method) to a resource for execution, the server evaluates		When a principal submits an operation (such as an HTTP or
	the ACEs in the ACL to determine if the principal has permission		WebDAV method) to a resource for execution, the server
	for that operation.		evaluates the ACEs in the ACL to determine if the principal has
			permission for that operation.
	This specification intentionally omits discussion of		This specification intentionally omits discussion of
	authentication, as the HTTP protocol already has a number of		authentication, as the HTTP protocol already has a number of
	authentication mechanisms [RFC2617]. Some authentication mechanism		authentication mechanisms [RFC2617]. Some authentication
	(such as HTTP Digest Authentication, which all WebDAV compliant		mechanism (such as HTTP Digest Authentication, which all WebDAV
	implementations are required to support) must be available to		compliant implementations are required to support) must be
	validate the identity of a principal.		available to validate the identity of a principal.
	In the interests of timeliness, the following set of security		The following issues are out of scope for this document:
	mechanisms are not addressed by this document:
	* Access control that applies only to a particular property on a		* Access control that applies only to a particular property
	resource (excepting the access control properties DAV:acl and		on a resource (excepting the access control properties
	DAV:current-user-privilege-set), rather than the entire		DAV:acl and DAV:current-user-privilege-set), rather than
	resource,		the entire resource,
	* Role-based security (where a role can be seen as a dynamically		* Role-based security (where a role can be seen as a
	defined collection of principals),		dynamically defined collection of principals),
	* Specification of the ways an ACL on a resource is initialized,		* Specification of the ways an ACL on a resource is
			initialized,
	* Specification of an ACL that applies globally to a method,		* Specification of an ACL that applies globally to all
	rather than to a particular resource.		resources , rather than to a particular resource.
	This specification is organized as follows. Section 1.1 defines key		* Creation and maintenance of resources representing people
	concepts used throughout the specification, and is followed by more		or computational agents (principals), and groups of these.
	in-depth discussion of principals (Section 2), and privileges
	(Section 3). Properties defined on principals are specified in		This specification is organized as follows. Section 1.1 defines
	Section 4, and access control properties for content resources are		key concepts used throughout the specification, and is followed
	specified in Section 5. The semantics of access control lists are		by more in-depth discussion of principals (Section 2), and
	described in Section 6, including sections on ACE combination		privileges (Section 3). Properties defined on principals are
	(Section 6.1), ACE ordering (Section 6.2), and principals required		specified in Section 4, and access control properties for
	to be present in an ACE (Section 6.3). Client discovery of access		content resources are specified in Section 5. The semantics of
	control capability using OPTIONS is described in Section 7.1, and		access control lists are described in Section 6, including
	the access control setting method, ACL, is specified in Section 8.		sections on ACE combination (Section 6.1), ACE ordering
	Clemm, Hopkins, Sedlar, Whitehead [Page 4]		Clemm, Hopkins, Sedlar, Whitehead [Page 4]
	Internationalization considerations (Section 9) and security		(Section 6.2), and principals required to be present in an ACE
	considerations (Section 10) round out the specification. An		(Section 6.4). Client discovery of access control capability
	appendix (Section 17.1) provides an XML Document Type Definition		using OPTIONS is described in Section 7.1, and the access
	(DTD) for the XML elements defined in the specification.		control setting method, ACL, is specified in Section 8.
			Internationalization considerations (Section 11) and security
			considerations (Section 12) round out the specification. An
			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.
	principal collection		principal collection
	A "principal collection" is a group of principals, and is		A "principal collection" is a group of principals, and is
	represented in this protocol by a WebDAV collection containing HTTP		represented in this protocol by a WebDAV collection containing
	resources that represent principals, and principal collections.		HTTP resources that represent principals, and principal
			collections.
	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 an atomic or aggregate		The modifier "abstract", when applied to a privilege, means the
	privilege, means the privilege cannot be set in an access control		privilege cannot be set in an access control element (ace).
	element (ace).
	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
	control to a particular resource.		access 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)		An "ace" either grants or denies a particular set of (non-
	privileges for a particular principal.		abstract) privileges for a particular principal.
			Clemm, Hopkins, Sedlar, Whitehead [Page 5]
	inherited ace		inherited ace
	An "inherited ace" is an ace that is shared from the acl of another		An "inherited ace" is an ace that is dynamically shared from
	resource.		the ACL of another resource. When a shared ACE changes on the
			primary resource, it is also changed on inheriting resources.
	Clemm, Hopkins, Sedlar, Whitehead [Page 5]		protected property
			A "protected property" is one whose value cannot be updated
			except by a method explicitly defined as updating that specific
			property. In particular, a protected property cannot be
			updated with a 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
	2.2 of [RFC2616], those rules apply to this document as well.		Section 2.2 of [RFC2616], those rules apply to this document as
			well.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	this document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described
			in [RFC2119].
			Definitions of XML elements in this document use XML element
			type declarations (as found in XML Document Type Declarations),
			described in Section 3.2 of [REC-XML].
	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
	or computational actor that initiates access to network resources.		human or computational actor that initiates access to network
	On many implementations, users and groups are represented as		resources. On many implementations, users and groups are
	principals; other types of principals are also possible. A URL of		represented as principals; other types of principals are also
	any scheme MAY be used to identify a principal resource. However,		possible. A URI of any scheme MAY be used to identify a
	servers implementing this specification SHOULD expose principal		principal resource. However, servers implementing this
	resources at an http(s) URL, which is a privileged scheme that		specification MUST expose principal resources at an http(s)
	points to resources that have additional properties, as described		URL, which is a privileged scheme that points to resources that
	in Section 4. Although an implementation SHOULD support PROPFIND		have additional properties, as described in Section 4. So, a
	and PROPPATCH to access and modify information about a principal,		principal resource can have multiple URI identifiers, one of
			which has to be an http(s) scheme URL. Although an
			implementation SHOULD support PROPFIND and MAY support
			PROPPATCH to access and modify information about a principal,
	it is not required to do so.		it is not required to do so.
	A principal resource may or may not be a collection. A collection		A principal resource may or may not be a collection. If a
	principal may only contain other principals (not other types of		person or computational agent matches a principal resource that
	resources). Servers that support aggregation of principals (e.g.		is contained by a collection principal, they also match the
	groups of users or other groups) MUST manifest them as collection		collection principal. This definition is recursive, and hence
	principals. The WebDAV methods for examining and maintaining		if a person or computational agent matches a collection
	collections (e.g. DELETE, PROPFIND) MAY be used to maintain		principal that is the child of another collection principal,
	collection principals. Membership in a collection principal is		they also match the parent collection principal. Membership in
	recursive, so a principal in a collection principal GRPA contained		a collection principal is also recursive, so a principal in a
	by collection principal GRPB is a member of both GRPA and GRPB.		collection principal GRPA contained by collection principal
	Implementations not supporting recursive membership in principal
	collections can return an error if the client attempts to bind		Clemm, Hopkins, Sedlar, Whitehead [Page 6]
	collection principals into other collection principals.		GRPB is a member of both GRPA and GRPB. Implementations not
			supporting recursive membership in principal collections can
			return an error if the client attempts to bind collection
			principals into other collection principals.
			Servers that support aggregation of principals (e.g. groups of
			users or other groups) MUST manifest them as collection
			principals. At minimum, principals and collection principals
			MUST support the OPTIONS and PROPFIND methods.
			Implementer's Note: Collection principals are first and
			foremost WebDAV collections. Therefore they contain
			resources as members. Since there is no requirement that all
			members of a collection principal need be principals, it is
			possible for a collection principal to have non-principals
			as members. When enumerating the principals-only membership
			of a collection principal, it is necessary to retrieve the
			DAV:resourcetype property and check it for the DAV:principal
			XML element (described in Section 4). If the DAV:principal
			XML element is not present, the resource is not a principal
			and may be ignored for the purposes of determining the
			principals-only membership of the collection principal.
			For example, the collection principal /FOO/ has two members,
			Bar and Baz. Bar is a principal but Baz is not. Therefore
			when determining which principals belong to the collection
			principal /FOO/, a client would enumerate the membership
			using PROPFIND while asking for the DAV:resourcetype
			property, and see that only Bar has the DAV:principal XML
			element. Therefore, only Bar is the only principal that is a
			member of the collection principal /FOO/.
	3 PRIVILEGES		3 PRIVILEGES
	Ability to perform a given method on a resource SHOULD be		Ability to perform a given method on a resource SHOULD be
	controlled by one or more privileges. Authors of protocol		controlled by one or more privileges. Authors of protocol
	extensions that define new HTTP methods SHOULD specify which		extensions that define new HTTP methods SHOULD specify which
	privileges (by defining new privileges, or mapping to ones below)		privileges (by defining new privileges, or mapping to ones
	are required to perform the method. A principal with no privileges		below) are required to perform the method. A principal with no
	to a resource SHOULD be denied any HTTP access to that resource.		privileges to a resource SHOULD be denied any HTTP access to
			that resource.
	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 or		they are termed aggregate privileges. If a principal is
	denied an aggregate privilege, it is semantically equivalent to		granted or denied an aggregate privilege, it is semantically
	granting or denying each of the aggregated privileges individually.		equivalent to granting or denying each of the aggregated
	For example, an implementation may define add-member and remove-		privileges individually. For example, an implementation may
	member privileges that control the ability to add and remove an		define add-member and remove-member privileges that control the
	internal member of a collection. Since these privileges control		ability to add and remove an internal member of a collection.
			Since these privileges control the ability to update the state
	Clemm, Hopkins, Sedlar, Whitehead [Page 6]		of a collection, these privileges would be aggregated by the
	the ability to update the state of a collection, these privileges		DAV:write privilege on a collection, and granting the DAV:write
	would be aggregated by the DAV:write privilege on a collection, and		privilege on a collection would also grant the add-member and
	granting the DAV:write privilege on a collection would also grant		remove-member privileges.
	the add-member and remove-member privileges.
	Privileges may have the quality of being abstract, in which case		Clemm, Hopkins, Sedlar, Whitehead [Page 7]
	they cannot be set in an ACE. Aggregate and atomic privileges are		Privileges may have the quality of being abstract, in which
	both capable of being abstract. Abstract privileges are useful for		case they cannot be set in an ACE. Aggregate and non-aggregate
	modeling privileges that otherwise would not be exposed via the		privileges are both capable of being abstract. Abstract
	protocol. Abstract privileges also provide server implementations		privileges are useful for modeling privileges that otherwise
	with flexibility in implementing the privileges defined in this		would not be exposed via the protocol. Abstract privileges also
	specification. For example, if a server is incapable of separating		provide server implementations with flexibility in implementing
	the read resource capability from the read ACL capability, it can		the privileges defined in this specification. For example, if
	still model the DAV:read and DAV:read-acl privileges defined in		a server is incapable of separating the read resource
	this specification by declaring them abstract, and containing them		capability from the read ACL capability, it can still model the
			DAV:read and DAV:read-acl privileges defined in this
			specification by declaring them abstract, and containing them
	within a non-abstract aggregate privilege (say, read-all) that		within a non-abstract aggregate privilege (say, read-all) that
	holds DAV:read, and DAV:read-acl. In this way, it is possible to		holds DAV:read, and DAV:read-acl. In this way, it is possible
	set the aggregate privilege, read-all, thus coupling the setting of		to set the aggregate privilege, read-all, thus coupling the
	DAV:read and DAV:read-acl, but it is not possible to set DAV:read,		setting of DAV:read and DAV:read-acl, but it is not possible to
	or DAV:read-acl individually. Since aggregate privileges can be		set DAV:read, or DAV:read-acl individually. Since aggregate
	abstract, it is also possible to use abstract privileges to group		privileges can be abstract, it is also possible to use abstract
	and classify non-abstract privileges.		privileges to group or organize non-abstract privileges.
			Privilege containment loops are not allowed, hence a privilege
			MUST NOT contain itself. For 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
	with the DAV:resourcetype of the resource, as well as between		vary with the DAV:resourcetype of the resource, as well as
	different server implementations. To promote interoperability,		between different server implementations. To promote
	however, WebDAV defines a set of well-known privileges (e.g.		interoperability, however, this specification defines a set of
	DAV:read and DAV:write), which can at least be used to classify the		well-known privileges (e.g. DAV:read,DAV:write, DAV:read-acl,
	other privileges defined on a particular resource. The access		DAV:write-acl, DAV:read-current-user-privilege-set, and
	permissions on null and lock-null resources are solely those they		DAV:all), which can at least be used to classify the other
	inherit (if any), and they are not discoverable (i.e., the ACL		privileges defined on a particular resource. The access
	properties specified in Section 5 are not defined on null and lock-		permissions on null and lock-null resources (defined in
	null resources). On the transition from null or lock-null to a		[RFC2518], Sections 3 and 7.4) are solely those they inherit
	stateful resource, the initial access control list is set by the		(if any), and they are not discoverable (i.e., the access
	server's default ACL value policy (if any).		control properties specified in Section 5 are not defined on
			null and lock-null resources). On the transition from null or
			lock-null to a stateful resource, the initial access control
			list is set by the server's default ACL value policy (if any).
	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
	the state of the resource, including the resource's properties.		about the state of the resource, including the resource's
	Affected methods include GET and PROPFIND. Additionally, the read		properties. Affected methods include GET and PROPFIND.
	privilege MAY control the OPTIONS method.		Additionally, the read privilege MAY 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 modify the state of the		The write privilege controls methods that modify the content,
	resource, such as PUT and PROPPATCH. Note that state modification		dead properties, or (in the case of a collection) membership of
	is also controlled via locking (see section 5.3 of [WEBDAV]), so		the resource, such as PUT and PROPPATCH. Note that state
	effective write access requires that both write privileges and		modification is also controlled via locking (see section 5.3 of
	write locking requirements are satisfied.
	<!ELEMENT write EMPTY>		Clemm, Hopkins, Sedlar, Whitehead [Page 8]
			[WEBDAV]), so effective write access requires that both write
			privileges and write locking requirements are satisfied.
	Clemm, Hopkins, Sedlar, Whitehead [Page 7]		<!ELEMENT write EMPTY>
	3.3 DAV:read-acl Privilege		3.3 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.4 DAV:read-cuprivset Privilege		3.4 DAV:read-current-user-privilege-set Privilege
	The DAV:read-cuprivset privilege controls the use of PROPFIND to		The DAV:read-current-user-privilege-set privilege controls the
	retrieve the DAV:current-user-privilege-set property of the		use of PROPFIND to retrieve the DAV:current-user-privilege-set
	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
	their UI items that are dependent on the permissions of a resource,		in 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
	ACL contains information that may not be appropriate for the		full ACL contains information that may not be appropriate for
	current authenticated user. As a result, the set of users who can		the current authenticated user. As a result, the set of users
	view the full ACL is expected to be much smaller than those who can		who can view the full ACL is expected to be much smaller than
	read the current user privilege set, and hence distinct privileges		those who can read the current user privilege set, and hence
	are needed for each		distinct privileges are needed for each.
	<!ELEMENT read-cuprivset EMPTY>		<!ELEMENT read-current-user-privilege-set EMPTY>
	3.5 DAV:write-acl Privilege		3.5 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.6 DAV:all Privilege		3.6 DAV:all Privilege
	DAV:all is an aggregate privilege that contains all privileges on		DAV:all is an aggregate privilege that contains the entire set
	the resource.		of privileges that apply to the resource.
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
			3.7 Aggregation of Predefined Privileges
			Server implementations are free to aggregate the predefined
			privileges (defined above in Sections 3.1-3.6) subject to the
			following limitations:
			Clemm, Hopkins, Sedlar, Whitehead [Page 9]
			DAV:read-acl MUST NOT contain DAV:read, DAV:write, DAV:write-
			acl, or DAV:read-current-user-privilege-set.
			DAV:write-acl MUST NOT contain DAV:write, DAV:read, DAV:read-
			acl, or DAV:read-current-user-privilege-set.
			DAV:read-current-user-privilege-set MUST NOT contain DAV:write,
			DAV:read, DAV:read-acl, or DAV:write-acl.
			DAV:write MUST NOT contain DAV:read, DAV:read-acl, or DAV:read-
			current-user-privilege-set.
			DAV:read MUST NOT contain DAV:write, or DAV:write-acl.
	4 PRINCIPAL PROPERTIES		4 PRINCIPAL PROPERTIES
	Principals are manifested to clients as an HTTP resource,		Principals are manifested to clients as an HTTP resource,
	identified by a URL. A principal MUST have a DAV:displayname		identified by a URL. A principal MUST have a DAV:displayname
	property. This protocol defines the following additional		property (defined in Section 13.2 of [RFC2518]), and a
	properties for a principal. The name and value of these properties		DAV:resourcetype property (defined in Section 13.9 of
	SHOULD NOT be returned by PROPFIND allprop request (as defined in		[RFC2518]). Additionally, a principal MUST report the
	Section 12.14.1 of [RFC2518]). In the descriptions below, a read-		DAV:principal empty XML element in the value of the
	only property is defined as a property that MUST NOT be writeable		DAV:resourcetype property in addition to all other reported
	using PROPPATCH.		elements. For example, a collection principal would report
			DAV:collection and DAV:principal elements. The element type
	Clemm, Hopkins, Sedlar, Whitehead [Page 8]		declaration for DAV:principal is:
	4.1 DAV:is-principal
	This is a read-only property that indicates whether this resource		<!ELEMENT principal EMPTY>
	is a principal. A resource MUST have a non-empty DAV:is-principal
	property if and only if it is a principal resource.
	<!ELEMENT is-principal (#PCDATA)>		This protocol defines the following additional property for a
	PCDATA value: "true" - resource is a principal, "false" - resource		principal. Since it is expensive, for many servers, to retrieve
	is not a principal (note that in cases where the "F" value might be		access control information, the name and value of this property
	used, this specification requires the property not be present at		SHOULD NOT be returned by a PROPFIND allprop request (as
	all).		defined in Section 12.14.1 of [RFC2518]).
	4.2 DAV:alternate-URL		4.1 DAV:alternate-URL
	This read-only property, if present, contains the URL of a network		This protected property, if non-empty, contains the URIs of
	resource with additional descriptive information about the		network resources with additional descriptive information about
	principal. This property identifies one or more additional network		the principal. This property identifies one or more additional
	resources (i.e., it contains one or more URLs) that may be		network resources (i.e., it contains one or more URIs) that may
	consulted by a client to gain additional knowledge concerning a		be consulted by a client to gain additional knowledge
	principal. Two potential uses for this property are to store an		concerning a principal. Two potential uses for this property
	ldap [RFC2255] or mailto [RFC2368] scheme URL. Support for this		are to store an ldap [RFC2255] or mailto [RFC2368] scheme URL.
	property is OPTIONAL.		Support for this property is REQUIRED, and the value is empty
			if no alternate URL exists for the principal. .
	<!ELEMENT alternate-URL (href*)>		<!ELEMENT alternate-URL (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
	resources. Access control properties may be retrieved just like		WebDAV resources. Access control properties may be retrieved
	other WebDAV properties, using the PROPFIND method. Some access		just like other WebDAV properties, using the PROPFIND method.
	control properties (such as DAV:owner) MAY be updated with the		Since it is expensive, for many servers, to retrieve access
	PROPPATCH method. In the descriptions below, a read-only property
	is defined as a property that MUST NOT be writeable using		Clemm, Hopkins, Sedlar, Whitehead [Page 10]
	PROPPATCH. Since it is expensive, for many servers, to retrieve		control information, a PROPFIND allprop request (as defined in
	access control information, a PROPFIND allprop request (as defined		Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and
	in Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and
	values of the properties defined in this section.		values of the properties defined in this section.
	HTTP resources that support the WebDAV Access Control Protocol MUST		HTTP resources that support the WebDAV Access Control Protocol
	contain the following properties. Null, and lock-null resources		MUST contain the following properties. Null, and lock-null
	(described in Section 7.4 of [RFC2518]) MUST NOT contain the		resources (described in Section 7.4 of [RFC2518]) MUST NOT
	following properties:		contain the following properties:
	5.1 DAV:owner		5.1 DAV:owner
	This property identifies a particular principal as being the		This protected property identifies a particular principal as
	"owner" of the resource. Since the owner of a resource often has		being the "owner" of the resource. Since the owner of a
	special access control capabilities (e.g., the owner frequently has		resource often has special access control capabilities (e.g.,
	permanent write-ACL privilege), clients might display the resource		the owner frequently has permanent DAV:write-acl privilege),
	owner in their user interface.		clients might display the resource owner in their user
			interface.
	<!ELEMENT owner (href prop?)>		<!ELEMENT owner (href)>
	<!ELEMENT prop (see [RFC2518], section 12.11)>
	Clemm, Hopkins, Sedlar, Whitehead [Page 9]		5.1.1 Example: Retrieving DAV:owner
	An implementation MAY include a list of selected properties of that
	principal resource. Which properties (if any) are included is
	implementation defined, but might reasonably include properties
	such as DAV:displayname, which is useful for the construction of
	access control user interfaces on the client. A server might
	support this capability if it wished to save the client the
	additional network round-trip delay required to retrieve this
	information using a PROPFIND request on the principal URL in the
	href element. Servers that do not directly support PROPFIND on
	principal resources might also support this feature, since it
	allows them to return a server-controlled subset of the properties
	on the principal resource.
	An implementation MAY allow the use of PROPPATCH to update the		This example shows a client request for the value of the
	DAV:owner field. If the DAV:owner property is writeable, clients		DAV:owner property from a collection resource with URL
	MUST NOT submit the prop element; only the href element can be		http://www.webdav.org/papers/. The principal making the request
	modified by the client. The purpose of this restriction is to limit		is authenticated using Digest authentication. The value of
	the scope of effect of a PROPPATCH to just the owner property's		DAV:owner is the URL http://www.webdav.org/_acl/users/gstein,
	resource; setting the prop element would additionally require		wrapped in the DAV:href XML element.
	modification to properties of the principal resource identified by
	the href element.		>> Request <<
			PROPFIND /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="jim",
			realm="jim@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:owner/>
			</D:propfind>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			Clemm, Hopkins, Sedlar, Whitehead [Page 11]
			<D:response>
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:owner>
			<D:href>
			http://www.webdav.org/_acl/users/gstein
			</D:href>
			</D:owner>
			</D:prop>
			</D:propstat>
			</D:response>
			</D:multistatus>
			5.1.2 Example: An Attempt to Set DAV:owner
			The following example shows a client request to modify the
			value of the DAV:owner property on the resource with URL
			http://www.webdav.org/papers/. Since DAV:owner is a protected
			property, the server responds with a 207 (Multi-Status)
			response that contains a 403 (Forbidden) status code for the
			act of setting DAV:owner. [RFC2518], Section 8.2.1 describes
			PROPPATCH status code information, and Section 11 describes the
			Multi-Status response.
			>> Request <<
			PROPPATCH /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="jim",
			realm="jim@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propertyupdate xmlns:D="DAV:">
			<D:set>
			<D:prop>
			<D:owner>
			<D:href>
			http://www.webdav.org/_acl/users/jim
			</D:href>
			</D:owner>
			</D:prop>
			</D:set>
			</D:propertyupdate>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			Clemm, Hopkins, Sedlar, Whitehead [Page 12]
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 403 Forbidden</D:status>
			<D:prop><D:owner/></D:prop>
			</D:propstat>
			<D:responsedescription>Failure to set protected property
			(DAV:owner)
			</D:responsedescription>
			</D:response>
			</D:multistatus>
	5.2 DAV:supported-privilege-set		5.2 DAV:supported-privilege-set
	This is a read-only 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 of a resource MUST NOT be used in an ACE for		An abstract privilege of a resource MUST NOT be used in an ACE
	that resource. Servers MUST fail an attempt to set an abstract		for that resource. Servers MUST fail an attempt to set an
	privilege.		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.		privilege controls access to.
	<!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
	user to choose non-abstract privileges to apply in an ACE. The		the user to choose non-abstract privileges to apply in an ACE.
	privileges tree is useful programmatically to map well-known		The privileges tree is useful programmatically to map well-
	privileges (defined by WebDAV or other standards groups) into		known privileges (defined by WebDAV or other standards groups)
			into privileges that are supported by any particular server
			implementation. The privilege tree also serves to hide
			complexity in implementations allowing large number of
			privileges to be defined by displaying aggregates to the user.
	Clemm, Hopkins, Sedlar, Whitehead [Page 10]		Clemm, Hopkins, Sedlar, Whitehead [Page 13]
	privileges that are supported by any particular server		5.2.1 Example: Retrieving a List of Privileges Supported on a
	implementation. The privilege tree also serves to hide complexity		Resource
	in implementations allowing large number of privileges to be
	defined by displaying aggregates to the user.		This example shows a client request for the DAV:supported-
			privilege-set property on the resource
			http://www.webdav.org/papers/. The value of the DAV:supported-
			privilege-set property is a tree of supported privileges:
			DAV:all (aggregate, abstract)
			|
			+-- DAV:read (aggregate)
			|
			+-- DAV:read-acl (abstract)
			+-- DAV:read-current-user-privilege-set (abstract)
			+-- DAV:write (aggregate)
			|
			+-- DAV:write-acl (abstract)
			This privilege tree is not normative, and many possible
			privilege trees are possible.
			>> Request <<
			PROPFIND /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="gclemm",
			realm="gclemm@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:supported-privilege-set/>
			</D:propfind>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:supported-privilege-set>
			Clemm, Hopkins, Sedlar, Whitehead [Page 14]
			<D:supported-privilege>
			<D:privilege> <D:all/> </D:privilege>
			<D:abstract/>
			<D:description>Any operation</D:description>
			<D:supported-privilege>
			<D:privilege> <D:read/> </D:privilege>
			<D:description>Read any object</D:description>
			<D:supported-privilege>
			<D:privilege> <D:read-acl/> </D:privilege>
			<D:abstract/>
			<D:description>Read ACL</D:description>
			</D:supported-privilege>
			</D:supported-privilege>
			<D:supported-privilege>
			<D:privilege>
			<D:read-current-user-privilege-set/>
			</D:privilege>
			<D:abstract/>
			<D:description>Read current user privilege set
			property</D:description>
			</D:supported-privilege>
			<D:supported-privilege>
			<D:privilege> <D:write/> </D:privilege>
			<D:description>Write any object</D:description>
			<D:supported-privilege>
			<D:privilege> <D:write-acl/> </D:privilege>
			<D:description>Write ACL</D:description>
			<D:abstract/>
			</D:supported-privilege>
			</D:supported-privilege>
			</D:supported-privilege>
			</D:supported-privilege-set>
			</D:prop>
			</D:propstat>
			</D:response>
			</D:multistatus>
	5.3 DAV:current-user-privilege-set		5.3 DAV:current-user-privilege-set
	DAV:current-user-privilege-set is a read-only property containing		DAV:current-user-privilege-set is a protected property
	the exact set of privileges (as computed by the server) granted to		containing the exact set of privileges (as computed by the
	the currently authenticated HTTP user. Aggregate privileges and		server) granted to the currently authenticated HTTP user.
	their contained privileges are listed. A user-agent can use the		Aggregate privileges and their contained privileges are listed.
	value of this property to adjust its user interface to make actions		A user-agent can use the value of this property to adjust its
	inaccessible (e.g., by graying out a menu item or button) for which		user interface to make actions inaccessible (e.g., by graying
	the current principal does not have permission. This is		out a menu item or button) for which the current principal does
	particularly useful for an access control user interface, which can		not have permission. This is particularly useful for an access
	be constructed without knowing the ACE combining semantics of the		control user interface, which can be constructed without
	server. This property is also useful for determining what		knowing the ACE combining semantics of the server. This
	operations the current principal can perform, without having to		property is also useful for determining what operations the
	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*)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 15]
	<!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
	resource. Therefore, each element in the DAV:current-user-		on this resource. Therefore, each element in the DAV:current-
	privilege-set property MUST identify a non-abstract privilege from		user-privilege-set property MUST identify a non-abstract
	the DAV:supported-privilege-set property.		privilege from the DAV:supported-privilege-set property.
			5.3.1 Example: Retrieving the User's Current Set of Assigned
			Privileges
			Continuing the example from Section 5.2.1, this example shows a
			client requesting the DAV:current-user-privilege-set property
			from the resource with URL http://www.webdav.org/papers/. The
			username of the principal making the request is ôkhareö, and
			Digest authentication is used in the request. The principal
			with username ôkhareö has been granted the DAV:read privilege.
			Since the DAV:read privilege contains the DAV:read-acl and
			DAV:read-current-user-privilege-set privileges (see Section
			5.2.1), the principal with username ôkhareö can read the ACL
			property, and the DAV:current-user-privilege-set property.
			However, the DAV:all, DAV:read-acl, DAV:write-acl and DAV:read-
			current-user-privilege-set privileges are not listed in the
			value of DAV:current-user-privilege-set, since (for this
			example) they are abstract privileges. DAV:write is not listed
			since the principal with username ôkhareö is not listed in an
			ACE granting that principal write permission.
			>> Request <<
			PROPFIND /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="khare",
			realm="khare@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:current-user-privilege-set/>
			</D:propfind>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			Clemm, Hopkins, Sedlar, Whitehead [Page 16]
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:current-user-privilege-set>
			<D:privilege> <D:read/> </D:privilege>
			</D:current-user-privilege-set>
			</D:prop>
			</D:propstat>
			</D:response>
			</D:multistatus>
	5.4 DAV:acl		5.4 DAV:acl
	This is a read-only 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
	granted or denied to a single principal. If the DAV:acl property		either granted or denied to a single principal. If the DAV:acl
	is empty, no principal is granted any privilege.		property is empty, no principal is granted any privilege.
	<!ELEMENT ace (principal, (grant|deny), protected?, inherited?)>		<!ELEMENT ace (principal, (grant|deny), protected?,
			inherited?)>
	5.4.1 ACE Principal		5.4.1 ACE Principal
	The DAV:principal element identifies the principal to which this		The DAV:principal element identifies the principal to which
	ACE applies.		this ACE applies.
	<!ELEMENT principal ((href, prop?)		<!ELEMENT principal ((href)
	| all | authenticated | unauthenticated		| all | authenticated | unauthenticated
	| property | self)>		| property | self)>
	Clemm, Hopkins, Sedlar, Whitehead [Page 11]
	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. An implementation		identified by the URL contained by that DAV:href.
	MAY include a DAV:prop element after the DAV:href element,
	containing a list of selected properties of that principal
	resource. Which properties (if any) are included in the DAV:prop
	element is implementation defined. The DAV:prop element can be used
	by servers that do not support PROPFIND requests on principal
	resources to return principal-related information (such as the
	value of the DAV:displayname property) that a client would find
	useful in the creation of an access control user interface. A
	server might also support this capability if it wished to save the
	client the additional network round-trip delays required to
	retrieve this information via a series of PROPFIND requests on each
	principal URL in the ACL. In the worst case, this is one additional
	PROPFIND per ACE.
	<!ELEMENT prop (see [RFC2518], section 12.11)>
	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.
			Clemm, Hopkins, Sedlar, Whitehead [Page 17]
	<!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
	DAV:unauthenticated, but not both.		either DAV:authenticated, or DAV:unauthenticated, but not both
			(that is, 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 identified property of that		property of a resource only if the value of the identified
	resource contains a DAV:href that identifies a principal, and the		property of that resource contains at most one DAV:href XML
	current user is authenticated as being (or being a member of) that		element, the URI value of DAV:href identifies a principal, and
	principal. For example, if the DAV:property element contained		the current user is authenticated as being (or being a member
	<DAV:owner/>, the current user would match the DAV:property		of) that principal. For example, if the DAV:property element
	principal only if the current user is authenticated as matching the		contained <DAV:owner/>, the current user would match the
	principal identified by the DAV:owner property of the resource.		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>
	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 object and the		resource only if that resource is a principal object and the
	current user is authenticated as being that principal.		current user is authenticated as being that principal or a
			member of that principal collection.
	<!ELEMENT self EMPTY>		<!ELEMENT self EMPTY>
	Clemm, Hopkins, Sedlar, Whitehead [Page 12]
	5.4.2 ACE Grant and Deny		5.4.2 ACE 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
	to be either granted or denied to the specified principal. A		privileges to be either granted or denied to the specified
	DAV:grant or DAV:deny element of the DAV:acl of a resource MUST		principal. A DAV:grant or DAV:deny element of the DAV:acl of a
	only contain non-abstract elements specified in the DAV:supported-		resource MUST only contain non-abstract elements specified in
	privilege-set of that resource.		the DAV:supported-privilege-set of that resource.
	<!ELEMENT grant (privilege+)>		<!ELEMENT grant (privilege+)>
	<!ELEMENT deny (privilege+)>		<!ELEMENT deny (privilege+)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	5.4.3 ACE Protection		5.4.3 ACE Protection
	If an ACE contains a DAV:protected element, an ACL request without		If an ACE contains a DAV:protected element, an ACL request
	that ACE MUST fail.		without that ACE MUST fail.
	<!ELEMENT protected EMPTY>		<!ELEMENT protected EMPTY>
	5.4.4 ACE Inheritance		5.4.4 ACE Inheritance
	The presence of a DAV:inherited element indicates that this ACE is		The presence of a DAV:inherited element indicates that this ACE
	inherited from another resource that is identified by the URL		is inherited from another resource that is identified by the
	contained in a DAV:href element. An inherited ACE cannot be		URL contained in a DAV:href element. An inherited ACE cannot
	modified directly, but instead the ACL on the resource from which		be modified directly, but instead the ACL on the resource from
	it is inherited must be modified.		which it is inherited must be modified.
	Note that ACE inheritance is not the same as ACL initialization.		Clemm, Hopkins, Sedlar, Whitehead [Page 18]
	ACL initialization defines the ACL that a newly created resource		Note that ACE inheritance is not the same as ACL
	will use (if not specified). ACE inheritance refers to an ACE that		initialization. ACL initialization defines the ACL that a
	is logically shared - where an update to the resource containing an		newly created resource will use (if not specified). ACE
	ACE will affect the ACE of each resource that inherits that ACE.		inheritance refers to an ACE that is logically shared - where
	The method by which ACLs are initialized or by which ACEs are		an update to the resource containing an ACE will affect the ACE
	inherited is not defined by this document.		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.5 Example: Retrieving a Resource's Access Control List
			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 with URL http://www.webdav.org/papers/. There are two
			ACEs defined in this ACL:
			ACE #1: The principal collection identified by URL
			http://www.webdav.org/_acl/groups/maintainers/ (the group of
			site maintainers) is granted DAV:write privilege. Since (for
			this example) DAV:write contains the DAV:write-acl privilege
			(see Section 5.2.1), this means the ômaintainersö group can
			also modify the access control list.
			ACE #2: All principals (DAV:all) are granted the DAV:read
			privilege. Since (for this example) DAV:read contains DAV:read-
			acl and DAV:read-current-user-privilege-set, this means all
			users (including all members of the ômaintainersö group) can
			read the DAV:acl property and the DAV:current-user-privilege-
			set property.
			>> Request <<
			PROPFIND /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="masinter",
			realm="masinter@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:acl/>
			</D:propfind>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Clemm, Hopkins, Sedlar, Whitehead [Page 19]
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:acl>
			<D:ace>
			<D:principal>
			<D:href>
			http://www.webdav.org/_acl/groups/maintainers/
			</D:href>
			</D:principal>
			<D:grant>
			<D:privilege> <D:write/> </D:privilege>
			</D:grant>
			</D:ace>
			<D:ace>
			<D:principal>
			<D:href> <D:all/> </D:href>
			</D:principal>
			<D:grant>
			<D:privilege> <D:read/> </D:privilege>
			</D:grant>
			</D:ace>
			</D:acl>
			</D:prop>
			</D:propstat>
			</D:response>
			</D:multistatus>
	5.5 DAV:acl-semantics		5.5 DAV:acl-semantics
	This is a read-only property that defines the ACL semantics. These		This is a protected property that defines the ACL semantics.
	semantics define how multiple ACEs that match the current user are		These semantics define how multiple ACEs that match the current
	combined, what are the constraints on how ACEs can be ordered, and		user are combined, what are the constraints on how ACEs can be
	which principals must have an ACE. A client user interface could		ordered, and which principals must have an ACE. A client user
	use the value of this property to provide feedback to a human		interface could use the value of this property to provide
	operator concerning the impact of proposed changes to an ACL.		feedback to a human operator concerning the impact of proposed
	Alternately, a client could use this property to determine exactly,		changes to an ACL. Alternately, a client can use this property
	before submitting an ACL method invocation, what ACL changes it		to help it determine, before submitting an ACL method
	needs to make to accomplish a specific goal (or whether that goal		invocation, what ACL changes it needs to make to accomplish a
	is even achievable on this server).		specific goal (or whether that goal is even achievable on this
			server).
	Since it is not practical to require all implementations to use the		Since it is not practical to require all implementations to use
	same ACL semantics, the DAV:acl-semantics property is used to		the same ACL semantics, the DAV:acl-semantics property is used
	identify the ACL semantics for a particular resource. The DAV:acl-		to identify the ACL semantics for a particular resource. The
	semantics element is defined in section 6.		DAV:acl-semantics element is defined in Section 6.
	Clemm, Hopkins, Sedlar, Whitehead [Page 13]		Clemm, Hopkins, Sedlar, Whitehead [Page 20]
			5.5.1 Example: Retrieving DAV:acl-semantics
			In this example, the client requests the value of the DAV:acl-
			semantics property. Digest authentication provides credentials
			for the principal operating the client. In this example, the
			ACE combination semantics are DAV:first-match, described in
			Section 6.1.1, the ACE ordering semantics are not specified
			(some value other than DAV:deny-before-grant, described in
			Section 6.2.1), the DAV:allowed-ace element states that only
			one ACE is permitted for each principal, and an ACE describing
			the privileges granted the DAV:all principal must exist in
			every ACL.
			>> Request <<
			PROPFIND /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="srcarter",
			realm="srcarter@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:acl-semantics/>
			</D:propfind>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:acl-semantics>
			<D:ace-combination>
			<D:first-match/>
			</D:ace-combination>
			<D:ace-ordering/>
			<D:allowed-ace>
			<D:principal-only-one-ace/>
			</D:allowed-ace>
			<D:required-principal>
			Clemm, Hopkins, Sedlar, Whitehead [Page 21]
			<D:all/>
			</D:required-principal>
			</D:acl-semantics>
			</D:prop>
			</D:propstat>
			<D:response>
			</D:multistatus>
	5.6 DAV:principal-collection-set		5.6 DAV:principal-collection-set
	This read-only property contains zero, one, or more URLs that		This protected property contains zero, one, or more URLs that
	identify a collection principal. It is expected that		identify a collection principal. It is expected that
	implementations of this protocol will typically employ a relatively		implementations of this protocol will typically use a
	small number of locations in the URL namespace for principal, and		relatively small number of locations in the URL namespace for
	collection principals. In cases where this assumption holds, the		principal, and collection principals. In cases where this
	DAV:principal-collection-set property will contain a small set of		assumption holds, the DAV:principal-collection-set property
	URLs identifying the top of collection hierarchy containing		will contain a small set of URLs identifying the top of a
	multiple principals and collection principals. An access control		collection hierarchy containing multiple principals and
	protocol user agent could use the contents of DAV:principal-		collection principals. An access control protocol user agent
	collection-set to query the DAV:displayname property (specified in		could use the contents of DAV:principal-collection-set to query
	Section 13.2 of [RFC2518]) of all principals on that server,		the DAV:displayname property (specified in Section 13.2 of
	thereby yielding human-readable names for each principal that could		[RFC2518]) of all principals on that server, thereby yielding
	be displayed in a user interface.		human-readable names for each principal that could be displayed
			in a user interface.
	<!ELEMENT principal-collection-set (href*)>		<!ELEMENT principal-collection-set (href*)>
	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
	DAV:principal-collection-set values. The collections specified in		different DAV:principal-collection-set values. The collections
	the DAV:principal-collection-set MAY be located on different hosts		specified in the DAV:principal-collection-set MAY be located on
	from the resource. The URLs in DAV:principal-collection-set SHOULD		different hosts from the resource. The URLs in DAV:principal-
	be http or https scheme URLs. For security and scalability reasons,		collection-set SHOULD be http or https scheme URLs. For
	a server MAY report only a subset of the entire set of known		security and scalability reasons, a server MAY report only a
	collection principals, and therefore clients should not assume they		subset of the entire set of known collection principals, and
	have retrieved an exhaustive listing. Additionally, a server MAY		therefore clients should not assume they have retrieved an
	elect to report none of the collection principals it knows about.		exhaustive listing. Additionally, a server MAY elect to report
			none of the collection principals it knows about, in which case
			the property value would be empty.
			5.6.1 Example: Retrieving DAV:principal-collection-set
			In this example, the client requests the value of the
			DAV:principal-collection-set property on the collection
			resource identified by URL http://www.webdav.org/papers/. The
			property contains the two URLs,
			http://www.webdav.org/_acl/users/ and
			http://www.webdav.org/_acl/groups/, both wrapped in <DAV:href>
			XML elements. Digest authentication provides credentials for
			the principal operating the client.
			The client might reasonably follow this request with two
			separate PROPFIND requests to retrieve the DAV:displayname
			Clemm, Hopkins, Sedlar, Whitehead [Page 22]
			property of the members of the two collections (/_acl/users/
			and /_acl_groups/). This information could be used when
			displaying a user interface for creating access control
			entries.
			>> Request <<
			PROPFIND /papers/ HTTP/1.1
			Host: www.webdav.org
			Content-type: text/xml; charset="utf-8"
			Content-Length: xxx
			Depth: 0
			Authorization: Digest username="yarong",
			realm="yarong@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			<?xml version="1.0" encoding="utf-8" ?>
			<D:propfind xmlns:D="DAV:">
			<D:principal-collection-set/>
			</D:propfind>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/papers/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:principal-collection-set>
			<D:href>
			http://www.webdav.org/_acl/users/
			</D:href>
			<D:href>
			http://www.webdav.org/_acl/groups/
			</D:href>
			</D:principal-collection-set>
			</D:prop>
			</D:propstat>
			</D:response>
			</D:multistatus>
	5.7 Example: PROPFIND to retrieve access control properties		5.7 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
	retrieved by using the PROPFIND method to fetch the values of the		be retrieved by using the PROPFIND method to fetch the values
	DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-		of the DAV:owner, DAV:supported-privilege-set, DAV:current-
	set, and DAV:acl properties.		user-privilege-set, and DAV:acl properties.
			Clemm, Hopkins, Sedlar, Whitehead [Page 23]
	>> Request <<		>> Request <<
	PROPFIND /top/container/ HTTP/1.1		PROPFIND /top/container/ HTTP/1.1
	Host: www.foo.org		Host: www.foo.org
	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="..."
	<?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: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:propfind>		</D:propfind>
	Clemm, Hopkins, Sedlar, Whitehead [Page 14]
	>> 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		<D:multistatus
	xmlns:D="DAV:"		xmlns:D="DAV:"
	xmlns:A="http://www.webdav.org/acl/"> <D:response> <D:propstat>		xmlns:A="http://www.webdav.org/acl/"> <D:response>
			<D:href>http://www.foo.org/top/container/</D:href>
			<D:propstat>
	<D:status>HTTP/1.1 200 OK</D:status>		<D:status>HTTP/1.1 200 OK</D:status>
	<D:prop>		<D:prop>
	<D:owner>		<D:owner>
	<D:href>http://www.foo.org/users/gclemm</D:href> </D:owner>		<D:href>http://www.foo.org/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>
	<D:abstract/>		<D:abstract/>
	<D:description>Any operation</D:description>		<D:description>Any operation</D:description>
	<D:supported-privilege>		<D:supported-privilege>
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
	<D:description>Read any object</D:description>		<D:description>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>Write any object</D:description>		<D:description>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>Create an object</D:description>		<D:description>Create an object</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	<D:supported-privilege>		<D:supported-privilege>
			Clemm, Hopkins, Sedlar, Whitehead [Page 24]
	<D:privilege> <A:update/> </D:privilege>		<D:privilege> <A:update/> </D:privilege>
	<D:description>Update an object</D:description>		<D:description>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:delete/> </D:privilege>
	<D:description>Delete an object</D:description>		<D:description>Delete 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>
	skipping to change at line 793		skipping to change at line 1335
	</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>Write the ACL</D:description>		<D:description>Write the ACL</D:description>
	</D:supported-privilege>		</D:supported-privilege>
	</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>
	Clemm, Hopkins, Sedlar, Whitehead [Page 15]
	</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.foo.org/users/esedlar</D:href>		<D:href>http://www.foo.org/users/esedlar</D:href>
	<D:prop>		</D:principal>
	<D:displayname>Eric Sedlar</D:displayname>
	</D:prop> </D:principal>
	<D:grant>		<D:grant>
	<D:privilege> <D:read/> </D:privilege>		<D:privilege> <D:read/> </D:privilege>
	<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.foo.org/groups/marketing/</D:href>		<D:href>http://www.foo.org/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>
	<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.foo.org/top/</D:href> </D:inherited>		<D:href>http://www.foo.org/top/</D:href>
			</D:inherited>
			Clemm, Hopkins, Sedlar, Whitehead [Page 25]
	</D:ace> </D:acl>		</D:ace> </D:acl>
	</D:prop>		</D:prop>
	</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
	supported privileges:		of supported privileges:
	DAV:all (aggregate, abstract)		DAV:all (aggregate, abstract)
	|		|
	+-- DAV:read		+-- DAV:read
	+-- DAV:write (aggregate, abstract)		+-- DAV:write (aggregate, abstract)
	|		|
	+-- http://www.webdav.org/acl/create		+-- http://www.webdav.org/acl/create
	+-- http://www.webdav.org/acl/update		+-- http://www.webdav.org/acl/update
	+-- http://www.webdav.org/acl/delete		+-- http://www.webdav.org/acl/delete
	Clemm, Hopkins, Sedlar, Whitehead [Page 16]
	+-- 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.foo.org/users/esedlar is granted the DAV:read,		http://www.foo.org/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.foo.org/groups/marketing/ are denied the DAV:read		http://www.foo.org/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
	which is represented by a collection principal.		group, which is represented by a collection principal.
	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,
	value of the DAV:owner property is retrieved, and is examined to		the value of the DAV:owner property is retrieved, and is
	see if it contains a DAV:href XML element. If so, the URL within		examined to see if it contains a DAV:href XML element. If so,
	the DAV:href element is read, and identifies a principal. In this		the URL within the DAV:href element is read, and identifies a
	ACE, the owner is granted DAV:read-acl, and DAV:write-acl		principal. In this ACE, the owner is granted DAV:read-acl, and
	privileges.		DAV:write-acl 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.foo.org/top/, the parent collection of this resource.		http://www.foo.org/top/, the parent collection of this
			resource.
			Clemm, Hopkins, Sedlar, Whitehead [Page 26]
	6 ACL SEMANTICS		6 ACL SEMANTICS
	The ACL semantics define how multiple ACEs that match the current		The ACL semantics define how multiple ACEs that match the
	user are combined, what are the constraints on how ACEs can be		current user are combined, what are the constraints on how ACEs
	ordered, and which principals must have an ACE.		can be ordered, and which principals must have an ACE.
	<!ELEMENT acl-semantics acl-sem*>		<!ELEMENT acl-semantics acl-sem*>
	<!ELEMENT acl-sem (ace-combination, ace-ordering, required-		<!ELEMENT acl-sem (ace-combination, ace-ordering, allowed-ace,
	principal*)>		required-principal*)>
	6.1 ACE Combination		6.1 ACE Combination
	The DAV:ace-combination element defines how privileges from		The DAV:ace-combination element defines how privileges from
	multiple ACEs that match the current user will be combined to		multiple ACEs that match the current user will be combined to
	determine the access privileges for that user. Multiple ACEs may		determine the access privileges for that user. Multiple ACEs
	match the same user because the same principal can appear in		may match the same user because the same principal can appear
	multiple ACEs, because multiple principals can identify the same		in multiple ACEs, because multiple principals can identify the
	user, and because one principal can be a member of another		same user, and because one principal can be a member of another
	principal.		principal.
	<!ELEMENT ace-combination		<!ELEMENT ace-combination
	Clemm, Hopkins, Sedlar, Whitehead [Page 17]
	(first-match | all-grant-before-any-deny | specific-deny-		(first-match | all-grant-before-any-deny | specific-deny-
	overrides-grant)>		overrides-grant)>
	6.1.1 DAV:first-match ACE Combination		6.1.1 DAV:first-match ACE Combination
	The ACEs are evaluated in the order in which they appear in the		The ACEs are evaluated in the order in which they appear in the
	ACL. If the first ACE that matches the current user does not grant		ACL. If the first ACE that matches the current user does not
	all the privileges needed for the request, the request MUST fail.		grant all the privileges needed for the request, the request
			MUST fail.
	<!ELEMENT first-match EMPTY>		<!ELEMENT first-match EMPTY>
	6.1.2 DAV:all-grant-before-any-deny ACE Combination		6.1.2 DAV:all-grant-before-any-deny ACE Combination
	The ACEs are evaluated in the order in which they appear in the		The ACEs are evaluated in the order in which they appear in the
	ACL. If an evaluated ACE denies a privilege needed for the		ACL. If an evaluated ACE denies a privilege needed for the
	request, the request MUST fail. If all ACEs have been evaluated		request, the request MUST fail. If all ACEs have been
	without the user being granted all privileges needed for the		evaluated without the user being granted all privileges needed
	request, the request MUST fail.		for the request, the request MUST fail.
	<!ELEMENT all-grant-before-any-deny EMPTY>		<!ELEMENT all-grant-before-any-deny EMPTY>
	6.1.3 DAV:specific-deny-overrides-grant ACE Combination		6.1.3 DAV:specific-deny-overrides-grant ACE Combination
	All ACEs in the ACL are evaluated. An "individual ACE" is one		All ACEs in the ACL are evaluated. An "individual ACE" is one
	whose principal identifies the current user. A "group ACE" is one		whose principal identifies the current user. A "group ACE" is
	whose principal is a collection that contains a principal that		one whose principal is a collection that contains a principal
	identifies the current user. A privilege is granted if it is		that identifies the current user. A privilege is granted if it
	granted by an individual ACE and not denied by an individual ACE,		is granted by an individual ACE and not denied by an individual
	or if it is granted by a group ACE and not denied by an individual		ACE, or if it is granted by a group ACE and not denied by an
	or group ACE. A request MUST fail if any of its needed privileges		individual or group ACE. A request MUST fail if any of its
	are not granted.		needed privileges are not granted.
			Clemm, Hopkins, Sedlar, Whitehead [Page 27]
	<!ELEMENT specific-deny-overrides-grant EMPTY>		<!ELEMENT specific-deny-overrides-grant EMPTY>
	6.2 ACE Ordering		6.2 ACE Ordering
	The DAV:ace-ordering element defines a constraint on how the ACEs		The DAV:ace-ordering element defines a constraint on how the
	can be ordered in the ACL.		ACEs can be ordered in the ACL.
	<!ELEMENT ace-ordering (deny-before-grant)? >		<!ELEMENT ace-ordering (deny-before-grant)? >
	6.2.1 DAV:deny-before-grant ACE Ordering		6.2.1 DAV:deny-before-grant ACE Ordering
	This element indicates that all deny ACEs must precede all grant		This element indicates that all deny ACEs must precede all
	ACEs.		grant ACEs.
	<!ELEMENT deny-before-grant EMPTY>		<!ELEMENT deny-before-grant EMPTY>
	6.3 Required Principals		6.3 Allowed ACE
	The required principal elements identify which principals must have		The DAV:allowed-ace XML element specifies constraints on what
	an ACE defined in the ACL.		kinds of ACEs are allowed in an ACL.
			<!ELEMENT allowed-ace (principal-only-one-ace | grant-only)*>
			6.3.1 DAV:principal-only-one-ace ACE Constraint
			This element indicates that a principal can appear in only one
			ACE per resource.
			<!ELEMENT principal-only-one-ace EMPTY>
			6.3.2 DAV:grant-only ACE Constraint
			This element indicates that ACEs with deny clauses are not
			allowed.
			<!ELEMENT grant-only EMPTY>
			6.4 Required Principals
			The required principal elements identify which principals must
			have an ACE defined in the ACL.
	<!ELEMENT required-principal		<!ELEMENT required-principal
	(href | all | authenticated | unauthenticated | property | self)>		(href | all | authenticated | unauthenticated | property |
			self)>
	Clemm, Hopkins, Sedlar, Whitehead [Page 18]		For example, the following element requires that the ACL
	For example, the following element requires that the ACL contain a		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>
			Clemm, Hopkins, Sedlar, Whitehead [Page 28]
	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
	existing methods.		on existing methods.
	7.1 OPTIONS		7.1 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.		request on any resource implemented by that server.
	7.1.1 Example - OPTIONS		7.1.1 Example - OPTIONS
	>> Request <<		>> Request <<
	skipping to change at line 997		skipping to change at line 1561
	>> Response <<		>> Response <<
	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
			When a resource is moved from one location to another due to a
			MOVE request, the non-inherited ACEs in the DAV:acl property of
			the resource MUST NOT be modified, or the MOVE request fails.
			7.3 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 resource creation request (e.g. MKCOL, PUT).
	8 ACCESS CONTROL METHODS		8 ACCESS CONTROL METHODS
	8.1 ACL		8.1 ACL
	The ACL method modifies the DAV:acl property of a resource. A new		The ACL method modifies the access control list (which can be
	DAV:acl value must be written in its entirety, including any		read via the DAV:acl property) of a resource. Specifically,
	inherited ACEs. Unless the DAV:acl property of the resource can be		the ACL method only permits modification to ACEs that are not
	updated to be exactly the value specified in the ACL request, the		inherited, and are not protected. An ACL method invocation
	ACL request MUST fail. If a server restricts the set of ACEs		modifies all non-inherited and non-protected ACEs in a
	visible to the current user via the DAV:acl property, then the ACL		resource's access control list to exactly match the ACEs
	request would only replace the set of ACEs visible to the current		contained within in the DAV:acl XML element (specified in
	user, and would not affect any ACE that was not visible.		Section 5.4) of the request body. An ACL request body MUST
			contain only one DAV:acl XML element. Unless the non-inherited
	In order to avoid overwriting DAV:acl changes by another client, a		Clemm, Hopkins, Sedlar, Whitehead [Page 29]
	client SHOULD acquire a WebDAV lock on the resource before		and non-protected ACEs of the DAV:acl property of the resource
	retrieving the DAV:acl property of a resource that it intends on		can be updated to be exactly the value specified in the ACL
	updating.		request, the ACL request MUST fail.
	Clemm, Hopkins, Sedlar, Whitehead [Page 19]		It is possible that the ACEs visible to the current user in the
	When submitting ACEs, clients MUST NOT include the optional prop		DAV:acl property may only be a portion of the complete set of
	element (a child of the principal element). The purpose of this		ACEs on that resource. If this is the case, an ACL request only
	restriction is to limit the scope of effect of the ACL method to		modifies the set of ACEs visible to the current user, and does
	just the resource identified by the Request-URI; setting the prop		not affect any non-visible ACE.
	element would additionally require property modification for one or
	more principal resources.		In order to avoid overwriting DAV:acl changes by another
			client, a client SHOULD acquire a WebDAV lock on the resource
			before retrieving the DAV:acl property of a resource that it
			intends on updating.
			Implementation Note: Two common operations are to add or
			remove an ACE from an existing access control list. To
			accomplish this, a client uses the PROPFIND method to
			retrieve the value of the DAV:acl property, then parses the
			returned access control list to remove all inherited and
			protected ACEs (these ACEs are tagged with the DAV:inherited
			and DAV:protected XML elements). In the remaining set of non-
			inherited, non-protected ACEs, the client can add or remove
			one or more ACEs before submitting the final ACE set in the
			request body of the ACL method.
	8.1.1 ACL Preconditions		8.1.1 ACL Preconditions
	An implementation MAY enforce one or more of the following		An implementation MAY enforce one or more of the following
	constraints on an ACL request. If the constraint is violated, a		constraints on an ACL request. If the constraint is violated,
	403 (Forbidden) response MUST be returned and the indicated XML		a 403 (Forbidden) response MUST be returned and the indicated
	element MUST be returned in the response body.		XML element MUST be returned as the top level element in an XML
			response body.
	<DAV:protected/>: An implementation MAY protect an ACE from		<DAV:ace-conflict/>: A conflict exists between two or more ACEs
	modification or deletion. For example, some implementations		submitted in the ACL request.
	implicitly grant the DAV:owner of a resource DAV:read-acl and
	DAV:write-acl privileges, and this cannot be changed by a client.		<DAV:protected-ace-conflict/>: A conflict exists between an ACE
			in the ACL request and a protected ACE on the resource. For
			example, if the resource has a protected ACE granting DAV:write
			to a given principal, then it would be a protected ACE conflict
			if the ACL request submitted an ACE denying DAV:write to the
			same principal.
			<DAV:inherited-ace-conflict/>: A conflict exists between an ACE
			in the ACL request and an inherited ACE on the resource. For
			example, if the resource inherits an ACE from its parent
			collection granting DAV:write to a given principal, then it
			would be an inherited ACE conflict if the ACL request submitted
			an ACE denying DAV:write to the same principal. Note that
			reporting of this error will be implementation-dependent.
			Clemm, Hopkins, Sedlar, Whitehead [Page 30]
			Implementations have the choice to either report this error, or
			to allow the ACE to be set, and then let normal ACE evaluation
			rules determine whether the new ACE has any impact on the
			privileges available to a specific principal.
	<DAV:too-many-aces/>: An implementation MAY limit the number of		<DAV:too-many-aces/>: An implementation MAY limit the number of
	ACEs in an ACL. However, ACL-compliant servers MUST support at		ACEs in an ACL. However, ACL-compliant servers MUST support at
	least one ACE granting privileges to a single principal, and one		least one ACE granting privileges to a single principal, and
	ACE granting privileges to a collection principal.		one ACE granting privileges to a collection principal.
	<DAV:non-inherited-must-precede-inherited/>: All non-inherited ACEs
	MUST precede all inherited ACEs.
	<DAV:deny-must-precede-grant/>: All non-inherited deny ACEs MUST		<DAV:deny-before-grant/>: All non-inherited deny ACEs MUST
	precede all non-inherited grant ACEs.		precede all non-inherited grant ACEs.
	If the following precondition is not met, the server MUST return a		<DAV:principal-only-one-ace/>: For implementations that have
	409 (Conflict) response, and the indicated XML element MUST be		the DAV:principal-only-one-ace constraint (defined in Section
	returned in the response body:		6.3.1), this XML element indicates that fulfilling the ACL
			request would result in multiple ACEs for one or more
			principals.
	<DAV:inhereted-exist-parent>: Inherited ACEs MUST exist on a parent		<DAV:grant-only/>: For implementations that have the DAV:grant-
	resource.		only constraint (defined in Section 6.3.2), this XML element
			indicates the request contained one or more deny ACEs.
			<DAV:required-principal>: One or more required principals (see
			Section 6.4) would not be present in the access control list
			after processing the ACL request. The DAV:required-principal
			XML element MUST contain a list of the missing principal(s),
			following the syntax specified in Section 6.4.
	8.1.2 Example: the ACL method		8.1.2 Example: 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.foo.org/users/esedlar (i.e., the		identified by the URL http://www.foo.org/users/esedlar (i.e.,
	user "esedlar") read and write privileges, grants the owner of the		the user "esedlar") read and write privileges, grants the owner
	resource read-acl and write-acl privileges, and grants everyone		of the resource read-acl and write-acl privileges, and grants
	read privileges inherited from the parent collection		everyone read privileges.
	http://www.foo.bar/top/.
	>> Request <<		>> Request <<
	ACL /top/container/ HTTP/1.1		ACL /top/container/ HTTP/1.1
	Host: www.foo.org		Host: www.foo.org
	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="...",
	Clemm, Hopkins, Sedlar, Whitehead [Page 20]
	uri="/top/container/", response="...", opaque="..."		uri="/top/container/", 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>
			Clemm, Hopkins, Sedlar, Whitehead [Page 31]
	<D:principal>		<D:principal>
	<D:href>http://www.foo.org/users/esedlar</D:href>		<D:href>http://www.foo.org/users/esedlar</D:href>
	</D:principal>		</D:principal>
	<D:grant>		<D:grant>
	<D:privilege> <D:read/> </D:privilege>		<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: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:inherited>		</D:grant>
	<D:href>http://www.foo.org/top/</D:href> </D:inherited>
	</D:ace> </D:acl>		</D:ace> </D:acl>
	>> Response <<		>> Response <<
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	8.1.3 Example: ACL method failure due to omission of protected ACE		8.1.3 Example: 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 grant the		information in the Authorization header, attempts to deny the
	principal identified by the URL http://www.foo.org/users/esedlar		principal identified by the URL
	(i.e., the user "esedlar") read privileges. Prior to the request,		http://www.foo.org/users/esedlar (i.e., the user "esedlar")
	the DAV:acl property on the resource contained a protected ACE (see		write privileges. Prior to the request, the DAV:acl property on
	Section 5.4.3) granting DAV:owner the DAV:read-acl and DAV:write-		the resource contained a protected ACE (see Section 5.4.3)
	acl privileges. The ACL method invocation fails because this		granting DAV:owner the DAV:read and DAV:write privileges. The
	protected ACE is omitted, thus violating the semantics of ACE		principal identified by URL http://www.foo.org/users/esedlar is
	protection..		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.foo.org		Host: www.foo.org
	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="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	Clemm, Hopkins, Sedlar, Whitehead [Page 21]		Clemm, Hopkins, Sedlar, Whitehead [Page 32]
	<D:acl xmlns:D="DAV:">		<D:acl xmlns:D="DAV:">
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.foo.org/users/esedlar</D:href>		<D:href>http://www.foo.org/users/esedlar</D:href>
	</D:principal>		</D:principal>
	<D:grant>		<D:deny>
	<D:privilege> <D:read/> </D:privilege> </D:grant>		<D:privilege> <D:write/> </D:privilege>
			</D:deny>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
	>> Response <<		>> Response <<
	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" ?>
	<DAV:protected/>		<DAV:protected-ace-conflict/>
	8.1.4 Example: ACL method failure due to inherited ACEs preceding non-		8.1.4 Example: ACL method failure due to an inherited ACE conflict
	inherited ACEs
	In the following request, user "ejw", authenticated by information		In the following request, user "ejw", authenticated by
	in the Authorization header, tries to change the access control		information in the Authorization header, tries to change the
	list on the resource http://www.foo.org/top/index.html. This		access control list on the resource
	resource has two inherited ACEs.		http://www.foo.org/top/index.html. This 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.foo.org/users/ejw (i.e., the user "ejw")		http://www.foo.org/users/ejw (i.e., the user "ejw")
	http://www.foo.org/privs/write-all and DAV:read-acl privileges. On		http://www.foo.org/privs/write-all and DAV:read-acl privileges.
	this server, http://www.foo.org/privs/write-all is an aggregate		On this server, http://www.foo.org/privs/write-all is an
	privilege containing DAV:write, and DAV:write-acl.		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.
	The request attempts to add a third ACE, granting the principal		The request attempts to set a (non-inherited) ACE, denying the
	identified by the URL http://www.foo.org/users/gclemm (i.e., the		principal identified by the URL http://www.foo.org/users/ejw
	user ôgclemmö) DAV:write permission, but in the request places the		(i.e., the user ôejwö) DAV:write permission. This conflicts
	inherited ACEs before the non-inherited ACEs, causing an error on		with inherited ACE #1. Note that the decision to report an
	this specific server implementation. Note that on a different		inherited ACE conflict is specific to this server
	implementation, this request might be accepted.		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.foo.org		Host: www.foo.org
	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",
			Clemm, Hopkins, Sedlar, Whitehead [Page 33]
	realm="users@foo.org", nonce="...",		realm="users@foo.org", nonce="...",
	uri="/top/index.html", response="...", opaque="..."		uri="/top/index.html", response="...", opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:acl xmlns:D="DAV:" xmlns:F="http://www.foo.org/privs/">		<D:acl xmlns:D="DAV:" xmlns:F="http://www.foo.org/privs/">
	Clemm, Hopkins, Sedlar, Whitehead [Page 22]
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.foo.org/users/ejw</D:href>		<D:href>http://www.foo.org/users/ejw</D:href>
	</D:principal>		</D:principal>
	<D:grant>
	<D:privilege><F:write-all/></D:privilege>
	<D:privilege><D:read-acl/></D:privilege>
	</D:grant>
	<D:inherited/>
	</D:ace>
	<D:ace>
	<D:principal><D:all/></D:principal>
	<D:grant><D:read/></D:grant>
	<D:inherited/>
	</D:ace>
	<D:ace>
	<D:principal>
	<D:href>http://www.foo.org/users/gclemm</D:href>
	</D:principal>
	<D:grant><D:write/></D:grant>		<D:grant><D:write/></D:grant>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
	>> Response <<		>> Response <<
	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" ?>
	<DAV:non-inherited-must-precede-inherited/>		<DAV:inherited-ace-conflict/>
	8.1.5 Example: ACL method failure due to an attempt to set grant and deny		8.1.5 Example: ACL method failure due to an attempt to set grant and
	in a single ACE.		deny in a single ACE.
	In this example, user "ygoland", authenticated by information in		In this example, user "ygoland", authenticated by information
	the Authorization header, tries to change the access control list		in the Authorization header, tries to change the access control
	on the resource http://www.foo.org/diamond/engagement-ring.gif. The		list on the resource http://www.foo.org/diamond/engagement-
	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 collection principal		semantically incorrect ACE, which attempts to grant the
	identified by the URL http://www.foo.org/users/friends/ DAV:read		collection principal identified by the URL
	privilege and deny the principal identified by URL		http://www.foo.org/users/friends/ DAV:read privilege and deny
	http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-so")		the principal identified by URL
	DAV:read privilege. However, it is illegal to have multiple		http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-
	principal elements, as well as both a grant and deny element in the		so") DAV:read privilege. However, it is illegal to have
	same ACE, so the request fails due to poor syntax.		multiple principal elements, as well as both a grant and deny
			element in the same ACE, so the request fails due to poor
			syntax.
	>> Request <<		>> Request <<
	ACL /diamond/engagement-ring.gif HTTP/1.1		ACL /diamond/engagement-ring.gif HTTP/1.1
	Host: www.foo.org		Host: www.foo.org
	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",
	Clemm, Hopkins, Sedlar, Whitehead [Page 23]
	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>
			Clemm, Hopkins, Sedlar, Whitehead [Page 34]
	<D:href>http://www.foo.org/users/friends/</D:href>		<D:href>http://www.foo.org/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.foo.org/users/ygoland-so</D:href>		<D:href>http://www.foo.org/users/ygoland-so</D:href>
	</D:principal>		</D:principal>
	<D:deny><D:read/></D:deny>		<D:deny><D:read/></D:deny>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
	>> Response <<		>> Response <<
	HTTP/1.1 400 Bad Request		HTTP/1.1 400 Bad Request
	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
	well formed.		syntactically well formed.
	9 INTERNATIONALIZATION CONSIDERATIONS		9 ACCESS CONTROL REPORTS
	In this specification, the only human-readable content can be found		9.1 REPORT Method
	in the description XML element, found within the DAV:supported-
	privilege-set property. This element contains a human-readable
	description of the capabilities controlled by a privilege. As a
	result, the description element must be capable of representing
	descriptions in multiple character sets. Since the description
	element is found within a WebDAV property, it is represented on-
	the-wire as XML [REC-XML], and hence can leverage XML's language
	tagging and character set encoding capabilities. Specifically, XML
	processors must, at minimum, be able to read XML elements encoded
	using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual
	plane. XML examples in this specification demonstrate use of the
	charset parameter of the Content-Type header, as defined in
	[RFC3023], as well as the XML "encoding" attribute, which together
	provide charset identification information for MIME and XML
	processors.
	For XML elements other than the description element, it is expected		A REPORT request is an extensible mechanism for obtaining
	that implementations will treat the property names, privilege		information about a resource. Unlike a resource property,
	names, and values as tokens, and convert these tokens into human-		which has a single value, the value of a report can depend on
	readable text in the user's language and character set when		additional information specified in the REPORT request body and
	displayed to a person. Only a generic WebDAV property display		in the REPORT request headers.
	utility would display these values in their raw form to a human
	user.
	Clemm, Hopkins, Sedlar, Whitehead [Page 24]		Marshalling:
	For error reporting, we follow the convention of HTTP/1.1 status
	codes, including with each status code a short, English description
	of the code (e.g., 200 (OK)). While the possibility 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		The body of a REPORT request specifies which report is being
	described in the WebDAV Distributed Authoring protocol		requested, as well as any additional information that will be
			used to customize the report.
			The request MAY include a Depth header.
			The response body for a successful request MUST contain the
			requested report.
			If a Depth request header is included, the response MUST be a
			207 Multi-Status.
			Postconditions:
			The REPORT method MUST NOT change the content or dead
			properties of any resource.
			If a Depth request header is included, the request MUST be
			applied separately to the collection itself and to all members
			of the collection that satisfy the Depth value. The DAV:prop
			element of a DAV:response for a given resource MUST contain the
			requested report for that resource.
			Clemm, Hopkins, Sedlar, Whitehead [Page 35]
			9.2 DAV:acl-principal-props Report
			The DAV:acl-principle-props report returns, for all principals
			in the DAV:acl property that are identified by http(s) URLs,
			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-props report MUST return the properties
			for that principal only once.
			Marshalling
			The request body MUST be a DAV:acl-principal-props XML element.
			<!ELEMENT acl-principal-props ANY>
			ANY value: a sequence of one or more elements, with at most one
			DAV:prop element.
			prop: see RFC 2518, Section 12.11
			The response body for a successful request MUST be a
			DAV:multistatus XML element (i.e., the response uses the same
			format as the response for PROPFIND).
			multistatus: see RFC 2518, Section 12.9
			The response body for a successful DAV:acl-principal-props
			REPORT request MUST contain a DAV:response element for each
			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 identified by the Request-URI.
			9.2.1 Example: DAV:acl-principal-props Report
			Resource http;//www.webdav.org/index.html has an ACL with three
			ACEs:
			ACE #1: All principals (DAV:all) have DAV:read and DAV:read-
			current-user-privilege-set access.
			ACE #2: The principal identified by
			http://www.webdav.org/people/gstein (the user ôgsteinö) is
			granted DAV:write, DAV:write-acl, DAV:read-acl privileges.
			ACE #3: The collection principal identified by
			http://www.webdav.org/groups/authors/ (the ôauthorsö group) is
			granted DAV:write and DAV:read-acl privileges.
			The following example shows a DAV:acl-principal-props report
			requesting the DAV:displayname property. It returns the value
			of DAV:displayname for resources
			http://www.webdav.org/people/gstein and
			http://www.webdav.org/groups/authors/ , but not for DAV:all,
			since this is not an http(s) URL.
			Clemm, Hopkins, Sedlar, Whitehead [Page 36]
			>> Request <<
			REPORT /index.html HTTP/1.1
			Host: www.webdav.org
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:acl-principal-props xmlns:D="DAV:">
			<D:prop>
			<D:displayname/>
			</D:prop>
			</D:acl-principal-props>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/people/gstein</D:href>
			<D:propstat>
			<D:prop>
			<D:displayname>Greg Stein</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
			</D:propstat>
			</D:response>
			<D:response>
			<D:href>http://www.webdav.org/groups/authors/</D:href>
			<D:propstat>
			<D:prop>
			<D:displayname>Site authors</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
			</D:propstat>
			</D:response>
			</D:multistatus>
			9.3 DAV:principal-match REPORT
			The DAV:principal-match REPORT is used to identify all members
			of a collection that match the current user. In particular, if
			the collection contains principals, the report can be used to
			identify all members of the collection that match the current
			user. Alternatively, if the collection contains resources that
			have a property that identifies a principal (e.g. DAV:owner),
			then the report can be used to identify all members of the
			collection whose property identifies a principal that matches
			the current user. For example, this report can return all of
			Clemm, Hopkins, Sedlar, Whitehead [Page 37]
			the resources in a collection hierarchy that are owned by the
			current user.
			Marshalling:
			The request body MUST be a DAV:principal-match XML element.
			<!ELEMENT principal-match ((principal-property | self), prop?)>
			<!ELEMENT principal-property ANY>
			ANY value: an element whose value identifies a property. The
			expectation is the value of the named property typically
			contains an href element that contains the URI of a principal
			<!ELEMENT self EMPTY>
			prop: see RFC 2518, Section 12.11
			The response body for a successful request MUST be a
			DAV:multistatus XML element.
			multistatus: see RFC 2518, Section 12.9
			The response body for a successful DAV:principal-match REPORT
			request MUST contain a DAV:response element for each member of
			the collection that matches the current user. When the
			DAV:principal-property element is used, a match occurs if the
			current user is the same as the principal identified by the URI
			found in the DAV:href element of the property identified by the
			DAV:principal-property element. When the DAV:self element is
			used in a DAV:principal-match report issued against a
			collection principal, it matches a child of the collection
			principal if that child (a principal resource) identifies the
			same principal as the current user.
			If DAV:prop is specified in the request body, the properties
			specified in the DAV:prop element MUST be reported in the
			DAV:response elements.
			9.3.1 Example: DAV:principal-match REPORT
			The following example identifies the members of the collection
			identified by the URL http://www.webdav.org/doc/ that are owned
			by the current user. The current user (ôgclemmö) is
			authenticated using Digest authentication.
			>> Request <<
			REPORT /doc/ HTTP/1.1
			Host: www.webdav.org
			Authorization: Digest username="gclemm",
			realm="gclemm@webdav.org", nonce="...",
			uri="/papers/", response="...", opaque="..."
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			Clemm, Hopkins, Sedlar, Whitehead [Page 38]
			<?xml version="1.0" encoding="utf-8" ?>
			<D:principal-match xmlns:D="DAV:">
			<D:principal-property>
			<D:owner/>
			</D:principal-property>
			</D:principal-match>
			>> Response <<
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml; charset="utf-8"
			Content-Length: xxxx
			<?xml version="1.0" encoding="utf-8" ?>
			<D:multistatus xmlns:D="DAV:">
			<D:response>
			<D:href>http://www.webdav.org/doc/foo.html</D:href>
			<D:status>HTTP/1.1 200 OK</D:status>
			</D:response>
			<D:response>
			<D:href>http://www.webdav.org/doc/img/bar.gif</D:href>
			<D:status>HTTP/1.1 200 OK</D:status>
			</D:response>
			</D:multistatus>
			10 XML PROCESSING
			Implementations of this specification MUST support the XML
			element ignore rule, as specified in Section 23.3.2 of
			[RFC2518], and the WebDAV XML Namespace interpretation
			convention, described in Section 23.4 of [RFC2518].
			11 INTERNATIONALIZATION CONSIDERATIONS
			In this specification, the only human-readable content can be
			found in the description XML element, found within the
			DAV:supported-privilege-set property. This element contains a
			human-readable description of the capabilities controlled by a
			privilege. As a result, the description element must be
			capable of representing descriptions in multiple character
			sets. Since the description element is found within a WebDAV
			property, it is represented on-the-wire as XML [REC-XML], and
			hence can leverage XML's language tagging and character set
			encoding capabilities. Specifically, XML processors must, at
			minimum, be able to read XML elements encoded using the UTF-8
			[UTF-8] encoding of the ISO 10646 multilingual plane. XML
			examples in this specification demonstrate use of the charset
			parameter of the Content-Type header, as defined in [RFC3023],
			as well as the XML "encoding" attribute, which together provide
			charset identification information for MIME and XML processors.
			For XML elements other than the description element, it is
			expected that implementations will treat the property names,
			privilege names, and values as tokens, and convert these tokens
			Clemm, Hopkins, Sedlar, Whitehead [Page 39]
			into human-readable text in the user's language and character
			set when displayed to a person. Only a generic WebDAV property
			display utility would display these values in their raw form to
			a human user.
			For error reporting, we follow the convention of HTTP/1.1
			status codes, including with each status code a short, English
			description of the code (e.g., 200 (OK)). While the
			possibility 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 described in the WebDAV Distributed Authoring protocol
	specification [RFC2518].		specification [RFC2518].
	10 SECURITY CONSIDERATIONS		12 SECURITY CONSIDERATIONS
	Applications and users of this access control protocol should be		Applications and users of this access control protocol should
	aware of several security considerations, detailed below. In		be 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
	the WebDAV Distributed Authoring Protocol specification [RFC2518],		[RFC2616], the WebDAV Distributed Authoring Protocol
	and the XML Media Types specification [RFC3023] should be		specification [RFC2518], and the XML Media Types specification
	considered in a security analysis of this protocol.		[RFC3023] should be considered in a security analysis of this
			protocol.
	10.1 Increased Risk of Compromised Users		12.1 Increased 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
	compromised, only those resources for which the user has access		are compromised, only those resources for which the user has
	permission can be read, modified, moved, or deleted. With the		access permission can be read, modified, moved, or deleted.
	introduction of this access control protocol, if a single		With the introduction of this access control protocol, if a
	compromised user has the ability to change ACLs for a broad range		single compromised user has the ability to change ACLs for a
	of other users (e.g., a super-user), the number of resources that		broad range of other users (e.g., a super-user), the number of
	could be altered by a single compromised user increases. This risk		resources that could be altered by a single compromised user
	can be mitigated by limiting the number of people who have write-		increases. This risk can be mitigated by limiting the number of
	acl privileges across a broad range of resources.		people who have write-acl privileges across a broad range of
			resources.
	10.2 Risks of the read-acl and cuprivset 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
	property), or the privileges permitted the currently authenticated		DAV:acl property), or the privileges permitted the currently
	user (stored in the DAV:current-user-privilege-set property) on a		authenticated user (stored in the DAV:current-user-privilege-
	resource may seem innocuous, since reading an ACL cannot possibly		set property) on a resource may seem innocuous, since reading
	affect the resource's state. However, if all resources have world-		an ACL cannot possibly affect the resource's state. However, if
	readable ACLs, it is possible to perform an exhaustive search for		all resources have world-readable ACLs, it is possible to
	those resources that have inadvertently left themselves in a		perform an exhaustive search for those resources that have
	vulnerable state, such as being world-writeable. In particular, the		inadvertently left themselves in a vulnerable state, such as
	property retrieval method PROPFIND, executed with Depth infinity on		being world-writeable. In particular, the property retrieval
	an entire hierarchy, is a very efficient way to retrieve the
	DAV:acl or DAV:current-user-privilege-set properties. Once found,
	this vulnerability can be exploited by a denial of service attack
	in which the open resource is repeatedly overwritten. Alternately,
	writeable resources can be modified in undesirable ways.
	To reduce this risk, read-acl privileges should not be granted to		Clemm, Hopkins, Sedlar, Whitehead [Page 40]
	unauthenticated principals, and restrictions on read-acl and		method PROPFIND, executed with Depth infinity on an entire
			hierarchy, is a very efficient way to retrieve the DAV:acl or
			DAV:current-user-privilege-set properties. Once found, this
			vulnerability can be exploited by a denial of service attack in
			which the open resource is repeatedly overwritten. Alternately,
			writeable resources can be modified in undesirable ways.
	Clemm, Hopkins, Sedlar, Whitehead [Page 25]		To reduce this risk, read-acl privileges should not be granted
			to unauthenticated principals, and restrictions on read-acl and
	cuprivset privileges for authenticated principals should be		cuprivset privileges for authenticated principals should be
	carefully analyzed when deploying this protocol. Access to the		carefully analyzed when deploying this protocol. Access to the
	current-user-privilege-set property will involve a tradeoff of		current-user-privilege-set property will involve a tradeoff of
	usability versus security. When the current-user-privilege-set is		usability versus security. When the current-user-privilege-set
	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
	exploited. Deployment of this protocol will need to evaluate this		be exploited. Deployment of this protocol will need to evaluate
	tradeoff in light of the requirements of the deployment		this tradeoff in light of the requirements of the deployment
	environment.		environment.
	11 AUTHENTICATION		12.3 No Foreknowledge of Initial ACL
			In an effort to reduce protocol complexity, this protocol
			specification intentionally does not address the issue of how
			to 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 create a new resource, then retrieve the
			value of the DAV:acl property. This assumes the principal
			creating the resource also has been granted the DAV:read-acl
			privilege.
			As a result, it is possible that a principal could create a
			resource, and then discover that its ACL grants privileges that
			are undesirable. Furthermore, this protocol makes it possible
			(though unlikely) that the creating principal could be unable
			to modify the ACL, or even delete the resource. Even when the
			ACL can be modified, there will be a short period of time when
			the resource exists with the initial ACL before its new ACL can
			be set.
			Several factors mitigate this risk. Human principals are often
			aware of the default access permissions in their editing
			environments and take this into account when writing
			information. Furthermore, default privilege policies are
			usually very conservative, limiting the privileges granted by
			the initial ACL.
			13 AUTHENTICATION
	Authentication mechanisms defined in WebDAV also apply to this		Authentication mechanisms defined in WebDAV also apply to this
	WebDAV Access Control Protocol, in particular the Basic and Digest		WebDAV Access Control Protocol, in particular the Basic and
	authentication mechanisms defined in [RFC2617].		Digest authentication mechanisms defined in [RFC2617].
	12 IANA CONSIDERATIONS		Clemm, Hopkins, Sedlar, Whitehead [Page 41]
			14 IANA CONSIDERATIONS
	This document uses the namespace defined by [RFC2518] for XML		This document uses the namespace defined by [RFC2518] for XML
	elements. All other IANA considerations mentioned in [RFC2518]		elements. All other IANA considerations mentioned in [RFC2518]
	also applicable to WebDAV ACL.		also applicable to WebDAV ACL.
	13 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
	intellectual property or other rights that might be claimed to
	pertain to the implementation or use other technology described in
	this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on
	the IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances
	of licenses to be made available, or the result of an attempt made
	to obtain a general license or permission for the use of such
	proprietary rights by implementers or users of this specification
	can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF takes no position regarding the validity or scope of
	copyrights, patents or patent applications, or other proprietary		any intellectual property or other rights that might be claimed
	rights that may cover technology that may be required to practice		to pertain to the implementation or use other technology
	this standard. Please address the information to the IETF		described in this document or the extent to which any license
	Executive Director.		under such rights might or might not be available; neither does
			it represent that it has made any effort to identify any such
			rights. Information on the IETF's procedures with respect to
			rights in standards-track and standards-related documentation
			can be found in BCP-11. Copies of claims of rights made
			available for publication and any assurances of licenses to be
			made available, or the result of an attempt made to obtain a
			general license or permission for the use of such proprietary
			rights by implementers or users of this specification can be
			obtained from the IETF Secretariat.
	14 ACKNOWLEDGEMENTS		The IETF invites any interested party to bring to its attention
			any copyrights, patents or patent applications, or other
			proprietary rights that may cover technology that may be
			required to practice this standard. Please address the
			information to the IETF Executive Director.
	This protocol is the collaborative product of the WebDAV ACL design		16 ACKNOWLEDGEMENTS
	team: Bernard Chester, Geoff Clemm (Rational), Anne Hopkins
	Clemm, Hopkins, Sedlar, Whitehead [Page 26]		This protocol is the collaborative product of the WebDAV ACL
	(Microsoft), Barry Lind (Xythos), Sean Lyndersay (Microsoft), Eric		design team: Bernard Chester, Geoff Clemm, Anne Hopkins, Barry
	Sedlar (Oracle), Greg Stein (Apache.org), and Jim Whitehead (UC		Lind, Sean Lyndersay, Eric Sedlar, Greg Stein, and Jim
	Santa Cruz). The authors are grateful for the detailed review and		Whitehead. The authors are grateful for the detailed review and
	comments provided by Jim Amsden, Gino Basso, Murthy Chintalapati,		comments provided by Jim Amsden, Gino Basso, Murthy
	Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris Knight, and Remy		Chintalapati, Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris
	Maucherat. Prior work on WebDAV access control protocols has been		Knight, Remy Maucherat, Larry Masinter, Yaron Goland, Lisa
	performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard		Dusseault, and Joe Orton. Prior work on WebDAV access control
	Palmer, and Jon Radoff. We would like to acknowledge the foundation		protocols has been performed by Yaron Goland, Paul Leach, Lisa
	laid for us by the authors of the WebDAV and HTTP protocols upon		Dusseault, Howard Palmer, and Jon Radoff. We would like to
	which this protocol is layered, and the invaluable feedback from		acknowledge the foundation laid for us by the authors of the
	the WebDAV working group.		WebDAV and HTTP protocols upon which this protocol is layered,
			and the invaluable feedback from the WebDAV working group.
	15 REFERENCES		Clemm, Hopkins, Sedlar, Whitehead [Page 42]
			17 REFERENCES
	15.1 Normative References		17.1 Normative 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, Harvard, March, 1997.		Requirement Levels." RFC 2119, BCP 14, Harvard, 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
	REC-xml-19980210. http://www.w3.org/TR/REC-xml-19980210.		Recommendation REC-xml-19980210. http://www.w3.org/TR/REC-xml-
			19980210.
	[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. U.C.Irvine, Compaq, Xerox,		Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, Xerox,
	Microsoft, MIT/LCS, June, 1999.		Microsoft, MIT/LCS, June, 1999.
	[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.		[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S.
	Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and		Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP
	Digest Access Authentication. " RFC 2617. Northwestern University,		Authentication: Basic and Digest Access Authentication." RFC
	Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market,		2617. Northwestern University, Verisign, AbiSource, Agranat,
	June, 1999.		Microsoft, Netscape, Open Market, June, 1999.
	[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."
	2518. Microsoft, U.C.Irvine, Netscape, Novell, February, 1999.		RFC 2518. Microsoft, U.C. Irvine, Netscape, Novell, 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. Internet Mail Consortium, Xerox, Netscape, July,		scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape,
	1998.		July, 1998.
	[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.
	[RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types." RFC		[RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types."
	3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon		RFC 3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon
	Ventures, January, 2001.		Ventures, January, 2001.
	[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and		[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
	ISO 10646." RFC 2279. Alis Technologies. January, 1998.		and ISO 10646." RFC 2279. Alis Technologies. January, 1998.
	Clemm, Hopkins, Sedlar, Whitehead [Page 27]
	15.2 Informational References		17.2 Informational 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.
	16 AUTHORS' ADDRESSES		18 AUTHORS' ADDRESSES
	Geoffrey Clemm		Geoffrey Clemm
	Rational Software		Rational Software
	20 Maguire Road		20 Maguire Road
	Lexington, MA 02421		Lexington, MA 02421
	Email: geoffrey.clemm@rational.com		Email: geoffrey.clemm@rational.com
			Clemm, Hopkins, Sedlar, Whitehead [Page 43]
	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: esedlar@us.oracle.com		Email: esedlar@us.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
	17 APPENDICIES		19 APPENDICIES
	17.1 XML Document Type Definition		19.1 XML Document Type Definition
	<!-- Privileges -->		<!-- Privileges -->
	<!ELEMENT read EMPTY>		<!ELEMENT read EMPTY>
	<!ELEMENT write EMPTY>		<!ELEMENT write EMPTY>
	<!ELEMENT read-acl EMPTY>		<!ELEMENT read-acl EMPTY>
	<!ELEMENT read-cuprivset EMPTY>		<!ELEMENT read-current-user-privilege-set EMPTY>
	<!ELEMENT write-acl EMPTY>		<!ELEMENT write-acl EMPTY>
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
	<!-- Principal Properties (Section 4) -->		<!-- Principal Properties (Section 4) -->
	<!ELEMENT is-principal (#PCDATA)>		<!ELEMENT is-principal (#PCDATA)>
	<!ELEMENT alternate-URL (href*)>		<!ELEMENT alternate-URL (href*)>
	Clemm, Hopkins, Sedlar, Whitehead [Page 28]
	<!-- Access Control Properties (Section 5) -->		<!-- Access Control Properties (Section 5) -->
	<!-- DAV:owner Property (Section 5.1) -->		<!-- DAV:owner Property (Section 5.1) -->
	<!ELEMENT owner (href prop?)>		<!ELEMENT owner (href prop?)>
	<!ELEMENT prop (see [RFC2518], section 12.11)>		<!ELEMENT prop (see [RFC2518], section 12.11)>
	<!-- DAV:supported-privilege-set Property (Section 5.2) -->		<!-- DAV:supported-privilege-set Property (Section 5.2) -->
	<!ELEMENT supported-privilege-set (supported-privilege*)>		<!ELEMENT supported-privilege-set (supported-privilege*)>
	<!ELEMENT supported-privilege		<!ELEMENT supported-privilege
	(privilege, abstract?, description, supported-privilege*)>		(privilege, abstract?, description, supported-privilege*)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 44]
	<!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) -->
	<!ELEMENT current-user-privilege-set (privilege*)>		<!ELEMENT current-user-privilege-set (privilege*)>
	<!-- DAV:acl Property (Section 5.4) -->		<!-- DAV:acl Property (Section 5.4) -->
	<!ELEMENT acl (ace*)>		<!ELEMENT acl (ace*)>
	<!ELEMENT ace (principal, (grant|deny), protected?, inherited?)>		<!ELEMENT ace (principal, (grant|deny), protected?,
			inherited?)>
	<!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>
	<!ELEMENT property ANY>		<!ELEMENT property ANY>
	<!ELEMENT self EMPTY>		<!ELEMENT self EMPTY>
	skipping to change at line 1563		skipping to change at line 2442
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	<!ELEMENT protected EMPTY>		<!ELEMENT protected EMPTY>
	<!ELEMENT inherited (href)>		<!ELEMENT inherited (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*)>
	Clemm, Hopkins, Sedlar, Whitehead [Page 29]
	<!-- DAV:acl-semantics Property (Section 6) -->		<!-- DAV:acl-semantics Property (Section 6) -->
	<!ELEMENT acl-semantics acl-sem*>		<!ELEMENT acl-semantics acl-sem*>
	<!ELEMENT acl-sem (ace-combination, ace-ordering, required-		<!ELEMENT acl-sem (ace-combination, ace-ordering, allowed-ace,
	principal*)>		required-principal*)>
	<!ELEMENT ace-combination		<!ELEMENT ace-combination
	(first-match | all-grant-before-any-deny | specific-deny-		(first-match | all-grant-before-any-deny | specific-deny-
	overrides-grant)>		overrides-grant)>
	<!ELEMENT first-match EMPTY>		<!ELEMENT first-match EMPTY>
	<!ELEMENT all-grant-before-any-deny EMPTY>		<!ELEMENT all-grant-before-any-deny EMPTY>
			Clemm, Hopkins, Sedlar, Whitehead [Page 45]
	<!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>
			<!ELEMENT allowed-ace (principal-only-one-ace | grant-only)*>
			<!ELEMENT principal-only-one-ace EMPTY>
			<!ELEMENT grant-only EMPTY>
	<!ELEMENT required-principal		<!ELEMENT required-principal
	(href | all | authenticated | unauthenticated | property | self)>		(href | all | authenticated | unauthenticated | property |
			self)>
	<!-- ACL method preconditions (Section 8.1.1) -->		<!-- ACL method preconditions (Section 8.1.1) -->
	<!ELEMENT protected EMPTY>		<!ELEMENT ace-conflict EMPTY>
			<!ELEMENT protected-ace-conflict EMPTY>
			<!ELEMENT inherited-ace-conflict EMPTY>
	<!ELEMENT too-many-aces EMPTY>		<!ELEMENT too-many-aces EMPTY>
	<!ELEMENT non-inherited-must-precede-inherited EMPTY>
	<!ELEMENT deny-must-precede-grant EMPTY>
	<!ELEMENT acl-requires-lock-token EMPTY>
	<!ELEMENT inherited-exist-parent EMPTY>
	Clemm, Hopkins, Sedlar, Whitehead [Page 30]		<!-- REPORT Method -->
			<!ELEMENT acl-principal-props ANY>
			ANY value: a sequence of one or more elements, with at most one
			DAV:prop element.
			<!ELEMENT principal-match ((principal-property | self), prop?)>
			<!ELEMENT principal-property ANY>
			ANY value: an element whose value identifies a property. The
			expectation is the value of the named property typically
			contains an href element that contains the URI of a principal
			<!ELEMENT self EMPTY>
			20 NOTE TO RFC EDITOR
			*** This section (Section 20) MUST be removed before
			publication as an RFC ***
			Section 9.1 defines the REPORT method. The REPORT method is
			also defined in draft-ietf-deltav-versioning-15, in Section
			3.6, using identical text. This was done to avoid making this
			specification dependent on draft-ietf-deltav-versioning.
			If draft-ietf-deltav-versioning is published as an RFC before
			this specification, Section 9.1 MUST be removed.
			Clemm, Hopkins, Sedlar, Whitehead [Page 46]
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/