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:47 UTC

Return-Path: <arnaud.quillaud@oracle.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DA521F850E for <ietf@ietfa.amsl.com>; Thu, 15 Dec 2011 00:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
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 25KRq58spWRV for <ietf@ietfa.amsl.com>; Thu, 15 Dec 2011 00:47:42 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 281C021F8510 for <ietf@ietf.org>; Thu, 15 Dec 2011 00:47:42 -0800 (PST)
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>
Subject: Re: Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard
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
X-Mailman-Approved-At: Thu, 15 Dec 2011 14:18:40 -0800
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2011 08:49:12 -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