Subject: Support for non-DAV collections

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 08 Jul 2005 15:30:20 -0700

Speaking of RFC2518bis, do we have any support for this option in any  
WebDAV implementations?  I don't recall it being tested in past interops...

"   A resource MAY be a collection but not be WebDAV compliant.  That is,
    the resource may comply with all the rules set out in this
    specification regarding how a collection is to behave without
    necessarily supporting all methods that a WebDAV compliant resource
    is required to support.  In such a case the resource may return the
    DAV:resourcetype property with the value DAV:collection but MUST NOT
    return a DAV header containing the value "1" on an OPTIONS response."

If this option isn't implemented or isn't interoperable, let's cut it.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Jul 2005 09:18:50 +0200

> If this option isn't implemented or isn't interoperable, let's cut it.

As far as I can tell, there's no reason to cut it. It doesn't make the 
protocol harder to implement, and it may be of value for some servers 
that choose to implement a subset of WebDAV only (GroupDAV comes to mind).

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 09 Jul 2005 08:41:15 -0700

It depends on whether we're going for Draft Standard or not -- and it was  
my understanding that Ted is keeping the WG open so we can bring WebDAV to  
Draft Standard.  To go to Draft Standard, we need to take a Proposed  
Standard and remove the options that aren't implemented, interoperable and  
tested 2x2.

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?

Lisa

On Sat, 09 Jul 2005 00:18:50 -0700, Julian Reschke <[email-masked]>  
wrote:

>
> Lisa Dusseault wrote:
>>   Speaking of RFC2518bis, do we have any support for this option in  
>> any  WebDAV implementations?  I don't recall it being tested in past  
>> interops...

---

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Jul 2005 18:40:35 +0200

Lisa Dusseault wrote:
> It depends on whether we're going for Draft Standard or not -- and it 
> was  my understanding that Ted is keeping the WG open so we can bring 
> WebDAV to  Draft Standard.  To go to Draft Standard, we need to take a 
> Proposed  Standard and remove the options that aren't implemented, 
> interoperable and  tested 2x2.

Yes. Every server that supports collections as WebDAV compliant 
resources already supports this feature. And every client that issues a 
PROPFIND without using other WebDAV methods already uses it. I'm not 
sure what kind of additional test you're looking for.

> 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.

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 09 Jul 2005 17:19:47 -0700

> sure what kind of additional test you're looking for.

That's not how I read it.  I understood that paragraph as saying that a  
server could call something a collection (using the resourcetype property)  
but have it be non-WebDAV-compliant resources.  In fact "not be WebDAV  
compliant" is in the first sentence.  So that's why I asked if anybody had  
implemented non-WebDAV-compliant resources that still had the  
DAV:collection element in the DAV:resourcetype property.  I can imagine  
how one might use this -- for example, it might show up in its parent as a  
collection yet not itself support direct PROPFIND requests -- but I am  
unaware of any implementations.

> discussed this over three years ago and concluced that they are indeed  
I also figured that shared locks were implemented already although I'm not  
sure they satisfy the 2x2 test requirement.  But what about 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.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jul 2005 10:44:05 +0200

Lisa Dusseault wrote:
> On Sat, 09 Jul 2005 09:40:35 -0700, Julian Reschke 
> <[email-masked]>  wrote:
> 
>>
>> Lisa Dusseault wrote:
>>
>>> It depends on whether we're going for Draft Standard or not -- and 
>>> it  was  my understanding that Ted is keeping the WG open so we can 
>>> bring  WebDAV to  Draft Standard.  To go to Draft Standard, we need 
>>> to take a  Proposed  Standard and remove the options that aren't 
>>> implemented,  interoperable and  tested 2x2.
>>
>>
>> resources already supports this feature. And every client that issues 
>> a  PROPFIND without using other WebDAV methods already uses it. I'm 
>> not  sure what kind of additional test you're looking for.
> 
> 
> server could call something a collection (using the resourcetype 
> property)  but have it be non-WebDAV-compliant resources.  In fact "not 
> be WebDAV  compliant" is in the first sentence.  So that's why I asked 
> if anybody had  implemented non-WebDAV-compliant resources that still 
> had the  DAV:collection element in the DAV:resourcetype property.  I can 

What the spec says is that if a server has something that is a 
collection, but if the collection (or it's members) are not 
DAV-1-compliant resources, the server still can return a 
DAV:resourcetype of DAV:collection. That is, to be a DAV:collection is a 
feature that is ortogonal to other WebDAV features.

BTW: this implies that the collection supports PROPFIND, otherwise 
there'd be no way to return a resource type.

I think it's a very good approach, because it offers servers to pick one 
specific WebDAV feature (collection) without having to reach full WebDAV 
compliance.

In general, this is how many features in WebDAV work. For instance, a 
server can go ahead and implement one single WebDAV method (for 
instance, MKCOL), and nothing else. As long as it claims WebDAV 
compliance (through the DAV response header), this is just fine. So 
removing the sentence doesn't really change what the spec defines; it 
just makes one implementation option less obvious -- can you give a 
specific example where removing the statement would change *any* of the 
current interop requirements?

> imagine  how one might use this -- for example, it might show up in its 
> parent as a  collection yet not itself support direct PROPFIND requests 
> -- but I am  unaware of any implementations.

This is what 5.2, paragraph 4 explicitly states 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.5.2.p.4>):

"Collection resources MAY list the URLs of non-WebDAV compliant children 
in the HTTP URL namespace hierarchy as internal members but are not 
required to do so. For example, if the resource with URL 
http://foo.com/bar/blah is not WebDAV compliant and the URL 
http://foo.com/bar/ identifies a collection then URL 
http://foo.com/bar/blah may or may not be an internal member of the 
collection with URL http://foo.com/bar/."

 > ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jul 2005 10:50:35 +0200

Lisa Dusseault wrote:
>>> (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  
>> 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?

> 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.

Best regards, Julian

---

From: Helge Hess <[email-masked]>
Date: Sun, 10 Jul 2005 11:35:45 +0200

On 10. Jul 2005, at 02:19 Uhr, Lisa Dusseault wrote:
> So that's why I asked if anybody had implemented non-WebDAV- 
> compliant resources that still had the DAV:collection element in  
> the DAV:resourcetype property.

As Julian mentioned some GroupDAV servers (like Citadel) are in this  
category (implement PROPFIND, return a collection but not allow  
additional DAV operations).

Having said that this is probably not relevant for an IETF standard.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jul 2005 11:49:12 +0200

Helge Hess wrote:
>> So that's why I asked if anybody had implemented non-WebDAV- compliant 
>> resources that still had the DAV:collection element in  the 
>> DAV:resourcetype property.
> 
> 

As Helge just kind-of proved; it really doesn't matter what RFC2518bis 
says on this topic. Server implementers will do what makes sense to them 
anyway :-).

So removing that sentence will not affect what those who don't claim 
WebDAV compliance do anyway. On the other hand, it may give people that 
do want to re-use parts of WebDAV without doing a fully compliant server 
a useful hint about what can be done.

So I still see no compelling reason to that change: removing the 
sentence will have no effect on interop requirements at all.

Best regards, Julian

---

From: Helge Hess <[email-masked]>
Date: Sun, 10 Jul 2005 12:54:20 +0200

On 10. Jul 2005, at 11:49 Uhr, Julian Reschke wrote:
> So removing that sentence will not affect what those who don't  
> claim WebDAV compliance do anyway. On the other hand, it may give  
> people that do want to re-use parts of WebDAV without doing a fully  
> compliant server a useful hint about what can be done.

I don't think suggestions on how to subset belong into a standard for  
some specific protocol?

> sentence will have no effect on interop requirements at all.

Can't tell about the interop requirements, but removing superflous  
things is always a good thing.

Greets,
   Helge

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jul 2005 13:09:05 +0200

> things is always a good thing.

Funny enough, that's something I violently agree with :-) On the other 
hand, when going from Proposed to Draft, another good rule is not to 
change things that aren't broken.

But if we all agree that we *do* want to remove paragraphs that are 
superfluous (because they neither define anything specific, nor are 
needed as explanations), that's fine with me. Let's just be consistent 
in that.

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 10 Jul 2005 16:06:15 -0700

> ago, and it has been marked as resolved. Do you want to re-open that  

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

Ok, I'll leave those sections separate.  T

Lisa

---

From: Joachim Feise <[email-masked]>
Date: Sun, 10 Jul 2005 19:53:08 -0700

> if we'd heard of additional implementations in the intervening years.

The DAV Explorer client supports both exclusive and shared locks...

-Joe