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: Wed, 14 Dec 2005 13:24:48 -0800
Message-Id: <0ae6246e6d42dec224062290182e8e5b@osafoundation.org>
Cc: w3c-dist-auth@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

One could imagine the lock applying to the resource and to all its 
bindings, considering  the bindings to be part of the state of the 
resource.  If I recall, I think this is the model I'd always assumed 
until GULP.  With this model, if A and B are bindings to a resource, 
and a LOCK token to A is successful, then for the duration of the lock 
the token is required to change either A or B.

In today's server implementations, does a LOCK of depth 0 on a 
collection prevent MOVE from being used to change resource names inside 
the collection?  This is another possible case that might be different 
depending on whether bindings were considered part of the collection, 
part of the resource state, or both.


On Dec 14, 2005, at 1:15 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Good question, and I'm not sure -- it depends what the consequences 
>> are of assuming this distinction.  It seemed like a useful 
>> distinction until it led to what, to me, were unexpected or undesired 
>> consequences.
> Well. If not using this term, how do you distinguish between the 
> resources that are actually locked, and the URLs that are protected? 
> So for instance, with a
> /a/b
> being lcoked (through a LOCK request on /a/b), how do you describe the 
> fact that the URL is protected by the lock (that is, you'll need a 
> lock-token to MOVE /a itself)?
>> Do any servers implement multiple URLs, locking and DELETE 
>> (regardless of whether they support the exact model of BIND)?   If 
>> so, what do existing implementations do?
> Yes, we do, and of course we implement the model we discuss.
> Best regards, Julian
Received on Wednesday, 14 December 2005 21:25:07 UTC

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