W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2008

Re: Thoughts on relation to WebDAV

From: Werner Baumann <werner.baumann@onlinehome.de>
Date: Sat, 24 May 2008 14:16:51 +0200
Message-ID: <48380733.6030606@onlinehome.de>
CC: w3c-dist-auth@w3.org

Julian Reschke wrote:
> Werner Baumann wrote:
> If a server has a data model that supports collections, it will 
> implement MKCOL. Otherwise it won't. No matter what the spec says.
> So if you want to expose a set of HTTP resources for authoring, and you 
> can support all of WebDAV L2 and L3, *except* creating new collections, 
> what would you return in the DAV: response header upon OPTIONS?
> I bet you'd claim support for MKCOL, return level 3, and then fail the 
> request if somebody tries to MKCOL anyway.
What was the bet about? A barrel of beer? You lost the bet.

>> If you buy a WebDAV-server from a vendor and later notice it does not 
>> support MKCOL. Does it matter whether this is standard compliant?
> So how exactly is it an improvement to the client when the server claims 
> it can do MKCOL, but always returns 403? That would be compliant with 
> RFC2518, but not helpful it all.

It is not an improvement at all. In my opinion it would be fraud.
A server that does not support creation of collections is *not* 
compliant with RFC 2518 (and, I hope, with RFC 4918 neither) and must 
not send a DAV-header at all. Hiding this none-compliance by misusing 
403 makes things worse.

This does not mean, that it is not allowed to create and use servers and 
clients, that do not meet all requirements of the standard (or the 
proposed standard), and therefore are not compliant. But these needs to 
be documented and server and clients will need out of band information 
about their capabilities to be set up properly. There will be no 
guarantee for interoperability with other clients or servers. These 
cases are outside the spec.

Received on Saturday, 24 May 2008 12:17:47 UTC

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