Subject: [Bug 2] Bindings needs to completely describe how bindings interact with locks.

From: [email-masked]
Date: Fri, 3 Dec 2004 10:10:41 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |

------- Additional Comments From [email-masked]  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.