Re: [VCARDDAV] [caldav] WebDAv collection sync: last issue

Andrew McMillan <> Tue, 08 June 2010 04:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A19803A6925; Mon, 7 Jun 2010 21:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2B6sATi+W7ro; Mon, 7 Jun 2010 21:14:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FED43A6888; Mon, 7 Jun 2010 21:14:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 063F22374D; Tue, 8 Jun 2010 16:14:10 +1200 (NZST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id xuN2dWpa9Y-q; Tue, 8 Jun 2010 16:13:54 +1200 (NZST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id DD8EA23757; Tue, 8 Jun 2010 16:13:53 +1200 (NZST)
From: Andrew McMillan <>
To: Tim Hare <>
In-Reply-To: <001f01cb06a4$38a483a0$a9ed8ae0$@net> (sfid-20100608_124828_094303_CD91AB6B)
References: <> <001f01cb06a4$38a483a0$a9ed8ae0$@net> (sfid-20100608_124828_094303_CD91AB6B)
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ejaWjkx6i6kFmrtII6i/"
Date: Tue, 08 Jun 2010 16:13:52 +1200
Message-ID: <>
Mime-Version: 1.0
X-Mailer: Evolution
Subject: Re: [VCARDDAV] [caldav] WebDAv collection sync: last issue
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jun 2010 04:14:25 -0000

On Mon, 2010-06-07 at 20:47 -0400, Tim Hare wrote:
> I am not an implementor, but it seems to me that many Calendar/addressbook
> collections might be depth:2 to accomodate groups like mailing lists ?

Hi Tim,

Yes, that could be one way of implementing such things, though the
specifications for CalDAV explicitly state that calendar collections may
not contain collections.

In DAViCal I did implement multiple-calendars-as-one-calendar by
allowing collections of calendars (or more typically bindings to
calendars) to present as if they were a calendar.  In order to avoid
stepping on the specification I gave these collections a special

FWIW DAViCal's implementation of WebDAV sync is OK with depth infinity,
since (as the other poster points out) it makes little difference for
query based systems.

					Andrew McMillan.

> Tim Hare
> Interested Bystander, Non-Inc.
> -----Original Message-----
> From: [] On Behalf Of
> Cyrus Daboo
> Sent: Monday, June 07, 2010 9:57 AM
> To:
> Cc:;
> Subject: [caldav] WebDAv collection sync: last issue
> Hi folks,
> The latest WebDAV collection sync draft is here: 
> <>. We believe we 
> are close to done with this and would like to submit to the IESG soon. 
> However, there is one open issue that we need feedback from implementors on.
> The question is whether collection resources that are immediate children of 
> the collection being targeted for the REPORT should be reported as 
> "modified" if any of their child resources (depth infinity) are modified.
> Key points:
> 1) We have deliberately scoped the REPORT defined in this draft to be 
> Depth:1 only - i.e. it will only report changes to immediate children. 
> Depth:infinity change reporting was ruled out at this time (though 
> eventually we would expect to see it defined if there is interest).
> 2) The first real implementations of this REPORT are being done for CalDAV 
> and CardDAV servers where typically calendar/addressbook collections only 
> have immediate child resources and not collections - so the draft as 
> currently written is fine. (BTW there are already several client and server 
> implementations of this draft that have been tested at various interops). 
> However, my concern is that more "general" WebDAV servers may wish to do 
> reporting of changes to immediate child collections to allow clients to 
> progressively sync an entire hierarchy.
> 3) Reporting changes to immediate child collections requires any change at 
> depth:infinity within those collections to "bubble up" - i.e. a change with 
> a collection changes its DAV:sync-token and the properties of all its 
> parent collections. This potentially places a big performance burden on the 
> server - particularly if it were to choose to support the REPORT on the 
> root resource. In reality servers would probably limit the scope of the 
> report to a reasonable "sub-hierarchy" set (e.g. CalDAV and CardDAV servers 
> would only support the REPORT on calendar or address book home collections 
> and not on any parents of those).

andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
               Chicken Little only has to be right once.