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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Julian,

--On December 14, 2011 5:29:16 PM +0100 Julian Reschke <julian.reschke@xxxxxx> 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

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]