Re: RFC 3744: principal-collection-set

Cyrus Daboo wrote:
>>> 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#PR
>> OPERTY_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.
> 
> Why not state the intention to deprecate it in a future version and say 
> servers MUST support it (for now), but clients SHOULD NOT rely on it. 
> That way clients can migrate to using the property and eventually we can 
> get rid of the header. Maybe the draft already says that and I missed it...

No, it doesn't say that.

Thinking of it, another reason for the "legacy" design may be that DASL 
intended to make it possible that a search arbiter resource (something 
responding to SEARCH) doesn't need to be a WebDAV resource (responding 
to PROPFIND). I'm not entirely sure that we should eliminate that feature...

Best regards, Julian