From helge.hess@opengroupware.org Sun Dec 6 13:34:54 2009 Return-Path: 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 9D8003A69AB; Sun, 6 Dec 2009 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] 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 MUstik11Hj7v; Sun, 6 Dec 2009 13:34:54 -0800 (PST) Received: from mailhub.opengroupware.org (mailhub.opengroupware.org [213.211.192.144]) by core3.amsl.com (Postfix) with ESMTP id C7E8C3A697C; Sun, 6 Dec 2009 13:34:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTP id E67A1228245; Sun, 6 Dec 2009 22:34:41 +0100 (CET) X-Virus-Scanned: amavisd-new at opengroupware.org Received: from mailhub.opengroupware.org ([127.0.0.1]) by localhost (mailhub.opengroupware.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul5XJGofB+Go; Sun, 6 Dec 2009 22:34:34 +0100 (CET) Received: from [192.168.0.111] (91-65-6-214-dynip.superkabel.de [91.65.6.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTPSA id 3CA23228242; Sun, 6 Dec 2009 22:34:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Helge Hess In-Reply-To: <4B057E6B.7040808@sun.com> Date: Sun, 6 Dec 2009 22:34:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B057E6B.7040808@sun.com> To: Arnaud Quillaud X-Mailer: Apple Mail (2.1077) Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 21:34:54 -0000 Hi, Arnaud asked me on my opinion on the following ... On 19.11.2009, at 18:20, Arnaud Quillaud wrote: > I have just submitted a new version of the webdav sync draft = (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ). =3D> > 2. Do clients really need to be notified that a resource was = created > versus modified ? They should be able to figure that out by > looking at the state of their current cache. If this = information > is not necessary, the response would not need to contain a DAV: > status along with the DAV:propstat. This would allow the use = of > a regular multistatus (simply extended with a sync-token > element). Its not crucial, but helpful. If I don't know that a resource is new, I = obviously have to scan the cache to check for that. Which is = significantly more expensive than a simple INSERT (status =3D 'N', = url=3Dabc) ... Given that WebDAV sync is supposed to improve sync with large folders, = the 'check' time consumption becomes more relevant too ... The question is whether I would do the scan anyways, just to be sure = there are no DUPs. Probably! :-) [either me, or a database unique = constraint doing effectively the same thing] So I guess either way is fine with me with a slight preference towards = having a separate 'created'. If that would be significantly more = difficult for servers, lets drop it, if not, lets preserve it. Greets, Helge From helge.hess@opengroupware.org Sun Dec 6 13:51:47 2009 Return-Path: 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 638EE3A6896; Sun, 6 Dec 2009 13:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] 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 TVRwgRjwoZsF; Sun, 6 Dec 2009 13:51:46 -0800 (PST) Received: from mail383c25.carrierzone.com (mail383c25.carrierzone.com [209.235.146.153]) by core3.amsl.com (Postfix) with ESMTP id 8CA343A67F1; Sun, 6 Dec 2009 13:51:46 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail383c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB6LpXnD016409; Sun, 6 Dec 2009 21:51:35 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Sun, 6 Dec 2009 16:45:30 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG12062009-164524-12168.MMD@TencoAssembliesInc.local; Sun, 6 Dec 2009 16:45:24 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB6LaVpb021484 for ; Sun, 6 Dec 2009 16:36:33 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NHOl6-0000q5-L1 for w3c-dist-auth-dist@listhub.w3.org; Sun, 06 Dec 2009 21:35:12 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHOl4-0000pM-Ut for w3c-dist-auth@listhub.w3.org; Sun, 06 Dec 2009 21:35:11 +0000 Received: from mailhub.opengroupware.org ([213.211.192.144]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHOl2-0004kI-US for w3c-dist-auth@w3.org; Sun, 06 Dec 2009 21:35:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTP id E67A1228245; Sun, 6 Dec 2009 22:34:41 +0100 (CET) X-Virus-Scanned: amavisd-new at opengroupware.org Received: from mailhub.opengroupware.org ([127.0.0.1]) by localhost (mailhub.opengroupware.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul5XJGofB+Go; Sun, 6 Dec 2009 22:34:34 +0100 (CET) Received: from [192.168.0.111] (91-65-6-214-dynip.superkabel.de [91.65.6.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTPSA id 3CA23228242; Sun, 6 Dec 2009 22:34:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Helge Hess In-Reply-To: <4B057E6B.7040808@sun.com> Date: Sun, 6 Dec 2009 22:34:33 +0100 Message-Id: References: <4B057E6B.7040808@sun.com> To: Arnaud Quillaud X-Mailer: Apple Mail (2.1077) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1NHOl2-0004kI-US cc99dba5162c748a716c7ff03520b416 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13219 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Sun, 06 Dec 2009 21:35:12 +0000 X-MMR: 0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail362c25.carrierzone.com id nB6LaVpb021484 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 06 Dec 2009 21:45:30.0648 (UTC) FILETIME=[6E64D980:01CA76BD] Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 21:51:47 -0000 Hi, Arnaud asked me on my opinion on the following ... On 19.11.2009, at 18:20, Arnaud Quillaud wrote: > I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ). => > 2. Do clients really need to be notified that a resource was created > versus modified ? They should be able to figure that out by > looking at the state of their current cache. If this information > is not necessary, the response would not need to contain a DAV: > status along with the DAV:propstat. This would allow the use of > a regular multistatus (simply extended with a sync-token > element). Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ... Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ... The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing] So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it. Greets, Helge From Arnaud.Quillaud@Sun.COM Mon Dec 7 06:58:49 2009 Return-Path: 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 BC9123A6806; Mon, 7 Dec 2009 06:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] 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 EFVJHaQfyt-z; Mon, 7 Dec 2009 06:58:48 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 90DE03A67FB; Mon, 7 Dec 2009 06:58:48 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7EwaR7013792; Mon, 7 Dec 2009 14:58:36 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rUL4U2HZ1yHgNIdCVZietw)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00300CXB5T00@fe-emea-09.sun.com>; Mon, 07 Dec 2009 14:58:29 +0000 (GMT) Received: from arnaud-quillauds-mac-mini.local ([unknown] [129.150.117.219]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA00GVBEX7XA70@fe-emea-09.sun.com>; Mon, 07 Dec 2009 14:58:20 +0000 (GMT) Date: Mon, 07 Dec 2009 15:58:18 +0100 From: Arnaud Quillaud In-reply-to: Sender: Arnaud.Quillaud@Sun.COM To: Helge Hess Message-id: <4B1D180A.2050103@sun.com> References: <4B057E6B.7040808@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:58:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rUL4U2HZ1yHgNIdCVZietw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 6/12/09 22:34, Helge Hess wrote: > Hi, > > Arnaud asked me on my opinion on the following ... > > On 19.11.2009, at 18:20, Arnaud Quillaud wrote: > >> I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ). >> > > => > >> 2. Do clients really need to be notified that a resource was created >> versus modified ? They should be able to figure that out by >> looking at the state of their current cache. If this information >> is not necessary, the response would not need to contain a DAV: >> status along with the DAV:propstat. This would allow the use of >> a regular multistatus (simply extended with a sync-token >> element). >> > > Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ... > Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ... > > The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing] > Maximilian Odendahl who is working on the Symbian CalDAV connector gave us the same feedback. And it looks like the Inverse Edition of Mozilla Lightning is doing the same thing (i.e. scan regardless of the status sent by the server). Arnaud > So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it. > > Greets, > Helge > > > > _______________________________________________ > caldav mailing list > caldav@ietf.org > https://www.ietf.org/mailman/listinfo/caldav > --Boundary_(ID_rUL4U2HZ1yHgNIdCVZietw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 6/12/09 22:34, Helge Hess wrote: 
Hi,

Arnaud asked me on my opinion on the following ...

On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
  
I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).
    

=>
  
   2.  Do clients really need to be notified that a resource was created
       versus modified ?  They should be able to figure that out by
       looking at the state of their current cache.  If this information
       is not necessary, the response would not need to contain a DAV:
       status along with the DAV:propstat.  This would allow the use of
       a regular multistatus (simply extended with a sync-token
       element).
    

Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ...
Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ...

The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing]
Maximilian Odendahl who is working on the Symbian CalDAV connector gave us the same feedback.
And it looks like the Inverse Edition of Mozilla Lightning is doing the same thing (i.e. scan regardless of the status sent by the server).

Arnaud
So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.

Greets,
  Helge



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

--Boundary_(ID_rUL4U2HZ1yHgNIdCVZietw)-- From Arnaud.Quillaud@Sun.COM Mon Dec 7 07:08:22 2009 Return-Path: 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 1C32E3A6A5A; Mon, 7 Dec 2009 07:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.682 X-Spam-Level: X-Spam-Status: No, score=-7.682 tagged_above=-999 required=5 tests=[AWL=2.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] 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 lugpuVdSTnJr; Mon, 7 Dec 2009 07:08:22 -0800 (PST) Received: from mail383c25.carrierzone.com (mail383c25.carrierzone.com [209.235.146.153]) by core3.amsl.com (Postfix) with ESMTP id C1B1C3A6837; Mon, 7 Dec 2009 07:08:21 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail383c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7F83qO032285; Mon, 7 Dec 2009 15:08:08 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Dec 2009 10:00:34 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG12072009-100026-12266.MMD@TencoAssembliesInc.local; Mon, 7 Dec 2009 10:00:26 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail366c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7ExnqW028055 for ; Mon, 7 Dec 2009 09:59:51 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NHf3R-0005n0-9i for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Dec 2009 14:59:13 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHf3Q-0005mF-Lb for w3c-dist-auth@listhub.w3.org; Mon, 07 Dec 2009 14:59:12 +0000 Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHf3O-0002dX-GP for w3c-dist-auth@w3.org; Mon, 07 Dec 2009 14:59:12 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7EwaLq013794 for ; Mon, 7 Dec 2009 14:58:38 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OYRw8NW6GFoL5enUCeCtQA)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00300CXB5T00@fe-emea-09.sun.com> for w3c-dist-auth@w3.org; Mon, 07 Dec 2009 14:58:29 +0000 (GMT) Received: from arnaud-quillauds-mac-mini.local ([unknown] [129.150.117.219]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA00GVBEX7XA70@fe-emea-09.sun.com>; Mon, 07 Dec 2009 14:58:20 +0000 (GMT) Date: Mon, 07 Dec 2009 15:58:18 +0100 From: Arnaud Quillaud In-reply-to: To: Helge Hess Message-id: <4B1D180A.2050103@sun.com> References: <4B057E6B.7040808@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: bart.w3.org 1NHf3O-0002dX-GP 090159087180dc4051505667127561b4 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13222 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 07 Dec 2009 14:59:13 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 07 Dec 2009 15:00:34.0913 (UTC) FILETIME=[076BA510:01CA774E] Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 15:08:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_OYRw8NW6GFoL5enUCeCtQA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 6/12/09 22:34, Helge Hess wrote: > Hi, > > Arnaud asked me on my opinion on the following ... > > On 19.11.2009, at 18:20, Arnaud Quillaud wrote: > >> I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ). >> > > => > >> 2. Do clients really need to be notified that a resource was created >> versus modified ? They should be able to figure that out by >> looking at the state of their current cache. If this information >> is not necessary, the response would not need to contain a DAV: >> status along with the DAV:propstat. This would allow the use of >> a regular multistatus (simply extended with a sync-token >> element). >> > > Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ... > Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ... > > The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing] > Maximilian Odendahl who is working on the Symbian CalDAV connector gave us the same feedback. And it looks like the Inverse Edition of Mozilla Lightning is doing the same thing (i.e. scan regardless of the status sent by the server). Arnaud > So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it. > > Greets, > Helge > > > > _______________________________________________ > caldav mailing list > caldav@ietf.org > https://www.ietf.org/mailman/listinfo/caldav > --Boundary_(ID_OYRw8NW6GFoL5enUCeCtQA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 6/12/09 22:34, Helge Hess wrote: 
Hi,

Arnaud asked me on my opinion on the following ...

On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
  
I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).
    

=>
  
   2.  Do clients really need to be notified that a resource was created
       versus modified ?  They should be able to figure that out by
       looking at the state of their current cache.  If this information
       is not necessary, the response would not need to contain a DAV:
       status along with the DAV:propstat.  This would allow the use of
       a regular multistatus (simply extended with a sync-token
       element).
    

Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ...
Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ...

The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing]
Maximilian Odendahl who is working on the Symbian CalDAV connector gave us the same feedback.
And it looks like the Inverse Edition of Mozilla Lightning is doing the same thing (i.e. scan regardless of the status sent by the server).

Arnaud
So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.

Greets,
  Helge



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

--Boundary_(ID_OYRw8NW6GFoL5enUCeCtQA)-- From cyrus@daboo.name Mon Dec 7 07:55:37 2009 Return-Path: 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 07B0D3A6A6B; Mon, 7 Dec 2009 07:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599] 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 UQ04Zu+Odv-v; Mon, 7 Dec 2009 07:55:36 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 1B50D3A6A45; Mon, 7 Dec 2009 07:55:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E671E3D1C694; Mon, 7 Dec 2009 10:55:25 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4E+-aSVHibl; Mon, 7 Dec 2009 10:55:25 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 9AF223D1C687; Mon, 7 Dec 2009 10:55:23 -0500 (EST) Date: Mon, 07 Dec 2009 10:55:16 -0500 From: Cyrus Daboo To: Helge Hess , Arnaud Quillaud Message-ID: In-Reply-To: References: <4B057E6B.7040808@sun.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1710 Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 15:55:37 -0000 Hi Helge, --On December 6, 2009 10:34:33 PM +0100 Helge Hess wrote: > Its not crucial, but helpful. If I don't know that a resource is new, I > obviously have to scan the cache to check for that. Which is > significantly more expensive than a simple INSERT (status = 'N', url=abc) > ... Given that WebDAV sync is supposed to improve sync with large > folders, the 'check' time consumption becomes more relevant too ... > > The question is whether I would do the scan anyways, just to be sure > there are no DUPs. Probably! :-) [either me, or a database unique > constraint doing effectively the same thing] > > So I guess either way is fine with me with a slight preference towards > having a separate 'created'. If that would be significantly more > difficult for servers, lets drop it, if not, lets preserve it. Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT. In that case, were you to do an INSERT using the UID as a unique key for that reported item you would get an error as the client already has the old copy cached. So a "simple" INSERT isn't going to work in that case. Now we could change that behavior to have the deleted/re-created resource reported as "modified" rather than "new". However, I think the reality is that clients are going to have to accept the fact that there may be false positives (though hopefully never false negatives) so the prudent thing to do is always do a proper match between the server reported results and the full cache they currently have. Maybe we need a statement clarify that. -- Cyrus Daboo From cyrus@daboo.name Mon Dec 7 08:09:21 2009 Return-Path: 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 A1BBC3A68DB; Mon, 7 Dec 2009 08:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599] 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 NjvPw65oaxZc; Mon, 7 Dec 2009 08:09:20 -0800 (PST) Received: from mail385c25.carrierzone.com (mail385c25.carrierzone.com [209.235.146.155]) by core3.amsl.com (Postfix) with ESMTP id BAA2F3A68A4; Mon, 7 Dec 2009 08:09:20 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail385c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7G93pb003292; Mon, 7 Dec 2009 16:09:07 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Dec 2009 11:01:34 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG12072009-110127-12310.MMD@TencoAssembliesInc.local; Mon, 7 Dec 2009 11:01:27 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail368c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7FudGb014155 for ; Mon, 7 Dec 2009 10:56:41 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NHfwJ-00058M-VR for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Dec 2009 15:55:56 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHfwI-00057h-F8 for w3c-dist-auth@listhub.w3.org; Mon, 07 Dec 2009 15:55:54 +0000 Received: from daboo.name ([151.201.22.177]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHfwG-0001z1-TC for w3c-dist-auth@w3.org; Mon, 07 Dec 2009 15:55:54 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E671E3D1C694; Mon, 7 Dec 2009 10:55:25 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4E+-aSVHibl; Mon, 7 Dec 2009 10:55:25 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 9AF223D1C687; Mon, 7 Dec 2009 10:55:23 -0500 (EST) Date: Mon, 07 Dec 2009 10:55:16 -0500 From: Cyrus Daboo To: Helge Hess , Arnaud Quillaud Message-ID: In-Reply-To: References: <4B057E6B.7040808@sun.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1710 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1NHfwG-0001z1-TC 3ec536fac7e5927637793cb1dcfe9376 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13223 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 07 Dec 2009 15:55:55 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 07 Dec 2009 16:01:34.0491 (UTC) FILETIME=[8CB2EEB0:01CA7756] Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:09:21 -0000 Hi Helge, --On December 6, 2009 10:34:33 PM +0100 Helge Hess wrote: > Its not crucial, but helpful. If I don't know that a resource is new, I > obviously have to scan the cache to check for that. Which is > significantly more expensive than a simple INSERT (status = 'N', url=abc) > ... Given that WebDAV sync is supposed to improve sync with large > folders, the 'check' time consumption becomes more relevant too ... > > The question is whether I would do the scan anyways, just to be sure > there are no DUPs. Probably! :-) [either me, or a database unique > constraint doing effectively the same thing] > > So I guess either way is fine with me with a slight preference towards > having a separate 'created'. If that would be significantly more > difficult for servers, lets drop it, if not, lets preserve it. Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT. In that case, were you to do an INSERT using the UID as a unique key for that reported item you would get an error as the client already has the old copy cached. So a "simple" INSERT isn't going to work in that case. Now we could change that behavior to have the deleted/re-created resource reported as "modified" rather than "new". However, I think the reality is that clients are going to have to accept the fact that there may be false positives (though hopefully never false negatives) so the prudent thing to do is always do a proper match between the server reported results and the full cache they currently have. Maybe we need a statement clarify that. -- Cyrus Daboo From Dave.Thewlis@calconnect.org Mon Dec 7 10:54:08 2009 Return-Path: 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 532743A681C; Mon, 7 Dec 2009 10:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 v-ThS5mB2wC1; Mon, 7 Dec 2009 10:54:07 -0800 (PST) Received: from newredwood.morsemedia.net (newredwood.morsemedia.net [69.50.246.34]) by core3.amsl.com (Postfix) with ESMTP id 345983A67B5; Mon, 7 Dec 2009 10:54:06 -0800 (PST) Received: from [75.111.59.123] (helo=[192.168.0.216]) by newredwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1NHiiY-0004gC-C8; Mon, 07 Dec 2009 10:53:54 -0800 Message-ID: <4B1D4F46.6000303@calconnect.org> Date: Mon, 07 Dec 2009 10:53:58 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dave Thewlis , caldav@ietf.org, calsify@ietf.org, vcarddav@ietf.org Content-Type: multipart/alternative; boundary="------------010505070504010501050202" X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1NHiiY-0004gC-C8 X-MorseMedia-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newredwood.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org Subject: [caldav] Registration is open for CalConnect XVII, February 1-5, 2010 X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 18:54:08 -0000 This is a multi-part message in MIME format. --------------010505070504010501050202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Colleagues, /This e-mail is going to the mailing lists primarily interested in Calendaring and related matters. My apologies if you receive this notice multiple times; many of us are on multiple mailing lists. / Registration is now open for CalConnect XVII, February 1-5, 2010, at the University of California at Irvine, Irvine, California. Please see http://www.calconnect.org/calconnect17.shtml for logistics and registration information for the Roundtable and for the Interoperability Test Events. Note that we will be conducting both a regular Interoperability Test Event and a Mobile Calendaring Interoperability Test Event on February 1-3. More information about the regular IOP Test Event is at http://www.calconnect.org/iop1002.shtml. More information about the Mobile Calendaring IOP Test Event is at http://www.calconnect.org/miop1002.shtml. The meeting venue will be the University Club at UC Irvine. The logistics page includes a map of the area (including hotels and the location of the meeting venue) and directions to the University Club. The University club also has a dedicated parking lot for those who have cars. The Conference Hotel will be the Ayers Hotels & Suites, Costa Mesa / Newport Beach which is near the John Wayne Airport and about 4 miles from UC Irvine. CalConnect has a special rate for this event negotiated by the University. The logistics page contains more information about the hotel and how to reserve your room at the special rate of $79/night. /Please be aware that you may book at the CalConnect rate starting _Monday, December 7_/. The hotel offers shuttle service to and from the airport, and also expects to offer shuttle service for us to and from the meeting venue each day for those who are interested. We will be announcing additional and special sessions of interest as more material becomes available. At this time while the general schedule is set, we cannot guarantee that the specific dates and times set on the logistics page for each TC will not change. See you in Irvine! Best Regards, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------010505070504010501050202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Colleagues,

This e-mail is going to the mailing lists primarily interested in Calendaring and related matters.  My apologies if you receive this notice multiple times; many of us are on multiple mailing lists.


Registration is now open for CalConnect XVII, February 1-5, 2010, at the University of California at Irvine, Irvine, California.  Please see http://www.calconnect.org/calconnect17.shtml for logistics and registration information for the Roundtable and for the Interoperability Test Events.

Note that we will be conducting both a regular Interoperability Test Event and a Mobile Calendaring Interoperability Test Event on February 1-3.  More information about the regular IOP Test Event is at http://www.calconnect.org/iop1002.shtml. More information about the Mobile Calendaring IOP Test Event is at http://www.calconnect.org/miop1002.shtml.

The meeting venue will be the University Club at UC Irvine.  The logistics page includes a map of the area (including hotels and the location of the meeting venue) and directions to the University Club.  The University club also has a dedicated parking lot for those who have cars.

The Conference Hotel will be the Ayers Hotels & Suites, Costa Mesa / Newport Beach which is near the John Wayne Airport and about 4 miles from UC Irvine.  CalConnect has a special rate for this event negotiated by the University.  The logistics page contains more information about the hotel and how to reserve your room at the special rate of $79/night.  Please be aware that you may book at the CalConnect rate starting Monday, December 7.

The hotel offers shuttle service to and from the airport, and also expects to offer shuttle service for us to and from the meeting venue each day for those who are interested.

We will be announcing additional and special sessions of interest as more material becomes available.  At this time while the general schedule is set, we cannot guarantee that the specific dates and times set on the logistics page for each TC will not change.

See you in Irvine!

Best Regards,

Dave Thewlis

--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------010505070504010501050202-- From helge.hess@opengroupware.org Mon Dec 7 12:43:32 2009 Return-Path: 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 7E6F73A6988; Mon, 7 Dec 2009 12:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599] 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 HSItqFRPwEKP; Mon, 7 Dec 2009 12:43:31 -0800 (PST) Received: from mailhub.opengroupware.org (mailhub.opengroupware.org [213.211.192.144]) by core3.amsl.com (Postfix) with ESMTP id 88F3D3A6930; Mon, 7 Dec 2009 12:43:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTP id A5817228253; Mon, 7 Dec 2009 21:43:19 +0100 (CET) X-Virus-Scanned: amavisd-new at opengroupware.org Received: from mailhub.opengroupware.org ([127.0.0.1]) by localhost (mailhub.opengroupware.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTMEopb91iD0; Mon, 7 Dec 2009 21:43:18 +0100 (CET) Received: from [192.168.0.111] (91-65-6-214-dynip.superkabel.de [91.65.6.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTPSA id D4CAB2281D3; Mon, 7 Dec 2009 21:43:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Helge Hess In-Reply-To: Date: Mon, 7 Dec 2009 21:43:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> References: <4B057E6B.7040808@sun.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1077) Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:43:32 -0000 On 07.12.2009, at 16:55, Cyrus Daboo wrote: > Just to clarify - right now the spec says that a resource that is = deleted and re-created is reported as "new" if a sync-token prior to the = deletion is given in the REPORT. Ah, OK. I would have expected a "deleted" and a "new" entry in such a = case. Now thinking about it, I think it might be an issue if a resource in the = cache is replaced with an entirely new resource. Eg the client might have (real world: is likely to have) extra = client-side data which is only valid for the 'old' resource. But then, the client can't discover that specific situation with the = regular PROPFIND either. And it won't be terribly common, as new URLs = usually change in most systems. > However, I think the reality is that clients are going to have to = accept the fact that there may be false positives (though hopefully = never false negatives) so the prudent thing to do is always do a proper = match between the server reported results and the full cache they = currently have. Maybe we need a statement clarify that. I think performance might be a real world issue with restricted clients = (mobile) and large folders, where a key lookup does have a cost. Anyways, I stick to my opinion, slightly extended: Either way is fine = with me with a slight preference towards having a separate 'created' AND = 'deleted'. If that would be significantly more difficult for servers, = lets drop it, if not, lets preserve it. :-) Greets, Helge From helge.hess@opengroupware.org Mon Dec 7 12:53:20 2009 Return-Path: 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 6B13F3A68E1; Mon, 7 Dec 2009 12:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599] 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 d2b-GwYQC4PO; Mon, 7 Dec 2009 12:53:19 -0800 (PST) Received: from mail382c25.carrierzone.com (mail382c25.carrierzone.com [209.235.146.152]) by core3.amsl.com (Postfix) with ESMTP id 84EF73A6936; Mon, 7 Dec 2009 12:53:19 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail382c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7Kr1uf026491; Mon, 7 Dec 2009 20:53:03 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Dec 2009 15:45:32 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG12072009-154526-12423.MMD@TencoAssembliesInc.local; Mon, 7 Dec 2009 15:45:26 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail374c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7KinJY029248 for ; Mon, 7 Dec 2009 15:44:53 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NHkQx-0006sC-Lu for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Dec 2009 20:43:51 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHkQv-0006rT-8h for w3c-dist-auth@listhub.w3.org; Mon, 07 Dec 2009 20:43:49 +0000 Received: from mailhub.opengroupware.org ([213.211.192.144]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHkQt-0004GM-FS for w3c-dist-auth@w3.org; Mon, 07 Dec 2009 20:43:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTP id A5817228253; Mon, 7 Dec 2009 21:43:19 +0100 (CET) X-Virus-Scanned: amavisd-new at opengroupware.org Received: from mailhub.opengroupware.org ([127.0.0.1]) by localhost (mailhub.opengroupware.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTMEopb91iD0; Mon, 7 Dec 2009 21:43:18 +0100 (CET) Received: from [192.168.0.111] (91-65-6-214-dynip.superkabel.de [91.65.6.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTPSA id D4CAB2281D3; Mon, 7 Dec 2009 21:43:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Helge Hess In-Reply-To: Date: Mon, 7 Dec 2009 21:43:16 +0100 Message-Id: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> References: <4B057E6B.7040808@sun.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1077) Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_HELO_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1NHkQt-0004GM-FS 1acf1a0dbd0fae78566716fdaa3640d2 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13224 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 07 Dec 2009 20:43:51 +0000 X-MMR: 0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail374c25.carrierzone.com id nB7KinJY029248 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 07 Dec 2009 20:45:32.0257 (UTC) FILETIME=[37FFB510:01CA777E] Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:53:20 -0000 On 07.12.2009, at 16:55, Cyrus Daboo wrote: > Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT. Ah, OK. I would have expected a "deleted" and a "new" entry in such a case. Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource. Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource. But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems. > However, I think the reality is that clients are going to have to accept the fact that there may be false positives (though hopefully never false negatives) so the prudent thing to do is always do a proper match between the server reported results and the full cache they currently have. Maybe we need a statement clarify that. I think performance might be a real world issue with restricted clients (mobile) and large folders, where a key lookup does have a cost. Anyways, I stick to my opinion, slightly extended: Either way is fine with me with a slight preference towards having a separate 'created' AND 'deleted'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it. :-) Greets, Helge From julian.reschke@gmx.de Mon Dec 7 13:58:05 2009 Return-Path: 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 1CF503A69A2 for ; Mon, 7 Dec 2009 13:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.224 X-Spam-Level: X-Spam-Status: No, score=-4.224 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599] 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 Jxtf8vp7FjyD for ; Mon, 7 Dec 2009 13:58:05 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7614A3A694E for ; Mon, 7 Dec 2009 13:58:04 -0800 (PST) Received: (qmail invoked by alias); 07 Dec 2009 21:57:49 -0000 Received: from p508FF787.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.247.135] by mail.gmx.net (mp064) with SMTP; 07 Dec 2009 22:57:49 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18gpD18oPcgqHR81BlgCHzQKAt8i1ej3ELzGlRxO5 IjwLz7QY4GcdFR Message-ID: <4B1D7A59.2090902@gmx.de> Date: Mon, 07 Dec 2009 22:57:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess References: <4B057E6B.7040808@sun.com> <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> In-Reply-To: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 21:58:05 -0000 Helge Hess wrote: > On 07.12.2009, at 16:55, Cyrus Daboo wrote: >> Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT. > > Ah, OK. I would have expected a "deleted" and a "new" entry in such a case. > > Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource. > Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource. > > But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems. It could if the server supports DAV:resourceid. (see draft-ietf-webdav-bind). > ... BR, Julian From julian.reschke@gmx.de Mon Dec 7 14:08:13 2009 Return-Path: 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 D79893A683D; Mon, 7 Dec 2009 14:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.156 X-Spam-Level: X-Spam-Status: No, score=-8.156 tagged_above=-999 required=5 tests=[AWL=2.443, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CFxqYf0h3ex6; Mon, 7 Dec 2009 14:08:13 -0800 (PST) Received: from mail383c25.carrierzone.com (mail383c25.carrierzone.com [209.235.146.153]) by core3.amsl.com (Postfix) with ESMTP id 9B9093A63EB; Mon, 7 Dec 2009 14:08:13 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail383c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7M7wOL029729; Mon, 7 Dec 2009 22:08:00 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Dec 2009 17:00:29 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG12072009-170025-12445.MMD@TencoAssembliesInc.local; Mon, 7 Dec 2009 17:00:25 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail367c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7LxFaH032468 for ; Mon, 7 Dec 2009 16:59:19 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NHlbA-0003Lo-QG for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Dec 2009 21:58:28 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHlb8-0003LA-OQ for w3c-dist-auth@listhub.w3.org; Mon, 07 Dec 2009 21:58:26 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1NHlb6-0007AH-S6 for w3c-dist-auth@w3.org; Mon, 07 Dec 2009 21:58:26 +0000 Received: (qmail invoked by alias); 07 Dec 2009 21:57:49 -0000 Received: from p508FF787.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.247.135] by mail.gmx.net (mp064) with SMTP; 07 Dec 2009 22:57:49 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18gpD18oPcgqHR81BlgCHzQKAt8i1ej3ELzGlRxO5 IjwLz7QY4GcdFR Message-ID: <4B1D7A59.2090902@gmx.de> Date: Mon, 07 Dec 2009 22:57:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Helge Hess References: <4B057E6B.7040808@sun.com> <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> In-Reply-To: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1NHlb6-0007AH-S6 c23c9763b9348ee71f118aa2478cd9aa X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13225 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 07 Dec 2009 21:58:28 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 07 Dec 2009 22:00:29.0601 (UTC) FILETIME=[B09FF110:01CA7788] Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 22:08:14 -0000 Helge Hess wrote: > On 07.12.2009, at 16:55, Cyrus Daboo wrote: >> Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT. > > Ah, OK. I would have expected a "deleted" and a "new" entry in such a case. > > Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource. > Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource. > > But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems. It could if the server supports DAV:resourceid. (see draft-ietf-webdav-bind). > ... BR, Julian From andrew@morphoss.com Mon Dec 7 14:26:37 2009 Return-Path: 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 0DEED3A69A9; Mon, 7 Dec 2009 14:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 qme9luW46e9F; Mon, 7 Dec 2009 14:26:36 -0800 (PST) Received: from mail.morphoss.com (hoppy.mcmillan.net.nz [IPv6:2404:130:0:1::82:0]) by core3.amsl.com (Postfix) with ESMTP id 977F73A69A7; Mon, 7 Dec 2009 14:26:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id A87E223424; Tue, 8 Dec 2009 11:26:22 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at mail.morphoss.com Received: from mail.morphoss.com ([127.0.0.1]) by localhost (hoppy.mcmillan.net.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t2PebprUayj5; Tue, 8 Dec 2009 11:26:07 +1300 (NZDT) Received: from [192.168.55.20] (home.mcmillan.net.nz [202.160.48.75]) (Authenticated sender: andrew@mail.morphoss.com) by mail.morphoss.com (Postfix) with ESMTPSA id 9FBBF23421; Tue, 8 Dec 2009 11:26:07 +1300 (NZDT) From: Andrew McMillan To: Helge Hess In-Reply-To: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> (sfid-20091208_094344_410541_F025B12C) References: <4B057E6B.7040808@sun.com> <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> (sfid-20091208_094344_410541_F025B12C) Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Q+gYqDprkZMcLHYRv/8N" Date: Tue, 08 Dec 2009 11:26:06 +1300 Message-ID: <1260224766.3909.2111.camel@happy.home.mcmillan.net.nz> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 22:26:37 -0000 --=-Q+gYqDprkZMcLHYRv/8N Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2009-12-07 at 21:43 +0100, Helge Hess wrote: > On 07.12.2009, at 16:55, Cyrus Daboo wrote: > > Just to clarify - right now the spec says that a resource > > that is deleted and re-created is reported as "new" if a > > sync-token prior to the deletion is given in the REPORT. >=20 > Ah, OK. I would have expected a "deleted" and a "new" entry in such a > case. Yes, and in fact I revisited my code for this situation after reading Cyrus' note and discovered that I had implemented that particular case incorrectly in exactly that way. Sending a DELETE followed by a CREATE in this situation would seem to more clearly communicate the real-world action, and while there will be times when the sync report simply ends up prompting the client to perform a full sync, reducing the frequency of those situations should also be a goal. On the other hand if we consider this analogous to two consecutive PROPFIND requests providing a difference of 'that resource is modified' which clients must necessarily have to cope with already, then it would be better to send a 'resource modified' in the sync response. As it stands, it seems to me to be a gotcha and an inevitable a source of bugs for any client side implementation which sees the create and makes the easy assumption that it means no resource existed in a local cache. > Anyways, I stick to my opinion, slightly extended: Either way is fine > with me with a slight preference towards having a separate 'created' > AND 'deleted'. If that would be significantly more difficult for > servers, lets drop it, if not, lets preserve it. That does seem the safest approach. Regards, Andrew McMillan. ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN Don't you wish you had more energy... or less ambition? ------------------------------------------------------------------------ --=-Q+gYqDprkZMcLHYRv/8N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksdgP0ACgkQjJA0f48GgBI37gCfYA22bKQQugVoio9YA0mhTOCg w+IAn35zgJMXU4D3Ms7C0AeWMJ5gyjo5 =e3DE -----END PGP SIGNATURE----- --=-Q+gYqDprkZMcLHYRv/8N-- From andrew@morphoss.com Mon Dec 7 14:38:17 2009 Return-Path: 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 D4F623A69AF; Mon, 7 Dec 2009 14:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] 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 I-KpUp4d32t6; Mon, 7 Dec 2009 14:38:17 -0800 (PST) Received: from mail385c25.carrierzone.com (mail385c25.carrierzone.com [209.235.146.155]) by core3.amsl.com (Postfix) with ESMTP id EB1973A699E; Mon, 7 Dec 2009 14:38:16 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail385c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7Mbvus004677; Mon, 7 Dec 2009 22:38:02 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Dec 2009 17:30:28 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG12072009-173025-12451.MMD@TencoAssembliesInc.local; Mon, 7 Dec 2009 17:30:25 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB7MROm2005209 for ; Mon, 7 Dec 2009 17:27:27 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NHm2i-0005PB-PD for w3c-dist-auth-dist@listhub.w3.org; Mon, 07 Dec 2009 22:26:56 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHm2g-0005NN-Lc for w3c-dist-auth@listhub.w3.org; Mon, 07 Dec 2009 22:26:54 +0000 Received: from hoppy.mcmillan.net.nz ([202.78.240.82] helo=mail.morphoss.com ident=postfix) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NHm2d-0005Ii-Ql for w3c-dist-auth@w3.org; Mon, 07 Dec 2009 22:26:54 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id A87E223424; Tue, 8 Dec 2009 11:26:22 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at mail.morphoss.com Received: from mail.morphoss.com ([127.0.0.1]) by localhost (hoppy.mcmillan.net.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t2PebprUayj5; Tue, 8 Dec 2009 11:26:07 +1300 (NZDT) Received: from [192.168.55.20] (home.mcmillan.net.nz [202.160.48.75]) (Authenticated sender: andrew@mail.morphoss.com) by mail.morphoss.com (Postfix) with ESMTPSA id 9FBBF23421; Tue, 8 Dec 2009 11:26:07 +1300 (NZDT) From: Andrew McMillan To: Helge Hess In-Reply-To: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> (sfid-20091208_094344_410541_F025B12C) References: <4B057E6B.7040808@sun.com> <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> (sfid-20091208_094344_410541_F025B12C) Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Q+gYqDprkZMcLHYRv/8N" Date: Tue, 08 Dec 2009 11:26:06 +1300 Message-ID: <1260224766.3909.2111.camel@happy.home.mcmillan.net.nz> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1NHm2d-0005Ii-Ql 88b8465d3667aa4c8890b81944c476c2 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13226 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 07 Dec 2009 22:26:56 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 07 Dec 2009 22:30:28.0616 (UTC) FILETIME=[E0EBD880:01CA778C] Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 22:38:18 -0000 --=-Q+gYqDprkZMcLHYRv/8N Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2009-12-07 at 21:43 +0100, Helge Hess wrote: > On 07.12.2009, at 16:55, Cyrus Daboo wrote: > > Just to clarify - right now the spec says that a resource > > that is deleted and re-created is reported as "new" if a > > sync-token prior to the deletion is given in the REPORT. >=20 > Ah, OK. I would have expected a "deleted" and a "new" entry in such a > case. Yes, and in fact I revisited my code for this situation after reading Cyrus' note and discovered that I had implemented that particular case incorrectly in exactly that way. Sending a DELETE followed by a CREATE in this situation would seem to more clearly communicate the real-world action, and while there will be times when the sync report simply ends up prompting the client to perform a full sync, reducing the frequency of those situations should also be a goal. On the other hand if we consider this analogous to two consecutive PROPFIND requests providing a difference of 'that resource is modified' which clients must necessarily have to cope with already, then it would be better to send a 'resource modified' in the sync response. As it stands, it seems to me to be a gotcha and an inevitable a source of bugs for any client side implementation which sees the create and makes the easy assumption that it means no resource existed in a local cache. > Anyways, I stick to my opinion, slightly extended: Either way is fine > with me with a slight preference towards having a separate 'created' > AND 'deleted'. If that would be significantly more difficult for > servers, lets drop it, if not, lets preserve it. That does seem the safest approach. Regards, Andrew McMillan. ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN Don't you wish you had more energy... or less ambition? ------------------------------------------------------------------------ --=-Q+gYqDprkZMcLHYRv/8N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksdgP0ACgkQjJA0f48GgBI37gCfYA22bKQQugVoio9YA0mhTOCg w+IAn35zgJMXU4D3Ms7C0AeWMJ5gyjo5 =e3DE -----END PGP SIGNATURE----- --=-Q+gYqDprkZMcLHYRv/8N--