depth in draft-daboo-webdav-sync-01

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

depth in draft-daboo-webdav-sync-01

Arnaud Quillaud
Hello,

In Section 4.2
(http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.2), the
response is defined as:

<<

The response body for a successful DAV:sync-collection REPORT
      request MUST contain a DAV:sync-response element for each resource
      that was created, has changed or been deleted since the last
      synchronization operation as specified by the DAV:sync-token
      provided in the request.

 >>

Given that the depth header should be ignored, and given the ambiguity
of the term "resource", it would be worth mentioning that this applies
only to non-collection resources directly contained in the target
collection.
In other words, creation/modification/deletion of subcollections and
their children should not be included.

Arnaud

Reply | Threaded
Open this post in threaded view
|

Re: depth in draft-daboo-webdav-sync-01

Julian Reschke
Arnaud Quillaud wrote:

> Hello,
>
> In Section 4.2
> (http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.2), the
> response is defined as:
>
> <<
>
> The response body for a successful DAV:sync-collection REPORT
>      request MUST contain a DAV:sync-response element for each resource
>      that was created, has changed or been deleted since the last
>      synchronization operation as specified by the DAV:sync-token
>      provided in the request.
>
>  >>
>
> Given that the depth header should be ignored, and given the ambiguity
> of the term "resource", it would be worth mentioning that this applies
> only to non-collection resources directly contained in the target
> collection.
> In other words, creation/modification/deletion of subcollections and
> their children should not be included.

I was going to write something related about carddav (still reading it...).

A definition of a WebDAV report absolutely MUST specify the scope of the
request. So, for Depth:0, it needs to specify whether it affects only
the resource at the Request-URI, or more. The semantics for Depth:1 or
Depth:infinity then follow from that.

Specifying that the Depth header should be ignored or should be left out
is in conflict with how reports work in general and thus makes it
impossible to share code between various different reports.

BR, Julian