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

From: [email-masked]
Date: Tue, 21 Dec 2004 02:44:22 -0800

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

[email-masked] changed:

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

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 28 Dec 2004 11:30:19 -0800

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.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Dec 2004 20:50:44 +0100

> 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:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 28 Dec 2004 14:57:27 -0500

> MUST the contents of the lockdiscovery property look like for both A 

Whether or not a resource is mapped to multiple URL's (via bindings or
any other mechanism) has no effect on the lockdiscovery property.
So the lockdiscovery property is exactly what the locking protocol says
it will be when that resource is mapped to a single URL.

Since the binding protocol does not modify the definition of the
lockdiscovery property, I would object to it restating that definition,
especially since that definition may be revised in 2518bis.

> MUST the server respond to an UNLOCK request to B?"

That depends on how this question is resolved in RFC2518bis
(or preferably, in a separate locking protocol document split off from 
2518bis).
If an UNLOCK must be applied to the URL to which the original LOCK
request was applied, then it must be unlocked via an UNLOCK to A.
If an UNLOCK can be applied to any URL that identifies a resource
that is locked by that lock, then it can be applied to B.
This is the same question that arises in the context of a depth
lock, and the answer should be consistent.  As I recall, the last time
this was discussed, the group was leaning towards the latter (i.e. that
the UNLOCK can be applied to any URL that identifies a resource locked
by the lock), but this is a question that should/must be resolved by the
locking protocol, not be the binding protocol, if we want consistent
behavior defined.

> to do slightly different things.

I would also like to have locking behavior defined, which is why I 
continue
to advocate splitting off the locking protocol from 2518bis for rapid
action.  But putting a couple of bits of information about the locking
protocol in the binding protocol that have a 50/50 chance of conflicting
with how the semantics are defined in the locking protocol makes no sense 
at all.

So I completely agree with Julian's marking this issue as resolved.

Cheers,
Geoff

> > [email-masked] changed:
----------------------------------------------------------------------- 
> > -----

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Dec 2004 21:14:33 +0100

Geoffrey M Clemm wrote:
> ...
> I would also like to have locking behavior defined, which is why I continue
> with how the semantics are defined in the locking protocol makes no 
> sense at all.
> ...

...speaking of which, what *is* the status of RFC2518bis? It was on the 
IETF meeting's agenda, but for some reason it doesn't seem that it was 
discussed there.

Unless there are concrete plans to actually work on it (and the issues 
raised on the mailing list and now collected at 
<http://ietf.cse.ucsc.edu:8080/bugzilla/>), I'd propose to actually take 
out the locking part (as repeatedly proposed in the past 12 months) and 
continue work on 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>. 
This would significantly reduce the complexity of the base protocol (see 
experimental edit at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-base-latest.html>, 
and thus make it much easier to progress to Draft standard).

Best regards, Julian

P.S.: last mention of RFC2518bis on the mailing list seems to be in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0166.html>:

 > While I appreciate all the issues reported with RFC2518, I am not
 > dealing with them until we have issue status tracking more firmly in
 > hand somehow.  Joe is investigating tools to help with this issue.
 >
 > Thanks,
 > Lisa