W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2007

Re: RFC 3744: principal-collection-set

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 27 Apr 2007 15:52:18 +0200
Message-ID: <46320012.80202@gmx.de>
To: Cyrus Daboo <cyrus@daboo.name>
CC: w3c-dist-auth@w3.org

Cyrus Daboo wrote:
> Hi Julian,
> --On April 27, 2007 8:57:02 AM +0200 Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>>> The RCF3253 issues list should have a related entry, pointing out that
>>> rfc3253bis should make these live properties as well. Unfortunately,
>>> www.webdav.org is down right now (again).
>> See
>> <http://lists.w3.org/Archives/Public/ietf-dav-versioning/2002JulSep/0003.
>> html> and
>> <http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm>, Item
> This does beg the question about when it is appropriate to use OPTIONS 
> vs properties. Obviously you need to at least have a DAV header in 
> OPTIONS so a client knows it is dealing with a DAV server, but beyond 

Not really. The "Allow" response header should be sufficient.

> that, why have anything in OPTIONS when they could be a property? For 
> example, why do we need the DASL header in OPTIONS in WebDAV SEARCH? Why 
> can't that be a property? Sorry Julian, I had to bring that one up :-)

I totally agree, and thus SEARCH has also the 
DAV:supported-query-grammar-set property 

I tried to get rid of the DASL header a long time ago, but was told to 
keep it for backwards compatibility with the old expired DASL spec.

> There has also been some debate in the CalDAV arena about a more general 
> server "capabilities" option. Basically some why (via a property) for a 
> server to be very specific about what it supports - in particular for 
> any SHOULD or MAY features in a spec.

It would also make sense to expose the DAV header as property; we did 
that in the SAP stack as a vendor-specific extension in order to avoid 
unnecessary OPTIONS round trips...

Best regards, Julian
Received on Friday, 27 April 2007 13:53:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC