On 2011-12-14 18:27, Cyrus Daboo wrote:
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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf