RE: proposal for OPTIONS

From: Ron Jacobs (rjacobs@gforce.com)
Date: Thu, Sep 28 2000

  • Next message: Clemm, Geoff: "RE: predecessor-set"

    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 ...