Subject: RFC 3744: principal-collection-set

From: Werner Donné <[email-masked]>
Date: Thu, 26 Apr 2007 14:59:29 +0200

Hi,

The property-collection-set can be obtained through a PROPFIND
on a resource. Why isn't the OPTIONS method used for this? It
is the case for activity-collection-set, version-history-collection-set
and workspace-collection-set, which are defined in RFC 3253?

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Apr 2007 15:11:18 +0200

> and workspace-collection-set, which are defined in RFC 3253?

The working group decided that abusing OPTIONS for this is the wrong 
thing to do, and all information should be made properties instead (this 
  will save one round trip if you need both these and other properties).

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

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Apr 2007 08:57:02 +0200

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

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 27 Apr 2007 09:40:56 -0400

Hi Julian,

--On April 27, 2007 8:57:02 AM +0200 Julian Reschke <[email-masked]> 
wrote:

> <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 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 :-)

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.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Apr 2007 15:52:18 +0200

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On April 27, 2007 8:57:02 AM +0200 Julian Reschke 
> <[email-masked]> wrote:
> 
> 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.

> 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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 27 Apr 2007 10:02:53 -0400

Hi Julian,

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

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Apr 2007 16:16:40 +0200

Cyrus Daboo wrote:
> 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

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 27 Apr 2007 09:57:40 -0700

I think that's a very important feature.  There's no intrinsic need  
for SEARCH to rely on properties, and it should be valuable for a  
number of non-WebDAV use cases.

Duplicating the server's feature advertisement in both OPTIONS and  
properties should not be much of a hardship for a server and makes it  
easier for a variety of clients to learn what they need to know.

Lisa

On Apr 27, 2007, at 7:16 AM, Julian Reschke wrote:

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Apr 2007 23:21:58 +0200

Lisa Dusseault wrote:
> I think that's a very important feature.  There's no intrinsic need for 
> SEARCH to rely on properties, and it should be valuable for a number of 
> non-WebDAV use cases.

True, but note that the DAV:multistatus format is mandated anyway (and I 
think MS Exchange is doing that for it's "sql" grammar).

> ...

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 28 Apr 2007 15:10:50 -0700

Yes, and I think that's OK for non-WebDAV clients.  A client has to  
get its search results in some machine-readable form.  (If the client  
were looking for human readable results there'd likely be a WebUI and  
no standards involved).  So XML is adequate for that purpose, and why  
not "DAV:" and "multistatus".  At least it's a schema we have some  
experience with.

Lisa

On Apr 27, 2007, at 2:21 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> I think that's a very important feature.  There's no intrinsic  
>> need for SEARCH to rely on properties, and it should be valuable  
>> for a number of non-WebDAV use cases.
>
> True, but note that the DAV:multistatus format is mandated anyway  
> (and I think MS Exchange is doing that for it's "sql" grammar).
>
>> ...
>
> Best regards, Julian