- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Fri, 23 May 2008 14:32:41 -0700
- To: Werner Baumann <werner.baumann@onlinehome.de>
- Cc: w3c-dist-auth@w3.org
Hi, The omission of a MUST or REQUIRED statement for MKCOL itself was unintentional as far as I can remember. There was certainly no intent to make MKCOL optional -- I think that other sections, luckily, make that obvious even if it's not explicit. BTW, I like summary sections that list every major feature which is required to be implemented, and every major feature that is optional -- they make it easy to ensure that the document is clear about every feature. We did that in CalDAV <http://tools.ietf.org/html/rfc4791#section-2 >. If I entered an errata I could probably also approve it as document author AND as AD, but that might be in bad taste. I appreciate your injunction to take Internet standards more seriously, but I'm afraid you really are preaching to the choir! Thanks, Lisa On May 23, 2008, at 1:56 PM, Werner Baumann wrote: > > 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 21:33:35 UTC