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, 20 Dec 2005 11:09:20 -0800
Message-Id: <dbda34f535c4010f837fa12b26d26aef@osafoundation.org>
Cc: WebDav WG <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Dec 20, 2005, at 10:50 AM, Julian Reschke wrote:

> LD> One could imagine the lock applying to the resource and to all its
> LD> bindings, considering  the bindings to be part of the state of the
> LD> resource.  If I recall, I think this is the model I'd always 
> assumed
> LD> until GULP.  With this model, if A and B are bindings to a 
> resource,
> LD> and a LOCK token to A is successful, then for the duration of the 
> lock
> LD> the token is required to change either A or B.
>> It's actually very similar to the model proposed in GULP.  In that 
>> model, the LOCK covers one binding as well as the resource.  The GULP 
>> model does not imply that the locked binding is part of the state of 
>> the resource either.  What a lock covers is a separate concept from 
>> what a resource state includes.

You're right, I used language in a sloppy way in describing the model.  
Anyway, to update my language, I don't see why the model for a LOCK 
can't cover more than only the binding that was locked and the resource 
(and its state) itself.  We should be picking a model that results in 
desirable behaviors.

> Well, it's not completely separate because if affects how Depth 0 
> locks in collections behave.
> Anyway, I don't think we'll make any progress unless you tell us 
> exactly which part of GULP you're unhappy with, and how you propose to 
> change it.

I'm unhappy with the consequence of the GULP model that a DELETE of a 
binding to a locked resource may or may not work depending on whether 
that binding was the one locked.  I propose to change it by requiring 
that a DELETE of a binding to a locked resource needs a lock token.

Received on Tuesday, 20 December 2005 19:09:33 UTC

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