W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2010

Re: [caldav] WebDAv collection sync: last issue

From: Andrew McMillan <andrew@morphoss.com>
Date: Tue, 08 Jun 2010 16:13:52 +1200
To: Tim Hare <TimHare@comcast.net>
Cc: 'Cyrus Daboo' <cyrus@daboo.name>, w3c-dist-auth@w3.org, caldav@ietf.org, vcarddav@ietf.org
Message-ID: <1275970432.3820.9378.camel@happy.home.mcmillan.net.nz>
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: caldav-bounces@ietf.org [mailto:caldav-bounces@ietf.org] On Behalf Of
> Cyrus Daboo
> Sent: Monday, June 07, 2010 9:57 AM
> To: w3c-dist-auth@w3.org
> Cc: caldav@ietf.org; vcarddav@ietf.org
> Subject: [caldav] WebDAv collection sync: last issue
> Hi folks,
> The latest WebDAV collection sync draft is here: 
> <https://datatracker.ietf.org/doc/draft-daboo-webdav-sync/>. 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.

Received on Tuesday, 8 June 2010 04:14:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:38 UTC