Re: [caldav] WebDAv collection sync: last issue

"Tim Hare" <TimHare@comcast.net> Tue, 08 June 2010 00:47 UTC

Return-Path: <timhare@comcast.net>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048393A6843 for <caldav@core3.amsl.com>; Mon, 7 Jun 2010 17:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 d7wwjflO5QKX for <caldav@core3.amsl.com>; Mon, 7 Jun 2010 17:47:56 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id D1CA23A6879 for <caldav@ietf.org>; Mon, 7 Jun 2010 17:47:52 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id T82o1e0011swQuc55Cnuge; Tue, 08 Jun 2010 00:47:54 +0000
Received: from THARE ([71.203.98.77]) by omta15.westchester.pa.mail.comcast.net with comcast id TCnt1e00R1gAkVz3bCnuTi; Tue, 08 Jun 2010 00:47:54 +0000
From: "Tim Hare" <TimHare@comcast.net>
To: "'Cyrus Daboo'" <cyrus@daboo.name>, <w3c-dist-auth@w3.org>
References: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com>
In-Reply-To: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com>
Date: Mon, 7 Jun 2010 20:47:49 -0400
Message-ID: <001f01cb06a4$38a483a0$a9ed8ae0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcsGVLQsWQQQKu0YRgSm0kkPCv6/AQAT1CZQ
Content-Language: en-us
Cc: caldav@ietf.org, vcarddav@ietf.org
Subject: Re: [caldav] WebDAv collection sync: last issue
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2010 00:47:57 -0000

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 ?

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).

-- 
Cyrus Daboo

_______________________________________________
caldav mailing list
caldav@ietf.org
https://www.ietf.org/mailman/listinfo/caldav