Lisa Dusseault wrote: > I don't consider that this issue is resolved or fixed. Here's what I > asked for in the bug text: > > " - when a resource with bindings A, B is locked via a LOCK request to > A, what > MUST the contents of the lockdiscovery property look like for both A > and B? > - when a resource with bindings A, B is locked via a LOCK request to > A, how > MUST the server respond to an UNLOCK request to B?" > > I would like to have requirements on the server behavior in these > cases, because otherwise it will be very likely for server implementors > to do slightly different things. The questions have been answered in <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>: "- the value of the DAV:lockdiscovery property will be the same, as both bindings refer to the same resource, and the lock is on the resource (RFC2518, section 13.8) - UNLOCK removes the lock identified by the lock token from the resource identified by the request-URI (and all other resources included in the lock), so again, it doesn't matter to which binding the UNLOCK is applied (section 8.11)" As far as I can tell there was no working group consensus of adding LOCK semantics discussion into BIND. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760Received on Tuesday, 28 December 2004 19:51:23 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 October 2007 17:53:22 GMT