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 |
|---|
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| acl |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0063.html> cyrus@daboo.name, 2008-09-23: This brings up another question: presumably the DAV:bind privilege is required on the collection for the new POST ;add-member behavior to be allowed (just as it would be required for PUT creating a new member). I think we therefore need a statement in Security Considerations: "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is required to be granted on the collection resource in which the new member resource is being created. If this privilege is denied or not present, the POST request MUST fail." |
in revision 01: Add "relation to ACL" section; required DAV:bind privilege on associated WebDAV collection. |
| auth48 |
edit closed |
julian.reschke@greenbytes.de, 2010-08-31: Umbrella issue for changes made during the RFC Editor's AUTH48 period. | in revision latest: |
| collection |
change closed |
cyrus@daboo.name, 2009-11-05:
I have heard from some implementors that they would like collection
creation to also be part of this draft. In particular, CalDAV and/or
CardDAV clients creating calendars or address books would prefer to leave
specification of the resource name to the client.
Proposal: - Add a DAV:add-collection property containing a URI (which must be different than DAV:add-member) - A POST on that URI creates a collection within the parent collection, with a server chosen resource name - If the POST contains an XML body with DAV:mkcol as the root element, then that body is interpreted the same way as MKCOL ext. |
in revision 06: There was no sufficient interest for adding this feature at this point. Furthermore, this can be defined in a future extension spec when needed. |
| containment |
change closed |
julian.reschke@greenbytes.de, 2008-11-20: There seems to be some confusion about whether a POST as described here would allow a server to store the resource into a different folder. That is not the intent, e.g., it doesn't change WebDAV's containment model to the one used in AtomPub. Is a clarification needed? | in revision 02: Clarify "internal member" by pointing to RFC 4918, Section 3. |
| edit |
edit closed |
julian.reschke@greenbytes.de, 2008-09-22: Umbrella issue for editorial fixes/enhancements. | in revision 08: |
| forbidden-put |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0063.html> cyrus@daboo.name, 2008-09-23: So one option for the server to enforce its naming scheme would be to require POST by the client to create new resources rather than allowing PUT/COPY/MOVE to do so. However there is no way fort a client to discover that such a restriction might be in place other than getting a 403. How about a new pre-condition code for that so that the server can indicate "DAV:only-post-allowed-to-create-new-members" to the client? With perhaps a more compact name! |
in revision 01: Mention the use case, define the precondition, add example. |
| link-header |
edit closed |
julian.reschke@greenbytes.de, 2008-12-01: Restructure text so that link header reference becomes informative. | in revision 03: Change of plan: leave out discussion of the Link header for now. See http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0038.html. |
| member-uri-content |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0058.html> cyrus@daboo.name, 2008-09-22: Security consideration: "Servers MUST NOT derive the member path segment from the data being stored in the resource". This is important because you don't want server's leaking information in the URI that would not otherwise be visible (e.g. a user can PROPFIND the members but cannot read the content of the members - leaking content in the URI would be bad). Note this impacts how the server generates the member path segment. e.g. an md5 hash of the data only may not be appropriate. |
in revision 01: State the problem, but do not make a requirement (for instance, the server could be entirely public in which case this wouldn't be an issue at all). |
| ns |
change closed |
julian.reschke@greenbytes.de, 2008-12-01: Put elements into DAV: namespace. See http://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0035.html. | in revision 03: Done. |
| post-error-semantics |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0058.html> cyrus@daboo.name, 2008-09-22: Something needs to be stated about error handling: e.g., "If there are pre-conditions related to creating a resource in the collection using a PUT request, then those same pre-conditions apply to the new POST request behavior, and the same DAV:error response body returned on failure". This would be a "catch-all" to allow protocols such as CalDAV, which restrict certain aspects of the data stored in collections, to simply return the same pre-condition failure information for POST as for PUT. |
in revision 01: Adopt most of the proposed text, except for saying "HTTP response" to make it more generic (for instance, there may be no DAV:error entity body involved). |
| property-trust |
change closed |
julian.reschke@greenbytes.de, 2008-10-01: An attacker could set p:add-member as dead property and thus trick clients into POSTing new content somewhere else. | in revision 01: (1) Require server support for DAV:supported-live-property-set; (2) mention issue in security considerations. |
| protected |
change closed |
julian.reschke@greenbytes.de, 2009-01-08: State that the property is protected. | in revision 04: Done. |
| put-only |
edit closed |
julian.reschke@greenbytes.de, 2009-01-08: Clarify that this is only for PUT-to-create, not COPY/MOVE/LOCK/MKCOL. | in revision 04: |
| rational-server-uri |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0060.html> cyrus@daboo.name, 2008-09-22: One thing this reminds me of: another reason why this POST may be needed is if the server enforces a particular naming scheme on members. e.g., a CalDAV server may require that all member path segments match the UID in the calendar data, or match a record-id in its data store etc. In this case the add-member behavior is required. So its not just the case of "the client doesn't care to name members itself", but also this other one. Probably worth adding a comment on this. |
in revision 01: Mention that this can simplify the server by not having to persist a client-supplied name. |
| remote-uri |
change closed |
julian.reschke@greenbytes.de, 2008-09-30: Explicitly forbid Add-Member URIs pointing to other servers, mainly for reasons of security (DOS), but also for practical reasons (authentication). | in revision 01: Require that the "Add-Member" URI points to the same server. |
| uri-format |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0063.html> cyrus@daboo.name, 2008-09-23: Another question: there is no restriction on what p:add-member URI can be? e.g. if I have the collection "/a/b/" can the p:add-member be another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is possible it should be called out, as the behavior might be somewhat unexpected for clients. It might even be the case that the p:add-member URI is on a different server (e.g. new member items in a collection need "approval" from some other service). The interaction with WebDAV ACL in this case would need to be clear - i.e. what privileges are required on the p:add-member URI? |
in revision 01: Add a set of examples, and use "/collection;add-member/" in subsequent examples. |
| uri-uniqueness |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0058.html> cyrus@daboo.name, 2008-09-22: Is the server allowed to re-use new member URIs? i.e. /a/b.txt exists at some point, then is deleted. Is the server then allowed to use b.txt as a new member of /a/, or does the new member path segment have to be unique for the entire existence of that collection? If the member path segment is expected to be unique there should be some guidance to servers on how they might implement that (uuid's for instance). |
in revision 01: Clarified that this specification doesn't make any additional requirements on the collection semantics. |
| Version | Issues |
|---|---|
| latest | ||||||||||||||||| |
| 08 | |||||||||||||||| |
| 07 | |||||||||||||||| |
| 06 | |||||||||||||||| |
| 05 | |||||||||||||||| |
| 04 | ||||||||||||||| |
| 03 | ||||||||||||| |
| 02 | ||||||||||| |
| 01 | |||||||||| |
| 00 |
Last change: 2010-08-31