W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: OPTIONS and Depth (was: Re: Core versioning issues and nits)

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 5 Feb 2001 10:21:37 -0500 (EST)
Message-Id: <200102051521.KAA20876@tantalum.atria.com>
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

   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.

Received on Monday, 5 February 2001 10:22:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC