Hi Julian,
--On December 14, 2011 5:29:16 PM +0100 Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf