- From: <bugzilla@soe.ucsc.edu>
- Date: Fri, 3 Dec 2004 10:10:41 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2 ejw@cs.ucsc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From ejw@cs.ucsc.edu 2004-12-03 10:10 ------- There is merit to both sides of this issue. Many lock interactions can be determined by a careful reading both 2518 and the BIND specification, and I agree these shouldn't be repeated in this specification. However, there are some new issues which the BIND specification raises that are not addressed or considered by 2518. These include: * The interactions of locks and loopback bindings. I'm pretty sure we don't want depth infinity locks to propagate along loopback bindings, since this could have unintended consequences (consider a loopback to the root collection). AFAIK, there is nothing in 2518 or BIND that addresses this situation, and the desired semantics (of ignorning the loopback binding) are not entirely consistent with a strict reading of 2518. A careful reader could have doubt concerning the right implementation approach in this case. * The effect on locks of creating a binding to a new (locked or unlocked) collection from within a currently depth infinity locked hierarchy. The semantics for MOVE in 2518 might be appropriate here, but there's still the ambiguity left over from the COPY, DELETE semantics, which are not the same as REBIND. Again, informed people could have legitimate differences of opinion on this issue, which is raised by the BIND specification's BIND and REBIND operators. Due to these two issues, I'm reopening this. I do note that this whole issue (where to address interactions of bindings and locks) is really symptomatic of DAV's containment model being spread across two specifications. I continue to believe that the best approach is to have BIND go to Proposed, and then merge it into 2518bis. Only when the containment model is in one place will we be able to be totally consistent about which examples to include, where to put which descriptions of semantics, etc. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
Received on Friday, 3 December 2004 18:10:43 UTC