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

On 2011-12-14 18:27, Cyrus Daboo wrote:
> 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.

It states what it states :-)

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

No, you only need to package <multistatus> inside <prop> in case the 
response to the Depth: 0 request uses <multistatus>.

>>> 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?

I think so, because it defeats WebDAV stacks from executing reports 
consistently. (And, I assure you, I have written a framework in the past 
that did exactly that, otherwise I probably wouldn't have noticed the 
problem).

>>> 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.

Yes, a new child element of the request body (<depth>) works for me.

>>>> 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.

Yes, REPORT and PROPFIND should be consistent. Let's solve this puzzle 
another day.

Best regards, Julian

Received on Wednesday, 14 December 2011 17:50:17 UTC