Re: RFC 3744: principal-collection-set

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On April 27, 2007 8:57:02 AM +0200 Julian Reschke 
> <[email protected]> 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
>> "5.5_USE_PROPERTIES".
> 
> 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 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-12.html#PROPERTY_supported-query-grammar-set>).

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