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

Locking feature interop, was: Support for non-DAV collections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 10 Jul 2005 10:50:35 +0200
Message-ID: <42D0E15B.8000807@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Webdav WG <w3c-dist-auth@w3c.org>

Lisa Dusseault wrote:
 > ...
>>> Another option that isn't broadly implemented, if at all, is the  
>>> support  for locks that aren't write locks or aren't exclusive locks  
>>> (since only  exclusive write locks are fully defined).  Are there 
>>> any  implementations  at all that do locks that aren't write locks?  
>>> Didn't  Adobe or somebody  implement shared locks?
>> Me confused.
>> The only type of locks defined in RFC2518 are write locks. Write 
>> locks  can be shared or exclusive, and there are both servers 
>> implementing this  and clients using it. Looking at  
>> <http://www.webdav.org/wg/rfcdev/issues.htm>, issue #96, the WG has  
>> discussed this over three years ago and concluced that they are 
>> indeed  implemented.
> I also figured that shared locks were implemented already although I'm 
> not  sure they satisfy the 2x2 test requirement.  But what about 

I fear I need to make a procedural comment again. The question of shared 
lock interop *is* on the issues list, it *has* been dicussed three years 
ago, and it has been marked as resolved. Do you want to re-open that 

> non-write  locks?  Has anybody implemented locks that aren't write locks 
> and don't  advertise themselves as such?


> The way this impacts the document is that sections 6 and 7 could be 
> merged  if there are effectively only write locks.  Section 6 discusses 
> locks,  section 7 discusses specifically write locks.

RFC2518 has splitted the locking feature into some generic elements, and 
specific write-lock support for a very good reason. I don't see any 
compelling reason at all to change that.

Best regards, Julian
Received on Sunday, 10 July 2005 08:50:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:34 UTC