IETF Logo Mail Archive

Re: [VCARDDAV] WebDAv collection sync: last issue

Julian Reschke <julian.reschke@gmx.de> Tue, 08 June 2010 07:14 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5313A69AA for <vcarddav@core3.amsl.com>; Tue, 8 Jun 2010 00:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.394
X-Spam-Level:
X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=-3.695, BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z12NsUbgWM27 for <vcarddav@core3.amsl.com>; Tue, 8 Jun 2010 00:14:24 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EB2563A6991 for <vcarddav@ietf.org>; Tue, 8 Jun 2010 00:14:22 -0700 (PDT)
Received: (qmail invoked by alias); 08 Jun 2010 07:14:22 -0000
Received: from p508FDFE6.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.223.230] by mail.gmx.net (mp041) with SMTP; 08 Jun 2010 09:14:22 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18W8Xs7hZIWxYrG+8QmIKtXa4KaEtNgsuvsjZX8lT EA5vhy5+4SsvOy
Message-ID: <4C0DEDC8.1090200@gmx.de>
Date: Tue, 08 Jun 2010 09:14:16 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Werner Donné <werner.donne@pincette.biz>
References: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com> <0296DA16-10E8-47A9-959D-2B9681BEAB36@pincette.biz>
In-Reply-To: <0296DA16-10E8-47A9-959D-2B9681BEAB36@pincette.biz>
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
Subject: Re: [VCARDDAV] WebDAv collection sync: last issue
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Jun 2010 07:14:25 -0000

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

v2.23.0 | Report a Bug | By Email