draft-ietf-webdav-acl-01.txt		draft-ietf-webdav-acl-02.txt
	INTERNET-DRAFT Eric Sedlar, Oracle Corporation		INTERNET-DRAFT Geoffrey Clemm, Rational Software
	draft-ietf-webdav-acl-01.txt Geoffrey Clemm, Rational Software		draft-ietf-webdav-acl-02 Anne Hopkins, Microsoft Corporation
			Eric Sedlar, Oracle Corporation
	Expires November 1, 2000 May 1, 2000		Expires January 14, 2001 July 14, 2000
	Access Control Extensions to WebDAV		Access Control Extensions to WebDAV
	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 Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six 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		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document specifies a set of methods, headers, and resource-types		This document specifies a set of methods, headers, and resource-types
	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.		protocol.
	Sedlar, Clemm [Page 1]
	Table of Contents		Table of Contents
	1 INTRODUCTION............................................3		1 INTRODUCTION............................................3
	1.1 Notational Conventions................................3		1.1 Notational Conventions................................3
	2 PRINCIPALS..............................................3		2 PRINCIPALS..............................................3
	3 RIGHTS..................................................4		3 RIGHTS..................................................4
	3.1 RIGHTS-DISCOVERY method...............................5		3.1 DAV:access-rights property............................5
	3.2 Rights defined by WebDAV..............................6		3.2 Rights defined by WebDAV..............................6
	3.2.1 read Right........................................6		3.2.1 read Right........................................6
	3.2.2 write Right.......................................6		3.2.2 write Right.......................................7
	3.2.3 readacl Right.....................................6		3.2.3 readacl Right.....................................7
	3.2.4 writeacl Right....................................6		3.2.4 writeacl Right....................................7
	3.2.5 all Right.........................................6		3.2.5 all Right.........................................7
	4 ACCESS CONTROL PROPERTIES...............................7		4 ACCESS CONTROL PROPERTIES...............................7
	4.1 Example 1 - Retrieving Access Control information.....8		4.1 Retrieving Access Control Information................11
			4.1.1 Example: Retrieving Access Control information...11
	5 USING ACLS..............................................9		4.2 Setting Access Control Information...................12
			4.2.1 Example: Setting Access Control information......13
	6 ACL METHOD.............................................10		5 USING ACLS.............................................14
	6.1 Example 1 - Setting ACLs.............................10		5.1 System Controlled Rights.............................14
			5.2 Special Principal Identifiers........................15
			5.3 ACL Semantics Options................................15
			5.3.1 FirstSpecific....................................16
			5.3.2 ExplicitDenyPrecedence...........................16
	7 ACL INHERITANCE / DEFAULT ACLS.........................11		6 ACL INHERITANCE........................................18
			6.1 Inheritable ACEs.....................................18
			6.2 Propagate ACE but do not use for Access Check on this resource....19
			6.3 Propagate to immediate children only.................19
			6.4 Protect ACL from inheritance.........................19
	8 XML SCHEMA FOR DEFINED ELEMENTS........................12		7 XML SCHEMA FOR DEFINED ELEMENTS........................20
	9 INTERNATIONALIZATION CONSIDERATIONS....................13		8 INTERNATIONALIZATION CONSIDERATIONS....................21
	10 SECURITY CONSIDERATIONS..............................13		9 SECURITY CONSIDERATIONS................................21
	11 SCALABILITY..........................................13		10 SCALABILITY..........................................21
	12 AUTHENTICATION.......................................13		11 AUTHENTICATION.......................................21
	13 IANA CONSIDERATIONS..................................13		12 IANA CONSIDERATIONS..................................21
	14 INTELLECTUAL PROPERTY................................13		13 INTELLECTUAL PROPERTY................................21
	15 ACKNOWLEDGEMENTS.....................................14		14 ACKNOWLEDGEMENTS.....................................22
	16 INDEX................................................14		15 INDEX................................................22
			16 REFERENCES...........................................22
	17 REFERENCES...........................................14		17 AUTHORS' ADDRESSES...................................23
	18 AUTHORS' ADDRESSES...................................15		18 STILL TO DO :........................................23
	19 STILL TO DO :........................................15		19 OPEN ISSUES:.........................................25
	Sedlar, Clemm [Page 2]
	1 INTRODUCTION		1 INTRODUCTION
	The underlying principle of access control is that who you are		The 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.		servers, and groups of the previous have principal identifiers.
	The "how" is determined by an "access control list" (ACL)		The "how" is determined by an "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		control entries" (ACEs), where each ACE specifies a principal and
	a set of rights that are either granted or denied to that		a set of rights that are either granted or denied to that
	skipping to change at line 120		skipping to change at page 3, line 44
	2 PRINCIPALS		2 PRINCIPALS
	A principal identifies an entity that can be given access rights		A principal identifies an entity that can be given access rights
	to HTTP resources. On many implementations, a user or a group		to HTTP resources. On many implementations, a user or a group
	will be examples of principals, but other types of principals are		will be examples of principals, but other types of principals are
	possible. For the most part, any classification or other		possible. For the most part, any classification or other
	information about the entity identified by a principal is opaque		information about the entity identified by a principal is opaque
	with respect to this specification, and is dependent on the		with respect to this specification, and is dependent on the
	implementation.		implementation.
	Principals are manifested to clients as a HTTP resource,		Principals are manifested to clients as a HTTP resource,
	identified by a URL. The set of properties exposed by that		identified by a URL. The set of properties exposed by that
	resource are implementation dependent, although certain		resource are implementation dependent, although certain
	properties are required by this specification. Those properties		properties are required by this specification. Those properties
	include:		include:
			. DAV:principalname: A 'live' property containing the name
			used to authenticate this principal (typically typed into a
			login prompt/dialog). [OPTIONAL]
			. DAV:displayname: A property containing a human-readable
			description of this principal. This property may be "live"
			and not settable via PROPPATCH. [REQUIRED]
	@ <dav:principalname>: A "live" property containing the		. DAV:principal-type: A 'live' property containing a
	name used to authenticate this principal		classification word for this principal. The values DAV:user
	(typically typed into a login prompt/dialog).		and DAV:group are choices for value of this property
	[OPTIONAL]		recommended by this spec. The presence of this property can be
			used to distinguish it as a principal from other resources on
	@ <dav:displayname>: A property containing a human-readable		a WebDAV server. (Note that DAV:resourcetype may not be used,
	description of this principal. This property		as all collections must use the value "collection" for
	may be "live" and not settable via PROPPATCH.		DAV:resourcetype, which wouldn't distinguish normal
	[REQUIRED]		collections from principal collections.) [REQUIRED]
	@ <dav:principal-type>: A "live" property containing a
	classification word for this principal. The
	values <dav:user/> and <dav:group/> are
	choices for value of this property
	recommended by this spec. The presence of
	Sedlar, Clemm [Page 3]
	this property can be used to distinguish it
	as a principal from other resources on a
	WebDAV server. (Note that <dav:resourcetype>
	may not be used, as all collections must use
	the value "collection" for <resourcetype>,
	which wouldn't distinguish normal collections
	from principal collections.) [REQUIRED]
	Server implementations may include any other descriptive		Server implementations may include any other descriptive
	information for a principal via properties.		information for a principal via properties.
	A principal resource may or may not be a collection. A		A principal resource may or may not be a collection. A
	collection principal may only contain other principals (not other		collection principal may only contain other principals (not other
	types of resources). Servers that support aggregation of		types of resources). Servers that support aggregation of
	principals (e.g. groups of users or other groups) MUST manifest		principals (e.g. groups of users or other groups) MUST manifest
	them as collection principals. The WebDAV methods for examining		them as collection principals. The WebDAV methods for examining
	maintaining collections (e.g. BIND, DELETE, PROPFIND) may be used		maintaining collections (e.g. DELETE, PROPFIND) may be used to
	to maintain collection principals. Membership in a collection		maintain collection principals. Membership in a collection
	principal is recusive, so a principal in a collection principal A		principal is recursive, so a principal in a collection principal
	contained by collection principal B is a member of both		A contained by collection principal B is a member of both
	collection principals. Implementations not supporting recursive		collection principals. Implementations not supporting recursive
	membership in principal collections can return an error if the		membership in principal collections can return an error if the
	client attempts to bind collection principals into other		client attempts to bind collection principals into other
	collection principals. Using WebDAV methods to alter the content		collection principals. Using WebDAV methods to alter the content
	of a principal (e.g. using PROPPATCH or PUT) is outside the scope		of a principal (e.g. using PROPPATCH or PUT) is outside the scope
	of this specification, and is not required, recommended, or		of this specification, and is not required, recommended, or
	forbidden by this spec.		forbidden by this spec.
	3 RIGHTS		3 RIGHTS
	A right controls access to a particular set of HTTP operations on		A right controls access to a particular set of HTTP operations on
	a resource. The set of rights that apply to a particular		a resource. The set of rights that apply to a particular
	resource may vary with the <dav:resourcetype> of the resource, as		resource may vary with the DAV:resourcetype of the resource, as
	well as between different server implementations. To promote		well as between different server implementations. To promote
	interoperability, however, WebDAV defines a set of well-known		interoperability, however, WebDAV defines a set of well-known
	rights (e.g. <dav:read> and <dav:write>), which can at least be		rights (e.g. DAV:read and DAV:write), which can at least be used
	used to set some context to the other rights defined on a		to set some context to the other rights defined on a particular
	particular resource.		resource.
	Rights may be aggregates of other rights. For example, one		Rights may be aggregates of other rights. For example, one
	implementation may split out a right controlling the ability to		implementation may split out a right controlling the ability to
	BIND children into a collection from the right allowing a		add children to a collection from the right allowing a resource
	resource to be removed from a collection. Since these rights		to be removed from a collection. Since these rights control the
	control the ability to write to a collection, these rights would		ability to write to a collection, these rights would be
	be aggregated by the <dav:write> right. The relationships		aggregated by the DAV:write right. The relationships between
	between atomic rights and aggregate rights can be discovered via		atomic rights and aggregate rights can be discovered via the
	the RIGHTS-DISCOVERY HTTP method on a particular resource.		DAV:access-rights property on a particular resource. Servers may
	Servers may specify some rights as abstract, which means that it		specify some rights as abstract, which means that it MUST not
	may not appear in an ACL, but is described in the RIGHTS-		appear in an ACL, but is described in the DAV:access-rights
	DISCOVERY method to aid in setting context. Server		property to aid in setting context. Server implementations must
	implementations must return the same response to the RIGHTS-		return the same response to the DAV:access-rights property on all
	DISCOVERY method on all of the resources with the same		of the resources with the same DAV:resourcetype value.
	<dav:resourcetype> value.
	Sedlar, Clemm [Page 4]		3.1 DAV:access-rights property
	3.1 RIGHTS-DISCOVERY method
	Rights discovery is a method with no arguments, that returns the		The DAV:access-rights property is a live property that contains
	rights aggregation tree. Each right appears as an XML element,		the rights aggregation tree. The DAV:access-rights property MUST
			be available on every resource available via a WebDAV Access
			Control-compliant server. Each right appears as an XML element,
	where aggregate rights list all of their children as sub-		where aggregate rights list all of their children as sub-
	elements. Each right element can contain the following		elements. Each right element can contain the following
	attributes:		attributes:
			. abstract (Boolean): 'true' if this right MUST NOT be used in
			an ACL/ACE. Defaults to 'false.' Note: an abstract right need
			not be an aggregate right.
	@ abstract (Boolean): "true" if this right cannot be used in		. Description (string): a human-readable description of what
	an ACL/ACE. Defaults to "false"		this right controls access to. [REQUIRED]. The server MAY
			localize this description, based on the Accept-Language header
	@ description (string): a human readable description of what		of the request.
	this right controls access to. Required.
	For example, the following response might be generated to a		For example, the following response might be generated to a
	RIGHTS-DISCOVERY request on a WebDAV server implemented by a		request on a WebDAV server.
	relational database (where the resource in this case corresponds
	to a table):
	Request		Request
	RIGHTS-DISCOVERY /schemas/scott/emp HTTP/1.1		PROPFIND /file HTTP/1.1
	Host: www.foo.bar		Host: www.foo.bar
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: 0		Accept-Language: en-us
			Depth: 0
			Content-Length: xxx
			<?xml version="1.0" encoding="utf-8"?>
			<D:propfind xmlns:D="DAV:">
			<D:prop>
			<D:access-rights/>
			</D:prop>
			</D:propfind>
	Response		Response
	HTTP/1.1 200 Success		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: xxxxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0"?>
	<?namespace href = "http://www.oracle.com/webdav/ AS = ORA"?>		<D:multistatus xmlns:D="DAV:"
			xlmns:A="http://www.foo.bar/schema/">
	<D:response>		<D:response>
	<D:all abstract=true description="All access">		<D:href>http://www.foo.bar/file</D:href>
	<D:write abstract=true description="Write any database row">		<D:propstat>
	<ORA:insert abstract=false description="Insert a row"/>		<D:status>HTTP/1.1 200 OK</D:status>
	<ORA:update abstract=false description="Update a row"/>		<D:prop>
	<ORA:delete abstract=false description="Delete a row"/>		<D:access-rights>
	</D:write>		<D:all>
	<D:read abstract=false description="SELECT data from a row"/>		<D:write abstract="true" description="Write any
	<D:readacl abstract=false description="Read the ACL"/>		object">
	<D:acadmin abstract=false description="Update the ACL and		<A:create abstract="false" description="Create an
	owner"/>		object"/>
			<A:update abstract="false" description="Update an
			object"/>
			<A:delete abstract="false" description="Delete an
			object"/>
			<D:write/>
			<D:read abstract="false" description="Read any
			object"/>
			<D:readacl abstract="false" description="Read the
			ACL"/>
			<D:writeacl abstract="false" description="Write the
			ACL"/>
	</D:all>		</D:all>
			</D:access-rights>
			</D:prop>
			</D:propstat>
	</D:response>		</D:response>
			</D:multistatus>
	It is envisioned that a WebDAV ACL-aware administrative client		It is envisioned that a WebDAV ACL-aware administrative client
	would list the available in a dialog box, and allow the user to		would list the available rights in a dialog box, and allow the
	choose non-abstract rights to apply in an ACE. The rights tree		user to choose non-abstract rights to apply in an ACE. The
	is useful programmatically to map well-known rights (defined by		rights tree is useful programmatically to map well-known rights
	WebDAV or other standards groups) into rights that are supported		(defined by WebDAV or other standards groups) into rights that
	by any particular server implementation.		are supported by any particular server implementation.
	Sedlar, Clemm [Page 5]
	3.2 Rights defined by WebDAV		3.2 Rights defined by WebDAV
	The rights defined by WebDAV access control MUST be present in		The rights defined by WebDAV access control MUST be present in
	the response to the RIGHTS-DISCOVERY method, although they may be		the DAV:access-rights property, although they may be abstract
	abstract (and not usable within an ACE on a particular		(and not usable within an ACE on a particular implementation).
	implementation).		Ability to perform a given method on a resource MUST be
			controlled by some right. Authors of Internet drafts that define
			new methods must specify which right (by defining a new right, or
			mapping to one below) is required to perform the method. A
			principal with no rights to a resource should be denied any HTTP
			access to that resource.
	3.2.1read Right		3.2.1read Right
	Name: <dav:read>		Name: DAV:read
	Purpose: The read right provides and restricts access to		Purpose: The read right provides and restricts access to
	information regarding the state of the resource, including the		information regarding the state of the resource, including the
	resource's properties. Affected methods include GET and PROPFIND.		resource's properties. Affected methods include GET and PROPFIND.
	The read right does not affect the OPTIONS method since it		The read right does not affect the OPTIONS method since it
	reflects capabilities rather than state.		reflects capabilities rather than state.
	3.2.2write Right		3.2.2write Right
	Name: <dav:write>		Name: DAV:write
			Purpose: The write right affects the same methods as the
	Purpose: The <write> right affects the same methods as		Write Lock. Please refer to [WEBDAV] section 5.3 for the list of
	the Write Lock. Please refer to [WEBDAV] section 5.3 for the list		affected methods. Note however, that a write lock is a different
	of affected methods. Note however, that a write lock is a		mechanism than a write access change, although they affect the
	different mechanism than a write access change, although they		same methods, they have independent methods to set them and
	affect the same methods, they have independent methods to set		independent error codes.
	them and independent error codes.
	3.2.3readacl Right		3.2.3readacl Right
	Name: <dav:readacl>		Name: DAV:readacl
			Purpose: The readacl right provides and restricts access
	Purpose: The <readacl> right provides and restricts		to the DAV:acl property of this resource, rather than the
	access to the <dav:acl> property of this resource, rather than		DAV:read right. If a user has the readacl right and not the read
	the <dav:read> right. If a user has the <readacl> right and not		right, the DAV:acl and DAV:access-rights properties MUST be
	the <read> right, the <dav:acl> property ONLY is accessible via		accessible via PROPFIND, and the GET method is not authorized.
	PROPFIND, and the GET method is not authorized. If a user has		If a user has the read right and not the readacl right, the
	the <read> right and not the <readacl> right, the <dav:acl>		DAV:acl and DAV:access-rights properties will not be included in
	property will not be included in any PROPFIND requests on the		any PROPFIND requests on the associated resource.
	associated resource.
	3.2.4writeacl Right		3.2.4writeacl Right
	Name: <dav:writeacl>		Name: DAV:writeacl
			Purpose: The writeacl right provides and restricts access
	Purpose: The <writeacl> (Access Control ADMINistration)		to the DAV:acl and DAV:owner properties.
	right provides and restricts access to ACL method, which is the
	only means of altering the <dav:acl> (and indirectly,
	<dav:rights>) property of a resource.
	3.2.5all Right		3.2.5all Right
	Name: <dav:all>		Name: DAV:all
			Purpose: The DAV:all right controls all other rights on
	Sedlar, Clemm [Page 6]		this resource. If the DAV:all right appears in an ACE, it is an
	Purpose: The <dav:all> right controls all other rights on		error to have any other right in that ACE. This right is merely
	this resource. If the <dav:all> right appears in an ACE, it is		shorthand for all of the rights enumerated in the access-rights
	an error to have any other right in that ACE. This right is		property, and should not control access to rights not exposed via
	merely shorthand for all of the rights enumerated in the RIGHTS-		that route.
	DISCOVERY method, and should not control access to rights not
	exposed via that route.
	4 ACCESS CONTROL PROPERTIES		4 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 set and retrieved
	other WebDAV properties, using the PROPFIND method. An HTTP		just like other WebDAV properties, using the PROPFIND and
	resource on a WebDAV ACL-compliant server MUST contain the		PROPPATCH method (subject to permissions and 'liveness.' An HTTP
	following properties:		resource on a WebDAV Access Control-compliant server MUST contain
			the following properties:
			. DAV:owner: A property containing the principal information
			identifying a particular user as the owner of the resource.
	@ <dav:owner>: A property containing the principal		This property is readable by anyone with read access to the
	information identifying a particular user as		resource. [REQUIRED]
	the owner of the resource. This property is
	readable by anyone with read access to the
	resource. There is no provision for a client
	updating this property in this spec, however
	it is recommended that any authenticated user
	with appropriate administrative privileges be
	allowed to issue a PROPPATCH to update its
	value. Normally, an attempt to PROPPATCH this
	property will result in a 401 (Not
	Authorized) error. [REQUIRED]
	@ <dav:owner-name>: A "live" property containing a human-		. DAV:rights: A 'live' readonly property containing the list of
	readable description of the <dav:owner>		rights of the currently authenticated HTTP user. The read
	[OPTIONAL]		right controls read access to this property. [REQUIRED]
	@ <dav:rights>: A "live" property containing the list of		. DAV:acl: A 'live' property containing one or more DAV:ace
	rights of the currently authenticated HTTP		tags, which specify which principals are to get access to what
	user. Read access to this property is		rights, for the resource with this ACL property. [REQUIRED]
	controlled by the <read> right. This
	property can NEVER be set directly.
	[REQUIRED]
	@ <dav:acl>: A "live" property containing one or more		. DAV:aclsemantics: A readonly property indicating the ACL
	<dav:ace> tags, which specify which		semantics model supported by the system. [REQUIRED]
	principals are to get access to what rights,
	for the resource with this ACL property.		. DAV:protectaclfrominheritance: A "live" property indicating
			that the ACL does not inherit any ACEs. If this property is
			present, the ACL should contain no ACEs with the DAV:inherited
			element present. If this property is not present and the
			system supports ACL inheritance, then the ACL will contain
			inheritable ACEs from its parent resource. If a resource
			without this property present is updated with this property,
			it is a client choice whether to remove the inherited ACEs or
			retain them but remove the DAV:inherited element from the
			ACEs. [OPTIONAL]
			The DAV:owner element contains one or more of the following XML
			elements:
			. DAV:href: This contains the URI to the principal resource
			that is the 'owner' of the resource. Normally, an attempt to
			PROPPATCH this property will result in a 401 (Not Authorized)
			error. The principal indicated by the owner property is
			implicitly granted readacl and writeacl rights. This enables
			the owner to restore an appropriate ACL in the case that it
			becomes maliciously or accidently corrupted such that no
			principal is granted the writeacl right by any ACE.
	[REQUIRED]		[REQUIRED]
	The <dav:acl> element (property) contains 0 or more of the		. DAV:principalname, DAV:displayname, DAV:principal-type: These
			are the same as the properties that can exist on the principal
			URI. In this context they are considered 'live.' [OPTIONAL]
			The DAV:acl element (property) contains 0 or more of the
	following XML elements:		following XML elements:
			. DAV:ace: A "live" property representing an access control
			entry, which specifies the set of rights to be either granted
			or denied to a single principal.
	@ <dav:ace>: An access control entry, which specifies the		The DAV:ace element contains the following XML elements:
	set of rights to be granted to a single		. DAV:grant: Contains the set of XML elements corresponding to
	principal.		the rights being granted via this ACE. MUST contain at least
			one right. MUST NOT be present if the DAV:deny element is
			present.
	The <dav:ace> element contains the following XML elements:		. DAV:deny: Contains the set of XML elements corresponding to
			the rights being denied via this ACE. MUST contain at least
			one right, if present. MUST NOT be present if the DAV:grant
			element is present.
	Sedlar, Clemm [Page 7]		. DAV:principal: Contains information about the principal
	@ <dav:grant>: Contains the set of XML elements		resource this ACE applies to. [REQUIRED].
	corresponding to the rights being granted via
	this ACE. Must contain at least one right
	@ <dav:deny>: Contains the set of XML elements		. DAV:acepropertytypes: A "live" property containing one or more
	corresponding to the rights being denied via		elements, each of which is an XML tag identifying either a
	this ACE. Must contain at least one right,		property on this resource or a property on a child resource
	if present.		that may inherit this ACE. Presence of DAV:acepropertytypes
			distinguishes this ACE as a "Property ACE." The rights
			associated with a "Property ACE" control access to only the
			property(ies) contained in DAV:acepropertytypes, and do not
			control access to the resource as a whole. The set of access
			rights supported on Property ACEs may be all or a subset of
			the DAV:access-rights present on this resource. This spec
			does not provide a mechanism to specify a different set of
			access-rights for a property, than for the resource. An
			implementation that supports a different set of access-rights
			for a property than for the resource, must return an error
			"Unsupported Right" on an attempt to write a Property ACE with
			rights not supported by the server. [OPTIONAL]
	@ <dav:principal-id>: A URL of the principal resource this ACE		. DAV:inherittochildtype: A "live" property containing one or
	applies to, or one of the tags <dav:owner> or		more elements, each of which is an XML tag identifying the
	<dav:all-principals>. Always present. The		type of child object that will inherit this ACE. This
	value of this element must be unique within		property is only present if DAV:inheritanceflags contains at
	an ACL.		least one of the following: DAV:inheritonly,
			DAV:containerinherit, or DAV:objectinherit. A child of the
			current resource will only inherit this ACE if the type of the
			child object is present in DAV:inherittochildtype.
	@ <dav:principal>: Contains properties of the principal		. DAV:inheritanceflags: A "live" property containing flags
	resource (made available here to avoid the		indicating the inheritance features of this ACE. For an ACE
	need for a separate PROPFIND request).		that is neither inherited, nor inheritable, this element may
	Optional.		be either not present, or present but empty. [OPTIONAL]
	A PROPFIND on a resource on a WebDAV ACL server might produce the		. DAV:inheritancesource: A readonly property containing the URL
	following XML output:		of the resource from which this ACE was inherited (contained
			within an DAV:href element). In other words, the ACL on the
			resource referred to by this URI contains the inheritable
			explicit ACE which, when propagated to the current resource,
			resulted in the current ACE. This element may contain the
			special value of DAV:system-ace to indicate that the ACE is
			read-only and represents rights granted implicitly by the
			system. This element may contain the special value of
			DAV:unknown if the server is unable to generate a valid URI to
			the resource from which this element was inherited. This
			element MUST be present if DAV:inheritanceflags contains the
			DAV:inherited flag for inherited ACEs and MUST NOT be present
			for explicit ACEs.
	4.1 Example 1 - Retrieving Access Control information		The DAV:principal element contains the following elements:
			. DAV:href: This is a URI representing the resource to which
			the ACE applies, or one of the special principal identifier
			tags (e.g., DAV:owner) described in the "Special Principal
			Identifiers" section of this spec. [REQUIRED]
			. DAV:principalname, DAV:displayname, DAV:principal-type: These
			are the same as the properties that can exist on the principal
			URI. In this context they are considered 'live.' [OPTIONAL]
			The DAV:inheritanceflags element contains 0 or more of the
			following XML elements:
			. DAV:inherited: This flag indicates the ACE is inherited from
			the ACL on a different resource, identified in
			DAV:inheritancesource. This flag MUST be present for an
			inherited ACE and MUST NOT be present for an explicit ACE.
			This flag must not be present if the
			DAV:protectaclfrominheritance element is present on this
			resource unless the DAV:inheritancesource element contains the
			special value DAV:system-ace, indicating that this ACE wasn't
			really inherited, but reflects implicit system-granted rights.
			[REQUIRED]
			. DAV:inheritonly: This flag indicates the ACE should be ignored
			during access check. The ACE is present for the purposes of
			inheritance only and does not affect the security of the
			current resource. [OPTIONAL]
			. DAV:containerinherit: This flag indicates that container
			objects inherit this ACE as an effective ACE. The
			DAV:inheritonly flag, if also present on this ACE, will be
			removed from the inherited effective ACE on the container. If
			the DAV:nopropagateinheritance flag is present on the current
			ACE, the DAV: containerinherit flag is removed from the
			inherited ACE on the container. [REQUIRED]
			. DAV:objectinherit: This flag indicates that non-container
			resources inherit this ACE as an effective ACE. The
			DAV:inheritonly flag, if also present on this ACE, will be
			removed from the inherited effective ACE on the non-container
			resource. If the DAV:nopropagateinheritance> flag is not
			present, then container resources will also inherit this ACE
			with the addition of the DAV:inheritonly> flag. [REQUIRED]
			. DAV:nopropagateinheritance: This flag indicates the ACE should
			be inherited one level only. If an object inherits this ACE,
			the DAV:containerinherit and DAV:objectinherit flags are
			removed from the resultant inherited ACE, preventing further
			propagation of this ACE. [OPTIONAL]
			The DAV:aclsemantics element MUST contain exactly one of the
			following XML elements:
			. DAV:firstspecific: This element is present if the ACL
			conforms to the FirstSpecific semantics described in this
			spec.
			. DAV:explicitdenyprecedence: This element is present if the ACL
			conforms to the ExplicitDenyPrecedence semantics described in
			this spec.
			4.1 Retrieving Access Control Information
			Retrieving Access Control information is done via PROPFIND on the
			resource in question. All ACL properties are also returned as
			part of the response to PROPFIND allprop request.
			4.1.1Example: Retrieving Access Control information
			The following example shows how access control information could
			be retrieved using PROPFIND method.
	Request		Request
	PROPFIND /top/container HTTP/1.1		PROPFIND /top/container/ HTTP/1.1
	Host: www.foo.bar		Host: www.foo.bar
	Content-type: text/xml; charset="utf-8"		Content-type: text/xml; charset="utf-8"
	Content-Length: 0		Content-Length: 0
	Depth: 0		Depth: 0
	<?xml version="1.0">		<?xml version='1.0'>
	<D:propfind xmlns:D="DAV:">		<D:propfind xmlns:D='DAV:'>
	<D:allprop/>		<D:allprop/>
	</D:propfind>		</D:propfind>
	Response		Response
	HTTP/1.1 200 Success		HTTP/1.1 207 Multi-Status
	Content-Type: text/xml		Content-Type: text/xml
	Content-Length: xxxxx		Content-Length: xxx
	<?xml version="1.0" encoding="utf-8" ?>		<?xml version="1.0" encoding="utf-8" ?>
	<?namespace href = "http://www.ietf.org/standards/webdav/ AS =		<D:multistatus xmlns:D="DAV">
	D"?>
	<D:response>		<D:response>
	<D:propstat>		<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
	<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>		<D:creationdate>1997-12-01T17:42:21-08:00</D:creationdate>
	<D:displayname>Example collection</D:displayname>		<D:displayname>Example collection</D:displayname>
	<D:resourcetype><D:collection/></D:resourcetype>		<D:resourcetype><D:collection/></D:resourcetype>
	<D:supportedlock> XXXXX</D:supportedlock>		<D:supportedlock> XXXXX</D:supportedlock>
			<D:owner>
	<D:owner>http://www.rational.com/principals/users/gclemm</d:owner		<D:href>http://www.foo.bar/users/gclemm
	>		<D:displayname>Geoffrey Clemm</D:displayname>
	<D:owner-name>Geoffrey Clemm</d:owner-name>		</D:owner>
	Sedlar, Clemm [Page 8]
	<D:rights>		<D:rights>
	<D:read/><D:readacl/>		<D:read/><D:readacl/>
	</D:rights>		</D:rights>
	<D:acl>		<D:acl>
	<D:ace>		<D:ace>
	<D:grant><D:read/><D:write/><D:readacl/></D:grant>		<D:grant><D:read/><D:write/><D:readacl/></D:grant>
	<D:principal-id>
	<D:href>http://www.foo.com/users/esedlar</D:href>
	</D:principal-id>
	<D:principal>		<D:principal>
	<D:principal-type>User</D:principal-type>		<D:href>http://www.foo.bar/users/esedlar</D:href>
			<D:principal-type><DAV:user/></D:principal-type>
	<D:principalname>esedlar</D:principalname>		<D:principalname>esedlar</D:principalname>
	<D:displayname>Eric Sedlar</D:displayname>		<D:displayname>Eric Sedlar</D:displayname>
	</D:principal>		</D:principal>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
	<D:grant><D:read/><D:readacl/></D:grant>		<D:grant><D:read/><D:readacl/></D:grant>
	<D:deny><D:writeacl/></D:deny>
	<D:principal-id>
	<D:href>http://www.foo.com/groups/marketing</d:href>
	</D:principal-id>
	<D:principal>		<D:principal>
	<D:principal-type>Group</D:principal-type>		<D:href>http://www.foo.bar/groups/marketing</d:href>
	<D:displayname>Foo.Com marketing		<D:principal-type><DAV:group/></D:principal-type>
			<D:displayname>Foo.Bar marketing
	department</D:displayname>		department</D:displayname>
	<D:principalname>mktdept</D:principalname>		<D:principalname>mktdept</D:principalname>
	</D:principal>		</D:principal>
	</D:ace>		</D:ace>
	<D:ace>		<D:ace>
			<D:deny><D:writeacl/></D:deny>
			<D:principal>
			<D:href>http://www.foo.bar/groups/marketing</d:href>
			<D:principal-type><DAV:group/></D:principal-type>
			<D:displayname>Foo.Bar marketing
			department</D:displayname>
			<D:principalname>mktdept</D:principalname>
			</D:principal>
			<D:ace/>
			<D:ace>
	<D:grant><D:read/></D:grant>		<D:grant><D:read/></D:grant>
	<D:principal-id><d:all/></D:principal-id>		<D:principal><d:all/></D:principal>
	</D:ace>		</D:ace>
	</D:acl>		</D:acl>
			</D:prop>
	<D:propstat>		<D:propstat>
	<D:response>		<D:response>
			<D:multistatus>
			4.2 Setting Access Control Information
			An ACL is set by executing a PROPPATCH against the resource that
			contains the DAV:acl property. An ACL must be written in its
			entirety. All ACEs (readable by the current user) previously
			stored in the ACL on the indicated resource are removed. (If the
			server implements rights outside of those defined in this
			specification, they might allow only some ACEs to be visible=97
			behaviour on a PROPPATCH is undefined with respect to this
			specification).
			Setting an empty ACL property causes all ACEs in the ACL,
			including ACEs for associated properties, to be deleted.
			Since permission to set an ACL is typically controlled by a
			different right from permission to set other properties, it is
			recommended that ACL-setting PROPPATCHes be executed
			independently from PROPPATCHes of other properties. PROPATCH as
			defined in [WEBDAV] is an atomic operation, so failure to set the
			ACL will result in a failure to set all other properties.
			[WEBDAV] also defines that operations must be performed from top
			to bottom, so multiple instances of the DAV:acl element in a
			single PROPPATCH result in only the last being set.
			Changing ownership of a resource requires setting the DAV:href
			element of the DAV:owner property.
			4.2.1Example: Setting Access Control information
			The following example follows from the previous example and
			changes the group ACE to disallow read access to the ACL for the
			marketing group. The other information had to be copied from the
			ACL retrieved in the previous example.
			Request
			PROPPATCH /top/container HTTP/1.1
			Host: www.foo.bar
			Content-Type: text/xml
			Content-Length: xxxx
			<?xml version="1.0"?>
			<D:propertyupdate xmlns:D="DAV:">
			<D:set>
			<D:prop>
			<D:acl>
			<D:ace>
			<D:grant><D:read/><D:write/><D:readacl/></D:grant>
			<D:principal>
			<D:href>http://www.foo.bar/users/esedlar</D:href>
			</D:principal>
			</D:ace>
			<D:ace>
			<D:grant><D:read/></D:grant>
			<D:principal>
			<D:href>http://www.foo.bar/groups/marketing</D:href>
			</D:principal>
			</D:ace>
			</D:acl>
			</D:prop>
			</D:set>
			</D:propertyupdate>
			Response
			HTTP/1.1 207 Multi-Status
			Content-Type: text/xml
			Content-Length: xxx
			<?xml version="1.0"?>
			<D:multistatus xmlns:a="DAV:">
			<D:response>
			<D:href>http://www.foo.bar/top/container/</D:href>
			<D:propstat>
			<D:status>HTTP/1.1 200 OK</D:status>
			<D:prop>
			<D:acl/>
			</D:prop>
			</D:propstat>
			</D:response>
			</D:multistatus>
	5 USING ACLS		5 USING ACLS
	By default, a principal has no access rights to an object		An ACL contains zero or more ACEs that express the rights granted
	protected by an ACL. A particular ACE may either grant or deny a		or denied to the principal specified in the ACE. An ACL with
	set of rights to a single principal. It is illegal for an ACL to		zero ACEs implies that no principal is granted any rights. A
	have two ACEs applying to the same principal. However, since a		particular ACE may either grant or deny a set of rights to a
	server may match the currently authenticated HTTP user with		single principal. However, since a server may match the
	multiple principals, it is possible for multiple ACEs to apply to		currently authenticated HTTP user with multiple principals (for
	the current user. In this case, if a particular right is denied		instance, in the case where one principal refers to the user and
	to the current user by any ACE, this supercedes any ACE that		another principal refers to a group to which the user belongs),
	might grant that right. This is the case regardless if a ("more		it is possible for multiple ACEs to "match" the current user. A
	specific") ACE granting access applied to a principal identifying		user has no access rights to an object protected by an ACL unless
	the user directly, while the ACE denying access applied to a		that user matches one or more of the principals specified in the
	collection principal containing that user. The particular order		ACEs.
	of the ACEs within an ACL is irrelevant. The <principal-id> tag		Server implementations may limit the number of ACEs in an ACL.
	can also contain the following special tags: <owner>, <all>,		However, ACL-compliant servers are required to support at least
	<unauthenticated>. These tags have the following meaning:		one ACE granting rights to a single principal, and one ACE
			granting rights to a collection principal. If a client tries to
			write an ACL containing more ACEs than the server supports, the
			server should return an error "Too many ACEs."
	Sedlar, Clemm [Page 9]		5.1 System Controlled Rights
	@ owner: The principal identified by the owner property on
			Some implementations may grant certain rights implicitly. For
			example, some systems grant the resource owner DAV:readacl and
			DAV:writeacl implicitly to prevent an ACL from becoming
			irrevocably locked by an update that grants no one the
			DAV:writeacl right. Any rights granted implicitly by the system
			should be reflected as standard ACEs in the ACL returned to the
			client. Since these implicit permissions are read-only, they
			should be reflected as "system controlled" ACEs where
			DAV:inheritanceflags contains DAV:inherited and the
			DAV:inheritancesource element contains DAV:system-ace.
			5.2 Special Principal Identifiers
			The DAV:principal element in an ACE may contain, instead of a
			specific security principal identifier, one of the following
			special tags:
			. DAV:owner: The principal identified by the owner property on
	this resource is granted or denied the rights specified in		this resource is granted or denied the rights specified in
	this ACE.		this ACE.
	@ all: The current user always matches this ACE, whether or		. DAV:all: The current user always matches this ACE, whether or
	not s/he is authenticated.		not s/he is authenticated.
	@ unauthenticated: The current user matches this ACE if not		. DAV:authenticated: The current user matches this ACE if
			authenticated.
			. DAV:unauthenticated: The current user matches this ACE if not
	authenticated		authenticated
	Server implementations may limit the number of ACEs in an ACL.		. DAV:selfprincipal: The current user matches this ACE if the
	However, ACL-compliant servers are required to support at least		resource (for example, a user information object or security
	one ACE granting rights to a single principal, and one ACE		principal account) associated with this ACL is a
	granting rights to a collection principal. The server should		representation of the current user.
	return an error "Too many ACEs" in this case.
	6 ACL METHOD		5.3 ACL Semantics Options
	The ACL Method provides a mechanism to set ACL information. Its		In order to accommodate the different semantics of multiple
	request body is used to define alterations to the ACL of the		existing server implementations, we define a number of ACL
	resource identified by the request-URI. Its response body		Semantics options. The tag associated with each option is used
	contains the current ACL for that resource. The ACL method		to indicate what semantics to apply to the ACL. A client may use
	replaces the <acl> and <owner> properties on the specified		this tag to display information that helps an ACL author
	resource with the properties in the request. All readable ACEs		understand the implications of his updates. The client must also
	previously stored in the ACL on the indicated resource are		use this tag to determine the legal semantics for ordering ACEs
	removed, so an ACL method on a resource with an unreadable <acl>		prior to updating the ACL property.
	property will be ignored. (If the server implements rights		The following ACL Semantics options have been defined to
	outside of those defined in this specification, they might allow		indicate:
	only some ACEs to be visibleùin this case, only part of the ACL		. restrictions, if any, on the ordering of ACEs within a stored
	will be replaced).		ACL,
	Change requests through the ACL method MUST be atomic. If any		. how to determine during access check which ACE(s) apply to a
	part of the change request fails then all changes MUST fail. The		user that matches multiple principals,
	presence of an empty ACL causes all ACEs in the ACL, including
	ACEs for associated properties, to be deleted. An empty request
	body will cause no change to the ACL or associated values. If
	the <principal> element (specifying properties of the resource
	identified by the ACE's <principal-id>) is specified, it (and its
	children) is ignored.
	6.1 Example 1 - Setting ACLs		. how to combine the rights granted or denied by multiple
			matching ACEs during access check.
	An ACL request body is an acl-info XML element. The <dav:acl-		Additional ACL models may be accommodated by defining and
	info> element contains properties that can be set by the ACL		registering additional ACL Semantics tags. [How is this done?
	method (currently just <acl>).		TBD].
			Requested Rights: Some access check algorithms are based on not
			just the user identity and the ACEs, but also on the "requested
			rights," which is the set of rights required by the operation for
			which the access check is being performed.
	Request		Effective Rights: The "effective rights" of a user is the set of
	ACL /top/container HTTP/1.1		all rights that would be granted to a user by a given ACL. This
	Host: www.foo.com		set, which is exposed via the DAV:rights property, is independent
	Content-Type: text/xml		of any operation "requested rights" and may be generated by a
	Content-Length: xxxx		different algorithm than the access check algorithm that
	<?namespace href = "http://www.ietf.org/standards/webdav/ AS =		determines whether a user has specific requested rights. Each
	D"?>		right in the Effective Rights set applies to the user whether the
	<D:acl-info>		right is requested individually, or in combination with other
			rights, in the requested rights for an operation.
	Sedlar, Clemm [Page 10]		5.3.1FirstSpecific
	<D:acl>
	<D:ace>
	<D:grant><D:read/><D:write/><D:readacl/></D:grant>
	<D:principal-id>
	<D:href>http://www.foo.com/users/esedlar</D:href>
	</D:principal-id>
	</D:ace>
	<D:ace>
	<D:grant><D:read/> </D:grant>
	<D:principal-id>
	<D:href>http://www.foo.com/groups/marketing</D:href>
	</D:principal-id>
	</D:ace>
	</D:acl>
	</D:acl-info>
	Response		The FirstSpecific semantic model has the following
	HTTP/1.1 200 Success		characteristics:
	Content-Length: 0		Order of ACEs: ACEs are ordered from "most specific" to "least
			specific." Typically, the "most specific" ACEs identify
			principals that refer to a single user. ACEs with "intermediate"
			specificity have principals that refer to a collection or group
			of users or other entities. The "least specific" ACEs contain
			principals, like "World" or "Everyone," that indicate an
			unbounded set of users. If multiple ACEs with the same level of
			specificity are present, their order relative to each other is
			not defined here. Implementations of the FirstSpecific model are
			unlikely to have multiple ACEs in the intermediate and least
			specific categories (where multiple ACE matches are possible),
			making it unimportant to define a rule for relative ordering of
			ACEs within these two specificity levels.
			ACE Matching Algorithm: ACEs are evaluated in the order in which
			they appear in the ACL, from first to last. When a match is
			found, the algorithm is complete. This first matching ACE alone
			is used to determine the effective rights of the user. If it is
			a Grant ACE, then the user is granted all rights in the ACE. If
			it is a Deny ACE, then the user is denied all rights in the ACE.
			Requested rights may be compared with the effective rights to
			determine if access should be granted.
			ACE Combining Algorithm: The FirstSpecific model never matches
			more than one ACE to a user, thus there's no need to combine the
			rights of multiple ACEs.
			Example Implementation: UNIX rights (rwx for user:group:world) is
			an example of the FirstSpecific model.
	This request changes the group ACE to disallow read access to the		5.3.2ExplicitDenyPrecedence
	ACL for the marketing group. The other information had to be
	recopied from the ACL retrieved in the previous example.
	7 ACL INHERITANCE / DEFAULT ACLS		The ExplicitDenyPrecedence model has the following
			characteristics:
			Order of ACEs: All Explicit ACEs must precede all Inherited ACEs.
			Within the group of Explicit ACEs, all Deny ACEs must precede all
			Grant ACEs. Inherited ACEs are placed in the order in which they
			are inherited. ACEs inherited from the resource's parent come
			first, then ACEs from the grandparent, and so on.
	To be added		ACE Matching and Combining Algorithm: The ACE matching and
			combining algorithms are not distinct in this model and must be
			described together. A set of "Granted rights" and a set of
			"Denied rights", both initialized with zero rights, are
			maintained in the algorithms to check for Requested Rights and to
			calculate Effective Rights. In both cases, ACEs are evaluated in
			the order in which they appear in the ACL, from first to last.
			Checking for Requested Rights: For each ACE evaluated, if the ACE
			matches the current user, then:
			. if it is a Grant ACE, any rights in the ACE that are not
			already in the "Granted rights" or "Denied rights" sets are
			added to the "Granted rights" set
	Sedlar, Clemm [Page 11]		. if it is a Deny ACE, any rights in the ACE that are not
	8 XML SCHEMA FOR DEFINED ELEMENTS		already in the "Granted rights" or "Denied rights" sets are
			added to the "Denied rights" set
			If the "Granted rights" set now contains all rights in the set of
			"requested rights," then no more ACEs are evaluated and the
			algorithm completes with "Requested Access Granted."
			If the "Denied rights" set now contains any right that is in the
			set of "requested rights," then no more ACEs are evaluated and
			the algorithm completes with "Requested Access Denied."
			If neither of these cases is true, then the next ACE is
			evaluated. If there are no more ACEs present in the ACL, then
			the algorithm completes with "Requested Access Denied" since the
			accumulated Granted rights did not contain all of the requested
			rights.
			Calculating the effective rights of a user: As in the check for
			requested rights, for each ACE evaluated, if the ACE matches the
			current user, then:
			. if it is a Grant ACE, any rights in the ACE that are not
			already in the "Granted rights" or "Denied rights" sets are
			added to the "Granted rights" set
			. if it is a Deny ACE, any rights in the ACE that are not
			already in the "Granted rights" or "Denied rights" sets are
			added to the "Denied rights" set
			If the union of the "Granted rights" and "Denied rights" now
			contains all possible rights, then no more ACEs are evaluated and
			the algorithm returns the Granted rights as the set of Effective
			Rights.
			Otherwise, the next ACE is evaluated. If there are no more ACEs
			present in the ACL, then all rights present in the "Granted
			rights" set are returned as Effective Rights.
			Example Implementation: Microsoft Windows NT canonical ACLs are
			an example of this model.
			6 ACL INHERITANCE
			To support a more scalable administration model for configuration
			of access control information, the spec defines an ACL
			inheritance model that enables an ACL, or elements of an ACL, to
			be inherited and reused by other resources. An ACL-compliant
			implementation is not required to support inheritance.
			Typically, an ACL defined on a container resource may be
			inherited by children of that container, grandchildren if they
			exist, and so on down the tree. Although this hierarchical tree
			model of inheritance is popular, this spec does not require an
			implementation's ACL inheritance model to follow a tree structure
			where child resource inherits from parent resource. Nonetheless,
			for convenience, this description of inheritance assumes that a
			child resource would inherit access control information from its
			parent.
			6.1 Inheritable ACEs
			Access control information is inherited at the granularity of an
			ACE. An inherited ace is identified by the presence of the
			DAV:inherited element in the DAV:inheritanceflags property. An
			"Explicit" ACE is an ACE defined directly on a resource, rather
			than inherited from a different resource. An ACE without the
			DAV:inherited element is by definition an Explicit ACE. Only
			Explicit ACEs may updated by the client.
			To indicate that an ACE should be inherited by child resources,
			the DAV:inheritanceflags should contain:
			. DAV:objectinherit to indicate that non-container children
			should inherit the ACE,
			. DAV:containerinherit to indicate that container children
			should inherit the ACE, or
			. both to indicate that all child resources should inherit the
			ACE.
			6.2 Updating an inherited ACE
			When a child resource ACL inherits an ACE, the DAV:inherited
			flag is present on the ACE to indicate that this ACE is read-
			only (it may only be edited on the resource where the ACE was
			explicitly defined). To assist users who want to make changes
			to the rights that appear in an inherited ACE, the resource from
			which the ACE was inherited (and therefore, on which the
			explicit ACE is defined and editable) is identified in the
			DAV:inheritancesource property. If the inheritance source
			cannot be determined or if the system is unable to generate a
			valid URI to the resource from which the ACE was inherited,
			DAV:inheritancesource contains the special tag DAV:unknown.
			6.3 Propagate ACE but do not use for Access Check on this resource
			In some cases, an ACE (whether explicit or inherited) may be
			present on a container ACL purely for the sake of propagating
			the ACE to child objects and NOT to be used for access control
			on the container itself. In this case, the optional
			DAV:inheritonly flag is present on the ACE to indicate it should
			not be used for access check on this container.
			6.4 Propagate to immediate children only
			To indicate that an ACE should be inherited by children, but not
			by grandchildren or any further down the tree, the optional
			DAV:nopropagateinheritance flag is present on the ACE. This
			flag indicates that when this ACE is inherited by child objects,
			the DAV:objectinherit and/or DAV:containerinherit elements must
			be removed from the inherited ACE.
			6.5 Protect ACL from inheritance
			To prevent an ACL from inheriting any ACEs, the optional
			DAV:protectaclfrominheritance property is set on the resource.
			If this property is present on a resource, the DAV:inherited
			element must not be present on any ACEs in that resource's ACL.
			Other inheritance flags may be present on the ACEs of this
			resource, since this ACL may be the source of inheritable ACEs
			for the subtree under this resource.
			7 XML SCHEMA FOR DEFINED ELEMENTS
	<?xml version='1.0'?>		<?xml version='1.0'?>
	<!-- XML Schema for WebDAV ACLs -->		<!-- XML Schema for WebDAV ACLs -->
	<!DOCTYPE schema PUBLIC "-//IETF//DTD WEBDAVACL 20000420//EN"		<!DOCTYPE schema PUBLIC "-//IETF//DTD WEBDAVACL 20000420//EN"
	"WebDAVACL.dtd" >		"WebDAVACL.dtd" >
	<schema xmlns="http://www.w3.org/1999/XMLSchema"		<schema xmlns="http://www.w3.org/1999/XMLSchema"
	targetNamespace="http://www.ietf.org/standards/webdav"		targetNamespace="http://www.ietf.org/standards/webdav"
	xmlns:dav="http://www.ietf.org/standards/webdav"		xmlns:dav="http://www.ietf.org/standards/webdav"
	blockDefault="#all" elementFormDefault="qualified">		blockDefault="#all" elementFormDefault="qualified">
	<element name="right" abstract="true">		<element name="right" abstract="true">
	<complexType content="empty">		<complexType content="empty">
	</element>		</element>
	<!--For those folks not familiar with XML Schema, minOccurs		<!--For those folks not familiar with XML Schema, minOccurs
	defaults to 0, and maxOccurs defaults to 1 -->		defaults to 0, and maxOccurs defaults to 1 -->
	<element name="dav:read" base="right" equivClass="right"/>		<element name="DAV:read" base="right" equivClass="right"/>
	<element name="dav:write" base="right" equivClass="right"/>		<element name="DAV:write" base="right" equivClass="right"/>
	<element name="dav:readacl" base="right" equivClass="right"/>		<element name="DAV:readacl" base="right" equivClass="right"/>
	<element name="dav:writeacl" base="right"		<element name="DAV:writeacl" base="right"
	equivClass="right"/>		equivClass="right"/>
	<element name="dav:all" base="right" equivClass="right"/>		<element name="DAV:all" base="right" equivClass="right"/>
	<complexType name="dav:rights-list">		<complexType name="DAV:rights-list">
	<choice minOccurs="1" maxOccurs="unbounded">		<choice minOccurs="1" maxOccurs="unbounded">
	<element ref="dav:right">		<element ref="DAV:right">
	<element name="dav:unauthenticated" content="empty"/>		<element name="DAV:unauthenticated" content="empty"/>
	<element name="dav:all" content="empty"/>		<element name="DAV:all" content="empty"/>
	<element name="dav:owner" content="empty"/>		<element name="DAV:owner" content="empty"/>
	</complexType>		</complexType>
	<complexType name="dav:ace">		<complexType name="DAV:ace">
	<element name="dav:grant" type="dav:rights-list"		<element name="DAV:grant" type="DAV:rights-list"
	minOccurs="0" maxOccurs="1">		minOccurs="0" maxOccurs="1">
	<element name="dav:deny" type="dav:rights-list"		<element name="DAV:deny" type="DAV:rights-list"
	minOccurs="0" maxOccurs="1">		minOccurs="0" maxOccurs="1">
	<element name="dav:principal-id" minOccurs="1"/>		<element name="DAV:principal-id" minOccurs="1"/>
	<complexType>		<complexType>
	<choice minOccurs="1">		<choice minOccurs="1">
	<element name="dav:owner" content="empty"/>		<element name="DAV:owner" content="empty"/>
	<element name="dav:all" content="empty"/>		<element name="DAV:all" content="empty"/>
	<element name="dav:unauthenticated" content="empty"/>		<element name="DAV:unauthenticated" content="empty"/>
	<element name="dav:href" type="uri"/>		<element name="DAV:href" type="uri"/>
	</choice>		</choice>
	</complexType>		</complexType>
	</element>		</element>
	<element name="dav:principal" minOccurs="0" maxOccurs="1">		<element name="DAV:principal" minOccurs="0" maxOccurs="1">
	<complexType>		<complexType>
	<element name="dav:principal-name" type="string"		<element name="DAV:principal-name" type="string"
	minOccurs="1"/>		minOccurs="1"/>
			<element name="DAV:principal-type" type="string"
	Sedlar, Clemm [Page 12]
	<element name="dav:principal-type" type="string"
	minOccurs="1"/>		minOccurs="1"/>
	</complexType>		</complexType>
	</element>		</element>
	</complexType>		</complexType>
	<element name="dav:acl">		<element name="DAV:acl">
	<complexType>		<complexType>
	<element name="dav:ace" type="dav:ace"		<element name="DAV:ace" type="DAV:ace"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</complexType>		</complexType>
	</element>		</element>
	<element name="dav:rights">		<element name="DAV:rights">
	<complexType>		<complexType>
	<choice minOccurs="1" maxOccurs="unbounded">		<choice minOccurs="1" maxOccurs="unbounded">
	<element ref="dav:right"/>		<element ref="DAV:right"/>
	</choice>		</choice>
	</complexType>		</complexType>
	</element>		</element>
	</schema>		</schema>
	9 INTERNATIONALIZATION CONSIDERATIONS		8 INTERNATIONALIZATION CONSIDERATIONS
	To be supplied.		To be supplied.
	10 SECURITY CONSIDERATIONS		9 SECURITY CONSIDERATIONS
	To be supplied.		To be supplied.
	11 SCALABILITY		10 SCALABILITY
	To be supplied.		To be supplied.
	12 AUTHENTICATION		11 AUTHENTICATION
	Authentication mechanisms defined in WebDAV will also apply to		Authentication mechanisms defined in WebDAV will also apply to
	WebDAV ACL.		WebDAV ACL.
	13 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]		elements. All other IANA considerations mentioned in [RFC2518]
	also applicable to WebDAV ACL.		also applicable to WebDAV ACL.
	14 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		describes the position of the IETF concerning intellectual
	property claims made against this document.		property claims made against this document.
	Sedlar, Clemm [Page 13]
	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		pertain to the implementation or use other technology described
	in this document or the extent to which any license under such		in this document or the extent to which any license under such
	rights might or might not be available; neither does it represent		rights might or might not be available; neither does it represent
	that it has made any effort to identify any such rights.		that it has made any effort to identify any such rights.
	Information on the IETF's procedures with respect to rights in		Information on the IETF's procedures with respect to rights in
	standards-track and standards-related documentation can be found		standards-track and standards-related documentation can be found
	in BCP-11. Copies of claims of rights made available for		in BCP-11. Copies of claims of rights made available for
	publication and any assurances of licenses to be made available,		publication and any assurances of licenses to be made available,
	skipping to change at line 688		skipping to change at page 22, line 26
	permission for the use of such proprietary rights by implementers		permission for the use of such proprietary rights by implementers
	or users of this specification can be obtained from the IETF		or users of this specification can be obtained from the IETF
	Secretariat.		Secretariat.
	The IETF invites any interested party to bring to its attention		The IETF invites any interested party to bring to its attention
	any copyrights, patents or patent applications, or other		any copyrights, patents or patent applications, or other
	proprietary rights that may cover technology that may be required		proprietary rights that may cover technology that may be required
	to practice this standard. Please address the information to the		to practice this standard. Please address the information to the
	IETF Executive Director.		IETF Executive Director.
	15 ACKNOWLEDGEMENTS		14 ACKNOWLEDGEMENTS
	This protocol is the collaborative product of the WebDAV ACL		This protocol is the collaborative product of the WebDAV ACL
	design team: xxx, yyy, zzz. We would like to acknowledge the		design team: xxx, yyy, zzz. We would like to acknowledge the
	foundation laid for us by the authors of the WebDAV and HTTP		foundation laid for us by the authors of the WebDAV and HTTP
	protocols upon which this protocol is layered, and the invaluable		protocols upon which this protocol is layered, and the invaluable
	feedback from the WebDAV working group.		feedback from the WebDAV working group.
	16 INDEX		15 INDEX
	To be supplied.		To be supplied.
	17 REFERENCES		16 REFERENCES
	[RFC2026] S.Bradner, "The Internet Standards Process", Harvard,		[RFC2026] S.Bradner, "The Internet Standards Process", Harvard,
	1996, <http://www.ietf.org/rfc/rfc2026.txt>.		1996, <http://www.ietf.org/rfc/rfc2026.txt>.
	[RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and		[RFC2068] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, and
	T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC		T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
	2068, U.C. Irvine, DEC, MIT/LCS, 1997,		2068, U.C. Irvine, DEC, MIT/LCS, 1997,
	<http://www.ietf.org/rfc/rfc2068.txt >.		<http://www.ietf.org/rfc/rfc2068.txt >.
	[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", Harvard, 1997,		Requirement Levels", Harvard, 1997,
	<http://www.ietf.org/rfc/rfc2119.txt >.		<http://www.ietf.org/rfc/rfc2119.txt >.
	[RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,		[RFC2518] Y. Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen,
	"HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,		"HTTP Extensions for Distributed Authoring - WEBDAV", Microsoft,
	U.C.Irvine, Netscape, Novell, 1999		U.C.Irvine, Netscape, Novell, 1999
	<http://www.ietf.org/rfc/rfc2518.txt>.		<http://www.ietf.org/rfc/rfc2518.txt>.
	Sedlar, Clemm [Page 14]		17 AUTHORS' ADDRESSES
	18 AUTHORS' ADDRESSES
	Eric Sedlar
	Oracle Corporation
	500 Oracle Parkway
	Redwood Shores, CA 94065
	Email: esedlar@us.oracle.com
	Geoffrey Clemm		Geoffrey Clemm
	Rational Software		Rational Software
	20 Maguire Road		20 Maguire Road
	Lexington, MA		Lexington, MA
	Email: geoffrey.clemm@rational.com		Email: geoffrey.clemm@rational.com
	19 STILL TO DO :		Anne Hopkins
			Microsoft Corporation
			One Microsoft Way
			Redmond, WA
			Email: annehop@microsoft.com
	@ Describe the interactions with resource locking. I'm not		Eric Sedlar
			Oracle Corporation
			500 Oracle Parkway
			Redwood Shores, CA 94065
			Email: esedlar@us.oracle.com
			18 STILL TO DO :
			. Describe the interactions with resource locking. I'm not
	clear what the resolution was as far as locking the ACL		clear what the resolution was as far as locking the ACL
	separately from locking the resource.		separately from locking the resource.
			. Add a section defining new error codes/messages? Or should we
			make a pass through the doc and ensure all possible error
			conditions are mapped to existing errors?
			. Articulate that the required DAV:principal property should be
			able to be used for equality checks. Equality checks were
			mentioned as one reason why this property should be mandatory,
			even if the URI is fake.
			. Update "Setting Access Control Information" and to address
			whether read-only (ie, inherited) ACEs should be stripped out
			by the client prior to PROPPATCH. Fix, if necessary, comments
			on editing inherited ACEs in ACL Inheritance section.
			. Renaming DAV:rights to DAV:effectiverights? and update sample
			. Revisit description of Property ACEs to reflect group
			agreement. Add sample code. Anne will need to update
			Semantics descriptions to address property ACEs.
			. Update the self, ownergroup stuff according to eventual
			agreements.
			. Make document consistent:
			o Ensure all property descriptions indicate whether the
			property is:
			. "live" or "dead"
			. read-only or writable
			. REQUIRED or OPTIONAL
			o Ensure sample XML exists for all new properties, tags,
			etc.
			o Complete empty sections, like Scalability
			19 OPEN ISSUES:
			Issue Description Status
			1. Aggregate a right, if granted, that Now addressed in
			rights grants access to a set of spec.
			subsidiary rights
			2. Rights How do we find out what Now addressed in
			discovery rights are applicable to a spec.
			given resource? Can this be
			done by resource type, to
			avoid the need to ask each
			resource this question?
			3. Defined Should we define a 'group' Collection
			list of principal type which principals will
			"principal- specifically requires that have semantic
			types" principal membership be meaning (recursive
			recursive? This might make membership applies)
			administrative client
			implementation easier.
			Should this be a
			recommendation rather than a
			requirement?
			4. Reserved Is the list of 'reserved' Discussed in 4/28
			principals principals complete ( conference call.
			'owner', 'all', or Still Open.
			'unauthenticated', 'all-
			authenticated', etc.)
			5. Standard Is the list of standard Discussed on
			rights rights complete? conference call and
			updated once in
			draft.
			6. XML Do we need to scope the Use DAV namespace,
			namespace namespace of our XML like other working
			for ACL elements via <?namespace groups. Closed.
			href =
			"http://www.ietf.org/standar
			ds/acl/ AS = "A"?>, or can
			we use the regular DAV
			namespace (shared by both
			versioning and RFC 2518)?
			7. Rights What is the method for Not a method.
			discovery figuring out the list of DAV:Access-Rights
			rights? property available.
			Closed.
			8. Multiple Are we sure we don't want to Requires an
			principals/A allow multiple explicit vote
			CE [CKNIGHT] principals/ACE?
			9. Grant & Are we sure we don't want to Added to spec.
			Deny allow grant & deny in the Decision reversed
			[CKNIGHT] same ACE? Note that this per 6/23 call and
			simplifies the ACE rule to added to spec 01.3.
			disallow two ACEs for the Closed.
			same principal.
			10. Semantic Do we need to specify stuff Yes. Added to
			meaning of like whether or not spec.
			principal collection principal
			colls. membership is recursive?
			[GCLEMM]
			11. principa The semantic meaning of Added to spec=97
			l-name vs. principal-name should be principal-name
			display-name defined, or display-name holds
			[GCLEMM] should be used "authentication"
			string and
			displayname holds
			readable string
			12. ChangeOw Can servers disallow PROPPATCH support
			ner [GCLEMM/ changing the owner? for owner is
			CKNIGHT] optional in the
			spec.
			13. Local What text is needed Open
			principal regarding principal URLs
			URLs without hostname:port
			14. ACL as To what extent should ACLs ACLs are
			properties be treated as properties? properties. Closed.
			15. Semantic Would it be more appropriate Open
			s Model to identify these semantic
			names models by their
			[ANNEHOP] implementation names, ie,
			UNIX, NT Canonical? Could
			be easier for developers and
			users. Neither of these
			models is likely to be re-
			used by another
			implementation.
			16. Addition Do we need to include Open
			al Semantics additional ACL semantics
			models models? What other systems
			[ANNEHOP] (.htaccess?) do we need to
			support?
			17. Detectin How are WebDAV Access Open
			g a WebDAV Control compliant servers
			Access detected? Define acl
			Control extension for the DAV:
			server header?
			[SEANLYND]
			18. DAV:user If we're going to be Open
			/group or treating users as resources,
			DAV:resource then we should go all the
			/collection way.
			[SEANLYND]
			19. Per- ability to specify rights on Open
			property a per-property basis could
			ACEs be very useful for webdav.
			[ANNEHOP] consider adding an optional
			propertytype-id to the ace?
			20. Register Need to describe process for Open
			ing registering a new ACL
			Semantics semantics model option.
			Models
			[ANNEHOP]
			21. Strip Should the client strip all Agreed to strip
			Inherited Inherited (read-only) ACEs inherited ACEs in
			ACEs? prior to setting an ACL? Do 6/23 call. Anne
			[ANNEHOP] we need a flag that re-opening issue.
			indicates whether the server
			accepts a client update of
			inherited ACEs (to support
			client-side propagation of
			inheritance)? And/or a flag
			to indicate that the client
			WANTs to set inherited ACEs?
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/