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

Re: Option abuse

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sun, 4 Feb 2001 15:55:12 -0500 (EST)
Message-Id: <200102042055.PAA19569@tantalum.atria.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT