Message-ID: <CC2AF3B5727BD411907F00A0CC63594C0F0976@exchange.gforcesystems.com> From: Ron Jacobs <rjacobs@gforce.com> To: "'Boris Bokowski/OTT/OTI'" <Boris_Bokowski@oti.com> Cc: ietf-dav-versioning@w3.org Date: Thu, 28 Sep 2000 11:51:57 -0700 Subject: RE: proposal for OPTIONS Boris, An excellent proposal. Might I suggest a slight improvement? The OPTIONS response could reuse the Depth: header to indicate whether the response is valid for all members of a resource collection. The default would be Depth:0 in order to remain compatible with existing servers. If the server wishes to indicate that it's response is valid for the whole sub tree then it can do so by including Depth:infinity in the response. As a further improvement, the OPTIONS request could be spec'ed to contain a Depth: header. I must say, I'm not as fond of this idea because the server should be in control of how much work it has to do to respond to OPTIONS and the client can always send additional requests if the server did not provide sufficient response. (i.e., if it did not respond with the Depth:infinity header) Backward compatibility is important here as the advanced versioning server may be responding to a non-versioning WebDAV client, or even, for that matter, to an HTTP 1.1 client. BTW, whatever happened to specifying an asterisk URL (e.g., OPTIONS * HTTP/1.1) to request capabilities of a server? Thanks, Ron -----Original Message----- From: Boris Bokowski/OTT/OTI [mailto:Boris_Bokowski@oti.com] Sent: Thursday, September 28, 2000 10:58 AM To: ietf-dav-versioning@w3.org Subject: proposal for OPTIONS Here is a proposal for spec'ing the OPTIONS request. First of all, to attack the problem that OPTIONS, although applied to a resource, should report capabilities of a server: "The DAV response header for an OPTIONS request applies to a resource and all its members. If a DAV response header contains one or more of 'core-versioning', 'workspace', 'versioned-collection', 'baselined-collection', 'activity', 'merge', the DAV response header for its members MUST at least contain these as well." Spec'd this way, it is sufficient to query the root of a resource subtree in order to discover the versioning capabilities for all resources in the subtree. ... rest omitted ...