W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2011

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

From: Arnaud Quillaud <arnaud.quillaud@oracle.com>
Date: Thu, 15 Dec 2011 09:47:23 +0100
Message-ID: <4EE9B41B.2060206@oracle.com>
To: Cyrus Daboo <cyrus@daboo.name>
CC: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>

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

Received on Thursday, 15 December 2011 08:48:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:39 UTC