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