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

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.

Lisa

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