Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard
Julian Reschke <[email protected]> Tue, 13 Dec 2011 22:50:54 +0100
| Newsgroups | gmane.ietf.caldav,gmane.ietf.webdav,gmane.ietf.vcarddav,gmane.ietf.general |
|---|---|
| Message-ID | <[email protected]> |
On 2010-06-08 09:14, Julian Reschke wrote: > On 07.06.2010 17:11, Werner Donn=E9 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