ietf
[Top] [All Lists]

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

2011-12-15 16:20:24


On 14/12/2011 18:27, Cyrus Daboo wrote:

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.
In the text above, we are only talking about a change of value, not about a specific value. Are there really a lot of cases where the non-content negotiated etag would not change while a content negotiated one would ? Unless that is a common scenario, I would not clobber the text with this additional statement. The opposite case (non content-negotiated changes while content negotiated does not) is even less problematic as it would just result in a false positive for clients using content negotiation.

Arnaud
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>