draft-ietf-webdav-acl-04.txt		draft-ietf-webdav-acl-05.txt
	INTERNET-DRAFT Geoffrey Clemm, Rational Software		INTERNET-DRAFT Geoffrey Clemm, Rational Software
	draft-ietf-webdav-acl-04 Anne Hopkins, Microsoft Corporation		draft-ietf-webdav-acl-05 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 January 21, 2001		Expires July 21, 2001 April 23, 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 all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering Task
	Task Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other groups
	groups may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference material		time. It is inappropriate to use Internet- Drafts as reference material
	or to cite them other than as "work in progress."		or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	skipping to change at page 27, line ?		skipping to change at line 43
	This document specifies a set of methods, headers, and message bodies		This document specifies a set of methods, headers, and message bodies
	that define the WebDAV Access Control extensions to the HTTP/1.1		that define the WebDAV Access Control extensions to the HTTP/1.1
	protocol. This protocol permits a client to remotely read and modify		protocol. This protocol permits a client to remotely read and modify
	access control lists that instruct a server whether to grant or deny		access control lists that instruct a server whether to grant or deny
	operations upon a resource (such as HTTP method invocations) by a given		operations upon a resource (such as HTTP method invocations) by a given
	principal.		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 to
	the acl@webdav.org mailing list. Other related documents can be found		the acl@webdav.org mailing list. Other related documents can be found at
	at http://www.webdav.org/acl/, and		http://www.webdav.org/acl/, and http://www.ics.uci.edu/pub/ietf/webdav/.
	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......................................................3		1 INTRODUCTION......................................................4
	1.1 Terms..........................................................4		1.1 Terms...........................................................5
	1.2 Notational Conventions.........................................5		1.2 Notational Conventions..........................................6
	2 PRINCIPALS........................................................5		2 PRINCIPALS........................................................6
	3 PRIVILEGES........................................................5		3 PRIVILEGES........................................................6
	3.1 DAV:read Privilege.............................................6		3.1 DAV:read Privilege..............................................7
	3.2 DAV:write Privilege............................................6		3.2 DAV:write Privilege.............................................7
	3.3 DAV:read-acl Privilege.........................................7		3.3 DAV:read-acl Privilege..........................................8
	3.4 DAV:write-acl Privilege........................................7		3.4 DAV:read-cuprivset Privilege....................................8
	3.5 DAV:all Privilege..............................................7		3.5 DAV:write-acl Privilege.........................................8
			3.6 DAV:all Privilege...............................................8
	4 PRINCIPAL PROPERTIES..............................................7		4 PRINCIPAL PROPERTIES..............................................8
	4.1 DAV:is-principal...............................................7		4.1 DAV:is-principal................................................9
	4.2 DAV:authentication-id..........................................7		4.2 DAV:alternate-URL...............................................9
	5 ACCESS CONTROL PROPERTIES.........................................8		5 ACCESS CONTROL PROPERTIES.........................................9
	5.1 DAV:owner......................................................8		5.1 DAV:owner.......................................................9
	5.2 DAV:supported-privilege-set....................................8		5.2 DAV:supported-privilege-set....................................10
	5.3 DAV:current-user-privilege-set.................................9		5.3 DAV:current-user-privilege-set.................................11
	5.4 DAV:acl........................................................9		5.4 DAV:acl........................................................11
	5.4.1 ACE Principal................................................9		5.4.1 ACE Principal...............................................11
	5.4.2 ACE Grant and Deny..........................................10		5.4.2 ACE Grant and Deny..........................................13
	5.4.3 ACE Protection..............................................11		5.4.3 ACE Protection..............................................13
	5.4.4 ACE Inheritance.............................................11		5.4.4 ACE Inheritance.............................................13
	5.5 DAV:acl-semantics.............................................11		5.5 DAV:acl-semantics..............................................13
	5.6 DAV:principal-collection-set..................................11		5.6 DAV:principal-collection-set...................................14
	5.7 Example: PROPFIND to retrieve access control properties.......12		5.7 Example: PROPFIND to retrieve access control properties........14
	6 ACL SEMANTICS....................................................15		6 ACL SEMANTICS....................................................17
	6.1 ACE Combination...............................................15		6.1 ACE Combination................................................17
	6.1.1 DAV:first-match ACE Combination.............................15		6.1.1 DAV:first-match ACE Combination.............................18
	6.1.2 DAV:all-grant-before-any-deny ACE Combination...............15		6.1.2 DAV:all-grant-before-any-deny ACE Combination...............18
	6.1.3 DAV:no-deny ACE Combination.................................15		6.1.3 DAV:specific-deny-overrides-grant ACE Combination...........18
	6.2 ACE Ordering..................................................16		6.2 ACE Ordering...................................................18
	6.2.1 DAV:deny-before-grant ACE Ordering..........................16		6.2.1 DAV:deny-before-grant ACE Ordering..........................18
	6.3 Required Principals...........................................16		6.3 Required Principals............................................18
	7 ACCESS CONTROL AND EXISTING METHODS..............................16		7 ACCESS CONTROL AND EXISTING METHODS..............................19
	7.1 OPTIONS.......................................................16		7.1 OPTIONS........................................................19
	7.1.1 Example - OPTIONS...........................................16		7.1.1 Example - OPTIONS...........................................19
	8 ACCESS CONTROL METHODS...........................................17		8 ACCESS CONTROL METHODS...........................................19
	8.1 ACL...........................................................17		8.1 ACL............................................................19
	8.1.1 ACL Preconditions...........................................17		8.1.1 ACL Preconditions...........................................20
	8.1.2 Example: the ACL method.....................................17		8.1.2 Example: the ACL method.....................................20
	8.1.3 Example: ACL method failure due to omission of protected ACE18		8.1.3 Example: ACL method failure due to omission of protected ACE21
	8.1.4 Example: ACL method failure due to inherited ACEs preceding		8.1.4 Example: ACL method failure due to inherited ACEs preceding
	non-inherited ACEs................................................19		non-inherited ACEs................................................22
	8.1.5 Example: ACL method failure due to an attempt to set grant and
	deny in a single ACE..............................................20
	Clemm, Hopkins, Sedlar, Whitehead [Page 2]		Clemm, Hopkins, Sedlar, Whitehead [Page 2]
	9 INTERNATIONALIZATION CONSIDERATIONS..............................21		8.1.5 Example: ACL method failure due to an attempt to set grant and
			deny in a single ACE..............................................23
	10 SECURITY CONSIDERATIONS........................................22		9 INTERNATIONALIZATION CONSIDERATIONS..............................24
	10.1 Increased Risk of Compromised Users...........................22
	10.2 Authentication-id Property and Dictionary Attacks.............22
	10.3 Risks of the read-acl Privilege...............................23
	11 AUTHENTICATION.................................................23		10 SECURITY CONSIDERATIONS........................................25
			10.1 Increased Risk of Compromised Users...........................25
			10.2 Risks of the read-acl and cuprivset Privileges................25
	12 IANA CONSIDERATIONS............................................23		11 AUTHENTICATION.................................................26
	13 INTELLECTUAL PROPERTY..........................................23		12 IANA CONSIDERATIONS............................................26
	14 ACKNOWLEDGEMENTS...............................................24		13 INTELLECTUAL PROPERTY..........................................26
	15 REFERENCES.....................................................24		14 ACKNOWLEDGEMENTS...............................................26
	15.1 Normative References..........................................24
	15.2 Informational References......................................25
	16 AUTHORS' ADDRESSES.............................................25		15 REFERENCES.....................................................27
			15.1 Normative References..........................................27
			15.2 Informational References......................................28
	17 APPENDICIES....................................................25		16 AUTHORS' ADDRESSES.............................................28
	17.1 XML Document Type Definition..................................25
			17 APPENDICIES....................................................28
			17.1 XML Document Type Definition..................................28
			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 an
	interoperable mechanism for handling discretionary access control		interoperable mechanism for handling discretionary access control
	for content in WebDAV servers. WebDAV access control can be		for content in WebDAV servers. WebDAV access control can be
	implemented on content repositories with security as simple as that		implemented on content repositories with security as simple as that
	of a UNIX file system, as well as more sophisticated models. The		of a UNIX file system, as well as more sophisticated models. The
	underlying principle of access control is that who you are		underlying principle of access control is that who you are
	determines how you can access a resource. The "who you are" is		determines how you can access a resource. The "who you are" is
	defined by a "principal" identifier; users, client software,		defined by a "principal" identifier; users, client software,
	servers, and groups of the previous have principal identifiers. The		servers, and groups of the previous have principal identifiers. The
	"how" is determined by a single "access control list" (ACL)		"how" is determined by a single "access control list" (ACL)
	associated with a resource. An ACL contains a set of "access		associated with a resource. An ACL contains a set of "access
	control entries" (ACEs), where each ACE specifies a principal and a		control entries" (ACEs), where each ACE specifies a principal and a
	set of privileges that are either granted or denied to that		set of privileges that are either granted or denied to that
	principal. When a principal submits an operation (such as an HTTP or		principal. When a principal submits an operation (such as an HTTP
	WebDAV method) to a resource for execution, the server evaluates the		or WebDAV method) to a resource for execution, the server evaluates
	ACEs in the ACL to determine if the principal has permission for		the ACEs in the ACL to determine if the principal has permission
	that operation.		for that operation.
	This specification intentionally omits discussion of authentication,		This specification intentionally omits discussion of
	as the HTTP protocol already has a number of authentication		authentication, as the HTTP protocol already has a number of
	mechanisms [RFC2617]. Some authentication mechanism (such as HTTP		authentication mechanisms [RFC2617]. Some authentication mechanism
	Digest Authentication, which all WebDAV compliant implementations		(such as HTTP Digest Authentication, which all WebDAV compliant
	are required to support) must be available to validate the identity		implementations are required to support) must be available to
	of a principal.		validate the identity of a principal.
	In the interests of timeliness, the following set of security		In the interests of timeliness, the following set of security
	mechanisms are not addressed by this document:		mechanisms are not addressed by this document:
	Clemm, Hopkins, Sedlar, Whitehead [Page 3]		* Access control that applies only to a particular property on a
	* Access control that applies only to a particular property on		resource (excepting the access control properties DAV:acl and
	a resource, rather than the entire resource,		DAV:current-user-privilege-set), rather than the entire
			resource,
	* Role-based security (where a role can be seen as a		* Role-based security (where a role can be seen as a dynamically
	dynamically defined collection of principals),		defined collection of principals),
	* Specification of the ways an ACL on a resource is		* Specification of the ways an ACL on a resource is initialized,
	initialized,
	* Specification of an ACL that applies globally to a method,		* Specification of an ACL that applies globally to a method,
	rather than to a particular resource.		rather than to a particular resource.
	This specification is organized as follows. Section 1.1 defines key		This specification is organized as follows. Section 1.1 defines key
	concepts used throughout the specification, and is followed by more		concepts used throughout the specification, and is followed by more
	in-depth discussion of principals (Section 2), and privileges		in-depth discussion of principals (Section 2), and privileges
	(Section 3). Properties defined on principals are specified in		(Section 3). Properties defined on principals are specified in
	Section 4, and access control properties for content resources are		Section 4, and access control properties for content resources are
	specified in Section 5. The semantics of access control lists are		specified in Section 5. The semantics of access control lists are
	described in Section 6, including sections on ACE combination		described in Section 6, including sections on ACE combination
	(Section 6.1), ACE ordering (Section 6.2), and principals required		(Section 6.1), ACE ordering (Section 6.2), and principals required
	to be present in an ACE (Section 6.3). Client discovery of access		to be present in an ACE (Section 6.3). Client discovery of access
	control capability using OPTIONS is described in Section 7.1, and		control capability using OPTIONS is described in Section 7.1, and
	the access control setting method, ACL, is specified in Section 8.		the access control setting method, ACL, is specified in Section 8.
			Clemm, Hopkins, Sedlar, Whitehead [Page 4]
	Internationalization considerations (Section 9) and security		Internationalization considerations (Section 9) and security
	considerations (Section 10) round out the specification. An appendix		considerations (Section 10) round out the specification. An
	(Section 17.1) provides an XML Document Type Definition (DTD) for		appendix (Section 17.1) provides an XML Document Type Definition
	the XML elements defined in the specification.		(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 HTTP
	resources that represent principals, and principal collections.		resources that represent principals, and principal collections.
	privilege		privilege
	A "privilege" controls access to a particular set of HTTP operations		A "privilege" controls access to a particular set of HTTP
	on a resource.		operations on a resource.
	aggregate privilege		aggregate privilege
	An "aggregate privilege" is a privilege that contains a set of other		An "aggregate privilege" is a privilege that contains a set of
	privileges.		other privileges.
	abstract privilege		abstract privilege
	Clemm, Hopkins, Sedlar, Whitehead [Page 4]
	The modifier "abstract", when applied to an atomic or aggregate		The modifier "abstract", when applied to an atomic or aggregate
	privilege, means the privilege cannot be set in an access control		privilege, means the 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 access
	control to a particular resource.		control to a particular resource.
	access control element (ace)		access control element (ace)
	An "ace" either grants or denies a particular set of (non-abstract)		An "ace" either grants or denies a particular set of (non-abstract)
	privileges for a particular principal.		privileges for a particular principal.
	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 shared from the acl of another
	resource.		resource.
			Clemm, Hopkins, Sedlar, Whitehead [Page 5]
	1.2 Notational Conventions		1.2 Notational Conventions
	The augmented BNF used by this document to describe protocol		The augmented BNF used by this document to describe protocol
	elements is described in Section 2.1 of [RFC2616]. Because this		elements is described in Section 2.1 of [RFC2616]. Because this
	augmented BNF uses the basic production rules provided in Section		augmented BNF uses the basic production rules provided in Section
	2.2 of [RFC2616], those rules apply to this document as well.		2.2 of [RFC2616], those rules apply to this document as well.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	document are to be interpreted as described in [RFC2119].		this document are to be interpreted as described in [RFC2119].
	2 PRINCIPALS		2 PRINCIPALS
	A principal is an HTTP resource that represents a distinct human or		A principal is a network resource that represents a distinct human
	computational actor that initiates access to network resources. On		or computational actor that initiates access to network resources.
	many implementations, users and groups are represented as		On many implementations, users and groups are represented as
	principals; other types of principals are also possible. Although		principals; other types of principals are also possible. A URL of
	an implementation MAY support PROPFIND and PROPPATCH to access and		any scheme MAY be used to identify a principal resource. However,
	modify information about a principal, it is not required to do so.		servers implementing this specification SHOULD expose principal
			resources at an http(s) URL, which is a privileged scheme that
			points to resources that have additional properties, as described
			in Section 4. Although an implementation SHOULD support PROPFIND
			and PROPPATCH to access and modify information about a principal,
			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. A collection
	principal may only contain other principals (not other types of		principal may only contain other principals (not other types of
	resources). Servers that support aggregation of principals (e.g.		resources). Servers that support aggregation of principals (e.g.
	groups of users or other groups) MUST manifest them as collection		groups of users or other groups) MUST manifest them as collection
	principals. The WebDAV methods for examining and maintaining		principals. The WebDAV methods for examining and maintaining
	collections (e.g. DELETE, PROPFIND) MAY be used to maintain		collections (e.g. DELETE, PROPFIND) MAY be used to maintain
	collection principals. Membership in a collection principal is		collection principals. Membership in a collection principal is
	recursive, so a principal in a collection principal GRPA contained		recursive, so a principal in a collection principal GRPA contained
	by collection principal GRPB is a member of both GRPA and GRPB.		by collection principal GRPB is a member of both GRPA and GRPB.
	Implementations not supporting recursive membership in principal		Implementations not supporting recursive membership in principal
	collections can return an error if the client attempts to bind		collections can return an error if the client attempts to bind
	collection principals into other collection principals.		collection principals into other collection principals.
	3 PRIVILEGES		3 PRIVILEGES
	Ability to perform a given method on a resource SHOULD be controlled		Ability to perform a given method on a resource SHOULD be
	by one or more privileges. Authors of protocol extensions that		controlled by one or more privileges. Authors of protocol
			extensions that define new HTTP methods SHOULD specify which
	Clemm, Hopkins, Sedlar, Whitehead [Page 5]		privileges (by defining new privileges, or mapping to ones below)
	define new HTTP methods SHOULD specify which privileges (by defining		are required to perform the method. A principal with no privileges
	new privileges, or mapping to ones below) are required to perform		to a resource SHOULD be denied any HTTP access to that resource.
	the method. A principal with no privileges to a resource SHOULD be
	denied any HTTP access to that resource.
	Privileges may be containers of other privileges, in which case they		Privileges may be containers of other privileges, in which case
	are termed aggregate privileges. If a principal is granted or		they are termed aggregate privileges. If a principal is granted or
	denied an aggregate privilege, it is semantically equivalent to		denied an aggregate privilege, it is semantically equivalent to
	granting or denying each of the aggregated privileges individually.		granting or denying each of the aggregated privileges individually.
	For example, an implementation may define add-member and remove-		For example, an implementation may define add-member and remove-
	member privileges that control the ability to add and remove an		member privileges that control the ability to add and remove an
	internal member of a collection. Since these privileges control the		internal member of a collection. Since these privileges control
	ability to update the state of a collection, these privileges would
	be aggregated by the DAV:write privilege on a collection, and		Clemm, Hopkins, Sedlar, Whitehead [Page 6]
			the ability to update the state of a collection, these privileges
			would be aggregated by the DAV:write privilege on a collection, and
	granting the DAV:write privilege on a collection would also grant		granting the DAV:write privilege on a collection would also grant
	the add-member and remove-member privileges.		the add-member and remove-member privileges.
	Privileges may have the quality of being abstract, in which case		Privileges may have the quality of being abstract, in which case
	they cannot be set in an ACE. Aggregate and atomic privileges are		they cannot be set in an ACE. Aggregate and atomic privileges are
	both capable of being abstract. Abstract privileges are useful for		both capable of being abstract. Abstract privileges are useful for
	modeling privileges that otherwise would not be exposed via the		modeling privileges that otherwise would not be exposed via the
	protocol. Abstract privileges also provide server implementations		protocol. Abstract privileges also provide server implementations
	with flexibility in implementing the privileges defined in this		with flexibility in implementing the privileges defined in this
	specification. For example, if a server is incapable of separating		specification. For example, if a server is incapable of separating
	the read resource capability from the read ACL capability, it can		the read resource capability from the read ACL capability, it can
	still model the DAV:read and DAV:read-acl privileges defined in this		still model the DAV:read and DAV:read-acl privileges defined in
	specification by declaring them abstract, and containing them within		this specification by declaring them abstract, and containing them
	a non-abstract aggregate privilege (say, read-all) that holds		within a non-abstract aggregate privilege (say, read-all) that
	DAV:read, and DAV:read-acl. In this way, it is possible to set the		holds DAV:read, and DAV:read-acl. In this way, it is possible to
	aggregate privilege, read-all, thus coupling the setting of DAV:read		set the aggregate privilege, read-all, thus coupling the setting of
	and DAV:read-acl, but it is not possible to set DAV:read, or		DAV:read and DAV:read-acl, but it is not possible to set DAV:read,
	DAV:read-acl individually. Since aggregate privileges can be		or DAV:read-acl individually. Since aggregate privileges can be
	abstract, it is also possible to use abstract privileges to group		abstract, it is also possible to use abstract privileges to group
	and classify non-abstract privileges.		and classify non-abstract privileges.
	The set of privileges that apply to a particular resource may vary		The set of privileges that apply to a particular resource may vary
	with the DAV:resourcetype of the resource, as well as between		with the DAV:resourcetype of the resource, as well as between
	different server implementations. To promote interoperability,		different server implementations. To promote interoperability,
	however, WebDAV defines a set of well-known privileges (e.g.		however, WebDAV defines a set of well-known privileges (e.g.
	DAV:read and DAV:write), which can at least be used to classify the		DAV:read and DAV:write), which can at least be used to classify the
	other privileges defined on a particular resource.		other privileges defined on a particular resource. The access
			permissions on null and lock-null resources are solely those they
			inherit (if any), and they are not discoverable (i.e., the ACL
			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 about
	the state of the resource, including the resource's properties.		the state of the resource, including the resource's properties.
	Affected methods include GET and PROPFIND. Additionally, the read		Affected methods include GET and PROPFIND. Additionally, the read
	privilege MAY control the OPTIONS method.		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 state of the
	resource, such as PUT and PROPPATCH. Note that state modification		resource, such as PUT and PROPPATCH. Note that state modification
	Clemm, Hopkins, Sedlar, Whitehead [Page 6]
	is also controlled via locking (see section 5.3 of [WEBDAV]), so		is also controlled via locking (see section 5.3 of [WEBDAV]), so
	effective write access requires that both write privileges and write		effective write access requires that both write privileges and
	locking requirements are satisfied.		write locking requirements are satisfied.
	<!ELEMENT write EMPTY>		<!ELEMENT write EMPTY>
			Clemm, Hopkins, Sedlar, Whitehead [Page 7]
	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 retrieve
	the DAV:acl, and DAV:current-user-privilege-set properties of the		the DAV:acl property of the resource.
	resource.
	<!ELEMENT read-acl EMPTY>		<!ELEMENT read-acl EMPTY>
	3.4 DAV:write-acl Privilege		3.4 DAV:read-cuprivset Privilege
	The DAV:write-acl privilege controls use of the ACL method to modify		The DAV:read-cuprivset privilege controls the use of PROPFIND to
	the DAV:acl property of the resource.		retrieve the DAV:current-user-privilege-set property of the
			resource.
			Clients are intended to use this property to visually indicate in
			their UI items that are dependent on the permissions of a resource,
			for example, by graying out resources that are not writeable.
			This privilege is separate from DAV:read-acl because there is a
			need to allow most users access to the privileges permitted the
			current user (due to its use in creating the UI), while the full
			ACL contains information that may not be appropriate for the
			current authenticated user. As a result, the set of users who can
			view the full ACL is expected to be much smaller than those who can
			read the current user privilege set, and hence distinct privileges
			are needed for each
			<!ELEMENT read-cuprivset EMPTY>
			3.5 DAV:write-acl Privilege
			The DAV:write-acl privilege controls use of the ACL method to
			modify the DAV:acl property of the resource.
	<!ELEMENT write-acl EMPTY>		<!ELEMENT write-acl EMPTY>
	3.5 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 all privileges on
	the resource.		the resource.
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
	4 PRINCIPAL PROPERTIES		4 PRINCIPAL PROPERTIES
	Principals are manifested to clients as an HTTP resource, identified		Principals are manifested to clients as an HTTP resource,
	by a URL. A principal MUST have a DAV:displayname property. This		identified by a URL. A principal MUST have a DAV:displayname
	protocol defines the following additional properties for a		property. This protocol defines the following additional
	principal.		properties for a principal. The name and value of these properties
			SHOULD NOT be returned by PROPFIND allprop request (as defined in
			Section 12.14.1 of [RFC2518]). In the descriptions below, a read-
			only property is defined as a property that MUST NOT be writeable
			using PROPPATCH.
			Clemm, Hopkins, Sedlar, Whitehead [Page 8]
	4.1 DAV:is-principal		4.1 DAV:is-principal
	This property indicates whether this resource is a principal. A		This is a read-only property that indicates whether this resource
	resource MUST have a non-empty DAV:is-principal property if and only		is a principal. A resource MUST have a non-empty DAV:is-principal
	if it is a principal resource. (Note: If we can just add a		property if and only if it is a principal resource.
	DAV:principal element to the DAV:resourcetype property, then we do
	not need a DAV:is-principal property.)
	<!ELEMENT is-principal (#PCDATA)>		<!ELEMENT is-principal (#PCDATA)>
	PCDATA value: any non-empty value ("T" is suggested)		PCDATA value: "true" - resource is a principal, "false" - resource
			is not a principal (note that in cases where the "F" value might be
			used, this specification requires the property not be present at
			all).
	4.2 DAV:authentication-id		4.2 DAV:alternate-URL
	A property containing the name used to authenticate this principal		This read-only property, if present, contains the URL of a network
	(typically typed into a login prompt/dialog).		resource with additional descriptive information about the
			principal. This property identifies one or more additional network
			resources (i.e., it contains one or more URLs) that may be
			consulted by a client to gain additional knowledge concerning a
			principal. Two potential uses for this property are to store an
			ldap [RFC2255] or mailto [RFC2368] scheme URL. Support for this
			property is OPTIONAL.
	<!ELEMENT authentication-id (#PCDATA)>		<!ELEMENT alternate-URL (href*)>
	PCDATA value: any string
	Clemm, Hopkins, Sedlar, Whitehead [Page 7]
	5 ACCESS CONTROL PROPERTIES		5 ACCESS CONTROL PROPERTIES
	This specification defines a number of new properties for WebDAV		This specification defines a number of new properties for WebDAV
	resources. Access control properties may be retrieved just like		resources. Access control properties may be retrieved just like
	other WebDAV properties, using the PROPFIND method. Some access		other WebDAV properties, using the PROPFIND method. Some access
	control properties (such as DAV:owner) MAY be updated with the		control properties (such as DAV:owner) MAY be updated with the
	PROPPATCH method.		PROPPATCH method. In the descriptions below, a read-only property
			is defined as a property that MUST NOT be writeable using
			PROPPATCH. Since it is expensive, for many servers, to retrieve
			access control information, a PROPFIND allprop request (as defined
			in Section 12.14.1 of [RFC2518]) SHOULD NOT return the names and
			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 MUST
	contain the following properties:		contain the following properties. Null, and lock-null resources
			(described in Section 7.4 of [RFC2518]) MUST NOT contain the
			following properties:
	5.1 DAV:owner		5.1 DAV:owner
	This property identifies a particular principal as being the "owner"		This property identifies a particular principal as being the
	of the resource.		"owner" of the resource. Since the owner of a resource often has
			special access control capabilities (e.g., the owner frequently has
			permanent write-ACL privilege), clients might display the resource
			owner in their user interface.
	<!ELEMENT owner (href prop?)>		<!ELEMENT owner (href prop?)>
	<!ELEMENT prop (see [RFC2518], section 12.11)>		<!ELEMENT prop (see [RFC2518], section 12.11)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 9]
	An implementation MAY include a list of selected properties of that		An implementation MAY include a list of selected properties of that
	principal resource. Which properties (if any) are included is		principal resource. Which properties (if any) are included is
	implementation defined. An implementation MAY allow the use of		implementation defined, but might reasonably include properties
	PROPPATCH to update the DAV:owner field.		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
			DAV:owner field. If the DAV:owner property is writeable, clients
			MUST NOT submit the prop element; only the href element can be
			modified by the client. The purpose of this restriction is to limit
			the scope of effect of a PROPPATCH to just the owner property's
			resource; setting the prop element would additionally require
			modification to properties of the principal resource identified by
			the href element.
	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 read-only property that identifies the privileges defined
	for the resource.		for the resource.
	<!ELEMENT supported-privilege-set (supported-privilege*)>		<!ELEMENT supported-privilege-set (supported-privilege*)>
	Each privilege appears as an XML element, where aggregate privileges		Each privilege appears as an XML element, where aggregate
	list as sub-elements all of the privileges that they aggregate.		privileges list as sub-elements all of the privileges that they
			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 for
	that resource. Servers MUST fail an attempt to set an abstract		that resource. Servers MUST fail an attempt to set an abstract
	privilege.		privilege.
	<!ELEMENT abstract EMPTY>		<!ELEMENT abstract EMPTY>
	A description is a human-readable description of what this privilege		A description is a human-readable description of what this
	controls access to.		privilege controls access to.
	<!ELEMENT description #PCDATA>		<!ELEMENT description #PCDATA>
	It is envisioned that a WebDAV ACL-aware administrative client would		It is envisioned that a WebDAV ACL-aware administrative client
	list the supported privileges in a dialog box, and allow the user to		would list the supported privileges in a dialog box, and allow the
	choose non-abstract privileges to apply in an ACE. The privileges		user to choose non-abstract privileges to apply in an ACE. The
	tree is useful programmatically to map well-known privileges		privileges tree is useful programmatically to map well-known
	(defined by WebDAV or other standards groups) into privileges that		privileges (defined by WebDAV or other standards groups) into
	are supported by any particular server implementation. The
	Clemm, Hopkins, Sedlar, Whitehead [Page 8]		Clemm, Hopkins, Sedlar, Whitehead [Page 10]
	privilege tree also serves to hide complexity in implementations		privileges that are supported by any particular server
	allowing large number of privileges to be defined by displaying		implementation. The privilege tree also serves to hide complexity
	aggregates to the user.		in implementations allowing large number of privileges to be
			defined by displaying aggregates to the user.
	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 read-only property containing
	the exact set of privileges (as computed by the server) granted to		the exact set of privileges (as computed by the server) granted to
	the currently authenticated HTTP user. A user-agent can use the		the currently authenticated HTTP user. Aggregate privileges and
			their contained privileges are listed. A user-agent can use the
	value of this property to adjust its user interface to make actions		value of this property to adjust its user interface to make actions
	inaccessible (e.g, by graying out a menu item or button) for which		inaccessible (e.g., by graying out a menu item or button) for which
	the current principal does not have permission. This is particularly		the current principal does not have permission. This is
	useful for an access control user interface, which can be		particularly useful for an access control user interface, which can
	constructed without knowing the ACE combining semantics of the		be constructed without knowing the ACE combining semantics of the
	server. This property is also useful for determine what operations		server. This property is also useful for determining what
	can be performed by the current principal, without having to		operations the current principal can perform, without having to
	actually execute an operation.		actually execute an operation.
	<!ELEMENT current-user-privilege-set (privilege*)>		<!ELEMENT current-user-privilege-set (privilege*)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	If the current user is granted a specific privilege, that privilege		If the current user is granted a specific privilege, that privilege
	must belong to the set of privileges that may be set on this		must belong to the set of privileges that may be set on this
	resource. Therefore, each element in the DAV:current-user-privilege-		resource. Therefore, each element in the DAV:current-user-
	set property MUST identify a privilege from the DAV:supported-		privilege-set property MUST identify a non-abstract privilege from
	privilege-set property.		the DAV:supported-privilege-set property.
	5.4 DAV:acl		5.4 DAV:acl
	This property specifies the list of access control entries (ACEs),		This is a read-only property that specifies the list of access
	which define what principals are to get what privileges for this		control entries (ACEs), which define what principals are to get
	resource.		what privileges for this resource.
	<!ELEMENT acl (ace*)>		<!ELEMENT acl (ace*)>
	Each DAV:ace element specifies the set of privileges to be either		Each DAV:ace element specifies the set of privileges to be either
	granted or denied to a single principal. If the DAV:acl property is		granted or denied to a single principal. If the DAV:acl property
	empty, no principal is granted any privilege.		is empty, no principal is granted any privilege.
	<!ELEMENT ace (principal, (grant|deny), protected?, inherited?)>		<!ELEMENT ace (principal, (grant|deny), protected?, inherited?)>
	An attempt to update the DAV:acl property with a PROPPATCH MUST
	fail.
	5.4.1 ACE Principal		5.4.1 ACE Principal
	The DAV:principal element identifies the principal to which this ACE		The DAV:principal element identifies the principal to which this
	applies.		ACE applies.
	<!ELEMENT principal ((href, prop?)		<!ELEMENT principal ((href, prop?)
	| all | authenticated | unauthenticated		| all | authenticated | unauthenticated
	| property | self)>		| property | self)>
	The current user matches DAV:href only if that user is authenticated		Clemm, Hopkins, Sedlar, Whitehead [Page 11]
	as being (or being a member of) the principal identified by the URL		The current user matches DAV:href only if that user is
			authenticated as being (or being a member of) the principal
	Clemm, Hopkins, Sedlar, Whitehead [Page 9]		identified by the URL contained by that DAV:href. An implementation
	contained by that DAV:href. An implementation MAY include a		MAY include a DAV:prop element after the DAV:href element,
	DAV:prop element after the DAV:href element, containing a list of		containing a list of selected properties of that principal
	selected properties of that principal resource. Which properties		resource. Which properties (if any) are included in the DAV:prop
	(if any) are included in the DAV:prop element is implementation		element is implementation defined. The DAV:prop element can be used
	defined. The DAV:prop element is primarily intended for		by servers that do not support PROPFIND requests on principal
	implementations that do not support PROPFIND requests on the		resources to return principal-related information (such as the
	principal URL.		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)>		<!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>
	skipping to change at page 27, line ?		skipping to change at line 621
	resource contains a DAV:href that identifies a principal, and the		resource contains a DAV:href that identifies a principal, and the
	current user is authenticated as being (or being a member of) that		current user is authenticated as being (or being a member of) that
	principal. For example, if the DAV:property element contained		principal. For example, if the DAV:property element contained
	<DAV:owner/>, the current user would match the DAV:property		<DAV:owner/>, the current user would match the DAV:property
	principal only if the current user is authenticated as matching the		principal only if the current user is authenticated as matching the
	principal identified by the DAV:owner property of the resource.		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 current		resource only if that resource is a principal object and the
	user is authenticated as being that principal.		current user is authenticated as being that principal.
	<!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 privileges
	to be either granted or denied to the specified principal. A		to be either granted or denied to the specified principal. A
	DAV:grant or DAV:deny element of the DAV:acl of a resource MUST only		DAV:grant or DAV:deny element of the DAV:acl of a resource MUST
	contain elements specified in the DAV:supported-privilege-set of		only contain non-abstract elements specified in the DAV:supported-
	that resource.		privilege-set of that resource.
	<!ELEMENT grant (privilege+)>		<!ELEMENT grant (privilege+)>
	<!ELEMENT deny (privilege+)>		<!ELEMENT deny (privilege+)>
	<!ELEMENT privilege ANY>		<!ELEMENT privilege ANY>
	Clemm, Hopkins, Sedlar, Whitehead [Page 10]
	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 without
	that ACE MUST fail.		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 is
	inherited from another resource that is identified by the URL		inherited from another resource that is identified by the URL
	contained in a DAV:href element. An inherited ACE cannot be		contained in a DAV:href element. An inherited ACE cannot be
	modified directly, but instead the ACL on the resource from which it		modified directly, but instead the ACL on the resource from which
	is inherited must be modified.		it is inherited must be modified.
	Note that ACE inheritance is not the same as ACL initialization.		Note that ACE inheritance is not the same as ACL initialization.
	ACL initialization defines the ACL that a newly created resource		ACL initialization defines the ACL that a newly created resource
	will use (if not specified). ACE inheritance refers to an ACE that		will use (if not specified). ACE inheritance refers to an ACE that
	is logically shared - where an update to the resource containing an		is logically shared - where an update to the resource containing an
	ACE will affect the ACE of each resource that inherits that ACE.		ACE will affect the ACE of each resource that inherits that ACE.
	The method by which ACLs are initialized or by which ACEs are		The method by which ACLs are initialized or by which ACEs are
	inherited is not defined by this document.		inherited is not defined by this document.
	<!ELEMENT inherited (href)>		<!ELEMENT inherited (href)>
	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 read-only property that defines the ACL semantics. These
	semantics define how multiple ACEs that match the current user are		semantics define how multiple ACEs that match the current user are
	combined, what are the constraints on how ACEs can be ordered, and		combined, what are the constraints on how ACEs can be ordered, and
	which principals must have an ACE.		which principals must have an ACE. A client user interface could
			use the value of this property to provide feedback to a human
			operator concerning the impact of proposed changes to an ACL.
			Alternately, a client could use this property to determine exactly,
			before submitting an ACL method invocation, what ACL changes it
			needs to make to accomplish a 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 the
	same ACL semantics, the DAV:acl-semantics property is used to		same ACL semantics, the DAV:acl-semantics property is used to
	identify the ACL semantics for a particular resource. The DAV:acl-		identify the ACL semantics for a particular resource. The DAV:acl-
	semantics element is defined in section 6.		semantics element is defined in section 6.
			Clemm, Hopkins, Sedlar, Whitehead [Page 13]
	5.6 DAV:principal-collection-set		5.6 DAV:principal-collection-set
	This read-only property contains zero, one, or more URLs that		This read-only property contains zero, one, or more URLs that
	identify a collection principal. It is expected that implementations		identify a collection principal. It is expected that
	of this protocol will typically employ a relatively small number of		implementations of this protocol will typically employ a relatively
	locations in the URL namespace for principal, and collection		small number of locations in the URL namespace for principal, and
	principals. In cases where this assumption holds, the DAV:principal-		collection principals. In cases where this assumption holds, the
	collection-set property will contain a small set of URLs identifying		DAV:principal-collection-set property will contain a small set of
	the top of collection hierarchy containing multiple principals and		URLs identifying the top of collection hierarchy containing
	collection principals. An access control protocol user agent could		multiple principals and collection principals. An access control
	use the contents of DAV:principal-collection-set to, for example,		protocol user agent could use the contents of DAV:principal-
	query the DAV:displayname property (specified in Section 13.2 of		collection-set to query the DAV:displayname property (specified in
	[RFC2518]) of all principals on that server, thereby yielding human-		Section 13.2 of [RFC2518]) of all principals on that server,
	readable names for each principal that could be displayed in a user		thereby yielding human-readable names for each principal that could
	interface.		be displayed in a user interface.
	Clemm, Hopkins, Sedlar, Whitehead [Page 11]
	<!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 different
	DAV:principal-collection-set values. The collections specified in		DAV:principal-collection-set values. The collections specified in
	the DAV:principal-collection-set MAY be located on different hosts		the DAV:principal-collection-set MAY be located on different hosts
	from the resource. The URLs in DAV:principal-collection-set are not		from the resource. The URLs in DAV:principal-collection-set SHOULD
	limited to http scheme URLs, and can, for example, be ldap scheme		be http or https scheme URLs. For security and scalability reasons,
	URLs. For security and scalability reasons, a server MAY report only		a server MAY report only a subset of the entire set of known
	a subset of the entire set of known collection principals, and		collection principals, and therefore clients should not assume they
	therefore clients should not assume they have retrieved an		have retrieved an exhaustive listing. Additionally, a server MAY
	exhaustive listing. Additionally, a server MAY elect to report none		elect to report none of the collection principals it knows about.
	of the collection principals it knows about.
	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 be
	retrieved by using the PROPFIND method to fetch the values of the		retrieved by using the PROPFIND method to fetch the values of the
	DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-		DAV:owner, DAV:supported-privilege-set, DAV:current-user-privilege-
	set, and DAV:acl properties.		set, and DAV:acl properties.
	>> Request <<		>> Request <<
	skipping to change at page 27, line ?		skipping to change at line 739
	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.acl.org/"> <D:response> <D:propstat>		xmlns:A="http://www.webdav.org/acl/"> <D:response> <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>
	Clemm, Hopkins, Sedlar, Whitehead [Page 12]
	<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>
	skipping to change at page 27, line ?		skipping to change at line 793
	</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:prop>
	<D:authentication-id>esedlar</D:authentication-id>
	<D:displayname>Eric Sedlar</D:displayname>		<D:displayname>Eric Sedlar</D:displayname>
	</D:prop> </D:principal>		</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>
	Clemm, Hopkins, Sedlar, Whitehead [Page 13]
	<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>
	skipping to change at page 27, line ?		skipping to change at line 832
	<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>
	</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 element		The value of the DAV:owner property is a single DAV:href XML
	containing the URL of the principal that owns this resource.		element containing the URL of the principal that owns this
			resource.
	The value of the DAV:supported-privilege-set property is a tree of		The value of the DAV:supported-privilege-set property is a tree of
	supported privileges:		supported privileges:
	DAV:acl (aggregate, abstract)		DAV:all (aggregate, abstract)
	|		|
	+-- DAV:read		+-- DAV:read
	+-- DAV:write (aggregate, abstract)		+-- DAV:write (aggregate, abstract)
	|		|
	+-- http://www.acl.org/create		+-- http://www.webdav.org/acl/create
	+-- http://www.acl.org/update		+-- http://www.webdav.org/acl/update
	+-- http://www.acl.org/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 privileges,		The DAV:current-user-privilege-set property contains two
	DAV:read, and DAV:read-acl. This indicates that the current		privileges, DAV:read, and DAV:read-acl. This indicates that the
	authenticated user only has the ability to read the resource, and		current authenticated user only has the ability to read the
	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, DAV:write,		http://www.foo.org/users/esedlar is granted the DAV:read,
	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 group,
	which is represented by a collection principal.		which is represented by a collection principal.
	Clemm, Hopkins, Sedlar, Whitehead [Page 14]
	ACE #3: In this ACE, the principal is a property principal,		ACE #3: In this ACE, the principal is a property principal,
	specifically the DAV:owner property. When evaluating this ACE, the		specifically the DAV:owner property. When evaluating this ACE, the
	value of the DAV:owner property is retrieved, and is examined to see		value of the DAV:owner property is retrieved, and is examined to
	if it contains a DAV:href XML element. If so, the URL within the		see if it contains a DAV:href XML element. If so, the URL within
	DAV:href element is read, and identifies a principal. In this ACE,		the DAV:href element is read, and identifies a principal. In this
	the owner is granted DAV:read-acl, and DAV:write-acl privileges.		ACE, the owner is granted DAV:read-acl, and 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.
	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 current
	user are combined, what are the constraints on how ACEs can be		user are combined, what are the constraints on how ACEs can be
	ordered, and which principals must have an ACE.		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, required-
	principal)>		principal*)>
	6.1 ACE Combination		6.1 ACE Combination
	The DAV:ace-combination element defines how privileges from multiple		The DAV:ace-combination element defines how privileges from
	ACEs that match the current user will be combined to determine the		multiple ACEs that match the current user will be combined to
	access privileges for that user. Multiple ACEs may match the same		determine the access privileges for that user. Multiple ACEs may
	user because the same principal can appear in multiple ACEs, because		match the same user because the same principal can appear in
	multiple principals can identify the same user, and because one		multiple ACEs, because multiple principals can identify the same
	principal can be a member of another principal.		user, and because one principal can be a member of another
			principal.
	<!ELEMENT ace-combination		<!ELEMENT ace-combination
	(first-match | all-grant-before-any-deny | no-deny)>
			Clemm, Hopkins, Sedlar, Whitehead [Page 17]
			(first-match | all-grant-before-any-deny | specific-deny-
			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 ACL.		The ACEs are evaluated in the order in which they appear in the
	If the first ACE that matches the current user does not grant all		ACL. If the first ACE that matches the current user does not grant
	the privileges needed for the request, the request MUST fail.		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 ACL.		The ACEs are evaluated in the order in which they appear in the
	If an evaluated ACE denies a privilege needed for the request, the		ACL. If an evaluated ACE denies a privilege needed for the
	request MUST fail. If all ACEs have been evaluated without the user		request, the request MUST fail. If all ACEs have been evaluated
	being granted all privileges needed for the request, the request		without the user being granted all privileges needed for the
	MUST fail.		request, the request MUST fail.
	<!ELEMENT all-grant-before-any-deny EMPTY>		<!ELEMENT all-grant-before-any-deny EMPTY>
	6.1.3 DAV:no-deny ACE Combination		6.1.3 DAV:specific-deny-overrides-grant ACE Combination
	All ACEs in the ACL are evaluated. An "individual ACE" is one whose
	principal identifies the current user. A "group ACE" is one whose
	Clemm, Hopkins, Sedlar, Whitehead [Page 15]		All ACEs in the ACL are evaluated. An "individual ACE" is one
	principal is a collection that contains a principal that identifies		whose principal identifies the current user. A "group ACE" is one
	the current user. A privilege is granted if it is granted by an		whose principal is a collection that contains a principal that
	individual ACE and not denied by an individual ACE, or if it is		identifies the current user. A privilege is granted if it is
	granted by a group ACE and not denied by an individual or group ACE.		granted by an individual ACE and not denied by an individual ACE,
	A request MUST fail if any of its needed privileges are not granted.		or if it is granted by a group ACE and not denied by an individual
			or group ACE. A request MUST fail if any of its needed privileges
			are not granted.
	<!ELEMENT no-deny 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 ACEs
	can be ordered in the ACL.		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
	skipping to change at page 27, line ?		skipping to change at line 958
	ACEs.		ACEs.
	<!ELEMENT deny-before-grant EMPTY>		<!ELEMENT deny-before-grant EMPTY>
	6.3 Required Principals		6.3 Required Principals
	The required principal elements identify which principals must have		The required principal elements identify which principals must have
	an ACE defined in the ACL.		an ACE defined in the ACL.
	<!ELEMENT required-principal		<!ELEMENT required-principal
	(href | all | authenticated | unauthenticated | property |		(href | all | authenticated | unauthenticated | property | self)>
	self)>
	For example, the following element requires that the ACE contain a		Clemm, Hopkins, Sedlar, Whitehead [Page 18]
			For example, the following element requires that the ACL contain a
	DAV:owner property ACE:		DAV:owner property ACE:
	<D:required-principal xmlns:D="DAV:">		<D:required-principal xmlns:D="DAV:">
	<D:property> <D:owner/> </D:property>		<D:property> <D:owner/> </D:property>
	</D:required-principal>		</D:required-principal>
	7 ACCESS CONTROL AND EXISTING METHODS		7 ACCESS CONTROL AND EXISTING METHODS
	This section defines the impact of access control functionality on		This section defines the impact of access control functionality on
	existing methods.		existing methods.
	7.1 OPTIONS		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.1Example - OPTIONS		7.1.1Example - OPTIONS
	>> REQUEST <<		>> Request <<
	OPTIONS /foo.html HTTP/1.1		OPTIONS /foo.html HTTP/1.1
	Host: www.webdav.org		Host: www.webdav.org
	Content-Length: 0		Content-Length: 0
	Clemm, Hopkins, Sedlar, Whitehead [Page 16]		>> 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.
	8 ACCESS CONTROL METHODS		8 ACCESS CONTROL METHODS
	8.1 ACL		8.1 ACL
	A DAV:acl property of a resource is modified by the ACL method. A		The ACL method modifies the DAV:acl property of a resource. A new
	new DAV:acl value must be written in its entirety, including any		DAV:acl value must be written in its entirety, including any
	inherited ACEs. Unless the DAV:acl property of the resource can be		inherited ACEs. Unless the DAV:acl property of the resource can be
	updated to be exactly the value specified in the ACL request, the		updated to be exactly the value specified in the ACL request, the
	ACL request MUST fail. If a server restricts the set of ACEs		ACL request MUST fail. If a server restricts the set of ACEs
	visible to the current user via the DAV:acl property, then the ACL		visible to the current user via the DAV:acl property, then the ACL
	request would only replace the set of ACEs visible to the current		request would only replace the set of ACEs visible to the current
	user, and would not affect any ACE that was not visible.		user, and would not affect any ACE that was not visible.
	In order to avoid overwriting DAV:acl changes by another client, a		In order to avoid overwriting DAV:acl changes by another client, a
	client SHOULD acquire a WebDAV lock on the resource before		client SHOULD acquire a WebDAV lock on the resource before
	retrieving the DAV:acl property of a resource that it intends on		retrieving the DAV:acl property of a resource that it intends on
	updating.		updating.
			Clemm, Hopkins, Sedlar, Whitehead [Page 19]
			When submitting ACEs, clients MUST NOT include the optional prop
			element (a child of the principal element). The purpose of this
			restriction is to limit the scope of effect of the ACL method to
			just the resource identified by the Request-URI; setting the prop
			element would additionally require property modification for one or
			more principal resources.
	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 403		constraints on an ACL request. If the constraint is violated, a
	(Forbidden) response MUST be returned and the indicated XML element		403 (Forbidden) response MUST be returned and the indicated XML
	MUST be returned in the response body.		element MUST be returned in the response body.
	<DAV:protected/>: An implementation MAY protect an ACE from		<DAV:protected/>: An implementation MAY protect an ACE from
	modification or deletion. For example, some implementations		modification or deletion. For example, some implementations
	implicitly grant the DAV:owner of a resource DAV:read-acl and		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:write-acl privileges, and this cannot be changed by a client.
	<DAV:too-many-aces/>: An implementation MAY limit the number of ACEs		<DAV:too-many-aces/>: An implementation MAY limit the number of
	in an ACL. However, ACL-compliant servers MUST support at least one		ACEs in an ACL. However, ACL-compliant servers MUST support at
	ACE granting privileges to a single principal, and one ACE granting		least one ACE granting privileges to a single principal, and one
	privileges to a collection principal.		ACE granting privileges to a collection principal.
	<DAV:non-inherited-must-precede-inherited/>: All non-inherited ACEs		<DAV:non-inherited-must-precede-inherited/>: All non-inherited ACEs
	MUST precede all inherited ACEs.		MUST precede all inherited ACEs.
	<DAV:deny-must-precede-grant/>: All non-inherited deny ACEs MUST		<DAV:deny-must-precede-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
			409 (Conflict) response, and the indicated XML element MUST be
			returned in the response body:
			<DAV:inhereted-exist-parent>: Inherited ACEs MUST exist on a parent
			resource.
	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
	Clemm, Hopkins, Sedlar, Whitehead [Page 17]
	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., the
	user "esedlar") read and write privileges, grants the owner of the		user "esedlar") read and write privileges, grants the owner of the
	resource read-acl and write-acl privileges, and grants everyone read		resource read-acl and write-acl privileges, and grants everyone
	privileges inherited from the parent collection		read privileges inherited from the parent collection
	http://www.foo.bar/top/.		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>
	<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>
	skipping to change at page 27, line ?		skipping to change at line 1109
	>> 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 omission of protected ACE
	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 grant the
	principal identified by the URL http://www.foo.org/users/esedlar		principal identified by the URL http://www.foo.org/users/esedlar
	(i.e., the user "esedlar") read privileges, but fails because an		(i.e., the user "esedlar") read privileges. Prior to the request,
	protected ACE has been omitted (e.g. the ACE granting the DAV:owner		the DAV:acl property on the resource contained a protected ACE (see
	DAV:read-acl and DAV:write-acl privileges must always be present		Section 5.4.3) granting DAV:owner the DAV:read-acl and DAV:write-
	since it is protected -- see Section 5.4.3).		acl privileges. The ACL method invocation fails because this
			protected ACE is omitted, thus violating the semantics of ACE
			protection..
	Clemm, Hopkins, Sedlar, Whitehead [Page 18]
	>> 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]
	<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:grant>
	<D:privilege> <D:read/> </D:privilege> </D:grant>		<D:privilege> <D:read/> </D:privilege> </D:grant>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
	skipping to change at page 27, line ?		skipping to change at line 1152
	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/>
	8.1.4 Example: ACL method failure due to inherited ACEs preceding non-		8.1.4 Example: ACL method failure due to inherited ACEs preceding non-
	inherited ACEs		inherited ACEs
	In the following request, user "ejw", authenticated by information		In the following request, user "ejw", authenticated by information
	in the Authorization header, tries to change the access control list		in the Authorization header, tries to change the access control
	on the resource http://www.foo.org/top/index.html. This resource has		list on the resource http://www.foo.org/top/index.html. This
	two inherited ACEs.		resource has two inherited ACEs.
	Inherited ACE #1 grants the principal identified by URL		Inherited ACE #1 grants the principal identified by URL
	http://www.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. On
	this server, http://www.foo.org/privs/write-all is an aggregate		this server, http://www.foo.org/privs/write-all is an aggregate
	privilege containing DAV:write, and DAV:write-acl.		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 add a third ACE, granting the principal
	identified by the URL http://www.foo.org/users/gclemm (i.e., the		identified by the URL http://www.foo.org/users/gclemm (i.e., the
	user "gclemm") DAV:write permission, but in the request places the		user ôgclemmö) DAV:write permission, but in the request places the
	inherited ACEs before the non-inherited ACEs, causing an error on		inherited ACEs before the non-inherited ACEs, causing an error on
	this specific server implementation. Note that on a different		this specific server implementation. Note that on a different
	implementation, this request might be accepted.		implementation, this request might be accepted.
	>> Request <<		>> Request <<
	Clemm, Hopkins, Sedlar, Whitehead [Page 19]
	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",
	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:grant>
	<D:privilege><F:write-all/></D:privilege>		<D:privilege><F:write-all/></D:privilege>
	<D:privilege><D:read-acl/></D:privilege>		<D:privilege><D:read-acl/></D:privilege>
	</D:grant>		</D:grant>
	<D:inherited/>		<D:inherited/>
	</D:ace>		</D:ace>
	skipping to change at page 27, line ?		skipping to change at line 1217
	>> 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:non-inherited-must-precede-inherited/>
	8.1.5 Example: ACL method failure due to an attempt to set grant and		8.1.5 Example: ACL method failure due to an attempt to set grant and deny
	deny in a single ACE.		in a single ACE.
	In this example, user "ygoland", authenticated by information in the		In this example, user "ygoland", authenticated by information in
	Authorization header, tries to change the access control list on the		the Authorization header, tries to change the access control list
	resource http://www.foo.org/diamond/engagement-ring.gif. The ACL		on the resource http://www.foo.org/diamond/engagement-ring.gif. The
	request includes a single, syntactically and semantically incorrect		ACL request includes a single, syntactically and semantically
	ACE, which attempts to grant the collection principal identified by		incorrect ACE, which attempts to grant the collection principal
	the URL http://www.foo.org/users/friends/ DAV:read privilege and		identified by the URL http://www.foo.org/users/friends/ DAV:read
	deny the principal identified by URL		privilege and deny the principal identified by URL
	http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-so")		http://www.foo.org/users/ygoland-so (i.e., the user "ygoland-so")
	DAV:read privilege. However, it is illegal to have multiple		DAV:read privilege. However, it is illegal to have multiple
	Clemm, Hopkins, Sedlar, Whitehead [Page 20]
	principal elements, as well as both a grant and deny element in the		principal elements, as well as both a grant and deny element in the
	same ACE, so the request fails due to poor syntax.		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="...",		uri="/diamond/engagement-ring.gif", response="...", opaque="..."
	opaque="..."
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<D:acl xmlns:D="DAV:">		<D:acl xmlns:D="DAV:">
	<D:ace>		<D:ace>
	<D:principal>		<D:principal>
	<D:href>http://www.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>
	skipping to change at page 27, line ?		skipping to change at line 1270
	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 syntactically
	well formed.		well formed.
	9 INTERNATIONALIZATION CONSIDERATIONS		9 INTERNATIONALIZATION CONSIDERATIONS
	In this specification, the only human-readable content can be found		In this specification, the only human-readable content can be found
	in the DAV:authentication-id property, found on principal resources.		in the description XML element, found within the DAV:supported-
	This property contains the name used to authenticate a principal,		privilege-set property. This element contains a human-readable
	typically by a user entering this name into a password entry screen.		description of the capabilities controlled by a privilege. As a
	As a result, the authentication-id must be capable of representing		result, the description element must be capable of representing
	names in multiple character sets. Since DAV:authentication-id is a		descriptions in multiple character sets. Since the description
	WebDAV property, it is represented on-the-wire as XML [REC-XML], and		element is found within a WebDAV property, it is represented on-
	hence can leverage XML's language tagging and character set encoding		the-wire as XML [REC-XML], and hence can leverage XML's language
	capabilities. Specifically, XML processors must, at minimum, be able		tagging and character set encoding capabilities. Specifically, XML
	to read XML elements encoded using the UTF-8 [UTF-8] encoding of the		processors must, at minimum, be able to read XML elements encoded
	ISO 10646 multilingual plane. XML examples in this specification		using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual
	demonstrate use of the charset parameter of the Content-Type header,		plane. XML examples in this specification demonstrate use of the
	as defined in [RFC3023], as well as the XML "encoding" attribute,		charset parameter of the Content-Type header, as defined in
	which together provide charset identification information for MIME		[RFC3023], as well as the XML "encoding" attribute, which together
	and XML processors.		provide charset identification information for MIME and XML
			processors.
	Clemm, Hopkins, Sedlar, Whitehead [Page 21]		For XML elements other than the description element, it is expected
	For properties other than DAV:authentication-id, it is expected that		that implementations will treat the property names, privilege
	implementations will treat the property names and values as tokens,		names, and values as tokens, and convert these tokens into human-
	and convert these tokens into human-readable text in the user's		readable text in the user's language and character set when
	language and character set when displayed to a person. Only a		displayed to a person. Only a generic WebDAV property display
	generic WebDAV property display utility would display these values		utility would display these values in their raw form to a human
	in their raw form.		user.
			Clemm, Hopkins, Sedlar, Whitehead [Page 24]
	For error reporting, we follow the convention of HTTP/1.1 status		For error reporting, we follow the convention of HTTP/1.1 status
	codes, including with each status code a short, English description		codes, including with each status code a short, English description
	of the code (e.g., 200 (OK)). While the possibility exists that a		of the code (e.g., 200 (OK)). While the possibility exists that a
	poorly crafted user agent would display this message to a user,		poorly crafted user agent would display this message to a user,
	internationalized applications will ignore this message, and display		internationalized applications will ignore this message, and
	an appropriate message in the user's language and character set.		display an appropriate message in the user's language and character
			set.
	Further internationalization considerations for this protocol are		Further internationalization considerations for this protocol are
	described in the WebDAV Distributed Authoring protocol specification		described in the WebDAV Distributed Authoring protocol
	[RFC2518].		specification [RFC2518].
	10 SECURITY CONSIDERATIONS		10 SECURITY CONSIDERATIONS
	Applications and users of this access control protocol should be		Applications and users of this access control protocol should be
	aware of several security considerations, detailed below. In		aware of several security considerations, detailed below. In
	addition to the discussion in this document, the security		addition to the discussion in this document, the security
	considerations detailed in the HTTP/1.1 specification [RFC2616], the		considerations detailed in the HTTP/1.1 specification [RFC2616],
	WebDAV Distributed Authoring Protocol specification [RFC2518], and		the WebDAV Distributed Authoring Protocol specification [RFC2518],
	the XML Media Types specification [RFC3023] should be considered in		and the XML Media Types specification [RFC3023] should be
	a security analysis of this protocol.		considered in a security analysis of this protocol.
	10.1 Increased Risk of Compromised Users		10.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 specifications, if a single user's authentication		control lists, if a single user's authentication credentials are
	credentials are compromised, only those resources for which the user		compromised, only those resources for which the user has access
	has access permission can be read, modified, moved, or deleted. With		permission can be read, modified, moved, or deleted. With the
	the introduction of this access control protocol, if a single		introduction of this access control protocol, if a single
	compromised user has the ability to change ACLs for a broad range of		compromised user has the ability to change ACLs for a broad range
	other users (e.g., a super-user), the number of resources that could		of other users (e.g., a super-user), the number of resources that
	be altered by a single compromised user increases. This risk can be		could be altered by a single compromised user increases. This risk
	mitigated by limiting the number of people who have write-acl		can be mitigated by limiting the number of people who have write-
	privileges across a broad range of resources.		acl privileges across a broad range of resources.
	10.2 Authentication-id Property and Dictionary Attacks
	Every principal has a DAV:authentication-id property defined on it,
	which provides the name used to authenticate this principal,
	typically the username portion of a username/password authentication
	scheme. An attacker can use the information in this property when
	attempting either a brute-force, or a dictionary attack to guess the
	principal's identifying password. By providing the username in
	DAV:authentication-id, the scope of an attack can be reduced to a
	single, valid username. Furthermore, it is possible that principals
	can potentially belong to a collection. In this case, it is possible
	to use the PROPFIND method to retrieve the DAV:authentication-id
	property from all of the principals in a collection, thus providing
	multiple usernames that can be the focus of attack.
	Clemm, Hopkins, Sedlar, Whitehead [Page 22]
	To reduce this risk, the DAV:authentication-id property should not
	be world-readable. Which principals are granted default read
	privilege for DAV:authentication-id should be carefully considered
	in any deployment of this protocol.
	10.3 Risks of the read-acl Privilege		10.2 Risks of the read-acl and cuprivset Privileges
	The ability to read the access privileges (stored in the DAV:acl		The ability to read the access privileges (stored in the DAV:acl
	property), or the privileges permitted the currently authenticated		property), or the privileges permitted the currently authenticated
	user (stored in the DAV:current-user-privilege-set property) on a		user (stored in the DAV:current-user-privilege-set property) on a
	resource may seem innocuous, since reading an ACL cannot possibly		resource may seem innocuous, since reading an ACL cannot possibly
	affect the resource's state. However, if all resources have world-		affect the resource's state. However, if all resources have world-
	readable ACLs, it is possible to perform an exhaustive search for		readable ACLs, it is possible to perform an exhaustive search for
	those resources that have inadvertently left themselves in a		those resources that have inadvertently left themselves in a
	vulnerable state, such as being world-writeable. In particular, the		vulnerable state, such as being world-writeable. In particular, the
	property retrieval method PROPFIND, executed with Depth infinity on		property retrieval method PROPFIND, executed with Depth infinity on
	an entire hierarchy, is a very efficient way to retrieve the DAV:acl		an entire hierarchy, is a very efficient way to retrieve the
	or DAV:current-user-privilege-set properties. Once found, this		DAV:acl or DAV:current-user-privilege-set properties. Once found,
	vulnerability can be exploited by a denial of service attack in		this vulnerability can be exploited by a denial of service attack
	which the open resource is repeatedly overwritten. Alternately,		in which the open resource is repeatedly overwritten. Alternately,
	writeable resources can be modified in undesirable ways.		writeable resources can be modified in undesirable ways.
	To reduce this risk, read-acl privileges should not be granted to		To reduce this risk, read-acl privileges should not be granted to
	unauthenticated principals, and restrictions on read-acl privileges		unauthenticated principals, and restrictions on read-acl and
	for authenticated principals should be carefully analyzed when
	deploying this protocol.		Clemm, Hopkins, Sedlar, Whitehead [Page 25]
			cuprivset privileges for authenticated principals should be
			carefully analyzed when deploying this protocol. Access to the
			current-user-privilege-set property will involve a tradeoff of
			usability versus security. When the current-user-privilege-set is
			visible, user interfaces are expected to provide enhanced
			information concerning permitted and restricted operations, yet
			this information may also indicate a vulnerability that could be
			exploited. Deployment of this protocol will need to evaluate this
			tradeoff in light of the requirements of the deployment
			environment.
	11 AUTHENTICATION		11 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 Digest
	authentication mechanisms defined in [RFC2617].		authentication mechanisms defined in [RFC2617].
	12 IANA CONSIDERATIONS		12 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] also		elements. All other IANA considerations mentioned in [RFC2518]
	applicable to WebDAV ACL.		also applicable to WebDAV ACL.
	13 INTELLECTUAL PROPERTY		13 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 property
	claims made against this document.		claims made against this document.
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use other technology described in		pertain to the implementation or use other technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on
	IETF's procedures with respect to rights in standards-track and		the IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances		claims of rights made available for publication and any assurances
	of licenses to be made available, or the result of an attempt made		of licenses to be made available, or the result of an attempt made
	Clemm, Hopkins, Sedlar, Whitehead [Page 23]
	to obtain a general license or permission for the use of such		to obtain a general license or permission for the use of such
	proprietary rights by implementers or users of this specification		proprietary rights by implementers or users of this specification
	can be obtained from the IETF Secretariat.		can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to practice		rights that may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF
	Director.		Executive Director.
	14 ACKNOWLEDGEMENTS		14 ACKNOWLEDGEMENTS
	This protocol is the collaborative product of the WebDAV ACL design		This protocol is the collaborative product of the WebDAV ACL design
	team: Bernard Chester, Geoff Clemm (Rational), Anne Hopkins		team: Bernard Chester, Geoff Clemm (Rational), Anne Hopkins
			Clemm, Hopkins, Sedlar, Whitehead [Page 26]
	(Microsoft), Barry Lind (Xythos), Sean Lyndersay (Microsoft), Eric		(Microsoft), Barry Lind (Xythos), Sean Lyndersay (Microsoft), Eric
	Sedlar (Oracle), Greg Stein (Apache.org), and Jim Whitehead (UC		Sedlar (Oracle), Greg Stein (Apache.org), and Jim Whitehead (UC
	Santa Cruz). The authors are grateful for the detailed review and		Santa Cruz). 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 Chintalapati,
	Dennis Hamilton, Ron Jacobs, Chris Knight, and Remy Maucherat. Prior		Dennis Hamilton, Laurie Harper, Ron Jacobs, Chris Knight, and Remy
	work on WebDAV access control protocols has been performed by Yaron		Maucherat. Prior work on WebDAV access control protocols has been
	Goland, Paul Leach, Lisa Dusseault, Howard Palmer, and Jon Radoff.		performed by Yaron Goland, Paul Leach, Lisa Dusseault, Howard
	We would like to acknowledge the foundation laid for us by the		Palmer, and Jon Radoff. We would like to acknowledge the foundation
	authors of the WebDAV and HTTP protocols upon which this protocol is		laid for us by the authors of the WebDAV and HTTP protocols upon
	layered, and the invaluable feedback from the WebDAV working group.		which this protocol is layered, and the invaluable feedback from
			the WebDAV working group.
	15 REFERENCES		15 REFERENCES
	15.1 Normative References		15.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 Recommendation
	REC-xml-19980210. http://www.w3.org/TR/REC-xml-19980210.		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 Protocol		Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer
	-- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, Xerox, Microsoft,		Protocol -- HTTP/1.1." RFC 2616. U.C.Irvine, Compaq, Xerox,
	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. Lawrence, P.
	Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and		Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and
	Digest Access Authentication. " RFC 2617. Northwestern University,		Digest Access Authentication. " RFC 2617. Northwestern University,
	Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market,		Verisign, AbiSource, Agranat, Microsoft, Netscape, Open Market,
	June, 1999.		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." RFC
	2518. Microsoft, U.C.Irvine, Netscape, Novell, February, 1999.		2518. Microsoft, U.C.Irvine, Netscape, Novell, February, 1999.
			[RFC2368] P. Hoffman, L. Masinter, J. Zawinski, "The mailto URL
			scheme." RFC 2368. Internet Mail Consortium, Xerox, Netscape, July,
			1998.
			[RFC2255] T. Howes, M. Smith, "The LDAP URL Format." RFC 2255.
			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." RFC
	3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon Ventures,		3023. IBM Tokyo Research Laboratory, simonstl.com, Skymoon
	January, 2001.		Ventures, January, 2001.
	Clemm, Hopkins, Sedlar, Whitehead [Page 24]
	[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and		[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and
	ISO 10646." RFC 2279. Alis Technologies. January, 1998.		ISO 10646." RFC 2279. Alis Technologies. January, 1998.
			Clemm, Hopkins, Sedlar, Whitehead [Page 27]
	15.2Informational References		15.2Informational References
	[RFC2026] S.Bradner, "The Internet Standards Process û Revision 3."		[RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3."
	RFC 2026, BCP 9. Harvard, October, 1996.		RFC 2026, BCP 9. Harvard, October, 1996.
	16 AUTHORS' ADDRESSES		16 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
	skipping to change at page 27, line ?		skipping to change at line 1502
	17 APPENDICIES		17 APPENDICIES
	17.1XML Document Type Definition		17.1XML 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 write-acl EMPTY>		<!ELEMENT write-acl EMPTY>
	<!ELEMENT all EMPTY>		<!ELEMENT all EMPTY>
	<!-- Principal Properties (Section 4) -->		<!-- Principal Properties (Section 4) -->
	Clemm, Hopkins, Sedlar, Whitehead [Page 25]
	<!ELEMENT is-principal (#PCDATA)>		<!ELEMENT is-principal (#PCDATA)>
	<!ELEMENT authentication-id (#PCDATA)>
			<!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*)>
	skipping to change at page 27, line ?		skipping to change at line 1561
	<!ELEMENT grant (privilege+)>		<!ELEMENT grant (privilege+)>
	<!ELEMENT deny (privilege+)>		<!ELEMENT deny (privilege+)>
	<!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) -->
	Clemm, Hopkins, Sedlar, Whitehead [Page 26]
	<!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, required-
	principal)>		principal*)>
	<!ELEMENT ace-combination		<!ELEMENT ace-combination
	(first-match | all-grant-before-any-deny | no-deny)>		(first-match | all-grant-before-any-deny | specific-deny-
			overrides-grant)>
	<!ELEMENT first-match EMPTY>		<!ELEMENT first-match EMPTY>
	<!ELEMENT all-grant-before-any-deny EMPTY>		<!ELEMENT all-grant-before-any-deny EMPTY>
	<!ELEMENT no-deny 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 required-principal		<!ELEMENT required-principal
	(href | all | authenticated | unauthenticated | property |		(href | all | authenticated | unauthenticated | property | self)>
	self)>
	<!-- ACL method preconditions (Section 8.1.1) -->		<!-- ACL method preconditions (Section 8.1.1) -->
	<!ELEMENT protected EMPTY>		<!ELEMENT protected EMPTY>
	<!ELEMENT too-many-aces EMPTY>		<!ELEMENT too-many-aces EMPTY>
	<!ELEMENT non-inherited-must-precede-inherited EMPTY>		<!ELEMENT non-inherited-must-precede-inherited EMPTY>
	<!ELEMENT deny-must-precede-grant EMPTY>		<!ELEMENT deny-must-precede-grant EMPTY>
	<!ELEMENT acl-requires-lock-token EMPTY>		<!ELEMENT acl-requires-lock-token EMPTY>
			<!ELEMENT inherited-exist-parent EMPTY>
			Clemm, Hopkins, Sedlar, Whitehead [Page 30]
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/