- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 5 Apr 2004 23:10:13 +0200
- To: Lisa Dusseault <lisa@xythos.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Patrik Fältström <paf@cisco.com>, Webdav WG <w3c-dist-auth@w3c.org>
Am 05.04.2004 um 22:15 schrieb Lisa Dusseault: > [...] > Except for the cases where it does matter, like BIND/UNBIND, MOVE and > DELETE. The spec is not clear enough about which methods apply to the > binding and which apply to the resource, and when. The spec doesn't > say whether LOCK behaves more like PUT, or more like BIND. Well, the bind spec does not talk about LOCK. It defines how BIND, REBIND and UNBIND work in the presence of locked resources. RFC 2518 explicitly adresses the case where multiple URLs to a single resource do exist (see 2518 Chapter 5.1). *RFC 2518* does not explain how LOCK and other methods work in the presence of multiple URLs to the same resource. The bind spec currently defines the behaviour of namespace operations in the presence of bindings. Something which should have been done in RFC 2518, but nobody is perfect. The bind spec is a good place to do so. What is not a good idea is to throw the complete, current understanding of LOCK into the bind spec. This is not a failure of the spec, but was deliberatly chosen as the path of wisdom to follow. LOCK and locked resources in RFC 2518 are, as we know today, incompletely specified in RFC 2518 and have let to interoperability issues. Therefore all knowledge was agreed upon in the GULP and it was also agreed that GULP should find its way into RFC 2518bis, because that's where it should be. So, it is inaccurate and definitely not helping anyone with any implementation issue to request cleanup of LOCKs from the authors of the bind spec. I personally am waiting for 2 years now that RFC 2518bis makes progress comparable to other specs of this group. //Stefan
Received on Monday, 5 April 2004 17:10:57 UTC