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

Arnaud Quillaud <arnaud.quillaud@oracle.com> Thu, 15 December 2011 08:49 UTC

Return-Path: <w3c-dist-auth-request@listhub.w3.org>
X-Original-To: ietfarch-webdav-archive@ietfa.amsl.com
Delivered-To: ietfarch-webdav-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0C121F85D1 for <ietfarch-webdav-archive@ietfa.amsl.com>; Thu, 15 Dec 2011 00:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.878
X-Spam-Level:
X-Spam-Status: No, score=-7.878 tagged_above=-999 required=5 tests=[AWL=2.122, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU3ZjI2iMWJm for <ietfarch-webdav-archive@ietfa.amsl.com>; Thu, 15 Dec 2011 00:49:38 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5F70C21F85C7 for <webdav-archive@lists.ietf.org>; Thu, 15 Dec 2011 00:49:38 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <w3c-dist-auth-request@listhub.w3.org>) id 1Rb6zA-0005rY-FR for w3c-dist-auth-dist@listhub.w3.org; Thu, 15 Dec 2011 08:48:16 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <arnaud.quillaud@oracle.com>) id 1Rb6z6-0005pN-7i for w3c-dist-auth@listhub.w3.org; Thu, 15 Dec 2011 08:48:12 +0000
Received: from acsinet15.oracle.com ([141.146.126.227]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <arnaud.quillaud@oracle.com>) id 1Rb6z2-00082g-Vb for w3c-dist-auth@w3.org; Thu, 15 Dec 2011 08:48:11 +0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBF8lTNg027823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Dec 2011 08:47:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBF8lRle018332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2011 08:47:27 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBF8lPx8008537; Thu, 15 Dec 2011 02:47:26 -0600
Received: from [192.168.1.100] (/89.157.166.32) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Dec 2011 00:47:25 -0800
Message-ID: <4EE9B41B.2060206@oracle.com>
Date: Thu, 15 Dec 2011 09:47:23 +0100
From: Arnaud Quillaud <arnaud.quillaud@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
CC: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>
References: <1F36B3D7066D9669ECFC947D@cyrus.local> <4EE8CEDC.9090105@gmx.de> <017C07CDCBE6162D356E84A5@cyrus.local>
In-Reply-To: <017C07CDCBE6162D356E84A5@cyrus.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4EE9B422.018B,ss=1,re=0.000,fgs=0
Received-SPF: none client-ip=141.146.126.227; envelope-from=arnaud.quillaud@oracle.com; helo=acsinet15.oracle.com
X-W3C-Hub-Spam-Status: No, score=-4.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-2.31
X-W3C-Scan-Sig: maggie.w3.org 1Rb6z2-00082g-Vb e4489ad0b9bbe54bcab7dfcdb18c7287
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard
Archived-At: <http://www.w3.org/mid/4EE9B41B.2060206@oracle.com>
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/13370
X-Loop: w3c-dist-auth@w3.org
Resent-Sender: w3c-dist-auth-request@w3.org
Precedence: list
List-Id: <w3c-dist-auth.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:w3c-dist-auth@w3.org>
List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1Rb6zA-0005rY-FR@frink.w3.org>
Resent-Date: Thu, 15 Dec 2011 08:48:16 +0000

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