Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol

Glossary

The identifier is a name for the issue (and is unique within this document).

The type of issue is one of:

The status of the issue is one of:

The reference is an indication of where the issue was first raised.

The description is a succinct overview of the issue.

The resolution describes the specification change that resolves the issue.

Open Issues

Identifier Type / Status Reference and Description Proposed Resolution / Latest Change
1.1-­group-­vs-­non-­group
change
open
Reference: <http://mailman.webdav.org/pipermail/acl/2007-May/001984.html>

geoffrey.clemm@us.ibm.com, 2007-05-29: (Add definition for non-group).
latest change in revision latest
5.3-­privilege-­cardinality
change
open
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2010AprJun/0006.html>

cyrus@daboo.name, 2010-06-07: RFC3744 defines DAV:privilege as:
<!ELEMENT privilege ANY>
"ANY" technically implies one or more child elements. However, all examples in 3744 have just a single child. It has been my assumption that only one child is allowed. However, I recently came across a server that is returning multiple child elements. So what is, or is not, allowed here?
latest change in revision latest
5.3.1_­update_­example
change
open
Reference: <http://mailman.webdav.org/pipermail/acl/2004-August/001845.html>

bernard.desruisseaux@oracle.com, 2004-08-11: According to section 3.12 the DAV:write privilege MUST contain DAV:bind, DAV:unbind, DAV:write-properties and DAV:write-content. In the example in section 5.3.1 the DAV:write privilege omits to aggregate the DAV:bind and DAV:unbind privileges.
latest change in revision latest
5.4-­current-­user-­privilege-­set-­vs-­abstract
change
open
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2009AprJun/0006.html>

bernard.desruisseaux@oracle.com, 2009-05-21: In section 3 Privileges of RFC3744 it says:
Aggregate and non-aggregate privileges are both capable of being abstract.
but in section 5.4 DAV:current-user-privilege-set of RFC3744 it says:
Therefore, each element in the DAV:current-user-privilege-set property MUST identify a non-abstract privilege from the DAV:supported-privilege-set property.
In a discussion amongst CalDAV implementors, it was brought up that the above requirement would be problematic for implementations that supports non-aggregate "abstract" privileges.
That is, an implementation that allows such a privilege to be set individually on a resource (either by default or through a proprietary mechanism) would not be allowed to report this privilege in the DAV:current-user-privilege-set property.
latest change in revision latest
5.5.1_­property_­element
change
open
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2007AprJun/0024.html>

werner.donne@re.be, 2007-05-05: Can a server limit the set of properties that may be used to denote a principal in a principal element? If yes, what pre-condition violation should be reported when an unsupported property is included?
latest change in revision latest
5.6-­cleanup
edit
open
julian.reschke@greenbytes.de, 2006-07-01: This list just repeats information from the subsequent subsections; propose to remove the text and insert section references instead. Also unify section titles for those subsections. latest change in revision latest
7.1.1-­error-­body-­vs-­GET
change
open
Reference: <http://www.lyra.org/pipermail/acl/2006-October/001918.html>

julian.reschke@greenbytes.de, 2006-10-18: We can't require the DAV:error response body for GET (because then it may be displayed by browsers) and HEAD (because it doesn't have a response body).
latest change in revision latest
8.1_­modifying_­acl
change
open
Reference: <http://mailman.webdav.org/pipermail/acl/2007-June/002005.html>

werner.donne@re.be, 2007-06-07: In short the problem is that ACEs can't be modified because they are not identifiable entities. The only practical scenario is the update of the complete acl property, with the protected ACEs always first in the list. The position of protected ACEs can't change, because it is uncertain whether that constitutes a modification of an ACE or not.
latest change in revision latest
8.1_­safeness_­and_­idempotence
edit
open
julian.reschke@greenbytes.de, 2005-02-27: Specify safeness and idempotence of ACL method (see also http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=82). latest change in revision latest
9.2.1_­response_­format
edit
open
Reference: <http://mailman.webdav.org/pipermail/acl/2007-June/002000.html>

julian.reschke@gmx.de, 2007-06-01: (Add example showing response when no properties were requested).
latest change in revision latest
9.2_­prop_­format
edit
open
Reference: <http://mailman.webdav.org/pipermail/acl/2007-May/001996.html>

mrdemeanour@jackpot.uk.net, 2007-05-31: (Clarify that the properties to be reported have to be specified inside the DAV:prop element in the request body).
latest change in revision latest
9.2_­property_­principal
change
open
Reference: <http://mailman.webdav.org/pipermail/acl/2004-October/001869.html>

Keith@xythos.com, 2004-10-13: The acl-principal-props-set report indicates it should be applied to all principals in the acl specified by a href, as well as specified by a property.
However, the response section says "The response body MUST contain a DAV:response element for each principal identified by an http(s) URL listed in a DAV:principal XML element of an ACE" which doesn't include principals specified via a property.
Julian suggested this change: "The response body for a successful DAV:acl-principal-prop-set REPORT request MUST contain a DAV:response element for each principal identified by an http(s) URL or by a DAV:property principal listed in a DAV:principal XML element of an ACE within the DAV:acl property of the resource identified by the Request-URI."
While that technically solves the problem, how is a client going to be able to map the received property with a principal expressed via a property? With the other principals, the client can just match urls in the acl. Wouldn't it be more productive to somehow specify the property used to define the principal, in the response of acl-principal-props-set?
latest change in revision latest
bcp14
edit
open
julian.reschke@greenbytes.de, 2006-07-01: Remove usage of BCP14 (RFC2119) keywords when not appropriate. latest change in revision latest
current-­principal
change
open
julian.reschke@greenbytes.de, 2008-07-20: Adopt DAV:current-user-principal property (<https://datatracker.ietf.org/idtracker/draft-sanchez-webdav-current-principal/>) as optional property? latest change in revision latest
edit
edit
open
2004-05-27: Umbrella issue for editorial changes. latest change in revision latest
update-­references
change
open
2006-09-02: Keep references up-to-date. latest change in revision latest

Closed/Editor Issues

Identifier Type / Status Reference and Description Resolution / Latest Change
5.7_­inherited-­acl-­set-­protected
change
closed
Reference: <http://mailman.webdav.org/pipermail/acl/2004-April/001815.html>

eric.sedlar@oracle.com, 2004-04-16: Based on http://mailman.webdav.org/pipermail/acl/2004-April/001814.html, does anyone object if we change section 5.7, which currently reads .... to remove the second word "protected" here, to allow for more flexibility for server implementers? We can probably do this before the RFC is published.
in revision latest:
Agreed to allow servers to make the property non-protected.
6_­broken_­xml
change
closed
Reference: <http://mailman.webdav.org/pipermail/acl/2004-August/001851.html>

bernard.desruisseaux@oracle.com, 2004-08-18: (broken XML in example)
in revision latest:
Fix example.
6_­broken_­xml2
change
closed
Reference: <http://mailman.webdav.org/pipermail/acl/2004-August/001850.html>

bernard.desruisseaux@oracle.com, 2004-08-18: (broken XML in example)
in revision latest:
Fix example.
8.1.1_­deny_­before_­grant-­precondition
change
closed
tolsen718@gmail.com, 2006-06-30: Section 8.1.1 (http://greenbytes.de/tech/webdav/rfc3744.html#acl.preconditions) of RFC 3744 specifies that deny-before-grant is a requirement. It does not follow this with a condition stating that it only applies if the constraint is set, as is done for grant-only and no-invert.
Is this omission of a condition under which this preconditon holds intentional? Is deny-before-grant a requirement?
in revision latest:
Fixed. See http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JulSep/0002.html.
9.2_­DTD_­fragment
edit
closed
julian.reschke@greenbytes.de, 2004-11-07: Fix DTD fragments so that they are legal XML. in revision latest:
Done.
9.3-­clarify-­intro
edit
closed
Reference: <http://mailman.webdav.org/pipermail/acl/2006-February/001895.html>

lisa@osafoundation.org, 2006-02-21: Clarify introduction of report semantics.
in revision latest:
Done.
9.5-­apply-­to-­principal-­collection-­set
change
closed
Reference: <http://mailman.webdav.org/pipermail/acl/2006-February/001893.html>

julian.reschke@greenbytes.de, 2006-02-21: Adopt DAV:apply-to-principal-collection-set (defined for DAV:principal-property-search) feature for DAV:principal-search-property-set report as well.
in revision latest:
Done.
B_­deltav_­permissions
change
closed
Reference: <http://mailman.webdav.org/pipermail/acl/2005-February/001874.html>

bernard.desruisseaux@oracle.com, 2005-02-21: In Appendix B "WebDAV Method Privilege Table (Normative)" of RFC 3744, one can read: (...) Shouldn't MKWORKSPACE and MKACTIVITY require <D:bind> on the parent collection instead of <D:write-content>? Am I missing something obvious here?
in revision latest:
Fixed (see also http://mailman.webdav.org/pipermail/acl/2005-February/001876.html).

Progress

Version Issues
latest ||||||||||||||||||||||||

Last change: 2010-06-07