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

Julian Reschke <julian.reschke@gmx.de> Tue, 13 December 2011 21:57 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21411E809D for <vcarddav@ietfa.amsl.com>; Tue, 13 Dec 2011 13:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.189
X-Spam-Level:
X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 9F7BisoxztLI for <vcarddav@ietfa.amsl.com>; Tue, 13 Dec 2011 13:57:42 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id AAE1611E809B for <vcarddav@ietf.org>; Tue, 13 Dec 2011 13:57:41 -0800 (PST)
Received: (qmail invoked by alias); 13 Dec 2011 21:51:01 -0000
Received: from p3EE279D1.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.121.209] by mail.gmx.net (mp031) with SMTP; 13 Dec 2011 22:51:01 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+GdKlTKMeGMCUiK/GQgQuTdBzHpne9fVIy21kdqt JRgQ2zrSvbSbwY
Message-ID: <4EE7C8BE.9030503@gmx.de>
Date: Tue, 13 Dec 2011 22:50:54 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Werner Donné <werner.donne@pincette.biz>
References: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com> <0296DA16-10E8-47A9-959D-2B9681BEAB36@pincette.biz> <4C0DEDC8.1090200@gmx.de>
In-Reply-To: <4C0DEDC8.1090200@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org, IETF Discussion <ietf@ietf.org>
Subject: [VCARDDAV] Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2011 21:57:42 -0000

On 2010-06-08 09:14, Julian Reschke wrote:
> On 07.06.2010 17:11, Werner Donné wrote:
>> Hi,
>>
>> I don't see why Depth:infinity should be ruled out from the start. You
>> can let the server decide if the performance penalty is too high or
>> not. A server with a relational system underneath it, for example, can
>> do this with one query.
>>
>> I don't agree with the "bubble up" principle. A collection changes
>> when its member set changes. Changing a resource that is referred to
>> by one of the members doesn't affect the collection, whether that
>> resource is a collection or not. I think the "bubble up" principal is
>> not consistent with the "getlastmodified" property. It is also not
>> needed if Depth:infinity is supported.
>>
>> Best regards,
>>
>> Werner.
>
> Agreed.
>
> In particular: defining a report works by defining it for Depth: 0. The
> semantics for Depth: 1 and Depth: infinity follow by the definition in
> RFC 3253.
>
> It's probably *really* time to pull the definition of REPORT out of RFC
> 3253 and place it into a separate spec, including more rationale,
> recommendations for defining new reports, and examples.
>
> Best regards, Julian

It seems to me that this issue was never addressed.

As defined right now, the way REPORT is used doesn't seem to be 
compatible with the definition of REPORT in RFC 3253, and the definition 
of the Depth: header field in RFC 4918.

Unless I'm missing something, this will be a problem for any 
implementation that tries to implement the sync report based on a 
generic WebDAV reporting framework.

Best regards, Julian