- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sun, 4 Feb 2001 15:55:12 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "James J. Hunt" <jjh@allerton.de> Several extension define a root set for their resources. In the current version, these are obtained via the options request, however this is not the intent of options. Options should be just tags that identify what capabilities a server offers. Where in RFC 2616 does it limit the response from an OPTIONS request to be "tags"? HTTP defines a special request URI---"*"---for making request of a server instead of a particular resource. The problem with this approach is that different servers can manage different parts of the URL space at a given server, while '*" will always refer to just one of these servers (probably the one that manages "/"). So you need to tell the server what part of the URL space you're interested in. By defining the following resources as properties of a server, propfind could be used to query their values: DAV:versionable-resource-collection-set DAV:version-history-collection-set DAV:workspace-collection-set DAV:activity-collection-set For servers that do not allow new message to reference "*", then any resource collection directly or indirectly contained in any of the above variables should respond to the request. I beleive there was some object based on this kind of restriction. This solution does not have any disadvantage that OPTIONS does not also have. It really doesn't matter whether we marshall this as an OPTIONS call or as a PROPFIND for a property. This used to be marshalled as a property but a reviewer pointed out that this information seemed more like an option than a property. Can you give some motivation for switching this back to being a property? Cheers, Geoff
Received on Sunday, 4 February 2001 15:56:10 UTC