Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6B41280D79 for ; Wed, 30 Jul 2008 10:07:08 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C61AD142213 for ; Wed, 30 Jul 2008 10:07:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-50 required=4 tests=[AWL=2.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1LYLzX9wW+d for ; Wed, 30 Jul 2008 10:06:56 -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 laweleka.osafoundation.org (Postfix) with ESMTP id 1569014220C for ; Wed, 30 Jul 2008 10:06:55 -0700 (PDT) Received: from [75.111.37.127] (helo=[192.168.0.216]) by redwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1KOF8a-00079E-6U; Wed, 30 Jul 2008 10:06:56 -0700 Message-ID: <48909FAD.7070100@calconnect.org> Date: Wed, 30 Jul 2008 10:06:53 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------020809050604050306000509" 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 X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-caldav] CalConnect announces second Mobile Interoperability Test Event X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Wed, 30 Jul 2008 17:07:08 -0000 This is a multi-part message in MIME format. --------------020809050604050306000509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit CalConnect has announced that its second Mobile Calendaring Interoperability Test Event will be a standalone event November 4-6, 2008, hosted by Kerio Technologies in Plzen, Czech Republic, and registration is now open for the event. Several CalConnect members have indicated a distinct interest in or plan to participate. Logistics and registration information are available at http://www.calconnect.org/miop0811.shtml. The press release announcing this event can be found at http://www.calconnect.org/publicity/080728 CalConnect Mobile IOP Test Event.doc . As always, this event is open to members and non-members alike; however space will be somewhat limited and early registration is advisable. If you have questions about the event, feel free to post to the calmobileiop-l list (you may join the list at http://www.calconnect.org/calmobileioplist.shtml if you are not already a member), or contact me at the e-mail below. Hope to see you in Plzen! 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 --------------020809050604050306000509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit CalConnect has announced that its second Mobile Calendaring Interoperability Test Event will be a standalone event November 4-6, 2008, hosted by Kerio Technologies in Plzen, Czech Republic, and registration is now open for the event. Several CalConnect members have indicated a distinct interest in or plan to participate. Logistics and registration information are available at http://www.calconnect.org/miop0811.shtml.  The press release announcing this event can be found at http://www.calconnect.org/publicity/080728 CalConnect Mobile IOP Test Event.doc

As always, this event is open to members and non-members alike; however space will be somewhat limited and early registration is advisable.  If you have questions about the event, feel free to post to the calmobileiop-l list (you may join the list at http://www.calconnect.org/calmobileioplist.shtml if you are not already a member), or contact me at the e-mail below.

Hope to see you in Plzen!

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
--------------020809050604050306000509-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8EE3F80CD7 for ; Tue, 29 Jul 2008 08:52:36 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EE40D142207 for ; Tue, 29 Jul 2008 08:52:35 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-50 required=4 tests=[AWL=2.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3VuWa0-tEmO for ; Tue, 29 Jul 2008 08:52:25 -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 laweleka.osafoundation.org (Postfix) with ESMTP id 2A093142204 for ; Tue, 29 Jul 2008 08:52:24 -0700 (PDT) Received: from [75.111.37.127] (helo=[192.168.0.216]) by redwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1KNrUv-00022z-1b; Tue, 29 Jul 2008 08:52:25 -0700 Message-ID: <488F3CC3.6060505@calconnect.org> Date: Tue, 29 Jul 2008 08:52:35 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------020600040009060500030208" 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 X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-caldav] Registration Open for CalConnect XIII: Roundtable XIII and CalConnect Interoperability Test Event, October 6-10, 2008, Sunnyvale, California X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Tue, 29 Jul 2008 15:52:36 -0000 This is a multi-part message in MIME format. --------------020600040009060500030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Registration is now open for CalConnect XIII comprised of Roundtable XIII and a CalConnect Interoperability Test Event*, hosted by Yahoo/Zimbra in Sunnyvale, California on October 6-10, 2008. Please see http://www.calconnect.org/calconnect13.shtml for logistics information and links to registration for the Roundtable and for the CalConnect Interoperability Test Event*. If you are considering participating in the CalConnect Interoperability Test Event*, note that it begins with breakfast on Monday morning the 6th at 08:00 and runs to noon on Wednesday the 8th. As usual the Roundtable will begin with lunch at 12:30 on Wednesday the 8th and run until early Friday afternoon the 10th. 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-September. We will have a *Technology Preview* on Wednesday afternoon at 1600, demonstrating multiple clients and servers participating in Freebusy URL, CalDAV Scheduling, and iSCHEDULE server-server scheduling. (iSCHEDULE is the HTTP-based instance of iTIP being worked on by the iSCHEDULE Technical Committee.) Hope to see you in Sunnyvale in October! Cheers, Dave Thewlis *This CalConnect Interoperability Test Event will be a "regular" IOP test event. The next MOBILE Calendaring Interoperability Test Event will be held in November - see http://www.calconnect.org/miop0811.shtml. (The formal announcement of the Mobile IOP Test Event will be made soon.) -- *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 --------------020600040009060500030208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Registration is now open for CalConnect XIII comprised of Roundtable XIII and a CalConnect Interoperability Test Event*, hosted by Yahoo/Zimbra in Sunnyvale, California on October 6-10, 2008.

Please see http://www.calconnect.org/calconnect13.shtml for logistics information and links to registration for the Roundtable and for the CalConnect Interoperability Test Event*.

If you are considering participating in the CalConnect Interoperability Test Event*, note that it begins with breakfast on Monday morning the 6th at 08:00 and runs to noon on Wednesday the 8th.  As usual the Roundtable will begin with lunch at 12:30 on Wednesday the 8th  and run until early Friday afternoon the 10th. 

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

We will have a Technology Preview on Wednesday afternoon at 1600, demonstrating multiple clients and servers participating in Freebusy URL, CalDAV Scheduling, and iSCHEDULE server-server scheduling.  (iSCHEDULE is the HTTP-based instance of iTIP being worked on by the iSCHEDULE Technical Committee.)

Hope to see you in Sunnyvale in October!

Cheers,

Dave Thewlis


*This CalConnect Interoperability Test Event will be a "regular" IOP test event.  The next MOBILE Calendaring Interoperability Test Event will be held in November - see http://www.calconnect.org/miop0811.shtml.  (The formal announcement of the Mobile IOP Test Event will be made soon.)

--
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
--------------020600040009060500030208-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6FA0A80D0B for ; Sun, 20 Jul 2008 15:17:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EB7DB14221D for ; Sun, 20 Jul 2008 15:17:09 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-50 required=4 tests=[AWL=-1.400, BAYES_00=-2.599, SUBJ_RE_NUM=2.799] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnBTzlRNwBav for ; Sun, 20 Jul 2008 15:16:59 -0700 (PDT) Received: from mail.domain.com (otoupalik2.superhosting.cz [88.86.110.67]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D6CA0142206 for ; Sun, 20 Jul 2008 15:16:58 -0700 (PDT) Received: from emclient.com ([88.86.110.67]) by mail.domain.com (IceWarp 9.3.0 RC6) with ESMTP id ADK89755; Mon, 21 Jul 2008 00:16:55 +0200 Date: Mon, 21 Jul 2008 00:16:55 +0200 To: "Cyrus Daboo" , "ietf-caldav@osafoundation.org" , "Arnaud Quillaud" From: "Filip Navara" Subject: Re[2]: [Ietf-caldav] calendar-query REPORT depth handling? Message-ID: X-Mailer: IceWarp Mailer 9.3.0 RC6 X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sun, 20 Jul 2008 22:17:10 -0000 > -----Original Message----- > From: Cyrus Daboo > To: Filip Navara , ietf-caldav@osafoundation.org > Cc: Arnaud Quillaud > Date: 07/20/08 23:29 > Subject: Re: [Ietf-caldav] calendar-query REPORT depth handling? > > Hi Filip, > > --On July 20, 2008 10:19:15 PM +0200 Filip Navara > wrote: > > > I would to know how the Depth header on calendar-query REPORTs should be > > handled. CalDAVTester sends no Depth header and expects the REPORT to > > apply on the resources inside the collection. My reading of RFC 4791 and > > RFC 3253 (section 3.6) says that if no Depth header is specified then > > Depth: 0 is assumed. According to my understanding I would expect Depth: > > 0 requests to return empty responses and not match any calendar > > resources. This assumption is aided by the fact that all RFC 4791 > > examples explicitely specify Depth: 1 header. So, should Depth: 0 match > > the resources inside the collection or not? > > As you noted, in RFC 4791 no Depth header means Depth:0, so CalDAVTester's > behavior is wrong. Please file a bug on calendarserver.org for CalDAVTester > and I will get that fixed. In fact I will change the current tests to use > Depth:1 and then add a test that explicitly uses Depth:0 on a calendar > collection and test that nothing comes back. > > -- > Cyrus Daboo https://trac.calendarserver.org/ticket/297 Thanks for quick answer, Filip Navara Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0A3EA80C4A for ; Sun, 20 Jul 2008 14:30:01 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 86092142217 for ; Sun, 20 Jul 2008 14:30:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-50 required=4 tests=[AWL=0.028, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWM+n3D9k9nI for ; Sun, 20 Jul 2008 14:29:48 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE263142215 for ; Sun, 20 Jul 2008 14:29:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6E3D6A7878F; Sun, 20 Jul 2008 17:29:47 -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 ltd-6g7lLRhy; Sun, 20 Jul 2008 17:29:47 -0400 (EDT) Received: from [10.0.1.2] (unknown [151.201.22.177]) by daboo.name (Postfix) with ESMTP id 477B8A78788; Sun, 20 Jul 2008 17:29:46 -0400 (EDT) Date: Sun, 20 Jul 2008 17:29:44 -0400 From: Cyrus Daboo To: Filip Navara , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] calendar-query REPORT depth handling? Message-ID: <6A7437BF1B63184EF66FA5A5@ninevah-3.local> In-Reply-To: <690b03db704883aafcfe544e3c0d45f1@emclient.com> References: <690b03db704883aafcfe544e3c0d45f1@emclient.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 Cc: Arnaud Quillaud X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sun, 20 Jul 2008 21:30:01 -0000 Hi Filip, --On July 20, 2008 10:19:15 PM +0200 Filip Navara wrote: > I would to know how the Depth header on calendar-query REPORTs should be > handled. CalDAVTester sends no Depth header and expects the REPORT to > apply on the resources inside the collection. My reading of RFC 4791 and > RFC 3253 (section 3.6) says that if no Depth header is specified then > Depth: 0 is assumed. According to my understanding I would expect Depth: > 0 requests to return empty responses and not match any calendar > resources. This assumption is aided by the fact that all RFC 4791 > examples explicitely specify Depth: 1 header. So, should Depth: 0 match > the resources inside the collection or not? As you noted, in RFC 4791 no Depth header means Depth:0, so CalDAVTester's behavior is wrong. Please file a bug on calendarserver.org for CalDAVTester and I will get that fixed. In fact I will change the current tests to use Depth:1 and then add a test that explicitly uses Depth:0 on a calendar collection and test that nothing comes back. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 06A0C80D0B for ; Sun, 20 Jul 2008 13:19:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7FE46142213 for ; Sun, 20 Jul 2008 13:19:29 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id walxkbT-CvCN for ; Sun, 20 Jul 2008 13:19:23 -0700 (PDT) Received: from mail.domain.com (otoupalik2.superhosting.cz [88.86.110.67]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D46B6142210 for ; Sun, 20 Jul 2008 13:19:21 -0700 (PDT) Received: from emclient.com ([88.86.110.67]) by mail.domain.com (IceWarp 9.3.0 RC6) with ESMTP id ABN25815; Sun, 20 Jul 2008 22:19:15 +0200 Date: Sun, 20 Jul 2008 22:19:15 +0200 To: "ietf-caldav@osafoundation.org" From: "Filip Navara" Message-ID: <690b03db704883aafcfe544e3c0d45f1@emclient.com> X-Mailer: IceWarp Mailer 9.3.0 RC6 X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Cc: Arnaud Quillaud Subject: [Ietf-caldav] calendar-query REPORT depth handling? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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: Sun, 20 Jul 2008 20:19:30 -0000 Hello! I would to know how the Depth header on calendar-query REPORTs should be handled. CalDAVTester sends no Depth header and expects the REPORT to apply on the resources inside the collection. My reading of RFC 4791 and RFC 3253 (section 3.6) says that if no Depth header is specified then Depth: 0 is assumed. According to my understanding I would expect Depth: 0 requests to return empty responses and not match any calendar resources. This assumption is aided by the fact that all RFC 4791 examples explicitely specify Depth: 1 header. So, should Depth: 0 match the resources inside the collection or not? Best regards, Filip Navara Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 86E8A80DBA for ; Thu, 17 Jul 2008 08:19:09 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1C30F14222B for ; Thu, 17 Jul 2008 08:19:09 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-50 required=4 tests=[AWL=0.076, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn08B++jI2I5 for ; Thu, 17 Jul 2008 08:19:01 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 83007142223 for ; Thu, 17 Jul 2008 08:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4FBEDA5915B; Thu, 17 Jul 2008 11:19:01 -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 eftrfvi1ReqD; Thu, 17 Jul 2008 11:19:01 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id F211DA59154; Thu, 17 Jul 2008 11:18:59 -0400 (EDT) Date: Thu, 17 Jul 2008 11:18:57 -0400 From: Cyrus Daboo To: Daniel Gomez Brito , ietf-caldav@osafoundation.org Subject: RE: [Ietf-caldav] Question about time range filtering. Message-ID: <85F2FBA480D5E1AE670A1FE5@caldav.corp.apple.com> In-Reply-To: <98357389BF0844489B5D6FD186C720487C5DFA@GMVMAIL1.gmv.es> References: <98357389BF0844489B5D6FD186C720487C5CEE@GMVMAIL1.gmv.es> <0D0DB91727E16E31908DD3AD@caldav.corp.apple.com> <98357389BF0844489B5D6FD186C720487C5DFA@GMVMAIL1.gmv.es> 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 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jul 2008 15:19:09 -0000 Hi Daniel, --On July 17, 2008 4:52:49 PM +0200 Daniel Gomez Brito wrote: > Suppose I do a time-range query that spawns the second Monday. If I'm > not wrong, the response should be empty because the instance has been > rescheduled to a Tuesday. > I'm guessing the process is like this: > The server checks the master component, realizes there's an overlapping > instance and then examines the overridden components to test if the > overlapping instance has been overridden. If that's the case, then the > server tests whether the overridden instance impacts the time range and > acts upon so. > In this example, the matching instance has been overridden and it > doesn't overlap the time interval so the server drops the master > component because its match is not valid and therefore returns an empty > response. > Is this right? In the case where there are no overlapping instances at all, and thus no need to return the master, then yes the result can legitimately be empty even if an overridden instance's original time period was within the time-range. I guess the spec could be more explicit on that one case. The algorithm is: if (any instance overlaps the time-range) then return (the master instance, any overridden instances occurring in the time-range, any overridden instances that originally occurred in the time-range) else return (empty result) -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A98A80DBF for ; Thu, 17 Jul 2008 07:52:48 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E418D142223 for ; Thu, 17 Jul 2008 07:52:47 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkm3Htvw8WSm for ; Thu, 17 Jul 2008 07:52:40 -0700 (PDT) Received: from mx1.gmv.es (mx1.gmv.es [212.0.110.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9694A14222B for ; Thu, 17 Jul 2008 07:52:39 -0700 (PDT) Received: from webmail2.gmv.es (caronte [212.0.110.2]) by mx1.gmv.es (8.14.1/8.14.1/mx1.gmv.es - Win 3.11 under MAC OS mx1.gmv.es) with ESMTP id m6HEqU8O025540; Thu, 17 Jul 2008 16:52:30 +0200 Received: from GMVMAIL1.gmv.es ([172.22.2.21]) by webmail2.gmv.es with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 16:52:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-caldav] Question about time range filtering. Date: Thu, 17 Jul 2008 16:52:49 +0200 Message-ID: <98357389BF0844489B5D6FD186C720487C5DFA@GMVMAIL1.gmv.es> In-Reply-To: <0D0DB91727E16E31908DD3AD@caldav.corp.apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] Question about time range filtering. Thread-Index: AcjoESf1LWwbNdFIRfycOSOzWicdHwAC00OQ References: <98357389BF0844489B5D6FD186C720487C5CEE@GMVMAIL1.gmv.es> <0D0DB91727E16E31908DD3AD@caldav.corp.apple.com> From: "Daniel Gomez Brito" To: "Cyrus Daboo" , X-OriginalArrivalTime: 17 Jul 2008 14:52:41.0147 (UTC) FILETIME=[C32FB0B0:01C8E81C] Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 212.0.110.25 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jul 2008 14:52:48 -0000 Hello Cyrus,=20 Thank you for the quick response, it's nice to see the list is alive. Suppose I do a time-range query that spawns the second Monday. If I'm not wrong, the response should be empty because the instance has been rescheduled to a Tuesday.=20 I'm guessing the process is like this: The server checks the master component, realizes there's an overlapping instance and then examines the overridden components to test if the overlapping instance has been overridden. If that's the case, then the server tests whether the overridden instance impacts the time range and acts upon so.=20 In this example, the matching instance has been overridden and it doesn't overlap the time interval so the server drops the master component because its match is not valid and therefore returns an empty response. Is this right? > -----Mensaje original----- > De: Cyrus Daboo [mailto:cyrus@daboo.name] > Enviado el: jueves, 17 de julio de 2008 15:29 > Para: Daniel Gomez Brito; ietf-caldav@osafoundation.org > Asunto: Re: [Ietf-caldav] Question about time range filtering. >=20 > Hi Daniel, >=20 > --On July 17, 2008 11:03:17 AM +0200 Daniel Gomez Brito > wrote: >=20 > > If I have not misunderstood the above paragraph, it means that if the > > time interval overlaps the original start and end times of an overridden > > instance, that instance should be returned in the response. Am I right? > > If so, what's the rationale behind this? If that instance has been > > rescheduled, its old time slot should be now empty and therefore I > should > > receive an empty response. Why not? >=20 > The description in the spec is correct. Here is an example that shows why: >=20 > Let's say you have a weekly recurring meeting every Monday. >=20 > One instance is shifted to a Tuesday >=20 > Now you do a time-range query for 8 days starting on a Monday and > extending > to the week of the overridden instance. >=20 > The server is required to return the master component (the one with the > RRULE) to cover the first Monday in the time-range. >=20 > However, if that is all it did, then the client would see the weekly RRULE > and assume that there is an instance on the second Monday, which would be > wrong. >=20 > Instead the server has to return the overridden instance as well and that > correctly shows the client that there is no second Monday instance. >=20 > -- > Cyrus Daboo ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la=20 Informacion siendo para uso exclusivo del destinatario, quedando=20 prohibida su divulgacion copia o distribucion a terceros sin la=20 autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.= =20 Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential=20 information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ Return-Path: <> X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4025880DBF for ; Thu, 17 Jul 2008 07:06:20 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA11A14223F for ; Thu, 17 Jul 2008 07:06:19 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6UJZ9NTFzvZ for ; Thu, 17 Jul 2008 07:06:08 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BDE45142223 for ; Thu, 17 Jul 2008 07:06:07 -0700 (PDT) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m6HE65wT008164 for ; Thu, 17 Jul 2008 08:06:06 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m6GHlUCE003650 for ; Thu, 17 Jul 2008 08:06:05 -0600 Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3710035781216303458; Thu, 17 Jul 2008 07:04:18 -0700 MIME-Version: 1.0 Message-ID: <51ff6ca3-cbbc-4f2e-abf5-6b2985a3e6d9@default> Date: Thu, 17 Jul 2008 07:04:17 -0700 (PDT) From: PATRICE.SCATTOLIN@ORACLE.COM To: ietf-caldav@osafoundation.org Subject: New task: [Ietf-caldav] Question about time range filtering.. Content-Type: multipart/mixed; boundary="__12163034578015710acsmt700.oracle.com" X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jul 2008 14:06:20 -0000 --__12163034578015710acsmt700.oracle.com Content-Type: multipart/alternative; boundary="__12163034579555711acsmt700.oracle.com" --__12163034579555711acsmt700.oracle.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Title: [Ietf-caldav] Question about time range filtering. Organizer: PATRICE.SCATTOLIN@ORACLE.COM Start: Thu, Jul 17, 2008 11:00 AM EDT Due:=20 Priority: Medium Participants: ietf-caldav@osafoundation.org; PATRICE.SCATTOLIN@ORACLE.COM; = Daniel Gomez Brito Description:=20 Hi Daniel, --On July 17, 2008 11:03:17 AM +0200 Daniel Gomez Brito = =20 wrote: If I have not misunderstood the above paragraph, it means that if the time interval overlaps the original start and end times of an overridden instance, that instance should be returned in the response. Am I right? If so, what=E2=80=99s the rationale behind this? If that instance has been rescheduled, its old time slot should be now empty and therefore I should receive an empty response. Why not? The description in the spec is correct. Here is an example that shows why: Let's say you have a weekly recurring meeting every Monday. One instance is shifted to a Tuesday Now you do a time-range query for 8 days starting on a Monday and extending= =20 to the week of the overridden instance. The server is required to return the master component (the one with the=20 RRULE) to cover the first Monday in the time-range. However, if that is all it did, then the client would see the weekly RRULE= =20 and assume that there is an instance on the second Monday, which would be= =20 wrong. Instead the server has to return the overridden instance as well and that= =20 correctly shows the client that there is no second Monday instance. -- Cyrus Daboo _______________________________________________ Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav --__12163034579555711acsmt700.oracle.com Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Notification
Title:[Ietf-caldav] Question about time rang= e filtering.
Organizer:PATRICE.SCATTOLIN@ORACLE.COM
Start:Thu, Jul 17, 2008 11:00 AM EDT
Due:
Priority:Medium
Participants:
i= etf-caldav@osafoundation.org; PATRICE.SCATTOLIN@ORACLE.COM; Daniel Gomez Br= ito
Description:
Hi Daniel,

--On July 17, 2008 11:03:17 AM +0200 Daniel Gomez Brito <= br/> wrote:

If I have not misunderstood the above paragraph, it means that if the
time interval overlaps the original start and end times of an overridden instance, that instance should be returned in the response. Am I right?
If so, what=E2=80=99s the rationale behind this? If that instance has been<= br/> rescheduled, its old time slot should be now empty and therefore I should receive an empty response. Why not?

The description in the spec is correct. Here is an example that shows why:<= br/>
Let's say you have a weekly recurring meeting every Monday.

One instance is shifted to a Tuesday

Now you do a time-range query for 8 days starting on a Monday and extending=
to the week of the overridden instance.

The server is required to return the master component (the one with the RRULE) to cover the first Monday in the time-range.

However, if that is all it did, then the client would see the weekly RRULE =
and assume that there is an instance on the second Monday, which would be <= br/> wrong.

Instead the server has to return the overridden instance as well and that <= br/> correctly shows the client that there is no second Monday instance.

-- Cyrus Daboo

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org
See http://ietf.webdav.org/calda= v/ for more CalDAV resources
htt= p://lists.osafoundation.org/mailman/listinfo/ietf-caldav
--__12163034579555711acsmt700.oracle.com-- --__12163034578015710acsmt700.oracle.com Content-Type: text/calendar; charset=UTF-8; name="event.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="event.ics" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ORACLE//NONSGML Beehive Time Management - //EN X-ORACLE-ID:334B:3BF0:todo:1A585EF1CC7943B69571D9B8D8463EFC000000000F10 METHOD:PUBLISH BEGIN:VTODO CLASS:CONFIDENTIAL SUMMARY:[Ietf-caldav] Question about time range filtering. DTSTAMP:20080717T140411Z PRIORITY:5 SEQUENCE:0 UID:e2a035d4-f5d8-4dcf-b811-92c9886e41b1 STATUS:IN-PROCESS X-ORACLE-INTERNAL-ORGANIZER:mailto:PATRICE.SCATTOLIN@ORACLE.COM DTSTART:20080717T150000Z LAST-MODIFIED:20080717T140411Z ORGANIZER;X-ORACLE-ID=3D"334B:3BF0:user:97F82F8445F94BE8BCEA06D446E9276A000 0000002D5";CN=3DPatrice Scattolin:mailto:PATRICE.SCATTOLIN@ORACLE.COM X-ORACLE-ID:334B:3BF0:todo:1A585EF1CC7943B69571D9B8D8463EFC000000000F10 DESCRIPTION:Hi Daniel\,\n\n--On July 17\, 2008 11:03:17 AM +0200 Daniel G omez Brito \nwrote:\n\nIf I have not misunderstood the above paragraph\, it means that if the\ntime interval overlaps the orig inal start and end times of an overridden\ninstance\, that instance shou ld be returned in the response. Am I right?\nIf so\, what=E2=80=99s the ra= tion ale behind this? If that instance has been\nrescheduled\, its old time s lot should be now empty and therefore I should\nreceive an empty respons e. Why not?\n\nThe description in the spec is correct. Here is an exampl e that shows why:\n\nLet's say you have a weekly recurring meeting every Monday.\n\nOne instance is shifted to a Tuesday\n\nNow you do a time-ra nge query for 8 days starting on a Monday and extending \nto the week of the overridden instance.\n\nThe server is required to return the master component (the one with the \nRRULE) to cover the first Monday in the t ime-range.\n\nHowever\, if that is all it did\, then the client would se e the weekly RRULE \nand assume that there is an instance on the second=20 Monday\, which would be \nwrong.\n\nInstead the server has to return the overridden instance as well and that \ncorrectly shows the client that=20 there is no second Monday instance.\n\n-- Cyrus Daboo\n\n_______________ ________________________________\nIetf-caldav mailing list -- Ietf-calda v@osafoundation.org\nSee http://ietf.webdav.org/caldav/ for more CalDAV=20 resources\nhttp://lists.osafoundation.org/mailman/listinfo/ietf-caldav\n CREATED:20080717T140411Z END:VTODO END:VCALENDAR --__12163034578015710acsmt700.oracle.com-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7B01F80DA6 for ; Thu, 17 Jul 2008 06:29:27 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 10F6C14223F for ; Thu, 17 Jul 2008 06:29:27 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-50 required=4 tests=[AWL=-0.624, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOZofW831nth for ; Thu, 17 Jul 2008 06:29:20 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 82B0714222B for ; Thu, 17 Jul 2008 06:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 12ADEA582F3; Thu, 17 Jul 2008 09:29:20 -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 Y5z8WugR9zwJ; Thu, 17 Jul 2008 09:29:19 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id B3774A582EC; Thu, 17 Jul 2008 09:29:18 -0400 (EDT) Date: Thu, 17 Jul 2008 09:29:16 -0400 From: Cyrus Daboo To: Daniel Gomez Brito , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Question about time range filtering. Message-ID: <0D0DB91727E16E31908DD3AD@caldav.corp.apple.com> In-Reply-To: <98357389BF0844489B5D6FD186C720487C5CEE@GMVMAIL1.gmv.es> References: <98357389BF0844489B5D6FD186C720487C5CEE@GMVMAIL1.gmv.es> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jul 2008 13:29:27 -0000 Hi Daniel, --On July 17, 2008 11:03:17 AM +0200 Daniel Gomez Brito =20 wrote: > If I have not misunderstood the above paragraph, it means that if the > time interval overlaps the original start and end times of an overridden > instance, that instance should be returned in the response. Am I right? > If so, what=E2=80=99s the rationale behind this? If that instance has = been > rescheduled, its old time slot should be now empty and therefore I should > receive an empty response. Why not? The description in the spec is correct. Here is an example that shows why: Let's say you have a weekly recurring meeting every Monday. One instance is shifted to a Tuesday Now you do a time-range query for 8 days starting on a Monday and extending = to the week of the overridden instance. The server is required to return the master component (the one with the=20 RRULE) to cover the first Monday in the time-range. However, if that is all it did, then the client would see the weekly RRULE=20 and assume that there is an instance on the second Monday, which would be=20 wrong. Instead the server has to return the overridden instance as well and that=20 correctly shows the client that there is no second Monday instance. --=20 Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8E49080DBC for ; Thu, 17 Jul 2008 02:03:23 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 24EF3142217 for ; Thu, 17 Jul 2008 02:03:23 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT5paA8MqZb3 for ; Thu, 17 Jul 2008 02:03:08 -0700 (PDT) Received: from mx1.gmv.es (mx1.gmv.es [212.0.110.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AFA0A142215 for ; Thu, 17 Jul 2008 02:03:07 -0700 (PDT) Received: from webmail2.gmv.es (caronte [212.0.110.2]) by mx1.gmv.es (8.14.1/8.14.1/mx1.gmv.es - Win 3.11 under MAC OS mx1.gmv.es) with ESMTP id m6H92wV6031974 for ; Thu, 17 Jul 2008 11:02:58 +0200 Received: from GMVMAIL1.gmv.es ([172.22.2.21]) by webmail2.gmv.es with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 11:03:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E7EB.F0CE992F" Date: Thu, 17 Jul 2008 11:03:17 +0200 Message-ID: <98357389BF0844489B5D6FD186C720487C5CEE@GMVMAIL1.gmv.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about time range filtering. Thread-Index: Acjn6/QeNGAnyjnGT5ylrpdyC9rscQ== From: "Daniel Gomez Brito" To: X-OriginalArrivalTime: 17 Jul 2008 09:03:12.0444 (UTC) FILETIME=[F0DD87C0:01C8E7EB] X-Scanned-By: MIMEDefang 2.64 on 212.0.110.25 Subject: [Ietf-caldav] Question about time range filtering. X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jul 2008 09:03:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E7EB.F0CE992F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello,=20 I have some doubts about the expected behaviour of calendar-query report with a time range filter when dealing with overridden instances of a recurrent event. =20 According to the RFC (http://tools.ietf.org/html/rfc4791#section-7.6 ): {{{ A CalDAV client that is only interested in the recurrence instances that overlap a specified time range can request to receive only the "master component", along with the "overridden components" that impact the specified time range, and thus, limit the data returned by the server (see CALDAV:limit-recurrence-set in Section 9.6.6). An overridden component impacts a time range if its current start and end times overlap the time range, or if the original start and end times -- the ones that would have been used if the instance were not overridden -- overlap the time range, or if it affects other instances that overlap the time range. }}} =20 If I have not misunderstood the above paragraph, it means that if the time interval overlaps the original start and end times of an overridden instance, that instance should be returned in the response. Am I right? If so, what's the rationale behind this? If that instance has been rescheduled, its old time slot should be now empty and therefore I should receive an empty response. Why not? =20 Can anybody shed some light on this? =20 Thanks in advance. =20 ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la=20 Informacion siendo para uso exclusivo del destinatario, quedando=20 prohibida su divulgacion copia o distribucion a terceros sin la=20 autorizacion expresa del remitente. Si Vd. ha recibido este mensaje=20 erroneamente, se ruega lo notifique al remitente y proceda a su borrado.= =20 Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential=20 information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ ------_=_NextPart_001_01C8E7EB.F0CE992F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hello,

I have some doubts about the expected behaviour o= f calendar-query report with a time range filter when dealing with overridden instances of a= recurrent event.

&nbs= p;

According= to the RFC (= http://tools.ietf.org/html/rfc4791#section-7.6):

{{{<= /o:p>

 &nb= sp; A CalDAV client that is only interested in the recurrence instances

 &nb= sp; that overlap a specified time range can request to receive only the

 &nb= sp; "master component", along with the "overridden components" that=

 &nb= sp; impact the specified time range, and thus, limit the data returned by

 &nb= sp; the server (see CALDAV:limit-recurrence-set in Section 9.6.6).  An

 &nb= sp; overridden component impacts a time range if its current start and

 &nb= sp; end times overlap the time range, or if the original start and end

 &nb= sp; times -- the ones that would have been used if the instance were not

 &nb= sp; overridden -- overlap the time range, or if it affects other<= /p>

 &nb= sp; instances that overlap the time range.

}}}<= /font>

 

If I have= not misunderstood the above paragraph, it means that if the time interval overl= aps the original start and end times of an overridden instance, that instance should be returned in the response. Am I right? If so, what’s the rationale behind this? If that instance has been rescheduled, its old time = slot should be now empty and therefore I should receive an empty response. Why n= ot?

&nbs= p;

Can anybo= dy shed some light on this?

&nbs= p;

Thanks in= advance.

 


Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informaci=F3n clasificada por su emisor como confidencial en el marco de su Sistema de Gesti=F3n de Seguridad de la Informaci=F3n siendo para uso exclu= sivo del destinatario, quedando prohibida su divulgaci=F3n copia o distribuci=F3= n a terceros sin la autorizaci=F3n expresa del remitente. Si Vd. ha recibido es= te mensaje err=F3neamente, se ruega lo notifique al remitente y proceda a su b= orrado. Gracias por su colaboraci=F3n.
This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you ha= ve received this transmission in error, please notify the sender immediately a= nd delete it.

------_=_NextPart_001_01C8E7EB.F0CE992F--