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

Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 13 Dec 2005 09:49:05 -0800
Message-Id: <d5500d4950f8bc0978ba1fe3c87ce246@osafoundation.org>
Cc: w3c-dist-auth@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

Well, I disagree with that model.  I propose that all methods work the  
same on all bindings to a resource with respect to requiring the lock  
token, including DELETE.


On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote:

> OK,
> this is really an important issue RFC2518bis has to solve (I'd say, if  
> we can't resolve it, we shouldn't publish a revision at all).
> So far I've seen two people agreeing that the semantics described by  
> GULP for this situation are indeed correct/desirable, and nobody  
> speaking against. I also note that this is what our server implements  
> (running code!), and nobody has so far made a proposal to define lock  
> semantics differently (not on a case-by-case basis, but with a  
> explanation spanning all methods/situations).
> So any additional feedback would be highly appreciated.
> Best regards, Julian
> Julian Reschke wrote:
>> Hi.
>> yesterday's conference call resulted in kind of interesting
>> news on this issues.
>> As far as I can tell, the current authors of the draft for RFC2518bis  
>> took the position that the text called GULP - the Grand Unified  
>> Locking Proposal (see for instance [1]) - doesn't need to be  
>> incorporated into RFC2518bis because all it says is already covered  
>> over there.
>> When we discussed BugZilla issue 54 [2], we discovered that there's  
>> indeed disagreement on locking semantics, and that we need to resolve  
>> that one way or another.
>> So what we ended up are two separate questions, which are:
>> (1) Should there be a single (normative) place in the doc which  
>> provides a high-level overview of locking, similar but not  
>> necessarily identical with GULP?
>> As far as I can tell, the attendees of the conference call concluded  
>> that yes, we want that.
>> (2) What are the semantics for a lock on a resource having multiple  
>> bindings (issue 54)? Consider:
>> - A resource Z identified by URLs /foo/a and /foo/b.
>> - Z gets locked by a LOCK request on /foo/a.
>> In this situation, is a lock token required to DELETE /foo/b? GULP's  
>> answer to that one is that you don't need the lock token. Removing  
>> the URI /foo/b does not affect the state of resource Z, nor does it  
>> affect any URL that is protected by that lock (/foo/a and /foo/). A  
>> lock token would need to be provided if the resource /foo itself  
>> would be locked, but it isn't.
>> On the other hand, a PUT or a PROPPATCH applied to /foo/b will  
>> require the lock token because it affects the state of resource Z.  
>> This may be confusing, but follows from the fact that the URI of a  
>> resource is not part of it's lockable state. My assumption is that  
>> any other attempt to define this would be even more confusing.
>> Feedback appreciated,
>> Julian
>> [1]  
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/ 
>> 1003.html>
>> [2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 14 December 2005 20:52:10 UTC

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