- From: Werner Baumann <werner.baumann@onlinehome.de>
- Date: Fri, 23 May 2008 22:56:54 +0200
- To: w3c-dist-auth@w3.org
Julian Reschke wrote: > There are many ways how a server can refuse to do MKCOL. It can > always claim "forbidden", it can say "not implemented" etc. > > In practice it means the client won't be able to create collections. So we need only two status codes in HTTP: success, no success. Ever occurred to you, that an error code should inform about the reason of the failure and that this reason makes a difference in practice? 403 says, the server can create collections, but it will not create *this* collection. 501 says, the server is not able to create collections at all. Can't you imagine, that clients and users might react differently in this two cases? Never seen a windows-user, completely mixing up the system configuration, just because of an idiotic, misleading error message? RFC 4918 has silently removed the requirement for servers to support MKCOL. This (together with compliance class 3) has lead to confusion (see this thread). But it does not matter in practice? Will it not effect the development of clients, whether they can trust in support of MKCOL by all compliant servers? They can always decide to not support badly broken servers, but they can hardly explain why they will not support compliant ones. 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? Was the requirement for supporting MKCOL removed by intention or by an editorial mistake. RFC 4918 lists three contributors and one author. One of them (Julian Reschke) says "It wasn't intentional". There is an Errata document with three entries, all by Julian Reschke. But unintentional removal of a WebDAV-method from the requirements is not worth an entry in Errata, because it does not matter in practice. I believe internet standards should be taken more seriously. Werner
Received on Friday, 23 May 2008 20:57:45 UTC