W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 14 Jan 2005 10:15:08 +0100
Message-ID: <41E78D9C.5050601@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: "WebDAV WG))'" <w3c-dist-auth@w3.org>

Lisa Dusseault wrote:
> I keep re-opening this issue because the spec still doesn't say what the 
> server MUST do or what the client must be prepared to handle.  I don't 
> care how you answer it on the list or in bugzilla; I am not even arguing 
> for any specific answer.  I am arguing for some *specification* here.


it would be helpful if you would indeed *read* my replies. See 

"General statement: it's not the BIND spec's job to resolve open issues 
with RFC2518's defintion of locking. RFC2518 explicitly allows multiple 
URIs to be mapped to the same resource (see for instance section 5.1), 
thus if there's some doubt about lock semantics, it needs to be 
clarified in RFC2518bis.

That being said, both questions can be answered by looking in RFC2518:

- 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)"

So I *both* answered the actual questions *and* explained how it is 
indeed specified through RFC2518 and BIND. So in order to have a 
constructive discussion, you'd need to challenge these statements.

> These answers may follow from RFC2518 in your interpretation, but there 
> have been and will be other interpretations.  Without clear guidance, 
> some clients will assume that the URL that they query (the target of 
> PROPFIND) is the one that MUST appear in the lockdiscovery property for 
> that URL, and that if another URL appears the server must be broken.

I don't know what you're talking about. Where is the URI supposed to 
appear inside the DAV:lockdiscovery element at all? We're talking about 
RFC2518 + BIND, not RFC2518bis, right? (see 

> Some clients will associate only one URL with each locktoken and be 
> confused if the same locktoken appears on some other URL.   Some clients 

Then they are buggy according to RFC2518 
Can you name a client that has this problem?

> will assume that if a URL that they query is locked (and they have the 
> lock token, etc) they can UNLOCK the same URL.   If server implementors 

They can.

> aren't forced to make compatible choices, then we will have 
> interoperability problems surrounding bindings.  We have specifications 
> not just so we can explain the model, but also to make requirements of 
> implementors.

Nobody argues with that. Can we please get back to the question *what* 
you think is underspecified?

Finally, a general note on "what to UNLOCK". A properly written client 
will apply UNLOCK to the URI where it originally applied the LOCK 
request to. It's supposed to keep this information anyway.

Questions about what to UNLOCK in case of "lock stealing" (removing a 
lock created by a different client (instance)) are interesting but 
really about an edge case that should not occur during normal operation. 
  It's fine to discuss this in the context of RFC2518bis (DAV:lockroot 
child element, for instance), but this has nothing to do whatsover with 

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 14 January 2005 09:15:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:31 UTC