Re: Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard

Hi Julian,

--On December 14, 2011 5:29:16 PM +0100 Julian Reschke 
<julian.reschke@gmx.de> wrote:

>> I am not convinced the use of Depth in sync report is violating the
>> definition in 3253. In some ways it is a matter of how you look at the
>
> It does.
>
> RFC 3253 defines the response format for Depth 0, and then states how the
> format for Depth > 0 is derived from that; essentially by packaging into
> <multistatus>.
>
> This means that reports that do not support Depth 0 can not be defined.
>
> It also means that a report that uses <multistatus> for Depth 0, and
> which supports depths > 0, will have to packages <multistatus> inside
> <multistatus>.

Well I don't consider the text there very clear at all. In fact I think it 
is very much tailored to the 3253 use cases and not flexible enough for 
other general purpose use of REPORT. It states this:

      The DAV:prop element of a DAV:response
      for a given resource MUST contain the requested report for that
      resource.

Which implies "packaging" of multistatus within the DAV:prop element, which 
seems completely wrong to me.

>> sync. Your viewpoint is that the report asks the collection for its
>> changes - in that case, yes, Depth:0 would apply. The other view is that
>> the report asks each of the child resources to list their change status,
>> in which case Depth:1 and Depth:infinity also makes sense. Which
>> viewpoint is taken probably depends on actual implementation rather than
>> any perceived protocol restrictions.
>
> What Depth 0 means is just a matter of definition. If you want to make
> Depth 0 mean "request-URI and all of it's direct members", that's fine.
> It just will give funny results when you use it with other Depths *and*
> follow the RFC 3253 definition in these cases.

So would it hurt to allow this spec to override the 3253 "nested 
multistatus" requirement in the interests of generating a compact response 
specific to this type of report?

>> Given that I feel the sync report is vital for WebDAV operations, for in
>> particular CalDAV and CardDAV, I want to ensure this draft proceeds as a
>> standard, not informational. If you feel strongly about this use of
>> Depth, in spite of my comments above, then I would be willing to make
>> some changes, provided we also include a statement on backwards
>> compatibility (i.e., in an appendix state that clients/servers MAY
>> use/accept the old Depth approach). If we do that we would need to
>> proceed as follows: state that sync report can only be used with
>> Depth:0, add a new request header to define the scope of the sync (e.g.
>> Sync-Depth with values 1 and infinite). If we require Sync-Depth to be
>> present, then we have a means for servers to detect old clients and
>> handle Depth in a backwards compatible manner.
>
> Not happy having to add a new header field just for that. A simpler
> approach might be to just assign a different report name, and then allow
> all depths.

I think if you insist on requiring Depth => nested multistatus, then we 
either add a new header or perhaps a <depth> element inside the request 
body (and that would also be reasonable in terms of being able to support 
backwards compatibility). At this point I would prefer the later as being 
least disruptive to existing implementations.

>>> In the case where a mapping between a member URI and the target
>>> collection was removed, then a new mapping with the same URI created,
>>> the member URI MUST be reported as changed and MUST NOT be reported
>>> as removed.
>>>
>>> The client could tell that this happened if the DAV:resourceid property
>>> was included.
>>>
>>> A member URI MUST be reported as changed if its mapped resource's
>>> entity tag value (defined in Section 3.11 of [RFC2616]) has changed
>>> since the request sync-token was generated.
>>>
>>> It should be mentioned that this only works well with resources that are
>>> not content-negotiated.
>>
>> Unless the content negotiation was done as part of the original full
>> sync request?
>
> How would that work?
>
> For instance, the common case for Conneg is using Accept:, but Accept: on
> REPORT specifies the expected media type for the REPORT response.
>
> Yes, that's a problem with WebDAV in general.

OK, so we should probably punt on per-resource content-negotiation within 
the report itself (though I could see us wanting to support that in the 
future, in which case it would probably be done through extensions elements 
in the request body).

So what do we need to do to address this? State that the etags returned in 
the report are always for the non-content-negotiated representation of each 
child resource? I think that is already implied by the definition of 
DAV:getetag, so perhaps we should state that we are referring to that 
value, which is the non-content negotiated entity tag.

-- 
Cyrus Daboo

Received on Wednesday, 14 December 2011 17:28:25 UTC