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

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

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Sun, 10 Jul 2005 16:06:15 -0700
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <op.stpzspvceochem@lisa.local>

On Sun, 10 Jul 2005 01:50:35 -0700, Julian Reschke <julian.reschke@gmx.de>  

>>> 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  
> discussion?

No -- shared locks, I agree, are OK, though I'd be even more comfortable  
if we'd heard of additional implementations in the intervening years.

>> non-write  locks?  Has anybody implemented locks that aren't write  
>> locks and don't  advertise themselves as such?
> <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_webdav_locktype_element.asp>
>> 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.

Ok, I'll leave those sections separate.  T

Received on Sunday, 10 July 2005 23:06:29 UTC

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