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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf