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.
| 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 |
| 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). |
| Version | Issues |
|---|---|
| latest | |||||||||||||||||||||||| |
Last change: 2010-06-07