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: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 18 Jan 2005 12:06:37 -0800
Message-Id: <757BEC0A-698C-11D9-98F2-000A95B2BB72@osafoundation.org>
To: w3c-dist-auth@w3.org

Removing locking from base WebDAV is a major step.  Before we take it, 
I'd specifically like to hear from client implementors, some of whom 
(Adobe) rely on locking being implemented in the server.

Client implementors, please identify yourselves and speak up!


On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote:

> Julian Reschke wrote:
>> Ok,  so do we have consensus to add the following [...]?
> I've been considering the various options suggested to address this 
> issue since it was raised, along with the various implications. For 
> the record, I don't have any problem with the suggested language 
> (below) being added to the BIND specification as it seems to address 
> Lisas' concerns, while leaving the actual locking behavior specified 
> in the core WebDAV specification.
> For future reference, I would also like to see similar clarification / 
> specification of locking behavior in the presence of multiple bindings 
> to a resource appear in either 2518bis or a separate locking 
> specification. My preference, once again, is for locking to be broken 
> out into a separate specification, as suggested and discussed 
> previously on this list. I believe that there was /rough concensus/ on 
> that approach the last time it came up.
> Cheers,
> Elias
> _________________________
>> 2.x UNLOCK and Bindings
>> Due to the specific language used in section 8.11 of [RFC2518], it 
>> might be thought that an UNLOCK request to a locked resource would 
>> unlock just the binding of the Request-URI.  This is not the case, 
>> however.  Section 6 of [RFC2518] clearly states that locks are on 
>> resources, not URIs, so the server MUST allow UNLOCK to be used to 
>> unlock a locked resource through any binding to that resource.  The 
>> authors of this specification anticipate and recommend that future 
>> revisions of [RFC2518] maintain this behavior.
Received on Tuesday, 18 January 2005 22:20:43 UTC

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