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 |
|---|---|---|---|
| 1.3_error_negotiation |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0205.html> joe@cursive.net, 2004-06-22: Second paragraph: how might I otherwise negotiate? The DAV:bind header? |
in revision 06: No change. Summary: this is to allow future extensions where different error marsahlling mechanisms would be used. See also http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0210.html. |
| 2.1.1-bind-loops |
edit closed |
julian.reschke@greenbytes.de, 2007-07-29: Add a clarification over here that support for bind loops (= cycles) is optional. | in revision 20: Done. |
| 2.1.1-cycles |
edit closed |
julian.reschke@greenbytes.de, 2007-11-11: We never introduce the term "cycle". | in revision 20: Fixed. |
| 2.1.1_bind_loops_vs_locks |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0217.html> ejw@cs.ucsc.edu, 2004-12-03: ...The other is the semantics of the lock operation in the presence of loopback bindings. I think the handling of If headers is relatively straightforward. The semantics of locking are not.... |
in revision 09: After some discussion, the working group agreed that we don't want to define special semantics for depth:infinity locks, thus the standard lock sematics apply (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0271.html). |
| 2.1_separate_loop_discussion |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: I think it would be more clear to separate out the discussion of loops and bindings, and make it a separate section (say, 2.2) This issue comes up frequently enough that it would be good to make it easy to find this issue in the TOC. Also, a mention of the Already Reported status code would be good to have here, since it also mentions 506. |
in revision 09: Agreed to move 1st paragraph into separate subsection. |
| 2.3_copy_depth_infinity |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: This section doesn't clearly address the semantics of COPY with Depth infinity. My recommendation is to add, after paragraph 3, text like this: "As specified in [RFC2518], a COPY with Depth infinity causes the collection resource to be duplicated, all of its bound children to be duplicated, and their children's bound children, and so on, to the bottom of the containment hierarchy. All of the segments of the bindings of the destination collection are the same as for the destination collection. However, the destination resource for all bindings in the destination collection are different from those of the source collection, since all resources have been duplicated, creating new resources with distinct DAV:resource-id properties." |
in revision 09: Example added. |
| 2.3_copy_example |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: It might make sense to create an example covering the situation described in the final paragraph of Section 2.3. I'm not 100% sure I know what scenario this paragraph addresses, other reading the spec. for the first time would presumably have a tougher time. |
in revision 09: Example added. |
| 2.3_COPY_SHARED_BINDINGS |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0010.html> Peter.Nevermann@softwareag.com, 2003-07-10: What if a copied collection has two bindings to the same resource. |
in revision 03: Recommend that only one resource with multiple bindings to it be created by the COPY. |
| 2.3_copy_to_same |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0140.html> lisa@osafoundation.org, 2004-03-24: When a user does a COPY or MOVE from one binding to another binding to the same resource, this should be flagged as an error. Since this has to interoperate with existing clients that won't look at the error body, the status code would have to stand alone. 409 is already used for non-existent parent collections, so that can't be reused. Possibly 403 which in 2518 for COPY means "_ The source and destination URIs are the same." |
in revision 08: Copying/moving to a binding identifying the same resource is harmless (see explanation in http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0143.html) and does not need to be rejected by the server. |
| 2.3_copy_vs_loops |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: There should also be some text addressing COPY depth infinity and loops -- in some instances during a COPY with Depth infinity, the server really wants to recreate the binding that causes the loop, rather than continuing to make duplicate resources. This is somewhat addressed by the final paragraph in Section 2.3, but not exactly. |
in revision 09: Can be closed after copy/depth:infinity example was added (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0181.html). |
| 2.3_MULTIPLE_COPY |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0124.html> Peter.Nevermann@softwareag.com, 2003-08-17: What two resources are copied to the same resource by a single COPY. |
in revision 03: Server decides order of updates. |
| 2.5-move-creating-cycles |
change closed |
julian.reschke@greenbytes.de, 2007-11-10: In presence of collection bindings, a MOVE operation can lead to a bind cycle. Add an example, and mention the right way to reject the request if that is required. See thread starting at <http://lists.w3.org/Archives/Public/w3c-dist-auth/2007OctDec/0022.html>. | in revision 20: |
| 2.5_language |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0205.html> joe@cursive.net, 2004-06-22: Last paragraph is a repeat of text two paragraphs before. |
in revision 06: Just move the second sentence of the last paragraph to the end of the second paragraph, and then delete the rest of the last paragraph. |
| 2.6_bindings_vs_properties |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0248.html> ejw@cs.ucsc.edu, 2004-12-06: I think it would be good to include the following language in the bind specification: Note that, consistent with [RFC2518], the value of a dead property is independent of the number of bindings to its host resource, and of the path submitted to PROPFIND. Since live properties can be aribtrary computational processes, they MAY vary depending on path or number of bindings, but SHOULD NOT do this unless the definition of the live property explicitly includes this dependency. Here I avoided adding new requirements in areas already covered by 2518, but did add requirements for the new situation raised by the BIND specification. julian.reschke@greenbytes.de, 2004-12-14: Original resolution in draft-10: Add that statement (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0299.html and subsequent messages). fielding@gbiv.com, 2005-01-19: ... There are two sections to consider in the bindings draft 2.6 PROPFIND and Bindings Consistent with [RFC2518] the value of a dead property MUST be, and the value of a live property SHOULD be, independent of the number of bindings to its host resource or of the path submitted to PROPFIND. which I consider to be in error because live properties are owned by the server -- any requirement that they be consistent across bindings is wrong. ... julian.reschke@greenbytes, 2005-01-25: Fixed the sentence. Further changes to be proposed / discussed. See also http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0109.html. |
in revision 11: Issue closed for now with statement about dead properties added, but no explicit mention of live properties. See also http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0112.html. |
| 2.6_identical |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0188.html> julian.reschke@greenbytes.de, 2004-09-17: Clarify exactly when when two resource-ids are identical. |
in revision 07: They are identical if and only they are the same character by character. |
| 2.6_resource-id_vs_versions |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: There needs to be some discussion on the interactions of DAV:resource-id and versioning. As near as I can tell, the intent is that every revision will have a unique DAV:resource-id value. |
in revision 09: Mention in an example. |
| 2.6_when_do_ids_change |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: Change "must not" to "MUST NOT" (and eliminate the "For example" at the start of the sentence -- perhaps change to "Specifically," julian.reschke@greenbytes.de, 2004-11-30: Fix language, replace MOVE by REBIND (because MOVE may be implemented as COPY/DELETE). Unclear whether we need more changes. |
in revision 10: Closed (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0300.html). |
| 2.7_unlock_vs_bindings |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0031.html> JHildebrand@jabber.com, 2005-01-14: (Proposal to clarify UNLOCK vs bindings, see http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0031.html) |
in revision 11: Added (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0042.html). |
| 2_allow_destroy |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: The language here would preclude the future definition of a DESTROY method which had the semantics of removing the state of a resource from a server, irregardless of any containment relationships that may hold it. Such a method could be quite useful for records management functionality, in order to implement a records disposition policy that specified deletion at a certain time. My recommended tweak to the language of section 2 is minor: add the following sentence to the end of the paragraph: "It is permissible, however, for future method definitions (e.g., a DESTROY method) to have semantics that remove all bindings and/or immediately reclaim system resources." |
in revision 09: Agreed to add statement about methods that explicitly have that semantics. |
| 3.1-clarify-resource-id |
change closed |
julian.reschke@greenbytes.de, 2007-11-11: Clarify that as the resource-id is a URI, it is effectively an alternate identifier for the resource. Thus, if it is resolvable, it should be resolved to the same resource. | in revision 20: Done. |
| 3.1_uuids |
edit closed |
julian.reschke@greenbytes.de, 2004-12-11: Action item: if draft-mealling-uuid-urn gets accepted in time, consider referencing it and using urn:uuid URIs instead of opaquelocktoken URIs. See IETF I-D Tracker. | in revision 11: Done after approval of draft-mealling-uuid-urn, see also http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0027.html. |
| 3.2_example |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: I think it would be helpful to have an example of this property. I'd be happy to help develop such an example. |
in revision 09: Example added, including diagram. |
| 4-precondition-language |
edit closed |
julian.reschke@greenbytes.de, 2007-11-11: Rephrase definitions for DAV:cross-server-binding and DAV:cycle-allowed so it becomes clear that support for these features is optional. | in revision 20: Done. |
| 4_507_status |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0282.html> julian.reschke@greenbytes.de, 2003-12-09: Section 4 refers to a definition of a 507 status code in Section 7.1, which doesn't exist. Should this text be replaced by a reference to the DAV:cross-server-binding precondition? |
in revision 03: Change wording to refer to precondition name. |
| 4_LOCK_BEHAVIOR |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0200.html> briank@xythos.com, 2003-02-28: Define "Resource": The term "resource" should be defined in the draft. I imagine the definition is something along the lines of "all content and all properties associated with that content (including live and dead properties), but which does not include properties associated with URIs." Bindings and Locks: The relationship between bindings and locks is missing from the draft. I think the behavior of locks and the lock methods should be fully specified in this draft. URL Properties: The behavior of other URL properties (in addition to locks) should be fully specified, for instance the display-name property. Move and Delete: The spec states that move and delete are merely operations on bindings. At the very least, this is inconsistent with 2518, but I also think that the draft doesn't adequately address any of the issues that come up when the server goes to "reclaim system resources." I would expect most servers to reclaim said resources during move and delete. Operations not Atomic: None of the operations specified should be required to be atomic. I'd prefer SHOULD NOT myself. This is especially true for any operation that involves deleting collections. |
in revision 06: This was closed in draft 02. Some comments: (1) It's up to RFC2396 and RFC2616 to define what a "resource" is. We don't change that here. (2) There is no such thing as URL properties. WebDAV properties are part of the state of a WebDAV/HTTP resource; and a URI by itself is not a resource. (3) Bindings vs Locks: see other issues. (4) MOVE and DELETE are allowed to work the same way as in RFC2518 (except for Delete not removing all bindings). (5) The new methods are all atomic on purpose. If a server can't implement UNBIND on collections; that is fine. It can still implement DELETE with the classic non-atomic behaviour. |
| 5.1_506_STATUS_STREAMING |
change closed |
julian.reschke@greenbytes.de, 2004-01-12: Take a server that allows Depth: infinity upon PROPFIND. In general, the only way to implement this efficiently is to *stream* the multistatus response. However this means that the server needs to decide about the HTTP status code to return *prior* to actually doing the recursion. Therefore, requiring the server to return a 506 status in case there's a bind loop somewhere below the request URI will not work. An obvious alternative would be to allow the 506 to be returned inside the DAV:status element for the resource the server refuses to recurse into. Of course that would mean that the client essentially would get a partly incorrect picture of the server state. However, I don't think there's any way to avoid that (except for rejecting all Depth: infinity PROPFINDs, like many servers already do). | in revision 04: Allow 506 inside multistatus. |
| 5.1_LOOP_STATUS |
change closed |
julian.reschke@greenbytes.de, 2002-10-11:
Should the 506 status in a PROPFIND be handled differently?
geoffrey.clemm@us.ibm.com, 2003-08-03: Use new 208 status to report cycles in PROPFIND. julian.reschke@greenbytes.de, 2003-11-16: Proposal: a) import DAV request header definition from rfc2518bis (note that the definition in the latest draft probably needs some more work) b) define a DAV compliance class for the BIND spec c) clarify that 208 should only be returned when the client specifies compliance to the BIND spec in the PROPFIND request (otherwise fail the complete request). |
in revision 04: Define DAV compliance class "bind", define DAV request header, clarify that 208 must only be used when the client signals that it knows about this specification. |
| 6.1_rebind_vs_locks |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0281.html> ejw@cs.ucsc.edu, 2004-12-09: (Request to add a REBIND example that requires submitting a lock token) |
in revision 10: Example added. |
| 6_lock_behaviour |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0093.html> lisa@osafoundation.org, 2004-03-17: Does REBIND destroy locks, as MOVE does? It shouldn't, unless there's a compelling reason for backward compatibility. |
in revision 05: REBIND behaves like MOVE (and any other namespace operation), thus locks are destroyed. Add postcondition DAV:lock-deleted. |
| 6_precondition_binding_allowed |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0093.html> lisa@osafoundation.org, 2004-03-17: One precondition is " (DAV:binding-allowed): The resource identified by the DAV:href supports multiple bindings to it." How can this error possibly occur? |
in revision 05: Cut & Paste error (copied from BIND method). Remove it. |
| 6_rebind_intro |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0044.html> ejw@cs.ucsc.edu, 2004-11-12: I'm reading through the BIND specification, and the description of the REBIND method's operands is a bit unclear to me. I'm assuming the intent is similar to BIND and UNBIND, each of which clearly state in the first sentence what role the Request-URI, segment, and href fields play. In my reading I just jumped right into the spec. at this method (typical reference reading pattern), and hence I didn't initially see the similarity with the BIND and UNBIND method operands. |
in revision 09: Agreed and fixed (fixed again after it was broken in -08). |
| 6_rebind_premissions |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0218.html> ejw@cs.ucsc.edu, 2004-12-03: I agree with Lisa that the access control implications of REBIND should be made explicit. My suggestion is to add the following language to Section 6. Change: "It is effectively an atomic form of a MOVE request." To: "It is effectively an atomic form of a MOVE request, and MUST be treated as a MOVE for the purpose of determining access permissions (see RFC 3744, Appendix B)." |
in revision 09: Make that statement, but avoid the unnecessary normative reference to RFC3744. |
| 7.1.1_add_resource_id |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0205.html> joe@cursive.net, 2004-06-22: I think this would be clearer if it included D:resource-id in the request and response, so you could tell where the loop happened. Are resource-id's likely to be costly to return? |
in revision 06: No, they should be cheap. Update example. |
| 9.2_redirect_loops |
edit closed |
julian.reschke@greenbytes.de, 2004-01-09: Avoid confusion with REDIRECT. Propose rename to "Bind Loops". | in revision 04: Do the rename. |
| 9_ns_op_and_acl |
change closed |
julian.reschke@greenbytes.de, 2005-02-04: Define the interactions between BIND and REBIND and the DAV:acl property (see RFC3744, section 7.3) and http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0165.html). | in revision 11: State that BIND and REBIND behave as MOVE (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0166.html). |
| atomicity |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0129.html> ejw@cs.ucsc.edu, 2004-11-29: The intent of the BIND method is for its behavior to be atomic. However, this is never actually stated explicitly in the specification. Seems like it should be. |
in revision 09: Agreed. Steal text from RFC3253 (applies to all method definitions). |
| auth48 |
edit closed |
julian.reschke@greenbytes.de, 2010-02-27: Issues resolved during RFC-Editor's AUTH48 phase. | in revision latest: |
| bind-vs-hierarchy |
edit closed |
julian.reschke@greenbytes.de, 2009-11-29: Note that a system based on the BIND collection model will be inherently incompatible with a system that inherits information based on just the naming hierarchy, not taking multiple bindings into account. In particular, Access Control implementations based on path inheritance come to mind. (This is not a problem of the BIND data model itself, but a known issue when an attempt is made to build a hybrid system). | in revision 27: Add a note to the overview, and also clarify the "Relation to WebDAV ACL" section. |
| bind_properties |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.html> lisa@osafoundation.org, 2004-03-24: (Issues with BIND semantics vs servers that compute properties based on request-URI, see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.html and http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0154.html). |
in revision 08: The authors feel that in the WebDAV data model, properties are part of the state of the resource, thus should not vary on request URI. A server that implements properties as state of a binding instead of the resource to which it binds would be inherently incompatible with both WebDAV and BIND semantics. It's unclear why this would matter - a server that can't implement BIND semantics simply can't support this specification (likely for more reasons than this one). See also summary at http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0022.html. |
| bind_vs_ACL |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0149.html> lisa@osafoundation.org, 2004-03-24: What permissions are required in order to perform a BIND request? I would think that permissions for UNBIND and REBIND are identical to permissions for DELETE and MOVE respectively, but this should be stated. |
in revision 08: BIND and UNBIND are controlled by the privileges DAV:bind and DAV:unbind. REBIND is an atomic form of MOVE, those the same privileges apply. The authors feel that this does not need to be explicitly stated (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0150.html). |
| clarify-alternate-uri |
change closed |
alexey.melnikov@isode.com, 2009-05-15:
The note about resource-id being an alternate URI is confusing.
julian.reschke@greenbytes.de, 2009-05-25: This was added in draft 19, dealing with issue "3.1-clarify-resource-id" (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.3.1-clarify-resource-id>). See also <http://lists.w3.org/Archives/Public/w3c-dist-auth/2007OctDec/0029.html>. Proposal: either clarify (expand) or remove it. |
in revision 24: Statement removed. |
| clarify-clarify |
change closed |
julian.reschke@greenbytes.de, 2009-06-08: Rephrase this so it becomes clear this is really a clarification making RFC 4918 consistent internally. | in revision 25: Done. Expand the explanation, rephrase the clarification. See also <http://lists.w3.org/Archives/Public/w3c-dist-auth/2009AprJun/0020.html>. |
| copying-complex-loops |
edit closed |
rjsparks@nostrum.com, 2009-06-03:
The document provides some discussion of the ramifications of simple loops, but
its not immediately obvious that the recommendations for handling them are
sufficient for dealing with more complex loops. Are there additional issues
introduced when each added level of depth adds an exponentially growing number
of elements?
(view in fixed width)
+---------+
| root |
| |
| start |
+---------+
|
v
+---------+ +---------+
+---->| C1 | | C2 |<---+
| +->| | | |<-+ |
| | | a b | | a b | | |
| | +---------+ +---------+ | |
| | | | | | | |
| | | | +----+ | | |
| | | | | | | |
| | | +----------c---+ | | |
| | | | | | | |
| | | +----------+ | | | |
| | v v v v | |
| | +---------+ +---------+ | |
| | | C3 | | C4 | | |
| | | | | | | |
| | | a b | | a b | | |
| | +---------+ +---------+ | |
| | | | | | | |
| +----+ | +----+ +-----+ |
| | | |
| +----------c-----------------+
| |
+-----------------------+
|
in revision 27: The authors discussed this question and came to the conclusion that the considerations for complex loops are identical to those for simple loops; a COPY operation still duplicates the binding graph. A short note pointing this out was added to the end of the example. |
| def-integrity |
change closed |
alexey.melnikov@isode.com, 2009-05-15: Define the term "integrity". | in revision 24: Add definition to Terminology Section. |
| ED_authors |
edit closed |
julian.reschke@greenbytes.de, 2004-01-02: Ensure contact information for all original authors is still correct, and that the authors in fact support the current draft. | in revision 04: J. Slein removed as author and added to Acknowledgments. |
| ED_references |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0283.html> julian.reschke@greenbytes.de, 2003-12-09: (1) Distinguish normative and informative references, (2) text referring to RFC2119 is missing, (3) references to RFC2277, RFC2616 and XML not needed. |
in revision 03: Editorial changes applied. |
| ED_rfc2026_ref |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0220.html> julian.reschke@greenbytes.de, 2004-09-27: The reference to RFC2026 isn't used anywhere in the text. |
in revision 07: Remove it. |
| ED_updates |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0306.html> julian.reschke@greenbytes.de, 2003-12-30: Shouldn't the BIND spec be labelled as "updating" RFC2518 and/or RFC3253? julian.reschke@greenbytes.de, 2004-01-05: It seems that there was consensus to say that BIND does update RFC2518, while there's no consensus about the relationship to RFC3253. As this is a minor editorial question, I propose to just say "updated 2518" and to close the issue. |
in revision 13: Previously: State "updates 2518". Changed to: "updated draft-ietf-webdav-rfc2518bis". |
| edit |
edit closed |
julian.reschke@greenbytes.de, 2004-05-30: Umbrella issue for editorial fixes/enhancements. | in revision latest: |
| ex-copy-graph |
edit closed |
alexey.melnikov@isode.com, 2009-05-15:
Add example for the case discussed below: "If a COPY request would cause a new resource to be created as a copy of an
existing resource, and that COPY request has already created a copy of that
existing resource, ..."
julian.reschke@greenbytes.de, 2009-05-18: It seems that we already have that example, see "2.3.2. Example: COPY with 'Depth: infinity' with Multiple Bindings to a Leaf Resource". |
in revision 24: Added forward reference to example. |
| ex-copy-multiple-update |
edit closed |
alexey.melnikov@isode.com, 2009-05-15: Add example for the case: "If because of multiple bindings to a resource, more than one source resource updates a single destination resource, the order of the updates is server defined." | in revision 24: Example added. |
| ex-live-property |
edit closed |
alexey.melnikov@isode.com, 2009-05-15:
Give an example of a live property where the value depends on the path.
julian.reschke@greenbytes.de, 2009-05-19: Thread in which the latest version of this paragraph was discussed: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0023.html>. |
in revision 24: |
| iana-vs-http-status |
change closed |
Reference: <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=266> julian.reschke@greenbytes.de, 2007-02-08: Need to register new HTTP status codes according to RFC2817 and <http://www.iana.org/assignments/http-status-codes>). |
in revision 17: Done. |
| iana.statuscode |
change closed |
julian.reschke@greenbytes.de, 2010-01-25: IANA rightfully points out that status code 506 is taken by RFC 2295. Let's use 508 instead. | in revision latest: Done. |
| locking |
change closed |
Reference: <http://www.xmpp.org/ietf-logs/webdav@ietf.xmpp.org/2004-03-01.html> lisa@xythos.com, 2004-03-02: (concerns about the behaviour of multiple bindings to the same resource when the resource was locked via WebDAV LOCK on one of it's bindings). |
in revision 04: No issue here: given two URIs "a" and "b" mapped to the same resource, and a WebDAV LOCK that was requested for "a", attempts to modify the lockable state of "b" will fail unless the lock-token is presented. This is because the resource itself is locked, not only it's URI "a". See RFC2518, section 6. |
| locking-example |
edit closed |
julian.reschke@greenbytes.de, 2009-09-05: Based on IESG feedback: add an example showing a case where the text below becomes relevant. | in revision 26: Example added. |
| locking2 |
change closed |
julian.reschke@greenbytes.de, 2009-11-29: We have failed to reach consensus about the RFC 4918 clarification. Thus we'll have to accept that it says what it says, and need to clarify how it applies to locking, essentially pointing out which behavior we expect. To do this, create a new section about locking, which will explain the "lock root" as required by a server that supports multiple bindings. Also keep the example. | in revision 27: Added new section specifying the locking behavior, removed the appendix. |
| relation-to-deltav |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0031.html> werner.donne@re.be, 2008-08-11: ...When supporting version controlled collections, bindings may be introduced in a server without actually issuing the BIND method. When a MOVE is performed of a resource from one collection to another, both collections should be checked out. An additional binding would be the result if one collection would be subsequently checked in, while the check-out of the other is undone. The resulting situation is meaningless if the binding model is not supported... |
in revision 22: Add new section containing that example. |
| rfc2396bis |
edit closed |
julian.reschke@greenbytes.de, 2004-10-21: Update references to RFC2396 with draft-fielding-uri-rfc2396bis-07. | in revision 08: Done. |
| rfc2518bis-lock-root |
change closed |
julian.reschke@greenbytes.de, 2007-01-04: draft-ietf-webdav-rfc2518bis-17 uses the term "lock root" inconsistently. Add an appendix explaining the problem and suggesting a clarification. | in revision 16: Add appendix explaining the issue and recommending a fix to rfc2518bis. |
| rfc4918 |
edit closed |
julian.reschke@greenbytes.de, 2007-06-30: Update RFC2518bis reference to RFC4918. | in revision 19: Done. |
| sec-cons-references |
edit closed |
kivinen@iki.fi, 2009-06-02: Security considerations section refers to the "HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification" and says that all security considerations of them also applies to this document, but it does not give explicit references to the documents containing those security considerations. | in revision 25: Add the references. |
| should-not-update-4918 |
change closed |
julian.reschke@greenbytes.de, 2009-06-04: Based on IESG feedback: should not state that we update a Standards Track document unless we have to. | in revision 25: Boilerplate updated. |
| should-update-2616 |
change closed |
adrian.farrel@huawei.com, 2009-06-03:
The referenced IANA registry states: Values to be added to this name space SHOULD be subject to review in the form of a standards track document within the IETF Applications Area. Any such document SHOULD be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1. ...I only see "updates 4918". Following the trail... 4918 obsoletes 2518 2518 doesn't update or obsolete anything. So I think you need to add "Updates 2616" |
in revision 25: First resolution was: add the clause; but subsequent discussion with the IESG led to the conclusion it doesn't need to. HTTPbis is going to take over the status code registry procedure, and is already working on this issue, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170> (as of this writing, the plan was to remove the requirement for "updates" -- <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/591>, and to issue an erratum to RFC 2817). |
| specify_safeness_and_idempotence |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0192.html> julian.reschke@greenbytes.de, 2004-09-18: Specify safeness and idempotence of new methods. |
in revision 07: Done. |
| status-codes |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0067.html> julian.reschke@greenbytes.de, 2008-09-26: The spec currently micro-manages HTTP status codes: for instance, for a successful BIND it requires status codes of 200 or 201, while - from an HTTP point of view - a 204 should be acceptable as well. Proposal: rephrase the text so that other success codes are acceptable as well, or remove the normative language completely, point to RFC2616, and rely on examples. |
in revision 22: Also allow 204 where previously only 200 was allowed. Add Location header to example using status 201. |
| uri_draft_ref |
edit closed |
julian.reschke@greenbytes.de, 2005-01-01: Fix reference to draft-fielding-uri-rfc2396bis-07 | in revision 10: |
| webdav-rev |
edit closed |
julian.reschke@greenbytes.de, 2006-01-30: Update from RFC2518 to RFC2518bis. | in revision 14: Removed own explanation of DTD syntax, removed own definition of precondition/postcondition, removed reference to broken RFC2518 language about DELETE and UNLOCK, removed own definition of DAV: request header, updated examples to use application/xml instead of text/xml MIME type, removed "Rationale for Distinguishing Bindings from URI Mappings" to reflect the changes in draft-ietf-webdav-rfc2518bis-14. |
| webdav-wg-gone |
edit closed |
adrian.farrel@huawei.com, 2009-06-03: There is no WebDAV WG (anymore). | in revision 25: Add "concluded". |
| Version | Issues |
|---|---|
| latest | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 27 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 26 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 25 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 24 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 23 | ||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 22 | ||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 21 | ||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 20 | ||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 19 | |||||||||||||||||||||||||||||||||||||||||||||| |
| 18 | ||||||||||||||||||||||||||||||||||||||||||||| |
| 17 | ||||||||||||||||||||||||||||||||||||||||||||| |
| 16 | |||||||||||||||||||||||||||||||||||||||||||| |
| 15 | ||||||||||||||||||||||||||||||||||||||||||| |
| 14 | ||||||||||||||||||||||||||||||||||||||||||| |
| 13 | ||||||||||||||||||||||||||||||||||||||||||| |
| 12 | ||||||||||||||||||||||||||||||||||||||||| |
| 11 | ||||||||||||||||||||||||||||||||||||||||| |
| 10 | ||||||||||||||||||||||||||||||||||||||| |
| 09 | ||||||||||||||||||||||||||||||||||| |
| 08 | |||||||||||||||||||||||| |
| 07 | ||||||||||||||||||| |
| 06 | |||||||||||||||| |
| 05 | ||||||||||| |
| 04 | |||||||||| |
| 03 | ||||| |
| 02 |
Last change: 2010-02-27