Subject: rfc2518bis-14: the term 'DAV-compliance'

From: Manfred Baedke <[email-masked]>
Date: Wed, 15 Mar 2006 16:39:51 +0100

Hi,

the more I think about it, the more headaches I get from the term 
'DAV-compliance' as it is used in RFC2518bis.
First of all, it is never defined in the specification, though it 
appears to be a widely used technical term. Since it is not defined 
explicitly, one has to extract its meaning from the usage in the text. A 
DAV-compliant resource has to support all methods defined in the spec 
with the exception of LOCK and UNLOCK. Consequently, if an 
implementation decides to support a proper subset of the set of these 
methods, it will be not DAV-compliant. But of course, one wants such an 
implementation to fulfil general requirements on DAV resources, for 
example those defined in section 5.2 on collection resources. But 
section 5.2 in turn applies explicitly to DAV-compliant resources, using 
wordings like 'For all WebDAV compliant resources A and B, identified by 
URLs "U" and "V" respectively...'.
IMHO, the term 'DAV-compliance' should refer to implemetations that are 
aware of the specification and fulfil some general requirenments. It 
does not make sense to require a DAV-compliant resource to support any 
given set of methods (there are still the compliance classes to express 
different levels of support). Consequently, i would drop all the 
requirements matching the 'All DAV-compliant resources MUST support the 
XYZ method' pattern from the method definitions in section 9 and define 
a DAV-compliant resource to be a resource fulfilling the MUST 
requirements in the spec.

Regards,
Manfred

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Wed, 22 Mar 2006 14:15:35 -0800

Well, a resource can return a FORBIDDEN response to (just about?)  
any method and still comply, so implementing a method that you don't  
want people to invoke is pretty trivial, no?

	-wsv

On Mar 15, 2006, at 7:39 AM, Manfred Baedke wrote:

> A DAV-compliant resource has to support all methods defined in the  
> spec with the exception of LOCK and UNLOCK.

---

From: Manfred Baedke <[email-masked]>
Date: Wed, 22 Mar 2006 23:43:47 +0100

Well, even if one did that, what is the point of telling the client that 
the server actually supports a method, only the send FORBIDDEN in every 
case?

Regards,
Manfred