- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Mon, 5 Feb 2001 10:21:37 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Greg Stein <gstein@lyra.org> On Sun, Feb 04, 2001 at 08:05:06PM -0500, Geoffrey M. Clemm wrote: >... > Now this is a good argument for turning the DAV:supported-method-set > back into a property! Which is what James Hunt has just asked us > to do. I asked him "why". I think this is a pretty good answer. > So I'd propose that we switch them back, based on this point that > Lisa has made. That doesn't make sense. You're always going to have a tension between OPTIONS for capability discovery and PROPFIND/Depth: for discovery over a set of resources. supported-xxx was moved to OPTIONS because that is where discovery normally occurs. Yes, there always is such a tension, but I think it is reasonable to make the cut at "information about just that resource" and "information about the server that implements that resource". With this criterion, it is reasonable to marshal "supported-xxx" (which is about the particular resource) as a property, as opposed to the "xxx-collection-set" information (which is about the server), which should continue to be marshalled as an OPTIONS response. By your logic, we should move the DAV: header into properties. No, because that is about the server, not just about the particular resource. The right answer is to modify OPTIONS to allow a Depth: header value. We could do that, but then to make sure that your PROPFIND and OPTIONS requests are not out of synch, you'd have to Depth lock the resource tree (and it would be nice to not have to Depth lock the tree just to query information about it). In addition, a Depth header on "server based information" is almost always redundant, since most of the resources will return exactly the same value. Cheers, Geoff
Received on Monday, 5 February 2001 10:22:35 UTC