Next message: Geoffrey M. Clemm: "Versioning TeleConf Agenda, 9/29/00 (Friday) 11-12 EST"
Date: Thu, 28 Sep 2000 23:35:53 -0400 (EDT)
Message-Id: <200009290335.XAA29589@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: proposal for OPTIONS
Boris's proposal with Ron's Depth response variation look fine to me.
Unless anyone has a better idea, I'll use this for the 09 (last call)
draft.
The only change that I'd make is that I believe we need to replace
"core-versioning" with "version-selector-checkout" and "version-checkout",
since those are two distinct alternatives.
Cheers,
Geoff
From: Ron Jacobs <rjacobs@gforce.com>
Date: Thu, 28 Sep 2000 11:51:57 -0700
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 ...