- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 13 Dec 2011 22:50:54 +0100
- To: Werner Donné <werner.donne@pincette.biz>
- CC: Cyrus Daboo <cyrus@daboo.name>, caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org, IETF Discussion <ietf@ietf.org>
On 2010-06-08 09:14, Julian Reschke wrote: > On 07.06.2010 17:11, Werner Donné wrote: >> Hi, >> >> I don't see why Depth:infinity should be ruled out from the start. You >> can let the server decide if the performance penalty is too high or >> not. A server with a relational system underneath it, for example, can >> do this with one query. >> >> I don't agree with the "bubble up" principle. A collection changes >> when its member set changes. Changing a resource that is referred to >> by one of the members doesn't affect the collection, whether that >> resource is a collection or not. I think the "bubble up" principal is >> not consistent with the "getlastmodified" property. It is also not >> needed if Depth:infinity is supported. >> >> Best regards, >> >> Werner. > > Agreed. > > In particular: defining a report works by defining it for Depth: 0. The > semantics for Depth: 1 and Depth: infinity follow by the definition in > RFC 3253. > > It's probably *really* time to pull the definition of REPORT out of RFC > 3253 and place it into a separate spec, including more rationale, > recommendations for defining new reports, and examples. > > Best regards, Julian It seems to me that this issue was never addressed. As defined right now, the way REPORT is used doesn't seem to be compatible with the definition of REPORT in RFC 3253, and the definition of the Depth: header field in RFC 4918. Unless I'm missing something, this will be a problem for any implementation that tries to implement the sync report based on a generic WebDAV reporting framework. Best regards, Julian
Received on Tuesday, 13 December 2011 21:51:39 UTC