- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sat, 1 Mar 2003 09:27:29 -0500
- To: WebDAV <w3c-dist-auth@w3.org>
From: Brian Korver [mailto:briank@xythos.com] I like to bring up a couple of issues that I've found with the bind draft. I'll post more comprehensive comments on the draft in a subsequent email. Define "Resource" The term "resource" should be defined in the draft. I imagine the definition is something along the lines of "all content and all properties associated with that content (including live and dead properties), but which does not include properties associated with URIs." As indicated in section 1.1, the bind draft inherits all terminology from RFC2518, and therefore this section only includes definitions that refine or extend those from RFC2518 (which in turn inherits definitions from RFC2616). The bind draft does not modify the definition of resource inherited from RFC2518. Bindings and Locks The relationship between bindings and locks is missing from the draft. I think the behavior of locks and the lock methods should be fully specified in this draft. RFC2518bis is in the process of finalizing the behavior of locks, and we do not want the bind draft to say anything that conflicts with this. Instead, we will make sure that the locking model in RFC2518bis clearly defines locking behavior in the presence of multiple bindings. URL Properties The behavior of other URL properties (in addition to locks) should be fully specified, for instance the display-name property. I'm not aware of the binding protocol causing any change to the behavior of the properties defined by 2518. Also note that a resource has properties, not a URL. Move and Delete The spec states that move and delete are merely operations on bindings. At the very least, this is inconsistent with 2518, How is this inconsistent with 2518 (other than the use of terminology not defined in 2518)? but I also think that the draft doesn't adequately address any of the issues that come up when the server goes to "reclaim system resources." I would expect most servers to reclaim said resources during move and delete. The protocol explicitly leaves those decisions up to the server implementation, since different servers have made (and need to make) different choices wrt how system resources are reclaimed. For example, a versioning server will probably reclaim very few resources, since most of the resources are being maintained as history. Operations not Atomic None of the operations specified should be required to be atomic. I'd prefer SHOULD NOT myself. This is especially true for any operation that involves deleting collections. Atomic operations are one of the primary purposes of the binding protocol. A server that cannot maintain atomic MOVE/DELETE/BIND operations is not capable of supporting the bind protocol. Cheers, Geoff
Received on Saturday, 1 March 2003 09:28:01 UTC