Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9C5F57841F2 for ; Mon, 23 Mar 2009 07:31:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-50 required=4 tests=[AWL=-0.138, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JitCKR3U-oCr for ; Mon, 23 Mar 2009 07:31:11 -0700 (PDT) Received: from mail385c25.carrierzone.com (mail385c25.carrierzone.com [209.235.146.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 7EA477841F0 for ; Mon, 23 Mar 2009 07:31:11 -0700 (PDT) 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 n2NEV1TA031646; Mon, 23 Mar 2009 14:31:03 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Mar 2009 09:31:01 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG03232009-093056-169.MMD@TencoAssembliesInc.local; Mon, 23 Mar 2009 09:30:56 -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 n2NEN1lO028764 for ; Mon, 23 Mar 2009 10:23:04 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Lll1f-00004r-CM for w3c-dist-auth-dist@listhub.w3.org; Mon, 23 Mar 2009 14:21:15 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lll1d-0008Vo-Pe for w3c-dist-auth@listhub.w3.org; Mon, 23 Mar 2009 14:21:14 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1Lll1S-0003ld-SN for w3c-dist-auth@w3.org; Mon, 23 Mar 2009 14:21:13 +0000 Received: (qmail invoked by alias); 23 Mar 2009 14:13:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 23 Mar 2009 15:13:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+50dF5yi65qZs94wqd6cOr8cOfmcMlzVp/x0mKO2 +h2t62aM6lu12Q Message-ID: <49C7991C.5000706@gmx.de> Date: Mon, 23 Mar 2009 15:13:48 +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: Cyrus Daboo References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> In-Reply-To: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 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: maggie.w3.org 1Lll1S-0003ld-SN 708b68dbe6f2eecd0f6b57cd28d7281f X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13108 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, 23 Mar 2009 14:21:15 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 23 Mar 2009 14:31:01.0252 (UTC) FILETIME=[FD3F3440:01C9ABC3] Cc: WebDAV , CardDAV , CalDAV Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:31:17 -0000 Hi, below are some comments on draft-daboo-webdav-sync-01. High Level: First of all, the complexity of this mainly depends on the type of server. For instance, for a Subversion-style store (with a global change counter) this could be almost trivial, while it may be very hard to implement for many others. Also, there's some related work in this area, such as: - using a feed format (Atom?) - sending notifications over XMPP () - Microsoft's take on it: SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL () - Notifications, as defined in JCR (Java Content Repository), which at some point we'll want to transport over HTTP.... - RFC 3253 (DeltaV) and WebDAV BIND which clarify what the state of a collection is, and define a property (DAV:resource-id) which could be used to define "sameness" of a WebDAV resource under name changes. Regarding Section 3, "Open Issues": "1. Should we try and discriminate between changes to the body of a resource and changes to the properties?" I think we need to. "2. If we indicate a property change, should we return the list of properties that changed on each resource (propnames NOT values)?" Why only the names? "3. Should we provide a way to indicate that a 'new' resource is new in the collection as a result of a COPY or MOVE from another location, as opposed to being created?" At least MOVE and COPY should be handled separately; DAV:resource-id () could be used for that. "4. Should we provide a way to indicate that a 'deleted' resource was removed from the collection as a result of a MOVE to another location, as opposed to being actually deleted?" Not sure it makes a difference. "5. How should ACLs be handled? e.g. a resource is visible to a user at one point in time, then its privilege is removed. Should the resource be marked as having been deleted when next synchronized?" Why deleted? I realize that some servers return 404 for resources the user doesn't have read access to, but that's not the general case. "6. Do we want a special indicator for a resource that was deleted and then re-created, as opposed to just indicating that the resource was 'changed'?" I think the information is needed. It could be provided using DAV:resource-id. Other substantial comments: 1. Introduction "This can currently be done using a WebDAV PROPFIND request on a collection to list all members of a collection along with their HTTP ETag values, which allows the client to determine which resources were changed, added or deleted." s/HTTP ETag values/DAV:getetag property values/ Also note this wouldn't necessarily detect property changes. "Additionally, a new property is added to collection resources that is used to convey a "synchronization token" that is guaranteed to change when the contents of the collection have changed." You need to define the term "contents" here. Obviously, it includes data that is not included in the collection's state, as defined in RFC 3253, for example. 4.1 "HTTP already defines a synchronization token in the form of an entity tag which is attached to a resource. However, the entity tag is not always required to be 'strong' and thus cannot be relied on absolutely as a valid synchronization indicator. In addition, there is no concept of an entity tag for a collection's contents." Sic -- it's because that term is not defined (at least not in the way this spec wants to use it :-) 4.2 "To implement the behavior for this REPORT a server needs to keep track of changes to any resources in a collection." Need to clarify what "in a collection" means; I guess "Internal Member", as defined by RFC 4918, Section 3? "The request URI MUST be a collection." Why? "The "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client." Nope, see earlier discussion. "The response body for a successful request MUST be a DAV:multistatus XML element, which MUST contain one DAV:sync-token element in addition to any DAV:sync-response elements." Not sure why this re-uses DAV:multistatus, and then puts something completely else as child elements. Editorial Comments: - state venue for discussion - expand abbreviations on first use - 4.1 "The is specification defines a new WebDAV REPORT that is used to enable client-server collection synchronization." "The is"? "That is done by the client sending an empty token value to the server." I think "no token" would be better. - "4.2 REPORT defined" Title. "If the report is not available, clients MUST NOT attempt to execute one." Requirement unnecessary. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5AFDC7841F0 for ; Mon, 23 Mar 2009 07:14:03 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-50 required=4 tests=[AWL=-1.487, BAYES_50=0.001, SPF_PASS=-0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVjAf1f4hqS0 for ; Mon, 23 Mar 2009 07:13:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id E548F77D728 for ; Mon, 23 Mar 2009 07:13:53 -0700 (PDT) Received: (qmail invoked by alias); 23 Mar 2009 14:13:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 23 Mar 2009 15:13:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+50dF5yi65qZs94wqd6cOr8cOfmcMlzVp/x0mKO2 +h2t62aM6lu12Q Message-ID: <49C7991C.5000706@gmx.de> Date: Mon, 23 Mar 2009 15:13:48 +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: Cyrus Daboo References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> In-Reply-To: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: WebDAV , CardDAV , CalDAV Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:14:03 -0000 Hi, below are some comments on draft-daboo-webdav-sync-01. High Level: First of all, the complexity of this mainly depends on the type of server. For instance, for a Subversion-style store (with a global change counter) this could be almost trivial, while it may be very hard to implement for many others. Also, there's some related work in this area, such as: - using a feed format (Atom?) - sending notifications over XMPP () - Microsoft's take on it: SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL () - Notifications, as defined in JCR (Java Content Repository), which at some point we'll want to transport over HTTP.... - RFC 3253 (DeltaV) and WebDAV BIND which clarify what the state of a collection is, and define a property (DAV:resource-id) which could be used to define "sameness" of a WebDAV resource under name changes. Regarding Section 3, "Open Issues": "1. Should we try and discriminate between changes to the body of a resource and changes to the properties?" I think we need to. "2. If we indicate a property change, should we return the list of properties that changed on each resource (propnames NOT values)?" Why only the names? "3. Should we provide a way to indicate that a 'new' resource is new in the collection as a result of a COPY or MOVE from another location, as opposed to being created?" At least MOVE and COPY should be handled separately; DAV:resource-id () could be used for that. "4. Should we provide a way to indicate that a 'deleted' resource was removed from the collection as a result of a MOVE to another location, as opposed to being actually deleted?" Not sure it makes a difference. "5. How should ACLs be handled? e.g. a resource is visible to a user at one point in time, then its privilege is removed. Should the resource be marked as having been deleted when next synchronized?" Why deleted? I realize that some servers return 404 for resources the user doesn't have read access to, but that's not the general case. "6. Do we want a special indicator for a resource that was deleted and then re-created, as opposed to just indicating that the resource was 'changed'?" I think the information is needed. It could be provided using DAV:resource-id. Other substantial comments: 1. Introduction "This can currently be done using a WebDAV PROPFIND request on a collection to list all members of a collection along with their HTTP ETag values, which allows the client to determine which resources were changed, added or deleted." s/HTTP ETag values/DAV:getetag property values/ Also note this wouldn't necessarily detect property changes. "Additionally, a new property is added to collection resources that is used to convey a "synchronization token" that is guaranteed to change when the contents of the collection have changed." You need to define the term "contents" here. Obviously, it includes data that is not included in the collection's state, as defined in RFC 3253, for example. 4.1 "HTTP already defines a synchronization token in the form of an entity tag which is attached to a resource. However, the entity tag is not always required to be 'strong' and thus cannot be relied on absolutely as a valid synchronization indicator. In addition, there is no concept of an entity tag for a collection's contents." Sic -- it's because that term is not defined (at least not in the way this spec wants to use it :-) 4.2 "To implement the behavior for this REPORT a server needs to keep track of changes to any resources in a collection." Need to clarify what "in a collection" means; I guess "Internal Member", as defined by RFC 4918, Section 3? "The request URI MUST be a collection." Why? "The "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client." Nope, see earlier discussion. "The response body for a successful request MUST be a DAV:multistatus XML element, which MUST contain one DAV:sync-token element in addition to any DAV:sync-response elements." Not sure why this re-uses DAV:multistatus, and then puts something completely else as child elements. Editorial Comments: - state venue for discussion - expand abbreviations on first use - 4.1 "The is specification defines a new WebDAV REPORT that is used to enable client-server collection synchronization." "The is"? "That is done by the client sending an empty token value to the server." I think "no token" would be better. - "4.2 REPORT defined" Title. "If the report is not available, clients MUST NOT attempt to execute one." Requirement unnecessary. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 1F0E67841F4 for ; Fri, 20 Mar 2009 14:04:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-50 required=4 tests=[AWL=1.060, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98DIbUlIRqlR for ; Fri, 20 Mar 2009 14:04:37 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4E71A7841ED for ; Fri, 20 Mar 2009 14:04:37 -0700 (PDT) Received: from [75.111.31.7] (helo=[192.168.0.216]) by redwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1LkltM-0004em-1J; Fri, 20 Mar 2009 14:04:36 -0700 Message-ID: <49C404E8.1000901@calconnect.org> Date: Fri, 20 Mar 2009 14:04:40 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------080309020406000509000303" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org Subject: [ietf-caldav] Registration is Now Open for CalConnect XV: Roundtable XV and CalConnect Interoperability Test Event, June 1-5, 2009, Redwood Shores, California X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 21:04:45 -0000 This is a multi-part message in MIME format. --------------080309020406000509000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit *Registration is now open* for CalConnect XV comprised of Roundtable XV and a CalConnect Interoperability Test Event, hosted by *Oracle in Redwood Shores, California*, on June 1-5, 2009. Please see http://www.calconnect.org/calconnect15.shtml for logistics information and links to registration for the Roundtable and for the CalConnect Interoperability Test Event. We will meet in the Oracle Conference Center at 350 Oracle Parkway, Redwood Shores. If you are planning on participating in the CalConnect Interoperability Test Event, it begins with breakfast on Monday morning the 1st at 08:00 and runs to noon on Wednesday the 3rd. As usual the Roundtable will begin with lunch at 12:30 on Wednesday the 3rd and run until early Friday afternoon the 5th. A general schedule of events is provided on the logistics page; the final schedule of TC sessions, together with topical agendas, will be available by mid-May. See you at Oracle in June! *Also* as an aid to CalConnect announcements (i.e. an RSS feed) we now have a CalConnect blog at http://calconnect.wordpress.com. The primary purpose is to announce events, publications, and other CalConnect and Calendaring occurrences, but there will be occasional other posts. If you want to get them hot off the (Word)press, be sure and link to the RSS feed. Cheers, 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 --------------080309020406000509000303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Registration is now open for CalConnect XV comprised of Roundtable XV and a CalConnect Interoperability Test Event, hosted by Oracle in Redwood Shores, California, on June 1-5, 2009.

Please see  http://www.calconnect.org/calconnect15.shtml for logistics information and links to registration for the Roundtable and for the CalConnect Interoperability Test Event.  We will meet in the Oracle Conference Center at 350 Oracle Parkway, Redwood Shores. 

If you are planning on participating in the CalConnect Interoperability Test Event, it begins with breakfast on Monday morning the 1st at 08:00 and runs to noon on Wednesday the 3rd.  As usual the Roundtable will begin with lunch at 12:30 on Wednesday the 3rd  and run until early Friday afternoon the 5th. 

A general schedule of events is provided on the logistics page; the final schedule of TC sessions, together with topical agendas, will be available by mid-May. 

See you at Oracle in June!

Also as an aid to CalConnect announcements (i.e. an RSS feed) we now have a CalConnect blog at http://calconnect.wordpress.com.  The primary purpose is to announce events, publications, and other CalConnect and Calendaring occurrences, but there will be occasional other posts.  If you want to get them hot off the (Word)press, be sure and link to the RSS feed.

Cheers,

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
--------------080309020406000509000303-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 6174A7841EF for ; Mon, 16 Mar 2009 09:17:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-50 required=4 tests=[AWL=-0.560, BAYES_50=0.001, RDNS_DYNAMIC=0.1] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu1rMT+KrpbL for ; Mon, 16 Mar 2009 09:17:00 -0700 (PDT) Received: from postalo2.babel.it (81-208-88-105.ip.fastwebnet.it [81.208.88.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 9150D77D700 for ; Mon, 16 Mar 2009 09:16:59 -0700 (PDT) Received: by postalo2.babel.it (Postfix, from userid 8) id 167C211C620; Mon, 16 Mar 2009 17:16:51 +0100 (CET) Received: from ananke.localnet (ananke.dhcp.babel.it [10.0.10.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rpolli) by postalo2.babel.it (Postfix) with ESMTP id 0A1C311C61A for ; Mon, 16 Mar 2009 17:16:48 +0100 (CET) From: Roberto Polli Organization: Babel s.r.l To: ietf-caldav@osafoundation.org Date: Mon, 16 Mar 2009 17:17:26 +0100 User-Agent: KMail/1.11.0 (Linux/2.6.24-21-generic; KDE/4.2.0; i686; ; ) References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> <200903111314.39176.rpolli@babel.it> <49B7BD68.8010401@sun.com> In-Reply-To: <49B7BD68.8010401@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903161717.26785.rpolli@babel.it> Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 16:17:07 -0000 On mercoled=EC 11 marzo 2009 14:32:24 you wrote: > > I miss the point: > > * as of now we can find events by time-range with caldav for queries 1) > > and 2) using CREATED|LAST-MOD > > Hmm, this is rather dangerous since those iCalendar properties are > controlled by the client, not by the server. I checked and you're right, but that's not evil. example: 1) let's assume I got one client and one server in sync at T0 2) let's create 100 items (E1..E100) on client, and trigger a new sync at T1 3) imagine that sync lasts 2 minutes and ends at T3 =3D T1+120secs 4) there're now events E1..E100 on server that have been created since the= =20 beginning of the last sync at T2 : T1< T2 X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0841377D70E for ; Thu, 12 Mar 2009 09:22:40 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-50 required=4 tests=[AWL=-0.797, BAYES_20=-0.74] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGC5q7GYRuy for ; Thu, 12 Mar 2009 09:22:28 -0700 (PDT) Received: from mail.uk.scalix.com (mail.uk.scalix.com [82.111.253.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id CC51D77D70B for ; Thu, 12 Mar 2009 09:22:24 -0700 (PDT) Received: from mail.uk.scalix.com (localhost.localdomain [127.0.0.1]) by mail.uk.scalix.com (8.13.8/8.13.8) with ESMTP id n2CGMHLI024853; Thu, 12 Mar 2009 16:22:17 GMT Received: from copper.uk.scalix.com (copper.uk.scalix.com [10.11.108.128]) by mail.uk.scalix.com (Scalix SMTP Relay 11.4.4.12572) via ESMTP; Thu, 12 Mar 2009 16:22:16 +0000 (GMT) Date: Thu, 12 Mar 2009 16:22:16 +0000 From: Gren Elliot To: Julian Reschke , CalDAV DevList , Arnaud Quillaud Message-ID: <49B936B8.4090907@scalix.com> In-Reply-To: <49B930DA.1080206@gmx.de> References: <49B92DF9.2000106@scalix.com> References: <49B930DA.1080206@gmx.de> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) X-SMP-CT-RefID: str=0001.0A0B0203.49B936B8.029D,ss=1,fgs=0 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [ietf-caldav] Thanks Re: and invalid URL characters X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 16:22:40 -0000 Hi Julian and Arnaud, Thank you for your quick and valuable feedback. I agree with your thoughts that invalid characters should NOT be included in and therefore do not plan to try and workaround this. As you say, doing so may prove dangerous! Regards, Gren. Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0857A7841F3 for ; Thu, 12 Mar 2009 08:57:30 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-50 required=4 tests=[AWL=-0.223, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVQ6W64oOY2r for ; Thu, 12 Mar 2009 08:57:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by leka.osafoundation.org (Postfix) with SMTP id D044779401C for ; Thu, 12 Mar 2009 08:57:19 -0700 (PDT) Received: (qmail invoked by alias); 12 Mar 2009 15:57:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.106]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 12 Mar 2009 16:57:17 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+/QrgKIAC/IiFXlSkAjrEJV1+qPy1oUtOvNjagah DmHbVm+er+buzZ Message-ID: <49B930DA.1080206@gmx.de> Date: Thu, 12 Mar 2009 16:57:14 +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: Gren Elliot References: <49B92DF9.2000106@scalix.com> In-Reply-To: <49B92DF9.2000106@scalix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: CalDAV DevList Subject: Re: [ietf-caldav] and invalid URL characters X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:57:30 -0000 Gren Elliot wrote: > Hi, > > Seeking some thoughts or a pointer to a definitive answer, as I can't > see an immediate, definitive answer in the WebDAV spec. > > We sometimes find that a CalDAV client ends up choosing the final > element of the path name for a new calendar entry using a PUT similar to : > > PUT > /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/%7BCA-GREN-49B1-233%7D.ics > HTTP/1.1 > > %7B happens to be the way you would encode "{" in a URL and %7D for "}", > these characters not being valid in a well formed URL. Looks good so far. > The same client then later asks for the same entry using : > REPORT /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/ HTTP/1.1 > ... > > > xmlns:x1="DAV:"> > > > > > /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/{CA-GREN-49B1-233}.ics > That's, stricly speaking, a malformed request, as the contents of DAV:href is syntactically invalid. > and is not happy when it gets the response : > > > > /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/%7BCA-GREN-49B1-233%7D.ics > > > 8 > BEGIN:VCALENDAR > CALSCALE:GREGORIAN > ... It should be more than happy with it :-) > So, my question is, what should go in ? A well formed URL > with correct encoding or is it OK (or even more correct?) to translate > to the more visually friendly form? Theoretically, in this particular > case, the response could follow whatever was used in the request but... Nope. RFC 4918 (WebDAV) requires the content to be a URI or a relative reference. You're not doing anybody a favor by working around client bugs; instead I'd recommend to contact the authors of the client and get it fixed. BR, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C8A2A77D70E for ; Thu, 12 Mar 2009 08:57:14 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-50 required=4 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoeT+i1vWbuj for ; Thu, 12 Mar 2009 08:57:06 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 57BC57841F3 for ; Thu, 12 Mar 2009 08:57:04 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2CFuo3e025838 for ; Thu, 12 Mar 2009 15:57:03 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGE00F00GXDA500@fe-emea-09.sun.com> for ietf-caldav@osafoundation.org; Thu, 12 Mar 2009 15:56:50 +0000 (GMT) Received: from [129.150.117.220] ([unknown] [129.150.117.220]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGE00ANIHMOB360@fe-emea-09.sun.com>; Thu, 12 Mar 2009 15:56:49 +0000 (GMT) Date: Thu, 12 Mar 2009 16:56:48 +0100 From: Arnaud Quillaud In-reply-to: <49B92DF9.2000106@scalix.com> Sender: Arnaud.Quillaud@Sun.COM To: Gren Elliot Message-id: <49B930C0.7050006@sun.com> References: <49B92DF9.2000106@scalix.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090105) Cc: CalDAV DevList Subject: Re: [ietf-caldav] and invalid URL characters X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:57:14 -0000 Gren Elliot wrote: > Hi, > > Seeking some thoughts or a pointer to a definitive answer, as I can't > see an immediate, definitive answer in the WebDAV spec. > > We sometimes find that a CalDAV client ends up choosing the final > element of the path name for a new calendar entry using a PUT similar to : > > PUT > /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/%7BCA-GREN-49B1-233%7D.ics > HTTP/1.1 > > %7B happens to be the way you would encode "{" in a URL and %7D for "}", > these characters not being valid in a well formed URL. > > The same client then later asks for the same entry using : > REPORT /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/ HTTP/1.1 > ... > > > xmlns:x1="DAV:"> > > > > > /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/{CA-GREN-49B1-233}.ics > > > and is not happy when it gets the response : > > > > /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/%7BCA-GREN-49B1-233%7D.ics > > > 8 > BEGIN:VCALENDAR > CALSCALE:GREGORIAN > ... > > So, my question is, what should go in ? A well formed URL > Yes, it should be encoded. See http://tools.ietf.org/html/rfc4918#section-8.3.1 (or read the full rfc3986 but that is probably more painful). > with correct encoding or is it OK (or even more correct?) to translate > to the more visually friendly form? Theoretically, in this particular > It is not OK, especially if both sides start to reencode/decode stuff, assuming that the other side was using/not using encoding (e.g. your %7B might become %407B after a first round trip, then %40407B,...). > case, the response could follow whatever was used in the request but... > > Regards, > Gren. > > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0028F77D70E for ; Thu, 12 Mar 2009 08:45:12 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-50 required=4 tests=[BAYES_20=-0.74] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da9qVa4ZcsuG for ; Thu, 12 Mar 2009 08:45:02 -0700 (PDT) Received: from mail.uk.scalix.com (mail.uk.scalix.com [82.111.253.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id A7C8F77D70B for ; Thu, 12 Mar 2009 08:45:02 -0700 (PDT) Received: from mail.uk.scalix.com (localhost.localdomain [127.0.0.1]) by mail.uk.scalix.com (8.13.8/8.13.8) with ESMTP id n2CFiwsS025698 for ; Thu, 12 Mar 2009 15:44:58 GMT Received: from copper.uk.scalix.com (copper.uk.scalix.com [10.11.108.128]) by mail.uk.scalix.com (Scalix SMTP Relay 11.4.4.12572) via ESMTP; Thu, 12 Mar 2009 15:44:58 +0000 (GMT) Date: Thu, 12 Mar 2009 15:44:57 +0000 From: Gren Elliot To: CalDAV DevList Message-ID: <49B92DF9.2000106@scalix.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) X-SMP-CT-RefID: str=0001.0A0B0204.49B92DFA.003E,ss=1,fgs=0 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [ietf-caldav] and invalid URL characters X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:45:13 -0000 Hi, Seeking some thoughts or a pointer to a definitive answer, as I can't see an immediate, definitive answer in the WebDAV spec. We sometimes find that a CalDAV client ends up choosing the final element of the path name for a new calendar entry using a PUT similar to : PUT /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/%7BCA-GREN-49B1-233%7D.ics HTTP/1.1 %7B happens to be the way you would encode "{" in a URL and %7D for "}", these characters not being valid in a well formed URL. The same client then later asks for the same entry using : REPORT /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/ HTTP/1.1 ... /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/{CA-GREN-49B1-233}.ics and is not happy when it gets the response : /api/dav/Calendars/Users/Attendee.One@eg.test/Calendar/%7BCA-GREN-49B1-233%7D.ics 8 BEGIN:VCALENDAR CALSCALE:GREGORIAN ... So, my question is, what should go in ? A well formed URL with correct encoding or is it OK (or even more correct?) to translate to the more visually friendly form? Theoretically, in this particular case, the response could follow whatever was used in the request but... Regards, Gren. -- Gren Elliot Senior Software Engineer *Scalix* gren.elliot@scalix.com Tel: +44 1344 381812 www.scalix.com Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 629287841F7 for ; Wed, 11 Mar 2009 07:38:25 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-50 required=4 tests=[AWL=0.788, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ETNsdIW-DeY for ; Wed, 11 Mar 2009 07:38:25 -0700 (PDT) Received: from postalo2.babel.it (81-208-88-105.ip.fastwebnet.it [81.208.88.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 9436C7841F5 for ; Wed, 11 Mar 2009 07:38:24 -0700 (PDT) Received: by postalo2.babel.it (Postfix, from userid 8) id A833811C617; Wed, 11 Mar 2009 15:38:17 +0100 (CET) Received: from ananke.localnet (ananke.dhcp.babel.it [10.0.10.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rpolli) by postalo2.babel.it (Postfix) with ESMTP id 7B6A911C606; Wed, 11 Mar 2009 15:38:16 +0100 (CET) From: Roberto Polli Organization: Babel s.r.l To: Arnaud Quillaud Date: Wed, 11 Mar 2009 15:38:15 +0100 User-Agent: KMail/1.11.0 (Linux/2.6.24-21-generic; KDE/4.2.0; i686; ; ) References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> <200903111314.39176.rpolli@babel.it> <49B7BD68.8010401@sun.com> In-Reply-To: <49B7BD68.8010401@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903111538.15890.rpolli@babel.it> Cc: ietf-caldav@osafoundation.org Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:38:25 -0000 On mercoled=EC 11 marzo 2009 14:32:24 you wrote: > this spec applies to both (and to > any other webdav based protocol e.g. CardDAV). ok, now all is clear ;)=20 > >> For CalDAV we would > >> need to write an extension that would allow a time-range to be included > >> in the report ok. Another way could be returning the sync info in the report query, like= =20 what we do for the etags - but maybe this is not ok for other DAV protocols= (I=20 know caldav only) eg for calendar-query: REPORT /my/dav/path 1234 =2E... I should add the 5678 in the response. A drawback is that we should return the same sync token in each multi-statu= s=20 stanza. > > ... using CREATED|LAST-MOD > Hmm, this is rather dangerous since those iCalendar properties are > controlled by the client, not by the server. I'm not sure caldav servers take dumbly these props from client. I hope to= =20 find some time to go in depth about it. > I think the current spec returns exactly what you want. except for the time-range issue, they seems ok. Thank you very much for your response! Peace, R. =2D-=20 Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo=20 messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20 notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi= o=20 erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto= =20 della legge in materia di protezione dei dati personali." Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id F119979401D for ; Wed, 11 Mar 2009 06:32:51 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-50 required=4 tests=[AWL=1.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqfaq3ZBd7QF for ; Wed, 11 Mar 2009 06:32:47 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 047AC7841ED for ; Wed, 11 Mar 2009 06:32:45 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2BDWUql005828 for ; Wed, 11 Mar 2009 13:32:43 GMT MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KGC00J00E2Z4X00@fe-emea-10.sun.com> for ietf-caldav@osafoundation.org; Wed, 11 Mar 2009 13:32:30 +0000 (GMT) Received: from [129.150.118.101] ([unknown] [129.150.118.101]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KGC0031GGA0HXH0@fe-emea-10.sun.com>; Wed, 11 Mar 2009 13:32:25 +0000 (GMT) Date: Wed, 11 Mar 2009 14:32:24 +0100 From: Arnaud Quillaud In-reply-to: <200903111314.39176.rpolli@babel.it> Sender: Arnaud.Quillaud@Sun.COM To: Roberto Polli Message-id: <49B7BD68.8010401@sun.com> References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> <200903101539.33711.rpolli@babel.it> <8F0CB26631865CED16D04B54@caldav.corp.apple.com> <200903111314.39176.rpolli@babel.it> User-Agent: Thunderbird 2.0.0.19 (X11/20090105) Cc: ietf-caldav@osafoundation.org Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 13:32:52 -0000 Roberto Polli wrote: > On marted́ 10 marzo 2009 15:50:29 you wrote: > >> Note that the current spec is a generic webdav spec. >> > you mean the target is about fasten webdav sync and not caldav one? > > Given that caldav is based on webdav, this spec applies to both (and to any other webdav based protocol e.g. CardDAV). >> You want to get deleted items separately from other changes? >> > yes. I know the issue is quite complex. Afaik sync process needs at least 3 > methods: > 1- get new items since last sync > 2- get updated items since last sync > 3- get deleted items since last sync > > The current spec gives you all 3, except that there is only one method (see http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.2): << The DAV:status element in each DAV:sync-response element is used to indicate how the resource may have changed: A status code of '201 Created' is used to indicate resources that are new. A status code of '200 OK' is used to indicate resources that have changed. A status code of '404 Not Found' is used to indicate resources that have been removed. >> >> For CalDAV we would >> need to write an extension that would allow a time-range to be included in >> the report >> > I miss the point: > * as of now we can find events by time-range with caldav for queries 1) and 2) > using CREATED|LAST-MOD > Hmm, this is rather dangerous since those iCalendar properties are controlled by the client, not by the server. > * as we lack a method for 3) we're forced to use etags mapping (and storing a > table on database with a history between syncs), thus retrieving all events > and retrieve deleted items by difference of sets (stored - retrieved). > * retrieving deleted items directly from server will (partially) solve that > issue.. > I think the current spec returns exactly what you want. > I wish this mail is not too confuse. > > Hope it helps+Peace, > R. > > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 70AD37841F7 for ; Wed, 11 Mar 2009 05:14:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-50 required=4 tests=[AWL=0.857, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4VUXKPsmZYE for ; Wed, 11 Mar 2009 05:14:44 -0700 (PDT) Received: from postalo2.babel.it (81-208-88-105.ip.fastwebnet.it [81.208.88.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 527E57841ED for ; Wed, 11 Mar 2009 05:14:44 -0700 (PDT) Received: by postalo2.babel.it (Postfix, from userid 8) id 6CD4D11C616; Wed, 11 Mar 2009 13:14:39 +0100 (CET) Received: from ananke.localnet (ananke.dhcp.babel.it [10.0.10.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rpolli) by postalo2.babel.it (Postfix) with ESMTP id 4558611C5F6; Wed, 11 Mar 2009 13:14:37 +0100 (CET) From: Roberto Polli Organization: Babel s.r.l To: ietf-caldav@osafoundation.org Date: Wed, 11 Mar 2009 13:14:38 +0100 User-Agent: KMail/1.11.0 (Linux/2.6.24-21-generic; KDE/4.2.0; i686; ; ) References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> <200903101539.33711.rpolli@babel.it> <8F0CB26631865CED16D04B54@caldav.corp.apple.com> In-Reply-To: <8F0CB26631865CED16D04B54@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903111314.39176.rpolli@babel.it> Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 12:14:45 -0000 On marted=EC 10 marzo 2009 15:50:29 you wrote: > Note that the current spec is a generic webdav spec. you mean the target is about fasten webdav sync and not caldav one? > You want to get deleted items separately from other changes? yes. I know the issue is quite complex. Afaik sync process needs at least 3= =20 methods: 1- get new items since last sync 2- get updated items since last sync 3- get deleted items since last sync > For CalDAV we would > need to write an extension that would allow a time-range to be included in > the report I miss the point: * as of now we can find events by time-range with caldav for queries 1) and= 2)=20 using CREATED|LAST-MOD * as we lack a method for 3) we're forced to use etags mapping (and storing= a=20 table on database with a history between syncs), thus retrieving all events= =20 and retrieve deleted items by difference of sets (stored - retrieved). * retrieving deleted items directly from server will (partially) solve that= =20 issue..=20 I wish this mail is not too confuse. Hope it helps+Peace, R. =2D-=20 Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo=20 messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20 notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi= o=20 erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto= =20 della legge in materia di protezione dei dati personali." Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 24F4477D721 for ; Tue, 10 Mar 2009 07:50:36 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-50 required=4 tests=[AWL=0.094, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmNIoiESt6aM for ; Tue, 10 Mar 2009 07:50:34 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id 1809377D719 for ; Tue, 10 Mar 2009 07:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B5C7E1266E64; Tue, 10 Mar 2009 10:50:32 -0400 (EDT) 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 LAX6XZKV+KK9; Tue, 10 Mar 2009 10:50:32 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id F10EE1266E5A; Tue, 10 Mar 2009 10:50:31 -0400 (EDT) Date: Tue, 10 Mar 2009 10:50:29 -0400 From: Cyrus Daboo To: Roberto Polli , ietf-caldav@osafoundation.org Message-ID: <8F0CB26631865CED16D04B54@caldav.corp.apple.com> In-Reply-To: <200903101539.33711.rpolli@babel.it> References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> <200903101539.33711.rpolli@babel.it> 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=827 Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:50:36 -0000 Hi Roberto, --On March 10, 2009 3:39:33 PM +0100 Roberto Polli wrote: >> enquiries from folks interested in implementing something like this now. > afaik, the main issue I got with caldav is about the lack of tombstones. > > during sync process in the funambol-caldav connector I save a map of > (href,etag) to be re-used each time. > > a nice feature would be a getDeletedEvents from server: this would enable > the possibilty to easily synchronize by time-range. You want to get deleted items separately from other changes? Note that the current spec is a generic webdav spec. For CalDAV we would need to write an extension that would allow a time-range to be included in the report so that you can do time-range syncs. That would have to be a CalDAV specific specification though. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id ECB9677D719 for ; Tue, 10 Mar 2009 07:39:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-50 required=4 tests=[AWL=-0.811, BAYES_50=0.001, RDNS_DYNAMIC=0.1] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmcljj+EjHVB for ; Tue, 10 Mar 2009 07:39:15 -0700 (PDT) Received: from postalo2.babel.it (81-208-88-105.ip.fastwebnet.it [81.208.88.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 36F4777D721 for ; Tue, 10 Mar 2009 07:39:15 -0700 (PDT) Received: by postalo2.babel.it (Postfix, from userid 8) id 44D2411C61C; Tue, 10 Mar 2009 15:39:08 +0100 (CET) Received: from ananke.localnet (ananke.dhcp.babel.it [10.0.10.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rpolli) by postalo2.babel.it (Postfix) with ESMTP id 4119C11C606; Tue, 10 Mar 2009 15:39:04 +0100 (CET) From: Roberto Polli Organization: Babel s.r.l To: ietf-caldav@osafoundation.org Date: Tue, 10 Mar 2009 15:39:33 +0100 User-Agent: KMail/1.11.0 (Linux/2.6.24-21-generic; KDE/4.2.0; i686; ; ) References: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> In-Reply-To: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903101539.33711.rpolli@babel.it> Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:39:18 -0000 hi all, On marted=EC 10 marzo 2009 15:09:56 Cyrus Daboo wrote: > enquiries from folks interested in implementing something like this now. afaik, the main issue I got with caldav is about the lack of tombstones. during sync process in the funambol-caldav connector I save a map of=20 (href,etag) to be re-used each time. a nice feature would be a getDeletedEvents from server: this would enable t= he=20 possibilty to easily synchronize by time-range. Peace, R. =2D-=20 Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo=20 messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20 notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi= o=20 erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto= =20 della legge in materia di protezione dei dati personali." Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D92B977D724 for ; Tue, 10 Mar 2009 07:15:50 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-50 required=4 tests=[AWL=0.101, BAYES_00=-2.599] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkpEsEr-t22y for ; Tue, 10 Mar 2009 07:15:50 -0700 (PDT) Received: from mail385c25.carrierzone.com (mail385c25.carrierzone.com [209.235.146.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 20E4377D723 for ; Tue, 10 Mar 2009 07:15:50 -0700 (PDT) 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 n2AEFTf8002945; Tue, 10 Mar 2009 14:15:44 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Mar 2009 09:15:26 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG03102009-091521-7638.MMD@TencoAssembliesInc.local; Tue, 10 Mar 2009 09:15:21 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail363c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n2AECUMU024587 for ; Tue, 10 Mar 2009 10:12:32 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Lh2fH-0006cH-Mf for w3c-dist-auth-dist@listhub.w3.org; Tue, 10 Mar 2009 14:10:39 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lh2fG-0006bd-E6 for w3c-dist-auth@listhub.w3.org; Tue, 10 Mar 2009 14:10:38 +0000 Received: from daboo.name ([151.201.22.177]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lh2f7-0004NB-Ft for w3c-dist-auth@w3.org; Tue, 10 Mar 2009 14:10:37 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E8C90126691C; Tue, 10 Mar 2009 10:10:00 -0400 (EDT) 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 NEmYkro6FpNV; Tue, 10 Mar 2009 10:10:00 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 512D51266915; Tue, 10 Mar 2009 10:09:58 -0400 (EDT) Date: Tue, 10 Mar 2009 10:09:56 -0400 From: Cyrus Daboo To: WebDAV Message-ID: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.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=545 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: maggie.w3.org 1Lh2f7-0004NB-Ft 9bfe2da844e44a11f67464ad03f6a76e X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13079 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: Tue, 10 Mar 2009 14:10:39 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 10 Mar 2009 14:15:26.0931 (UTC) FILETIME=[A8FA6230:01C9A18A] Cc: CalDAV , CardDAV Subject: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:15:51 -0000 Hi folks, I have posted an update for the webdav-sync extension: . This is mostly as refresh of the original -00 with a few references updated. The goal is to restart discussion of this specification as I have been getting quite a few enquiries from folks interested in implementing something like this now. For now let is keep primary discussion of this document on w3c-dist-auth@w3.org. CalDAV and CardDAV have been cc'd as this is of interest in those areas too. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7AE8077D722 for ; Tue, 10 Mar 2009 07:10:05 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-50 required=4 tests=[AWL=-1.218, BAYES_50=0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i0z-Pj47tgu for ; Tue, 10 Mar 2009 07:10:02 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id BB1A877D721 for ; Tue, 10 Mar 2009 07:10:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E8C90126691C; Tue, 10 Mar 2009 10:10:00 -0400 (EDT) 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 NEmYkro6FpNV; Tue, 10 Mar 2009 10:10:00 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 512D51266915; Tue, 10 Mar 2009 10:09:58 -0400 (EDT) Date: Tue, 10 Mar 2009 10:09:56 -0400 From: Cyrus Daboo To: WebDAV Message-ID: <29696E9E8589A72FC19EB4F6@caldav.corp.apple.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=545 Cc: CalDAV , CardDAV Subject: [ietf-caldav] draft-daboo-webdav-sync-01 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:10:05 -0000 Hi folks, I have posted an update for the webdav-sync extension: . This is mostly as refresh of the original -00 with a few references updated. The goal is to restart discussion of this specification as I have been getting quite a few enquiries from folks interested in implementing something like this now. For now let is keep primary discussion of this document on w3c-dist-auth@w3.org. CalDAV and CardDAV have been cc'd as this is of interest in those areas too. -- Cyrus Daboo