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 792137F624; Thu, 23 Feb 2006 19:06:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6AC341422B0; Thu, 23 Feb 2006 19:06:48 -0800 (PST) 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 21756-05; Thu, 23 Feb 2006 19:06:47 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AA8761422AC; Thu, 23 Feb 2006 19:06:47 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1O36kIO007068; Thu, 23 Feb 2006 21:06:46 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k1O36jiB010760; Thu, 23 Feb 2006 20:06:45 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-97-75.vpn.oracle.com [141.144.97.75]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1O36ar4010721; Thu, 23 Feb 2006 20:06:39 -0700 Message-ID: <43FE7841.5040506@oracle.com> Date: Thu, 23 Feb 2006 22:06:41 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList , Calsify WG , WebDAV WG Content-Type: multipart/mixed; boundary="------------070600070206030600050804" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-10.txt] 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: Fri, 24 Feb 2006 03:06:48 -0000 This is a multi-part message in MIME format. --------------070600070206030600050804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-dusseault-caldav-10.txt Date: Thu, 23 Feb 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendaring Extensions to WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-10.txt Pages : 94 Date : 2006-2-23 This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dusseault-caldav-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dusseault-caldav-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070600070206030600050804 Content-Type: Message/External-body; name="draft-dusseault-caldav-10.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dusseault-caldav-10.txt" Content-Type: text/plain Content-ID: <2006-2-23145218.I-D@ietf.org> --------------070600070206030600050804 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BDESRUIS/LOCALS%7E1/TEMP/nsmail-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BDESRUIS/LOCALS%7E1/TEMP/nsmail-1.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------070600070206030600050804-- 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 03BD37F526 for ; Thu, 23 Feb 2006 07:22:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E1D0E1422A9 for ; Thu, 23 Feb 2006 07:22:03 -0800 (PST) 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 21724-06 for ; Thu, 23 Feb 2006 07:22:03 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 05130142276 for ; Thu, 23 Feb 2006 07:22:02 -0800 (PST) Received: (qmail invoked by alias); 23 Feb 2006 15:22:01 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 23 Feb 2006 16:22:01 +0100 X-Authenticated: #1915285 Message-ID: <43FDD2DE.9010005@gmx.de> Date: Thu, 23 Feb 2006 16:21:02 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernard Desruisseaux References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> <43FDCDC3.3000004@oracle.com> In-Reply-To: <43FDCDC3.3000004@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify WG , WebDAV WG , Ted Hardie , CalDAV DevList Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call 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, 23 Feb 2006 15:22:04 -0000 Bernard Desruisseaux wrote: > > Julian, > > Thanks for your feedback! The idea to do an informal last call is > exactly to get this kind of feedback. :-) > > Lisa, Cyrus and I already discussed about the possibility of making > reference to RFC2518bis. We will consider your feedback on this issue. Well, and that's the problem. To provide that kind of feedback, I'll have to review the spec, and that's the one thing I really don't have time for during RFC2518bis' last call :-) > Meanwhile, it would be appreciated if you could elaborate some more on > the implication of referencing RFC2518bis instead of RFC2518 in CalDAV. > > Thanks, > Bernard > > P.S. I have printed rfc2518bis and will take the time to review it! Great! Best regards, Julian 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 D4E357F645; Thu, 23 Feb 2006 07:01:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C64651422AA; Thu, 23 Feb 2006 07:01:00 -0800 (PST) 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 16825-05; Thu, 23 Feb 2006 07:01:00 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E1E9A1422A9; Thu, 23 Feb 2006 07:00:59 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k1NF0swE026961; Thu, 23 Feb 2006 08:00:54 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k1NF0sfS023892; Thu, 23 Feb 2006 08:00:54 -0700 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1NF0lbv023847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 23 Feb 2006 08:00:47 -0700 Message-ID: <43FDCDC3.3000004@oracle.com> Date: Thu, 23 Feb 2006 09:59:15 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke References: <43FD273E.3020702@oracle.com> <43FD6D6F.3030308@gmx.de> In-Reply-To: <43FD6D6F.3030308@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: Calsify WG , WebDAV WG , Ted Hardie , CalDAV DevList Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call 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, 23 Feb 2006 15:01:01 -0000 Julian, Thanks for your feedback! The idea to do an informal last call is exactly to get this kind of feedback. :-) Lisa, Cyrus and I already discussed about the possibility of making reference to RFC2518bis. We will consider your feedback on this issue. Meanwhile, it would be appreciated if you could elaborate some more on the implication of referencing RFC2518bis instead of RFC2518 in CalDAV. Thanks, Bernard P.S. I have printed rfc2518bis and will take the time to review it! Julian Reschke wrote: > Hm. > > It strikes me as a particularly bad idea to last-call a draft that > builds on top of RFC2518, while, at the same time, RFC2518bis is last > called. > > Reasons: > > - you will likely have to update the spec to refer to rfc2518bis instead > anyway, and this frequently is more work than just updating a single > reference (in particular, the stuff about ETags in section 5.3.4 is > partly in conflict with RFC2616, and likely to be in conflict with the > separate document about ETag handling in HTTP the IETF has decided to > produce). > > - the group of people who can give constructive feedback to CalDAV > definitively overlaps with those who can review RFC2518bis. > > Therefore I strongly suggest not to last-call anything WebDAV related > before RFC2518bis' last call has ended. > > Best regards, Julian > > > Bernard Desruisseaux wrote: > >> >> We submitted CalDAV draft -10 to the IETF yesterday. The draft has >> not been officially announced yet, but it is already available for >> you to review at the following URL: >> >> http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt >> >> We would like to submit the CalDAV draft for Last Call in time for >> the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do >> so, we would like to get as much feedback as possible from the >> participants of the "ietf-caldav" mailing list as well as from the >> members of the WebDAV and Calsify Working Groups. >> >> Once officially announced the draft should be available at: >> >> http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt >> >> Previous versions of the draft are available at: >> >> http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ >> >> Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: >> >> mailto:ietf-caldav@osafoundation.org >> >> which is archived at: >> >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav >> >> Reports on the 4 CalDAV Interoperability Events organized by the >> Calendaring and Scheduling Consortium (CalConnect) can be found at: >> >> http://www.calconnect.org/ioppast.html >> >> Finally, additional information on CalDAV can also be found at: >> >> http://ietf.webdav.org/caldav/ >> >> Please review draft -10 and send us feedback/questions/comments. >> >> Thanks for you help! >> >> Cheers, >> Bernard >> >> -- >> >> C.1. Changes in -10 >> >> a. Added new section about support for X- items when storing data. >> >> b. Added new precondition to allow servers to reject queries on >> unsupported X- items, and a new example. >> >> c. Added new text about always supporting X- in calendar-data. >> >> d. Created new section for PUT, COPY and MOVE preconditions. >> >> e. Report examples re-done with full listing of calendar data in >> Appendix. >> >> f. Removed description of using UID, SUMMARY etc as resource name. >> >> g. Indicate that calendar object resource may contain only >> overridden components. >> >> h. Add security consideration about not expose details in resource >> names. >> >> i. Add constraint that free-busy-query can only be run on a >> collection. >> >> j. Add preconditions for calendar-timezone property/elements in >> MKCALENDAR, PROPPATCH and calendar-query REPORT. >> >> k. Fix principal-match example. >> >> >> >> > > 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 EABCE7F5A1 for ; Thu, 23 Feb 2006 00:09:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DBBD0142275 for ; Thu, 23 Feb 2006 00:09:07 -0800 (PST) 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 17334-05 for ; Thu, 23 Feb 2006 00:09:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id D324B142273 for ; Thu, 23 Feb 2006 00:09:05 -0800 (PST) Received: (qmail invoked by alias); 23 Feb 2006 08:09:04 -0000 Received: from p508FB53A.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.181.58] by mail.gmx.net (mp029) with SMTP; 23 Feb 2006 09:09:04 +0100 X-Authenticated: #1915285 Message-ID: <43FD6D6F.3030308@gmx.de> Date: Thu, 23 Feb 2006 09:08:15 +0100 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernard Desruisseaux References: <43FD273E.3020702@oracle.com> In-Reply-To: <43FD273E.3020702@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO X-Spam-Level: Cc: Calsify WG , WebDAV WG , Ted Hardie , CalDAV DevList Subject: [Ietf-caldav] Re: CalDAV draft Informal Last-Call 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, 23 Feb 2006 08:09:08 -0000 Hm. It strikes me as a particularly bad idea to last-call a draft that builds on top of RFC2518, while, at the same time, RFC2518bis is last called. Reasons: - you will likely have to update the spec to refer to rfc2518bis instead anyway, and this frequently is more work than just updating a single reference (in particular, the stuff about ETags in section 5.3.4 is partly in conflict with RFC2616, and likely to be in conflict with the separate document about ETag handling in HTTP the IETF has decided to produce). - the group of people who can give constructive feedback to CalDAV definitively overlaps with those who can review RFC2518bis. Therefore I strongly suggest not to last-call anything WebDAV related before RFC2518bis' last call has ended. Best regards, Julian Bernard Desruisseaux wrote: > > We submitted CalDAV draft -10 to the IETF yesterday. The draft has > not been officially announced yet, but it is already available for > you to review at the following URL: > > http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt > > We would like to submit the CalDAV draft for Last Call in time for > the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do > so, we would like to get as much feedback as possible from the > participants of the "ietf-caldav" mailing list as well as from the > members of the WebDAV and Calsify Working Groups. > > Once officially announced the draft should be available at: > > http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt > > Previous versions of the draft are available at: > > http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ > > Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: > > mailto:ietf-caldav@osafoundation.org > > which is archived at: > > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Reports on the 4 CalDAV Interoperability Events organized by the > Calendaring and Scheduling Consortium (CalConnect) can be found at: > > http://www.calconnect.org/ioppast.html > > Finally, additional information on CalDAV can also be found at: > > http://ietf.webdav.org/caldav/ > > Please review draft -10 and send us feedback/questions/comments. > > Thanks for you help! > > Cheers, > Bernard > > -- > > C.1. Changes in -10 > > a. Added new section about support for X- items when storing data. > > b. Added new precondition to allow servers to reject queries on > unsupported X- items, and a new example. > > c. Added new text about always supporting X- in calendar-data. > > d. Created new section for PUT, COPY and MOVE preconditions. > > e. Report examples re-done with full listing of calendar data in > Appendix. > > f. Removed description of using UID, SUMMARY etc as resource name. > > g. Indicate that calendar object resource may contain only > overridden components. > > h. Add security consideration about not expose details in resource > names. > > i. Add constraint that free-busy-query can only be run on a > collection. > > j. Add preconditions for calendar-timezone property/elements in > MKCALENDAR, PROPPATCH and calendar-query REPORT. > > k. Fix principal-match example. > > > > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 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 DFB597F530; Wed, 22 Feb 2006 19:08:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D0D6D142285; Wed, 22 Feb 2006 19:08:59 -0800 (PST) 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 23255-06; Wed, 22 Feb 2006 19:08:59 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 33EB3142280; Wed, 22 Feb 2006 19:08:59 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1N38rCL008747; Wed, 22 Feb 2006 21:08:53 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k1N38qet009820; Wed, 22 Feb 2006 20:08:52 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw5-141-144-105-62.vpn.oracle.com [141.144.105.62]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1N38gnf009762; Wed, 22 Feb 2006 20:08:49 -0700 Message-ID: <43FD273E.3020702@oracle.com> Date: Wed, 22 Feb 2006 22:08:46 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList , Calsify WG , WebDAV WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Ted Hardie Subject: [Ietf-caldav] CalDAV draft Informal Last-Call 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, 23 Feb 2006 03:09:00 -0000 We submitted CalDAV draft -10 to the IETF yesterday. The draft has not been officially announced yet, but it is already available for you to review at the following URL: http://ietf.webdav.org/caldav/draft-dusseault-caldav-10.txt We would like to submit the CalDAV draft for Last Call in time for the 65th IETF Meeting in Dallas (i.e., really soon!). Before we do so, we would like to get as much feedback as possible from the participants of the "ietf-caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups. Once officially announced the draft should be available at: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-10.txt Previous versions of the draft are available at: http://ietfreport.isoc.org/idref/draft-dusseault-caldav/ Discussion on CalDAV is taking place on the "ietf-caldav" mailing list: mailto:ietf-caldav@osafoundation.org which is archived at: http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Reports on the 4 CalDAV Interoperability Events organized by the Calendaring and Scheduling Consortium (CalConnect) can be found at: http://www.calconnect.org/ioppast.html Finally, additional information on CalDAV can also be found at: http://ietf.webdav.org/caldav/ Please review draft -10 and send us feedback/questions/comments. Thanks for you help! Cheers, Bernard -- C.1. Changes in -10 a. Added new section about support for X- items when storing data. b. Added new precondition to allow servers to reject queries on unsupported X- items, and a new example. c. Added new text about always supporting X- in calendar-data. d. Created new section for PUT, COPY and MOVE preconditions. e. Report examples re-done with full listing of calendar data in Appendix. f. Removed description of using UID, SUMMARY etc as resource name. g. Indicate that calendar object resource may contain only overridden components. h. Add security consideration about not expose details in resource names. i. Add constraint that free-busy-query can only be run on a collection. j. Add preconditions for calendar-timezone property/elements in MKCALENDAR, PROPPATCH and calendar-query REPORT. k. Fix principal-match example. 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 80FED808E7 for ; Wed, 22 Feb 2006 09:49:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 717151422A8 for ; Wed, 22 Feb 2006 09:49:33 -0800 (PST) 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 20316-01 for ; Wed, 22 Feb 2006 09:49:33 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 80A6B1422A7 for ; Wed, 22 Feb 2006 09:49:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) To: CalDAV DevList Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-7--885402181 References: From: Lisa Dusseault Date: Wed, 22 Feb 2006 09:49:14 -0800 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_70_80, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-caldav] Fwd: WGLC of draft-ietf-webdav-rfc2518bis-14.txt 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: Wed, 22 Feb 2006 17:49:33 -0000 --Apple-Mail-7--885402181 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The next version of WebDAV recycles at the same state, but is much less ambiguous and simpler in how locks and If headers work. Reviews are most welcome. Lisa Begin forwarded message: > From: Cullen Jennings > Date: February 22, 2006 7:42:18 AM PST > To: WebDav > Cc: Lisa Dusseault > Subject: WGLC of draft-ietf-webdav-rfc2518bis-14.txt > > > I am absolutely thrilled to be able to Working Group Last Call (WGLC) > draft-ietf-webdav-rfc2518bis. The WGLC will end on March 15, 2006. > > I am aware of one complex open issue with this version of the > draft. The use > of ETAGs in the response to a HTTP PUT is not exactly clear in the > HTTP spec > and this has implications for WebDAV. Some folks are working on a > draft to > clarify this in HTTP. I'm sure this issue will be discussed during > the Last > Call. > > On minor issues, Julian will be proposing new text for bug 143. > > The "if header" section needs particularly careful review. > > I would like to ask everyone to read this. We really need to get > some fresh > eyes reading this document. Did we get it right? Is there enough > detail that > you can implement it? Does this clarify previous interoperable > problems? > > Thank you, > Cullen > > I'd like to take this moment to thank the several contributors that > put in a > ton of work to make this happen and to all the folks on the mailing > list > that put up with the roughly two thousand email posts from bugzilla. I > really hope the volume of these will be reducing. --Apple-Mail-7--885402181 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 The next version of WebDAV = recycles at the same state, but is much less ambiguous and simpler in = how locks and If headers work.=A0 Reviews are most welcome.

Lisa

Begin = forwarded message:

From: = Cullen Jennings <fluffy@cisco.com>
Date: = February 22, 2006 7:42:18 AM PST
To: WebDav = <w3c-dist-auth@w3.org>
Cc: Lisa Dusseault <lisa@osafoundation.org>
Subject: WGLC of = draft-ietf-webdav-rfc2518bis-14.txt


I am = absolutely thrilled to be able to Working Group Last Call = (WGLC)
draft-ietf-webdav-rfc2518bis. = The WGLC will end on March 15, 2006.

I am aware of one complex open = issue with this version of the draft. The use
of ETAGs in the response to a HTTP PUT is not = exactly clear in the HTTP spec
and this has = implications for WebDAV. Some folks are working on a draft to
clarify this in HTTP. I'm sure this issue will be = discussed during the Last
Call.=A0

On minor = issues, Julian will be proposing new text for bug 143.

The "if = header" section needs particularly careful review.

I would = like to ask everyone to read this. We really need to get some = fresh
eyes reading this document. Did = we get it right? Is there enough detail that
you can implement it? Does this clarify previous = interoperable problems?

Thank you,
Cullen

I'd like to take this moment to = thank the several contributors that put in a
ton of work to make this happen and to all the folks = on the mailing list
that put up with the = roughly two thousand email posts from bugzilla. I
really hope the volume of these will be = reducing.

= --Apple-Mail-7--885402181-- 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 270D87F62C for ; Thu, 16 Feb 2006 12:54:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 126461422AB for ; Thu, 16 Feb 2006 12:54:00 -0800 (PST) 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 27477-10 for ; Thu, 16 Feb 2006 12:53:59 -0800 (PST) Received: from cujo.runbox.com (aibo.runbox.com [193.71.199.94]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8974E14228B for ; Thu, 16 Feb 2006 12:53:59 -0800 (PST) Received: from [10.9.9.160] (helo=penny.runbox.com ident=Debian-exim) by greyhound.runbox.com with esmtp (Exim 4.34) id 1F9q8R-0006zz-E3 for ietf-caldav@osafoundation.org; Thu, 16 Feb 2006 21:53:55 +0100 Received: from [24.193.162.147] (helo=[192.168.15.5]) by penny.runbox.com with esmtpsa (uid:214186 ) (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.50) id 1F9q8R-0006kF-5f for ietf-caldav@osafoundation.org; Thu, 16 Feb 2006 21:53:55 +0100 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <4A04E7B8-D237-4A28-B5AE-BB5CA2146443@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bobby Rullo Subject: Re: [Ietf-caldav] expanding recurring (and non-recurring!) events Date: Thu, 16 Feb 2006 15:53:52 -0500 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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, 16 Feb 2006 20:54:00 -0000 Cyrus, Let me explain my specific use case. I am displaying a week view in a client with no local store, and I want to make sure that the user can see the timezones of the specific events. With your solution I'd have to do a REPORT and then a bunch of GET's for each specific resource to get the TZ information. Do you have a different solution given that my client has no local store? Thanks, bobby On Feb 16, 2006, at 2:49 PM, Cyrus Daboo wrote: > Hi Bobby, > > --On February 16, 2006 2:43:14 PM -0500 Bobby Rullo > wrote: > >> 1) Should a report with an "expand" element return events that >> have no >> RRULE's (referred to as "normal" events hereafter) ? > > Yes. > >> 1a) If so, should the DTSTART and DTEND of normal events be >> converted >> to UTC as well? > > Yes. > >> 1ai) If so, that seems like a problem to me as you now don't >> know the >> original timezone of the event and would need another GET to >> figure it >> out. (I am assuming that the purpose of a calendar-query w/ >> expand is to >> quickly get all the events in a time range, including recurring >> instances) > > No problem - see below. > >> 1b) If not, what is the best way to get all events for a given time >> range including recurring instances? Two REPORTs - one with >> expand and >> one w/o? Or am I better of doing a limit-recurrence-set and >> expanding >> out the recurrences myself? >> >> 2) The master event (event with the RRULE) of a set of recurrences >> should NOT have it's DTSTART and DTEND converted to UTC, right? > > No - the master event must be converted. > >> 3) What was the reason for returning expanded instances with times >> converted to UTC? > > The goal of 'expand' is to provided the simplest form of iCalendar > data for clients with very limited capability. i.e. clients that > have no capacity for handling recurrence expansion. Given that > VTIMEZONE objects usually contain recurrence rules, those too have > to be eliminated in an appropriate way - i.e. conversion of all > times to UTC. So all times must be returned in UTC - even for non- > recurring events. If a client really does want more detail about a > specific event, then it can always fetch that directly when needed > (e.g. when the user actually goes to edit the event). > > -- > 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 8C4187F6D4; Thu, 16 Feb 2006 11:49:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7D5B51422B3; Thu, 16 Feb 2006 11:49:48 -0800 (PST) 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 21115-07; Thu, 16 Feb 2006 11:49:48 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 325731422B2; Thu, 16 Feb 2006 11:49:48 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 97032D33FBF; Thu, 16 Feb 2006 14:49:46 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Thu, 16 Feb 2006 14:49:46 -0500 X-Sasl-enc: Kzh2T/O22ugzd9KKcMD0ivi5TwMMpPlui1S6i0XP4v+/ 1140119385 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 11E39571483; Thu, 16 Feb 2006 14:49:44 -0500 (EST) Date: Thu, 16 Feb 2006 14:49:42 -0500 From: Cyrus Daboo To: Bobby Rullo , CalDAV DevList Subject: Re: [Ietf-caldav] expanding recurring (and non-recurring!) events Message-ID: In-Reply-To: <4A04E7B8-D237-4A28-B5AE-BB5CA2146443@osafoundation.org> References: <4A04E7B8-D237-4A28-B5AE-BB5CA2146443@osafoundation.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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, 16 Feb 2006 19:49:48 -0000 Hi Bobby, --On February 16, 2006 2:43:14 PM -0500 Bobby Rullo wrote: > 1) Should a report with an "expand" element return events that have no > RRULE's (referred to as "normal" events hereafter) ? Yes. > 1a) If so, should the DTSTART and DTEND of normal events be converted > to UTC as well? Yes. > 1ai) If so, that seems like a problem to me as you now don't know the > original timezone of the event and would need another GET to figure it > out. (I am assuming that the purpose of a calendar-query w/ expand is to > quickly get all the events in a time range, including recurring > instances) No problem - see below. > 1b) If not, what is the best way to get all events for a given time > range including recurring instances? Two REPORTs - one with expand and > one w/o? Or am I better of doing a limit-recurrence-set and expanding > out the recurrences myself? > > 2) The master event (event with the RRULE) of a set of recurrences > should NOT have it's DTSTART and DTEND converted to UTC, right? No - the master event must be converted. > 3) What was the reason for returning expanded instances with times > converted to UTC? The goal of 'expand' is to provided the simplest form of iCalendar data for clients with very limited capability. i.e. clients that have no capacity for handling recurrence expansion. Given that VTIMEZONE objects usually contain recurrence rules, those too have to be eliminated in an appropriate way - i.e. conversion of all times to UTC. So all times must be returned in UTC - even for non-recurring events. If a client really does want more detail about a specific event, then it can always fetch that directly when needed (e.g. when the user actually goes to edit the event). -- 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 D58B67F645; Thu, 16 Feb 2006 11:43:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C665D1422B2; Thu, 16 Feb 2006 11:43:21 -0800 (PST) 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 25532-01; Thu, 16 Feb 2006 11:43:21 -0800 (PST) Received: from cujo.runbox.com (aibo.runbox.com [193.71.199.94]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 768E01422B0; Thu, 16 Feb 2006 11:43:21 -0800 (PST) Received: from [10.9.9.160] (helo=penny.runbox.com ident=Debian-exim) by greyhound.runbox.com with esmtp (Exim 4.34) id 1F9p25-0002OU-71; Thu, 16 Feb 2006 20:43:17 +0100 Received: from [24.193.162.147] (helo=[192.168.15.5]) by penny.runbox.com with esmtpsa (uid:214186 ) (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.50) id 1F9p24-0004Ex-SS; Thu, 16 Feb 2006 20:43:17 +0100 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A04E7B8-D237-4A28-B5AE-BB5CA2146443@osafoundation.org> Content-Transfer-Encoding: 7bit From: Bobby Rullo Date: Thu, 16 Feb 2006 14:43:14 -0500 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] expanding recurring (and non-recurring!) events 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, 16 Feb 2006 19:43:22 -0000 Hi all, I'm writing to get some clarification about REPORT's with an "expand" element. My questions are as follows: 1) Should a report with an "expand" element return events that have no RRULE's (referred to as "normal" events hereafter) ? 1a) If so, should the DTSTART and DTEND of normal events be converted to UTC as well? 1ai) If so, that seems like a problem to me as you now don't know the original timezone of the event and would need another GET to figure it out. (I am assuming that the purpose of a calendar-query w/ expand is to quickly get all the events in a time range, including recurring instances) 1b) If not, what is the best way to get all events for a given time range including recurring instances? Two REPORTs - one with expand and one w/o? Or am I better of doing a limit-recurrence-set and expanding out the recurrences myself? 2) The master event (event with the RRULE) of a set of recurrences should NOT have it's DTSTART and DTEND converted to UTC, right? 3) What was the reason for returning expanded instances with times converted to UTC? Thanks! bobby 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 512877F698 for ; Thu, 9 Feb 2006 07:39:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 41D191422D8 for ; Thu, 9 Feb 2006 07:39:38 -0800 (PST) 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 31742-08 for ; Thu, 9 Feb 2006 07:39:38 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5CF11422D1 for ; Thu, 9 Feb 2006 07:39:37 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 7DDBBD33FA7 for ; Thu, 9 Feb 2006 10:39:36 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Thu, 09 Feb 2006 10:39:36 -0500 X-Sasl-enc: ddwl4gc/tvNEEGbFiqua3k90Fx1rQ8JjCXfakvcyU4/W 1139499575 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 4950C5714A3 for ; Thu, 9 Feb 2006 10:39:28 -0500 (EST) Date: Thu, 09 Feb 2006 10:39:37 -0500 From: Cyrus Daboo To: CalDAV DevList Subject: Re: [Ietf-caldav] Storing multiple UIDs for the same version of a vevent Message-ID: <0675EC1C4550F687114B5FF2@Cyrus-Daboo.local> In-Reply-To: <43EACAB4.3010602@Royer.com> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <43EA6779.6010402@Royer.com> <43EAB96A.2070507@Royer.com> <55C4F9E8C2462957278874FD@ninevah.local> <43EACAB4.3010602@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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, 09 Feb 2006 15:39:38 -0000 Hi Doug, --On February 8, 2006 9:53:08 PM -0700 Doug Royer wrote: >> Right - and maybe that info would better be stored as meta-data - i.e. >> WebDAV properties - than in the actual iCal stream. Something to think >> about for the scheduling draft... > > Perhaps, however any CUA can process the data if it is stored > in iCal format. Where as the meta-data would have to be designed > from scratch and solve issues where many of these issues would > overlap with resolved iTIP processes. > > I think it would be nice if HOW this is done be in an iCal-store > draft so that any one can use the data, no matter what the > transport. A CUA already knows how to process those iCal > objects. So what would be the advantage of a 2nd representation > of the same state data? First of all how many clients actually do all of that iTIP work correctly and interopate with others? And second, how many of those have actually committed to supporting CalDAV? My feeling is that if CalDAV can simplify this process (something that still has to be determined) then I don't see why it should have an alternative way to do it. This isn't really reinventing iTIP its just coming up with another way to address it. -- 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 77B927F660 for ; Wed, 8 Feb 2006 20:53:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 691D81422D4 for ; Wed, 8 Feb 2006 20:53:11 -0800 (PST) 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 17129-03 for ; Wed, 8 Feb 2006 20:53:11 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 05F711422D1 for ; Wed, 8 Feb 2006 20:53:10 -0800 (PST) Received: (qmail 10884 invoked from network); 8 Feb 2006 23:53:09 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 23:53:09 -0500 Message-ID: <43EACAB4.3010602@Royer.com> Date: Wed, 08 Feb 2006 21:53:08 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Storing multiple UIDs for the same version of a vevent References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <43EA6779.6010402@Royer.com> <43EAB96A.2070507@Royer.com> <55C4F9E8C2462957278874FD@ninevah.local> In-Reply-To: <55C4F9E8C2462957278874FD@ninevah.local> Content-Type: multipart/mixed; boundary="------------000105020204060001060202" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 09 Feb 2006 04:53:11 -0000 This is a multi-part message in MIME format. --------------000105020204060001060202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Doug, > > --On February 8, 2006 8:39:22 PM -0700 Doug Royer wrote: > >> The entire history might not needed to be saved, just whatever >> represents the final state of the objects and other data >> that will tell the CUA where the user left off on processing >> or inviting and who got what updates. > > > Right - and maybe that info would better be stored as meta-data - i.e. > WebDAV properties - than in the actual iCal stream. Something to think > about for the scheduling draft... Perhaps, however any CUA can process the data if it is stored in iCal format. Where as the meta-data would have to be designed from scratch and solve issues where many of these issues would overlap with resolved iTIP processes. I think it would be nice if HOW this is done be in an iCal-store draft so that any one can use the data, no matter what the transport. A CUA already knows how to process those iCal objects. So what would be the advantage of a 2nd representation of the same state data? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------000105020204060001060202 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------000105020204060001060202-- 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 1A0767F695 for ; Wed, 8 Feb 2006 20:25:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0AED11422D3 for ; Wed, 8 Feb 2006 20:25:20 -0800 (PST) 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 12924-03 for ; Wed, 8 Feb 2006 20:25:19 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id C990E1422D0 for ; Wed, 8 Feb 2006 20:25:19 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id C314AD33985; Wed, 8 Feb 2006 23:25:17 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 23:25:17 -0500 X-Sasl-enc: DLWy+nxIHZTkx1FarBdeUJsUW0lgyhK144qKrIO8voYe 1139459114 Received: from [10.0.1.3] (pool-71-253-43-80.pitbpa.east.verizon.net [71.253.43.80]) by www.fastmail.fm (Postfix) with ESMTP id 5FAE5571506; Wed, 8 Feb 2006 23:25:13 -0500 (EST) Date: Wed, 08 Feb 2006 23:25:18 -0500 From: Cyrus Daboo To: Doug Royer Subject: Re: [Ietf-caldav] Storing multiple UIDs for the same version of a vevent Message-ID: <55C4F9E8C2462957278874FD@ninevah.local> In-Reply-To: <43EAB96A.2070507@Royer.com> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <43EA6779.6010402@Royer.com> <43EAB96A.2070507@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 09 Feb 2006 04:25:20 -0000 Hi Doug, --On February 8, 2006 8:39:22 PM -0700 Doug Royer wrote: > The entire history might not needed to be saved, just whatever > represents the final state of the objects and other data > that will tell the CUA where the user left off on processing > or inviting and who got what updates. Right - and maybe that info would better be stored as meta-data - i.e. WebDAV properties - than in the actual iCal stream. Something to think about for the scheduling draft... -- 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 196C37F694 for ; Wed, 8 Feb 2006 19:39:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 090931422D0 for ; Wed, 8 Feb 2006 19:39:25 -0800 (PST) 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 30965-01 for ; Wed, 8 Feb 2006 19:39:24 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 955461422CE for ; Wed, 8 Feb 2006 19:39:24 -0800 (PST) Received: (qmail 7264 invoked from network); 8 Feb 2006 22:39:23 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 22:39:23 -0500 Message-ID: <43EAB96A.2070507@Royer.com> Date: Wed, 08 Feb 2006 20:39:22 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] Storing multiple UIDs for the same version of a vevent References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <43EA6779.6010402@Royer.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040405000000090009000508" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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, 09 Feb 2006 03:39:25 -0000 This is a multi-part message in MIME format. --------------040405000000090009000508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If CalDAV is going to be iTIP aware, it will have to, else the CUA will not be able to tell who replied and who was invited. And it will need to know that user-4 replied to SEQUENCE:0 and the object is at SEQUENCE:4. If I started up my CUA and it forgot who I had invited, I would get another CUA. And if the user has more than one CUA, then the data needs to be in the store. And the CUA will need to know who replied that was not invited, so the CUA can handle forwarded object and auto-reject (I never want cal-spam@example.com to be accepted) and auto-accept (My boss is always yes). The entire history might not needed to be saved, just whatever represents the final state of the objects and other data that will tell the CUA where the user left off on processing or inviting and who got what updates. Cyrus Daboo wrote: > Hi Doug, > > --On February 8, 2006 2:49:45 PM -0700 Doug Royer wrote: > >> As iTIP specifies: >> >> Hence, CUAs must persist the following component properties: "UID", >> "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each >> "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" >> and "DTSTAMP" property values associated with the "Attendee's" >> response. >> >> Why not just store these in the same resource? > > > So what you are saying is that a CalDAV resource should store the entire > iTIP transaction history as well as the current state of the components. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040405000000090009000508 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------040405000000090009000508-- 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 141947F67F for ; Wed, 8 Feb 2006 13:59:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0049F1422BF for ; Wed, 8 Feb 2006 13:59:15 -0800 (PST) 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 25914-02 for ; Wed, 8 Feb 2006 13:59:14 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE5CE1422BE for ; Wed, 8 Feb 2006 13:59:14 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id E2DF3D33C82 for ; Wed, 8 Feb 2006 16:59:12 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 16:59:12 -0500 X-Sasl-enc: /OS0/DM7HlhwAJxJ7InBpWCRdJfJilrgrFG4N1daZUCU 1139435951 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 917D45714A3 for ; Wed, 8 Feb 2006 16:59:10 -0500 (EST) Date: Wed, 08 Feb 2006 16:59:16 -0500 From: Cyrus Daboo To: CalDAV DevList Subject: Re: [Ietf-caldav] Storing multiple UIDs for the same version of a vevent Message-ID: In-Reply-To: <43EA6779.6010402@Royer.com> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <43EA6779.6010402@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 21:59:15 -0000 Hi Doug, --On February 8, 2006 2:49:45 PM -0700 Doug Royer wrote: > As iTIP specifies: > > Hence, CUAs must persist the following component properties: "UID", > "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each > "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" > and "DTSTAMP" property values associated with the "Attendee's" > response. > > Why not just store these in the same resource? So what you are saying is that a CalDAV resource should store the entire iTIP transaction history as well as the current state of the components. -- 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 7F22E7F565 for ; Wed, 8 Feb 2006 13:57:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6EAF8142294 for ; Wed, 8 Feb 2006 13:57:11 -0800 (PST) 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 07519-07 for ; Wed, 8 Feb 2006 13:57:11 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id ED0361422BD for ; Wed, 8 Feb 2006 13:57:10 -0800 (PST) Received: (qmail 22972 invoked from network); 8 Feb 2006 16:57:09 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 16:57:09 -0500 Message-ID: <43EA6935.6080102@Royer.com> Date: Wed, 08 Feb 2006 14:57:09 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <43EA60CF.2010500@osafoundation.org> In-Reply-To: <43EA60CF.2010500@osafoundation.org> Content-Type: multipart/mixed; boundary="------------070105080404030105060003" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 08 Feb 2006 21:57:11 -0000 This is a multi-part message in MIME format. --------------070105080404030105060003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit How about, All components with the same SEQUENCE, DTSTAMP and UID are from the same version of the object. All components with the same UID must be in the same resource in a calendar collection. All components withOUT a METHOD property or with a METHOD:ADD property are all the 'master' object. The 3rd object allows for new instances to be added to the component that can not be covered in an updated RRULE or RDATE. (other properties such as LOCATION changed for example). Jeffrey Harris wrote: > Hi Cyrus, > > >>>What would be the negative impact of allowing a CalDAV server to store >>>VEVENTs with one or many RECURRENCE-IDs, but no RRULE or RDATEs? >> >>I think that is something we are going to have to support since you can >>get invited to a single instance. >> >>Right now we have the requirement that all components with the same UID >>MUST be in the same WebDAV resource. The implication being that all >>components in a recurring set are in the same resource. I don't think we >>actually state that the 'master' instance (the one without any >>RECURRENCE-ID property, defining the actual set) has to be present as >>well. > > > Hmm. This paragraph should probably be reworded a bit, then: > > Calendar components with the same UID property value, in a given > calendar collection, MUST be contained in the same calendar object > resource. This ensures that all components in a recurrence "set" are > contained in the same calendar object resource. In that case there > will be one component without a RECURRENCE-ID property (the component > that defines the recurrence pattern) and all the rest will have that > property (these are the recurrence exceptions). > > You're right that it doesn't forbid a RECURRENCE-ID in the absence > of a recurrence rule, but it does suggest that two occurrences with > difference RECURRENCE-IDs won't happen. > > Sincerely, > Jeffrey > _______________________________________________ > 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 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070105080404030105060003 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------070105080404030105060003-- 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 7E9AB7F66B for ; Wed, 8 Feb 2006 13:49:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6ECB41422BC for ; Wed, 8 Feb 2006 13:49:48 -0800 (PST) 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 13367-06 for ; Wed, 8 Feb 2006 13:49:48 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C029E1422BB for ; Wed, 8 Feb 2006 13:49:47 -0800 (PST) Received: (qmail 22593 invoked from network); 8 Feb 2006 16:49:46 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 16:49:46 -0500 Message-ID: <43EA6779.6010402@Royer.com> Date: Wed, 08 Feb 2006 14:49:45 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> In-Reply-To: <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010309020408030906020702" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, UPPERCASE_25_50 X-Spam-Level: Subject: [Ietf-caldav] Storing multiple UIDs for the same version of a vevent X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 08 Feb 2006 21:49:48 -0000 This is a cryptographically signed message in MIME format. --------------ms010309020408030906020702 Content-Type: multipart/mixed; boundary="------------090501070004050106050305" This is a multi-part message in MIME format. --------------090501070004050106050305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Jeffrey, > > --On February 7, 2006 3:20:28 PM -0800 Jeffrey Harris > wrote: > >> What would be the negative impact of allowing a CalDAV server to store >> VEVENTs with one or many RECURRENCE-IDs, but no RRULE or RDATEs? > > I think that is something we are going to have to support since you can > get invited to a single instance. As iTIP specifies: Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response. Why not just store these in the same resource? In this example, assume that USER-1 and USER-2 were invited to all 4 instances. And assume that USER-3 was invited to only instance 2. Also assume that all 3 were invited at the same time. BEGIN:VEVENT UID:1 SEQUENCE:0 DTSTAMP: Date of original object. DTSTART: first date-time of 4 instances RRULE;FREQ=DAILY;COUNT=4 .. END:VEVENT The above object has no METHOD, so it is not an iTIP object and could be considered the master object. BEGIN:VEVENT METHOD:REQUEST UID:1 SEQUENCE:0 DTSTAMP: Date of when the user-1 and user-2 REQUEST object was created. DTSTART: first date-time of 4 instances RRULE:FREQ=DAILY;COUNT=4 ATTENDEE:MAILTO:user-1 ATTENDEE:MAILTO:user-2 ... END:VEVENT The above object is the request sent to user-1 and user-2 persisted so that the CUA known who, when, and what instances user-1 and user-2 were invited. BEGIN:VEVENT METHOD:REQUEST UID:1 SEQUENCE:0 DTSTAMP: Date of when the user-3 REQUEST object was created. DTSTART: date-time of 2nd instance from the above 1st vevent ATTENDEE:MAILTO:user-3 ... END:VEVENT Why do you need a RECURRENCE-ID in the 3nd object? The CUA can tell that the non-iTIP object exists (the 1st above), it can tell which instances user-1, user-2, and user-3 were invited. And if user-1 and user-2 accepts, AND user-3 accepts only the 3nd instance and declines the 1st, 2nd, and 4th instance, store this: BEGIN:VEVENT METHOD:REPLY UID:1 SEQUENCE:0 DTSTAMP: Date of user-1 REPLY DTSTART: first date-time of 4 instances ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:user-1 .., END:VEVENT BEGIN:VEVENT METHOD:REPLY UID:1 SEQUENCE:0 DTSTAMP: Date of user-2 REPLY ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:user-2 ... END:VEVENT Because of how iTIP works, user-3 must sent these 4 reply objects, which can be stored in the store: BEGIN:VEVENT METHOD:REPLY UID:1 SEQUENCE:0 DTSTAMP: Date of user-3 REPLY RECURRENCE-ID: date-time of 1st instance ATTENDEE;PARTSTAT=DECLINED:MAILTO:user-3 ... END:VEVENT BEGIN:VEVENT METHOD:REPLY UID:1 SEQUENCE:0 DTSTAMP: Date of user-3 REPLY RECURRENCE-ID: date-time of 2nd instance ATTENDEE;PARTSTAT=DECLINED:MAILTO:user-3 ... END:VEVENT BEGIN:VEVENT METHOD:REPLY UID:1 SEQUENCE:0 DTSTAMP: Date of user-3 REPLY RECURRENCE-ID: date-time of 3rd instance ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:user-3 ... END:VEVENT BEGIN:VEVENT METHOD:REPLY UID:1 SEQUENCE:0 DTSTAMP: Date of user-3 REPLY RECURRENCE-ID: date-time of 4th instance ATTENDEE;PARTSTAT=DECLINED:MAILTO:user-3 ... END:VEVENT After user-1, user-2, and user-3 in this example have relied, there are 9 objects for the same UID stored. These are the kind of things that I see as needed in an iCal-Store draft. > Right now we have the requirement that all components with the same UID > MUST be in the same WebDAV resource. The implication being that all > components in a recurring set are in the same resource. I don't think we > actually state that the 'master' instance (the one without any > RECURRENCE-ID property, defining the actual set) has to be present as > well. So it should be possible to have a single overridden instance of > an event in a calendar-collection. The only important thing to bear in > mind is that if you want to add another component from the instance set > you have to add it to the existing resource to satisfy the UID/resource > constraint. > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090501070004050106050305 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------090501070004050106050305-- --------------ms010309020408030906020702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDIwODIxNDk0NVowIwYJKoZIhvcNAQkEMRYEFA7SyR/srYaCno+9nGIbno5Y ZSVVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAAUJfizx5CQk8/hhSufz6/hKf4eJ2jeknXqEbIqFqKiYYNLfToOWZggAUAY7CqHabiTS lJSPx8ZiER5j/tvb51/p7joTJlSAQ44dHWPOHiESsPPMWmBYFh8KN3/+RyPWbmNSg2g45sAr BWOwwCuoqp2kvaeU79yH4ni4dFQBUQWr1XD2iL+wnvwdD/ZSEZzmPZ22HzUMAs3LdatS5GYe hwmXSW2OTP/i4/Hb/avJ+nBMYTFrwh2hjYAZNPLb2CaR6Lpuvi52uAY+C71Aa8QgBI85gtDD B0F8+vUmm88Ecw+aDOruLwfABKR7deeY1oXUeZ4cvsoRN786DyvpH4h1opEAAAAAAAA= --------------ms010309020408030906020702-- 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 5ED267F639 for ; Wed, 8 Feb 2006 13:41:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F4691422BC for ; Wed, 8 Feb 2006 13:41:22 -0800 (PST) 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 16692-06 for ; Wed, 8 Feb 2006 13:41:22 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.207]) by laweleka.osafoundation.org (Postfix) with ESMTP id CF8201422BB for ; Wed, 8 Feb 2006 13:41:21 -0800 (PST) Received: by uproxy.gmail.com with SMTP id h2so13212ugf for ; Wed, 08 Feb 2006 13:41:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I2JI8xpXf2ExqjDhgDnvWZTbnCk+o99F0KvAjpE5E2dOJOan4Skd82RmEovdqnXpChOSKJs75dQFR0Stqif++SqD7XW6F6lDScJASX0NWUn2rg5k137L8P1dIxr98kWKN/VzXB8Dm29mvXPjrQicuTtYA1Pzgid/xbBcg/5+ke4= Received: by 10.49.33.17 with SMTP id l17mr2114254nfj; Wed, 08 Feb 2006 13:41:20 -0800 (PST) Received: by 10.48.231.17 with HTTP; Wed, 8 Feb 2006 13:41:20 -0800 (PST) Message-ID: <29a761a00602081341p4055f4fei7f1c4ef82f4dc6cf@mail.gmail.com> Date: Wed, 8 Feb 2006 13:41:20 -0800 From: Brian Moseley Sender: ixjonez@gmail.com To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? In-Reply-To: <10E2EBD7-E5B7-4E8A-9EB7-106A5C709791@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43CD457F.5000900@osafoundation.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> <10E2EBD7-E5B7-4E8A-9EB7-106A5C709791@osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 21:41:22 -0000 On 2/8/06, Lisa Dusseault wrote: > We should probably put this paragraph in the doc! Well said. please do, because otherwise the ambiguity will cause interop problems. i've implemented cosmo to require the master instance in a recurring component, which will slam the door on jeffrey's attempt to build this feature in chandler. 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 5080B7F626 for ; Wed, 8 Feb 2006 13:21:22 -0800 (PST) Received: from [192.168.1.115] (c-24-7-66-120.hsd1.ca.comcast.net [24.7.66.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2E66A1422AD; Wed, 8 Feb 2006 13:21:22 -0800 (PST) Message-ID: <43EA60CF.2010500@osafoundation.org> Date: Wed, 08 Feb 2006 13:21:19 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> In-Reply-To: <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: CalDAV DevList 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: Wed, 08 Feb 2006 21:21:22 -0000 Hi Cyrus, >> What would be the negative impact of allowing a CalDAV server to store >> VEVENTs with one or many RECURRENCE-IDs, but no RRULE or RDATEs? > > I think that is something we are going to have to support since you can > get invited to a single instance. > > Right now we have the requirement that all components with the same UID > MUST be in the same WebDAV resource. The implication being that all > components in a recurring set are in the same resource. I don't think we > actually state that the 'master' instance (the one without any > RECURRENCE-ID property, defining the actual set) has to be present as > well. Hmm. This paragraph should probably be reworded a bit, then: Calendar components with the same UID property value, in a given calendar collection, MUST be contained in the same calendar object resource. This ensures that all components in a recurrence "set" are contained in the same calendar object resource. In that case there will be one component without a RECURRENCE-ID property (the component that defines the recurrence pattern) and all the rest will have that property (these are the recurrence exceptions). You're right that it doesn't forbid a RECURRENCE-ID in the absence of a recurrence rule, but it does suggest that two occurrences with difference RECURRENCE-IDs won't happen. Sincerely, Jeffrey 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 3A2FE7F626 for ; Wed, 8 Feb 2006 13:21:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2ADFE1422B1 for ; Wed, 8 Feb 2006 13:21:09 -0800 (PST) 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 20596-01 for ; Wed, 8 Feb 2006 13:21:08 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 98B7A1422AD for ; Wed, 8 Feb 2006 13:21:08 -0800 (PST) Received: (qmail 21228 invoked from network); 8 Feb 2006 16:21:07 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 16:21:07 -0500 Message-ID: <43EA60C0.1020404@Royer.com> Date: Wed, 08 Feb 2006 14:21:04 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA3C57.2@oracle.com> <43EA4842.3020808@Royer.com> <2A4BF19B1CF404895FA5EA55@Cyrus-Daboo.local> In-Reply-To: <2A4BF19B1CF404895FA5EA55@Cyrus-Daboo.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010909080507090506040807" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 08 Feb 2006 21:21:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010909080507090506040807 Content-Type: multipart/mixed; boundary="------------080301070101080107060603" This is a multi-part message in MIME format. --------------080301070101080107060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Doug, > > --On February 8, 2006 12:36:34 PM -0700 Doug Royer wrote: > >> The iTIP VFREEBUSY request is sent to a MAILTO url (the user), not a >> calendar. And the users CUA determines the VFREEBUSY REPLY, not >> the calendar. A CALDAV F/B is a calendar store request, not a >> user request. > > > The free-busy-query report we have right now is effectively targetted at > calendar collections as opposed to calendar users. However, the CalDAV > scheduling spec will allow iTIP style free-busy queries against calendar > users (principles) and calendar users will be able to indicate which > calendars should be examined for queries against them. I agree, this is the only way that you can get accurate F/B for a user. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080301070101080107060603 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------080301070101080107060603-- --------------ms010909080507090506040807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDIwODIxMjEwNFowIwYJKoZIhvcNAQkEMRYEFG8GYU8+5aqPVqjkjVplZfdX R8IFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAMKBD5fAcdhdC5lKfV0CZuwiPVSNpBYno+2ih/42qdnYjEMm8i9dzfa2mxEdM+qsBba1 FEbJqfrmgyoUo536PbkKELo3ZHWgNp7VAkR39iVhpOPa8CcyCcyUOG9Eu6cppc8i59fb2fsC /ICSBT9vBzXWC8PvMZSLDNsVGIe48D9Sj+lj1Mb8mpBXaDT9XrskVHKjtXQlSg4zQDEuZHn3 4cdlvGdr1bJ/uyTaTAFS/fEZVqf1cUc9DpmWJZEsg4VE1x4Rl+LXyO3bv450dggxnFNKLm1O htI+iSep/2QeV8Rn3MbfICcefSigbBZFYlKTCOa3EEDGySx8y4601Jj5rRwAAAAAAAA= --------------ms010909080507090506040807-- 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 F1CD27F612; Wed, 8 Feb 2006 13:19:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D69321422BA; Wed, 8 Feb 2006 13:19:15 -0800 (PST) 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 03669-09; Wed, 8 Feb 2006 13:19:15 -0800 (PST) Received: from [192.168.1.100] (unknown [198.144.201.116]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 30E051422B1; Wed, 8 Feb 2006 13:19:15 -0800 (PST) In-Reply-To: <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10E2EBD7-E5B7-4E8A-9EB7-106A5C709791@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 8 Feb 2006 13:19:14 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Wed, 08 Feb 2006 21:19:16 -0000 On Feb 8, 2006, at 11:55 AM, Cyrus Daboo wrote: > > Right now we have the requirement that all components with the same > UID MUST be in the same WebDAV resource. The implication being that > all components in a recurring set are in the same resource. I don't > think we actually state that the 'master' instance (the one without > any RECURRENCE-ID property, defining the actual set) has to be > present as well. So it should be possible to have a single > overridden instance of an event in a calendar-collection. The only > important thing to bear in mind is that if you want to add another > component from the instance set you have to add it to the existing > resource to satisfy the UID/resource constraint. We should probably put this paragraph in the doc! Well said. Lisa 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 E7F3B7F54B for ; Wed, 8 Feb 2006 13:14:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D8CED1422B1 for ; Wed, 8 Feb 2006 13:14:04 -0800 (PST) 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 18305-02 for ; Wed, 8 Feb 2006 13:14:04 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 56EEB1422AD for ; Wed, 8 Feb 2006 13:14:04 -0800 (PST) Received: (qmail 20853 invoked from network); 8 Feb 2006 16:14:02 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 16:14:02 -0500 Message-ID: <43EA5F19.1080703@Royer.com> Date: Wed, 08 Feb 2006 14:14:01 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA45C7.7050908@rpi.edu> <13C89948-95EE-4BFD-8F06-B275F588032B@opengroupware.org> In-Reply-To: <13C89948-95EE-4BFD-8F06-B275F588032B@opengroupware.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070606090808050301020401" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-caldav] RESOURCE vs RESOURCE calendar X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 08 Feb 2006 21:14:05 -0000 This is a cryptographically signed message in MIME format. --------------ms070606090808050301020401 Content-Type: multipart/mixed; boundary="------------070608010805080406060806" This is a multi-part message in MIME format. --------------070608010805080406060806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If you go back to he CALSCH archives, I think that you will find that 'RESOURCE's are supported, and 'RESOURCE Calendars' were specifically out of scope for iCalendar at about the time of the Los Angles meeting that was pre-2445. The difference being that a "RESOURCE" property specifies the resources needed for an event. And a 'resource calendar' is a calendar for a resource. Resources had unique properties that were agreed at the time of the LA meeting to be better supported under a separate draft. Some of the properties were, number of items, related resources, and resources dependencies. I do not remember the entire list. So I agree that you can use a calendar as a resource. I disagree that they are fully supported as 'resource calendars'. Helge Hess wrote: > Resources are fully supported by iCalendar, see RFC 2445 section 4.2.3 > and 4.8.1.10. > I don't see the point in loosing that information? > > Greets, > Helge -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070608010805080406060806 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------070608010805080406060806-- --------------ms070606090808050301020401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDIwODIxMTQwMVowIwYJKoZIhvcNAQkEMRYEFAfzHrMpP3re9uLQxLm4SqJ1 uzkmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAGVxuN612qTaPwDBCyNzvVG7wQ6amKbe/qicvZ2vpo0x0cF94Fgth9/d/RzxqqKxEsCN 5Y9wziTTQZXt8RBigvoTd/HFfQWm57/OYbftMCJE50WIbYoiF/6fZPesAniq+LSpGoxF455+ 8hFJvrbGhIRAP6rhWkQmt5qYfeEuqCfdii6LZdbKRbyosezdL6NWDevL7akrdGYb8okeekDA wkdeuKuLkQ4VPCEeJyCLB3iuxKDFbhldFFgtCDNl8dAm3PPLbOrNPooTyIg5SXoHm+7WUT4P rgfagldXV0HsbXY0PqL+tNxQzHAv7qIlxQPYZE9MbXjn/kyhf7e6l2BBMakAAAAAAAA= --------------ms070606090808050301020401-- 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 93BA77F66B for ; Wed, 8 Feb 2006 11:59:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 843741422B1 for ; Wed, 8 Feb 2006 11:59:39 -0800 (PST) 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 27550-06 for ; Wed, 8 Feb 2006 11:59:39 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3197B142292 for ; Wed, 8 Feb 2006 11:59:39 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id DEF91D33CFC; Wed, 8 Feb 2006 14:59:37 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 14:59:37 -0500 X-Sasl-enc: L1Ag9+oQl6a6MYdhNTr3T5TKRzpgvm2tBjULt04Qfa9s 1139428776 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 499D7571513; Wed, 8 Feb 2006 14:59:28 -0500 (EST) Date: Wed, 08 Feb 2006 14:59:34 -0500 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: In-Reply-To: References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA3C57.2@oracle.com> <43EA4842.3020808@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:59:39 -0000 Hi Helge, --On February 8, 2006 8:51:08 PM +0100 Helge Hess wrote: > I'm not sure whether this discussion is leading anywhere (I think we had > it before). I'm fine with the suggestion of Lisa - just add an optional > ability to query the freebusy information of a given user (I would > prefer to have that in CalDAV draft 10). > > On 8. Feb 2006, at 20:36 Uhr, Doug Royer wrote: >> True, however CALDAV is not iTIP. > > Neither is CalDAV "just" iCalendar. So we should be basically free to > add operations to iCalendar on a higher protocol level. After all this > is the same thing done by iTIP ... > >> The iTIP VFREEBUSY request is sent to a MAILTO url (the user), not a >> calendar. > > This is what iTIP does. And CalDAV could specify a report which returns > the freebusy for a given "MAILTO url (the user)". I don't see how this > contradicts iCalendar, it is fully able to represent the needed > information in a format compliant way. The free-busy of a user is something we have left for the CalDAV scheduling spec as its more closely tied with scheduling operations than access operations. There has also been discussion as splitting it out as a separate 'service' (that would not require the full blown scheduling capability), so that you could have a standalone free-busy service that used CalDAV on the front-end, and aggregates free-busy results from different systems on the back end. There is a lot of demand to initially just solve the cross-organization free-busy lookup problem. -- 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 C8DD77F668; Wed, 8 Feb 2006 11:55:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B963E1422B1; Wed, 8 Feb 2006 11:55:42 -0800 (PST) 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 02742-05; Wed, 8 Feb 2006 11:55:42 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 65376142292; Wed, 8 Feb 2006 11:55:42 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id DDE0DD329C5; Wed, 8 Feb 2006 14:55:40 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 14:55:40 -0500 X-Sasl-enc: CBr9h+5dBjajPhi6gLinNakitkDnOLDatccHhBb2MXc9 1139428539 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id B22D057146F; Wed, 8 Feb 2006 14:55:38 -0500 (EST) Date: Wed, 08 Feb 2006 14:55:44 -0500 From: Cyrus Daboo To: Jeffrey Harris , CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: <9FB7006E21D015052DBE2166@Cyrus-Daboo.local> In-Reply-To: <43E92B3C.9010105@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:55:42 -0000 Hi Jeffrey, --On February 7, 2006 3:20:28 PM -0800 Jeffrey Harris wrote: > What would be the negative impact of allowing a CalDAV server to store > VEVENTs with one or many RECURRENCE-IDs, but no RRULE or RDATEs? I think that is something we are going to have to support since you can get invited to a single instance. Right now we have the requirement that all components with the same UID MUST be in the same WebDAV resource. The implication being that all components in a recurring set are in the same resource. I don't think we actually state that the 'master' instance (the one without any RECURRENCE-ID property, defining the actual set) has to be present as well. So it should be possible to have a single overridden instance of an event in a calendar-collection. The only important thing to bear in mind is that if you want to add another component from the instance set you have to add it to the existing resource to satisfy the UID/resource constraint. In terms of wanting to use the ATTENDEE property to indicate free-busy: there are two situations: 1) If you have read access to the calendar, then you can do regular calendar-query requests filtering on ATTENDEE value to determine the set of events that you are going to attend. Chances are you client will have some if not all of the relevant events int he time range already cached, so free-busy can be inferred from the cache without having to go to the server. 2) If you only have read-free-busy privilege then right now you cannot distinguish between different ATTENDEE's in a free-busy-query. It would be a simple matter to add a filtering capability to that report to allow for this, if there was sufficient demand for this case, as opposed to relying on (1). -- 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 3894D7F649 for ; Wed, 8 Feb 2006 11:51:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 283371422BA for ; Wed, 8 Feb 2006 11:51:11 -0800 (PST) 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 19041-10 for ; Wed, 8 Feb 2006 11:51:11 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id D32CA1422B1 for ; Wed, 8 Feb 2006 11:51:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A8890239136 for ; Wed, 8 Feb 2006 20:49:27 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 5016B238632 for ; Wed, 8 Feb 2006 20:49:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43EA4842.3020808@Royer.com> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA3C57.2@oracle.com> <43EA4842.3020808@Royer.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 8 Feb 2006 20:51:08 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:51:11 -0000 I'm not sure whether this discussion is leading anywhere (I think we had it before). I'm fine with the suggestion of Lisa - just add an optional ability to query the freebusy information of a given user (I would prefer to have that in CalDAV draft 10). On 8. Feb 2006, at 20:36 Uhr, Doug Royer wrote: > True, however CALDAV is not iTIP. Neither is CalDAV "just" iCalendar. So we should be basically free to add operations to iCalendar on a higher protocol level. After all this is the same thing done by iTIP ... > The iTIP VFREEBUSY request is sent to a MAILTO url (the user), not a > calendar. This is what iTIP does. And CalDAV could specify a report which returns the freebusy for a given "MAILTO url (the user)". I don't see how this contradicts iCalendar, it is fully able to represent the needed information in a format compliant way. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 785737F5C1 for ; Wed, 8 Feb 2006 11:46:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 69A8A1422B1 for ; Wed, 8 Feb 2006 11:46:12 -0800 (PST) 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 07536-03 for ; Wed, 8 Feb 2006 11:46:12 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33DD5142292 for ; Wed, 8 Feb 2006 11:46:12 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id E4A90D33A0F for ; Wed, 8 Feb 2006 14:46:10 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 14:46:10 -0500 X-Sasl-enc: cJZseOUqLIfYp/4LlrL0QQpP5/ted7a3Qd3BmLStVoHp 1139427969 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 9F45C571482 for ; Wed, 8 Feb 2006 14:46:09 -0500 (EST) Date: Wed, 08 Feb 2006 14:46:15 -0500 From: Cyrus Daboo To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: <2A4BF19B1CF404895FA5EA55@Cyrus-Daboo.local> In-Reply-To: <43EA4842.3020808@Royer.com> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA3C57.2@oracle.com> <43EA4842.3020808@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:46:12 -0000 Hi Doug, --On February 8, 2006 12:36:34 PM -0700 Doug Royer wrote: > The iTIP VFREEBUSY request is sent to a MAILTO url (the user), not a > calendar. And the users CUA determines the VFREEBUSY REPLY, not > the calendar. A CALDAV F/B is a calendar store request, not a > user request. The free-busy-query report we have right now is effectively targetted at calendar collections as opposed to calendar users. However, the CalDAV scheduling spec will allow iTIP style free-busy queries against calendar users (principles) and calendar users will be able to indicate which calendars should be examined for queries against them. -- 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 B3AD27F5C1 for ; Wed, 8 Feb 2006 11:45:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9D6AD1422BB for ; Wed, 8 Feb 2006 11:45:18 -0800 (PST) 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 32491-06 for ; Wed, 8 Feb 2006 11:45:18 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5542D142292 for ; Wed, 8 Feb 2006 11:45:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id ED26C3C8508 for ; Wed, 8 Feb 2006 20:43:34 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 9563F3C8507 for ; Wed, 8 Feb 2006 20:43:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43EA45C7.7050908@rpi.edu> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA45C7.7050908@rpi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13C89948-95EE-4BFD-8F06-B275F588032B@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 8 Feb 2006 20:45:09 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:45:18 -0000 On 8. Feb 2006, at 20:25 Uhr, Mike Douglass wrote: > Isn't free/busy the ideal way to display free time in a room? User or resource, doesn't matter. Its just some principal identified by a unique id (usually but not necessarily an [smtp] email address). > And shouldn't we allow a calendar per room rather than forcing each > room to be a pseudo-user? Whether you want to have a calendar per resource is your choice, but the resource must also be included in the iCalendar entity for further processing (just consider associated iMIP invitations). You cannot derive information from the collection context in a machine processable way. Resources are fully supported by iCalendar, see RFC 2445 section 4.2.3 and 4.8.1.10. I don't see the point in loosing that information? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 5811A7F62C for ; Wed, 8 Feb 2006 11:41:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 494381422BB for ; Wed, 8 Feb 2006 11:41:38 -0800 (PST) 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 06354-02 for ; Wed, 8 Feb 2006 11:41:38 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13A2C1422BA for ; Wed, 8 Feb 2006 11:41:38 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 84C8FD33AB3; Wed, 8 Feb 2006 14:41:36 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 14:41:36 -0500 X-Sasl-enc: B4+H3L4hzJYswHyxlWJgouWOz0vS913gga4atW9qMBSW 1139427695 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 773B657146F; Wed, 8 Feb 2006 14:41:33 -0500 (EST) Date: Wed, 08 Feb 2006 14:41:37 -0500 From: Cyrus Daboo To: Mike Douglass , CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: In-Reply-To: <43EA45C7.7050908@rpi.edu> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA45C7.7050908@rpi.edu> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:41:38 -0000 Hi Mike, --On February 8, 2006 2:25:59 PM -0500 Mike Douglass wrote: > Isn't free/busy the ideal way to display free time in a room? And > shouldn't we allow a calendar per room rather than forcing each room to > be a pseudo-user? Sure. I guess my point is that there is not always a one-to-one mapping between a calendar user or resource and an actual calendar (in the sense of a CalDAV calendar collection). One could also have one-to-many, many-to-one or many-to-many depending on the user case (e.g. the shared home calendar is an example of many-to-one - many users sharing the same data on one calendar). -- 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 384E17F62C for ; Wed, 8 Feb 2006 11:36:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 28E351422BA for ; Wed, 8 Feb 2006 11:36:39 -0800 (PST) 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 19987-08 for ; Wed, 8 Feb 2006 11:36:38 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 868141422B9 for ; Wed, 8 Feb 2006 11:36:38 -0800 (PST) Received: (qmail 16083 invoked from network); 8 Feb 2006 14:36:37 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 14:36:37 -0500 Message-ID: <43EA4842.3020808@Royer.com> Date: Wed, 08 Feb 2006 12:36:34 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> <43EA3C57.2@oracle.com> In-Reply-To: <43EA3C57.2@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040301040104040008030905" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 08 Feb 2006 19:36:39 -0000 This is a cryptographically signed message in MIME format. --------------ms040301040104040008030905 Content-Type: multipart/mixed; boundary="------------050200000404070103090807" This is a multi-part message in MIME format. --------------050200000404070103090807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit True, however CALDAV is not iTIP. The iTIP VFREEBUSY request is sent to a MAILTO url (the user), not a calendar. And the users CUA determines the VFREEBUSY REPLY, not the calendar. A CALDAV F/B is a calendar store request, not a user request. And his question was not how to you get the F/B time for a user. It was how can you tell a users F/B time from any calendar where the calendar user happens to be an ATTENDEE. The answer is - you can not. In addition to this, there is no way for the calling application to know if this is the complete set of busy time for the user without asking the user or the users CUA. So it could only ask which events the ATTENDEE is attending for 'this' calendar. Not the same as a USERS or CALENDARS F/B time. And his question was how do your represent in the store which ATTENDEEs are attending which instances of a multi instance event. In the original post that started this thread, it was falsely assumed that the contents of the store must match what is sent to all (each?) ATTENDEEs in a METHOD:REQUEST. His example clearly shows that it can not always match. With iTIP you can invite someone to a single instance of a recurring event. A calendar store has to be able to store multiple VEVENTs with the same UID and know that they are multiple VEVENT objects for the same version of the same UID. iTIP and 2445 were not designed with this in mind. The calendar store contents for a single UID, does not have to look like the METHOD:PUBLISH or any METHOD:REQUEST sent to individual ATTENDEEs and for the reason that Jeffrey pointed out, iTIP and 2445 were not designed to act as the file or data format for a calendar store. I think the most that could be hoped for is that the CALDAV server presents the data on one way for anonymous users, another for the calendar owner(s), and perhaps uniquely for an authenticated users. Exactly how the calendar owner(s) calling application stores multiple recurring attendees and request/reply status is yet to be defined by CALDAV. CAP addresses this issue by having a logical BOOKED and SCHEDULING states for objects. Bernard Desruisseaux wrote: > iTIP allows a "Calendar User" to request the free/busy information of > other "Calendar Users". > > From RFC 2446: > > > 3.3.2 REQUEST > > > > The "REQUEST" method in a "VFREEBUSY" calendar component is used to > > ask a "Calendar User" for their busy time information. The request > > may be for a busy time information bounded by a specific date and > > time interval. > > Cheers, > Bernard > > Cyrus Daboo wrote: > >> Hi Doug, >> >> --On February 8, 2006 10:31:29 AM -0700 Doug Royer >> wrote: >> >>> Free/Busy is for a calendar, not a person or ATTENDEE. >> >> >> >> That maybe how iCalendar perceives it, but in the real world actual >> calendar users perceive free-busy as being targeted at another user or >> resource - not a specific calendar. >> > > _______________________________________________ > 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 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------050200000404070103090807 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------050200000404070103090807-- --------------ms040301040104040008030905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDIwODE5MzYzNFowIwYJKoZIhvcNAQkEMRYEFImfD2AzuGWs09VIjtF1yUWA poVLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAJhjOZSQHTUCdL3N4fHDV21QEiwOSof7eibpIBUvFLAb7M25NwQ/k3q7JiRJazMtPxzu vgUUzSo7ZUZVqHfplDFf4oCC4ltdtiaK6rHyPpmihqamPyHxe0haAcBCe+tAE80xBHtx4vOh qGumSrVQ3LJu/plXFoygetWr1S6C3XQayBLiC1muMNV1zurHmfeseoLn27SCblnNX6/jCtNX HxCC0qzpIQKnzl3K371TTGB77KxNMICUjKQWW/kHI1VJxMc8IsAUgv3JNrqaQvmu36ciF0IQ TKA7OfSEqJmZrgtlCdM/vTtCZ0WDx848GtZj4eGQIOZ0mmuqlu58taVQnRcAAAAAAAA= --------------ms040301040104040008030905-- 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 EDECB7F5ED for ; Wed, 8 Feb 2006 11:26:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF3E61422BA for ; Wed, 8 Feb 2006 11:26:00 -0800 (PST) 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 25216-07 for ; Wed, 8 Feb 2006 11:26:00 -0800 (PST) Received: from smtp5.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D2351422B9 for ; Wed, 8 Feb 2006 11:26:00 -0800 (PST) Received: from [128.113.124.228] (blue-eyes-white-dragon-20.dynamic2.rpi.edu [128.113.124.228]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k18JPxqH018882 for ; Wed, 8 Feb 2006 14:25:59 -0500 Message-ID: <43EA45C7.7050908@rpi.edu> Date: Wed, 08 Feb 2006 14:25:59 -0500 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> In-Reply-To: <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 19:26:01 -0000 Isn't free/busy the ideal way to display free time in a room? And shouldn't we allow a calendar per room rather than forcing each room to be a pseudo-user? Cyrus Daboo wrote: > Hi Doug, > > --On February 8, 2006 10:31:29 AM -0700 Doug Royer > wrote: > >> Free/Busy is for a calendar, not a person or ATTENDEE. > > > That maybe how iCalendar perceives it, but in the real world actual > calendar users perceive free-busy as being targeted at another user or > resource - not a specific calendar. > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 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 8BFAD7F626 for ; Wed, 8 Feb 2006 10:45:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7DF6D1422BC for ; Wed, 8 Feb 2006 10:45:59 -0800 (PST) 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 31433-01 for ; Wed, 8 Feb 2006 10:45:59 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 419DA1422BB for ; Wed, 8 Feb 2006 10:45:59 -0800 (PST) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k18IjsHG004744; Wed, 8 Feb 2006 12:45:54 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k18Ijrse028770; Wed, 8 Feb 2006 11:45:53 -0700 Received: from [144.23.219.186] (dhcp-ca-montreal-144-23-219-186.ca.oracle.com [144.23.219.186]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k18IjmNG028728 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 8 Feb 2006 11:45:49 -0700 Message-ID: <43EA3C57.2@oracle.com> Date: Wed, 08 Feb 2006 13:45:43 -0500 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> In-Reply-To: <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Wed, 08 Feb 2006 18:45:59 -0000 iTIP allows a "Calendar User" to request the free/busy information of other "Calendar Users". From RFC 2446: > 3.3.2 REQUEST > > The "REQUEST" method in a "VFREEBUSY" calendar component is used to > ask a "Calendar User" for their busy time information. The request > may be for a busy time information bounded by a specific date and > time interval. Cheers, Bernard Cyrus Daboo wrote: > Hi Doug, > > --On February 8, 2006 10:31:29 AM -0700 Doug Royer wrote: > >> Free/Busy is for a calendar, not a person or ATTENDEE. > > > That maybe how iCalendar perceives it, but in the real world actual > calendar users perceive free-busy as being targeted at another user or > resource - not a specific calendar. > 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 D5CD27F5ED for ; Wed, 8 Feb 2006 09:46:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C63781422B8 for ; Wed, 8 Feb 2006 09:46:56 -0800 (PST) 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 20647-02 for ; Wed, 8 Feb 2006 09:46:56 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91B431422B6 for ; Wed, 8 Feb 2006 09:46:56 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0E226D336EA for ; Wed, 8 Feb 2006 12:46:55 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Wed, 08 Feb 2006 12:46:55 -0500 X-Sasl-enc: d0QRx0qLURk5YUivXhmw0OOOnYBqBZJt16/5iGdGKJI8 1139420814 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id CA3A357154B for ; Wed, 8 Feb 2006 12:46:52 -0500 (EST) Date: Wed, 08 Feb 2006 12:46:52 -0500 From: Cyrus Daboo To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: <10DD5A5CCF1083D8B5025C96@Cyrus-Daboo.local> In-Reply-To: <43EA2AF1.7060207@Royer.com> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43EA2AF1.7060207@Royer.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Wed, 08 Feb 2006 17:46:57 -0000 Hi Doug, --On February 8, 2006 10:31:29 AM -0700 Doug Royer wrote: > Free/Busy is for a calendar, not a person or ATTENDEE. That maybe how iCalendar perceives it, but in the real world actual calendar users perceive free-busy as being targeted at another user or resource - not a specific calendar. -- 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 8DADC7F5AC for ; Wed, 8 Feb 2006 09:31:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E4A21422B8 for ; Wed, 8 Feb 2006 09:31:32 -0800 (PST) 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 13543-01 for ; Wed, 8 Feb 2006 09:31:32 -0800 (PST) Received: from pjag.com (Intellical.net [217.160.241.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E655D1422B6 for ; Wed, 8 Feb 2006 09:31:31 -0800 (PST) Received: (qmail 9909 invoked from network); 8 Feb 2006 12:31:30 -0500 Received: from localhost (HELO ?192.168.168.10?) (127.0.0.1) by localhost with SMTP; 8 Feb 2006 12:31:30 -0500 Message-ID: <43EA2AF1.7060207@Royer.com> Date: Wed, 08 Feb 2006 10:31:29 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010303020905060508000407" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CalDAV DevList 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, 08 Feb 2006 17:31:32 -0000 This is a cryptographically signed message in MIME format. --------------ms010303020905060508000407 Content-Type: multipart/mixed; boundary="------------040609080807030707020906" This is a multi-part message in MIME format. --------------040609080807030707020906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Free/Busy is for a calendar, not a person or ATTENDEE. Helge Hess wrote: > On Feb 7, 2006, at 23:11, Cyrus Daboo wrote: > >> In particular, you cannot use a shared calendar for free-busy lookups >> where some events on the calendar affect one set of users, and others >> different sets. Since f-b is defined by the TRANSP and STATUS >> properties, and since iCalendar does not have a way to have >> user-specific variants of properties, you cannot separate out f-b time >> for each user. > > > Just for the record, I still dislike this "interpretation". I would > definitely change CalDAV 7.8 so that it allows the client to specify a > user in the request and that the freebusy processing includes processing > the attendee status. > Its not that iCal can't represent the wished for thing. > >> Thus what you really need to do in this situation is have two home >> calendars: one for Jenny and one for Kevin - allowing f-b to be >> determined separately for each. > > > Isn't it rather strange to enforce a copy just because we don't want to > include the attendee status in the freebusy request? > Doesn't make this a freebusy query on a collection rather useless since > it doesn't say anything about an actual user? > > Greets, > Helge -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040609080807030707020906 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------040609080807030707020906-- --------------ms010303020905060508000407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDIwODE3MzEyOVowIwYJKoZIhvcNAQkEMRYEFC/do2rxdNsDV2OrIhyRhPcF uvkWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAHg4S/+z0NcdGja0ld0x5xLj6xu9O/xYjHxaeUFuTb12DNBUiUHPR+vRrWO70cB+7WGM 6foAoifwWfaITtv5Aj8ujAdrDBrddZNDiROmUeJkwIbHVVtJnnvrHBkpTYcyKzT91ztlJXhd 8xOsZpuKgLB0rMtmCVOMh0ME5iv91/plNw1U5DGCh4ocj5vxI0h0cIpnvS1cpkKpcS38pCYy IrfT7Ug9mXdu5+uFrpylPIrGdF7BBr+nT8wC5AWz7pPEqFvrg6ulZQeqZGfnJpBRrOQg7AM/ ScWx2TAxbz4kuS9AIpKGYzSL+VJu51imyuUetHmx03TkjhZJm2jBnfhNjEEAAAAAAAA= --------------ms010303020905060508000407-- 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 EF0A67F63A for ; Tue, 7 Feb 2006 15:54:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DFA1F142283 for ; Tue, 7 Feb 2006 15:54:45 -0800 (PST) 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 06881-03 for ; Tue, 7 Feb 2006 15:54:45 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 68F35142264 for ; Tue, 7 Feb 2006 15:54:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 73A003C732F for ; Wed, 8 Feb 2006 00:52:56 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 114F13C7317 for ; Wed, 8 Feb 2006 00:52:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <9718AF43-391D-4A74-8C00-3A04165F641D@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <1FCB87A2-224F-4213-8F69-A016262645A2@osafoundation.org> <9718AF43-391D-4A74-8C00-3A04165F641D@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 8 Feb 2006 00:54:43 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 07 Feb 2006 23:54:46 -0000 On Feb 8, 2006, at 0:23, Lisa Dusseault wrote: > We keep an "Office Calendar" at OSAF of the regularly-scheduled > meetings: staff meeting, ops meeting, apps team meeting, design > meeting and bug council. We add occasional seminars to that calendar > too so it's not just recurring. It would be helpful to look at that > calendar to see some time that hadn't yet been booked for anything > worth noting. > > (Also note that calendar doesn't map to a resource because although > several meeting rooms are booked for those meetings, we share those > meeting rooms with other organizations.) We do this by booking the events in that calendar to a certain 'group' attendee, eg for company wide meetings to the 'all intranet' group. The physical location (collection) is irrelevant here, its still just an attendee, even if its a group attendee. I think its important in the context of freebusy to be aware that you cant 'look at that calendar' using freebusy. You can only see whether there is a meeting or not, not who is attending nor what the meeting is about. Which makes it rather useless except for the case when you know the participant (per-attendee freebusy). If you want to 'look' at the calendar, you would issue a regular read request containing relevant details, not a freebusy query. I think (not sure) Outlook can actually do this if you have read access to the private calendar of the user being scheduled. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 66D987F66D for ; Tue, 7 Feb 2006 15:41:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 41948142283 for ; Tue, 7 Feb 2006 15:41:38 -0800 (PST) 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 07701-02 for ; Tue, 7 Feb 2006 15:41:38 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id A75D7142262 for ; Tue, 7 Feb 2006 15:41:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A45843C7382 for ; Wed, 8 Feb 2006 00:39:48 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 344EB3C7367 for ; Wed, 8 Feb 2006 00:39:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <43E92B3C.9010105@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <43E92B3C.9010105@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 8 Feb 2006 00:41:36 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 07 Feb 2006 23:41:38 -0000 On Feb 8, 2006, at 0:20, Jeffrey Harris wrote: > Perhaps I should step back for a second. OSAF wants to implement > references to subsets of recurring events in a no-invitation, our > client > (Chandler) doesn't even know your email address, scheduling. I don't see how you can properly implement iCalendar w/o having the email address of the user (even if its a fake but unique one just to make iCalendar happy). I absolutly agree that you don't need iTIP or iMIP for scheduling on shared collections. Indeed this is what we exclusively do in OGo (which is rather annoying in our Outlook connector since you do not "send" appointments, but just change your status and "save" ;-). > In our model, the semantic meaning of the presence of an event in a > collection is entirely social, i.e., it's undesirable to assume that a > particular collection is connected to a particular person or email > address. Thats not "your model", thats the CalDAV model ;-) And basically my point - the connection to a person is done by the attendee and organizer properties of iCalendar and has nothing to do with the WebDAV collection at all. > We'll also have a more full complex invitation workflow eventually, but > we don't want to require users to use it. Which makes perfect sense. > If no-invitation scheduling is something that only OSAF thinks is > useful > and important, we should probably just use the X-OSAF-INCLUDE hack I > mentioned in > http://lists.osafoundation.org/pipermail/ietf-caldav/2006-January/ > 000651.html I don't like hacks. Using a standard protocol can have limitations and you should obey the data model imposed, even if it means more work for you (in this case synchronisation of necessary duplicates). > With that said, here's how I imagine a family using one home calendar. > Yes, CalDAV f/b reports don't work, instead, everyone just assumes the > absence of an event on the home calendar outside normal business hours > implies free time. Which is simply useless if that collection is shared between Jenny and Kevin ... > When Jenny has a dentist appointment, she puts it on the home calendar > with a title like "Jenny dentist appointment", so Kevin knows he can go > see a movie with friends, but he can't schedule a family trip to the > beach for that weekend. But he could schedule an own dentist appointment. If he wants to schedule the family trip, he needs to query the collection for the freebusy of him _and_ Jenny. And its the task of the client to make that easy :-) For example by making it easy to have a 'family' group which can be scheduled and gets flattened to the proper attendee queries. Its more work in the client but this is possible with standard techniques. > So, in summary, I don't think invitation workflow should be required > for > people who are perfectly happy without it. Again, total agreement over here :-) Invitations usually suck because they get moved to trash leaving the appointments in an uncommitted state. Notifications with the possibility to reject rule. > Mostly, CalDAV doesn't require this, which is great. Providing only > ATTENDEE based methods to interoperably persist a subset of a > recurring event just seems unfortunate to me. Yeah, a standard can't please everyone :-) But it _is_ possible, its just more work for the client. > What would be the negative impact of allowing a CalDAV server to store > VEVENTs with one or many RECURRENCE-IDs, but no RRULE or RDATEs? Data model inconsistency and incomplete data. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 6B1127F604 for ; Tue, 7 Feb 2006 15:37:06 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 58B16142262 for ; Tue, 7 Feb 2006 15:37:06 -0800 (PST) Message-ID: <43E92F20.5060504@osafoundation.org> Date: Tue, 07 Feb 2006 15:37:04 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <1946200387c7108ab6705da4c7bf3b82@opengroupware.org> In-Reply-To: <1946200387c7108ab6705da4c7bf3b82@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2006 23:37:06 -0000 Hi Folks, >> In the home collection, I suppose Jenny could publish the full RRULE >> with no attendees, and set the attendee to jenny@example.com. > > Why would she set the attendee of the _full_ rrule to herself? This > doesn't make sense unless she actually plans to attend every instance. ... > I can't follow this paragraph. > > Who is John? Someone else? Sorry, that message was poorly edited, I should've waited to send it till after lunch. I accidentally omitted the phrase "for one occurrence". And John is supposed to be Kevin. > Hm, I honestly have a hard time to explain this since it seems rather > obvious to me :-) The server and the client needs consistent data and > this can only be achieved if a single uid matches the same information. I don't think this concluding bit ("can only be") is necessarily true. Just as two CalDAV collections can contain non-recurring VEVENTs whose intersection is non-null, I can imagine various collections containing different subsets of a recurring event. That's certainly not the way things work now, I'd just like to understand what would be wrong with allowing this. > How can a client accessing the b) collection know about all the base > rrule information (assuming that the exception only contains the > changes)? One would need to add a URL pointing to the rrule resource (or > the folder which contains the resource) instead of relying on just the uid. If no RRULEs or RDATEs were specified, yup, all the base non-recurring properties would need to be duplicated. >> It's not that I want CalDAV to help with synchronization between >> collections (that would be really hard), I'm content for the client to >> deal with conflicts and sync. What I'd like is for CalDAV to have a >> standard way to semantically represent a subset of a recurring event >> without that implying state change to the full event. > > Well, just copy the relevant data of the event and sync against the base > collection in the client to keep them in-sync. That would be a reasonable way to do it, except that I don't want clients getting the subset from the server to lose the relationship between the full recurring event and the subset. Sincerely, Jeffrey 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 204C97F6F0 for ; Tue, 7 Feb 2006 15:23:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 115A4142289 for ; Tue, 7 Feb 2006 15:23:21 -0800 (PST) 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 20026-04; Tue, 7 Feb 2006 15:23:20 -0800 (PST) Received: from [192.168.101.253] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A106E142283; Tue, 7 Feb 2006 15:23:20 -0800 (PST) In-Reply-To: References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <1FCB87A2-224F-4213-8F69-A016262645A2@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9718AF43-391D-4A74-8C00-3A04165F641D@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Tue, 7 Feb 2006 15:23:17 -0800 To: Helge Hess X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Tue, 07 Feb 2006 23:23:21 -0000 We keep an "Office Calendar" at OSAF of the regularly-scheduled meetings: staff meeting, ops meeting, apps team meeting, design meeting and bug council. We add occasional seminars to that calendar too so it's not just recurring. It would be helpful to look at that calendar to see some time that hadn't yet been booked for anything worth noting. (Also note that calendar doesn't map to a resource because although several meeting rooms are booked for those meetings, we share those meeting rooms with other organizations.) Lisa On Feb 7, 2006, at 3:18 PM, Helge Hess wrote: > On Feb 8, 2006, at 0:12, Lisa Dusseault wrote: >> For the free-busy request with no user specified (what's in CalDAV >> today), it simply defaults to finding the sum total free-busy time >> for the calendar regardless of who's attending what. That's not >> useless for a shared calendar > > I really don't want to discuss that to death, but could you outline > a use case for a calendar based freebusy file which is independend > from the attendees? > I have a hard time finding one since I never use "calendars" in > scheduling but always users, resources or groups of them. > > Thanks a lot, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > _______________________________________________ > 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 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 85AC27F6F0 for ; Tue, 7 Feb 2006 15:20:30 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5EC27142285 for ; Tue, 7 Feb 2006 15:20:30 -0800 (PST) Message-ID: <43E92B3C.9010105@osafoundation.org> Date: Tue, 07 Feb 2006 15:20:28 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> In-Reply-To: <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2006 23:20:30 -0000 Hi Cyrus, >> Jenny and Kevin share one home calendar, Kevin doesn't have a >> separate home calendar. I do mean that having a VEVENT on the home >> calendar implies that Kevin is attending. > > Well this is the problem, depending on exactly what you are intending > to do. iCalendar itself does not really specify how you deal with a > shared calendar - in fact it makes shared calendars (ones where you > need to derive information separately for each person it is shared > to) hard. In particular, you cannot use a shared calendar for > free-busy lookups where some events on the calendar affect one set of > users, and others different sets. Since f-b is defined by the TRANSP > and STATUS properties, and since iCalendar does not have a way to > have user-specific variants of properties, you cannot separate out > f-b time for each user. [snip] > Note the above is just my opinion on how I think the scenario you > describe should work. The fact that it involves iTIP does appear to > make it more complex than simply 'sharing' the same data. Sorry, involving iTIP in this was probably a mistake. OSAF is, eventually, going to try to harmonize our outside-the-mainstream view of invitations, iTIP, and sharing to a CalDAV server. We're not nearly there yet, so I'll set iTIP aside for now. Perhaps I should step back for a second. OSAF wants to implement references to subsets of recurring events in a no-invitation, our client (Chandler) doesn't even know your email address, scheduling. The motivation for this is that in our UI, users are encouraged to have lots of CalDAV collections. They can add events from one to any other writable collection, including someone else's shared calendar. In our model, the semantic meaning of the presence of an event in a collection is entirely social, i.e., it's undesirable to assume that a particular collection is connected to a particular person or email address. In this way, lightweight scheduling can happen without using iTIP. We'll also have a more full complex invitation workflow eventually, but we don't want to require users to use it. It was on my plate (it's now on someone else's plate, but that's not really important) to allow users to add subsets of recurring events to other collections. If no-invitation scheduling is something that only OSAF thinks is useful and important, we should probably just use the X-OSAF-INCLUDE hack I mentioned in http://lists.osafoundation.org/pipermail/ietf-caldav/2006-January/000651.html I'm OK with that, I don't want to spend too much list time on this unless other people see this as useful to a broader audience. With that said, here's how I imagine a family using one home calendar. Yes, CalDAV f/b reports don't work, instead, everyone just assumes the absence of an event on the home calendar outside normal business hours implies free time. When Jenny has a dentist appointment, she puts it on the home calendar with a title like "Jenny dentist appointment", so Kevin knows he can go see a movie with friends, but he can't schedule a family trip to the beach for that weekend. So, in summary, I don't think invitation workflow should be required for people who are perfectly happy without it. Mostly, CalDAV doesn't require this, which is great. Providing only ATTENDEE based methods to interoperably persist a subset of a recurring event just seems unfortunate to me. What would be the negative impact of allowing a CalDAV server to store VEVENTs with one or many RECURRENCE-IDs, but no RRULE or RDATEs? Sincerely, Jeffrey 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 9C5DF7F6F0 for ; Tue, 7 Feb 2006 15:18:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C7DA142289 for ; Tue, 7 Feb 2006 15:18:28 -0800 (PST) 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 31718-02 for ; Tue, 7 Feb 2006 15:18:28 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43CFD142285 for ; Tue, 7 Feb 2006 15:18:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 22D203C71B8 for ; Wed, 8 Feb 2006 00:16:39 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 9F21D3C6F02 for ; Wed, 8 Feb 2006 00:16:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <1FCB87A2-224F-4213-8F69-A016262645A2@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> <1FCB87A2-224F-4213-8F69-A016262645A2@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 8 Feb 2006 00:18:25 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 07 Feb 2006 23:18:28 -0000 On Feb 8, 2006, at 0:12, Lisa Dusseault wrote: > For the free-busy request with no user specified (what's in CalDAV > today), it simply defaults to finding the sum total free-busy time for > the calendar regardless of who's attending what. That's not useless > for a shared calendar I really don't want to discuss that to death, but could you outline a use case for a calendar based freebusy file which is independend from the attendees? I have a hard time finding one since I never use "calendars" in scheduling but always users, resources or groups of them. Thanks a lot, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 1DA4B7F6E1 for ; Tue, 7 Feb 2006 15:12:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0D95214228A for ; Tue, 7 Feb 2006 15:12:58 -0800 (PST) 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 28411-08; Tue, 7 Feb 2006 15:12:57 -0800 (PST) Received: from [192.168.101.253] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A5979142285; Tue, 7 Feb 2006 15:12:57 -0800 (PST) In-Reply-To: References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FCB87A2-224F-4213-8F69-A016262645A2@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Tue, 7 Feb 2006 15:12:49 -0800 To: Helge Hess X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Tue, 07 Feb 2006 23:12:58 -0000 On Feb 7, 2006, at 2:46 PM, Helge Hess wrote: > On Feb 7, 2006, at 23:11, Cyrus Daboo wrote: >> In particular, you cannot use a shared calendar for free-busy >> lookups where some events on the calendar affect one set of users, >> and others different sets. Since f-b is defined by the TRANSP and >> STATUS properties, and since iCalendar does not have a way to have >> user-specific variants of properties, you cannot separate out f-b >> time for each user. > > Just for the record, I still dislike this "interpretation". I would > definitely change CalDAV 7.8 so that it allows the client to > specify a user in the request and that the freebusy processing > includes processing the attendee status. > Its not that iCal can't represent the wished for thing. I agree with Helge, however I propose that this be an extension to the free-busy request. For the free-busy request with no user specified (what's in CalDAV today), it simply defaults to finding the sum total free-busy time for the calendar regardless of who's attending what. That's not useless for a shared calendar and it's a fine default behavior for an individual calendar. Lisa 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 D44B17F695 for ; Tue, 7 Feb 2006 14:46:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C5471142285 for ; Tue, 7 Feb 2006 14:46:22 -0800 (PST) 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 29282-01 for ; Tue, 7 Feb 2006 14:46:22 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 52F2A142283 for ; Tue, 7 Feb 2006 14:46:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 18F863C7050 for ; Tue, 7 Feb 2006 23:45:26 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id AD7923C67A8 for ; Tue, 7 Feb 2006 23:45:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Tue, 7 Feb 2006 23:46:19 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 07 Feb 2006 22:46:22 -0000 On Feb 7, 2006, at 23:11, Cyrus Daboo wrote: > In particular, you cannot use a shared calendar for free-busy lookups > where some events on the calendar affect one set of users, and others > different sets. Since f-b is defined by the TRANSP and STATUS > properties, and since iCalendar does not have a way to have > user-specific variants of properties, you cannot separate out f-b time > for each user. Just for the record, I still dislike this "interpretation". I would definitely change CalDAV 7.8 so that it allows the client to specify a user in the request and that the freebusy processing includes processing the attendee status. Its not that iCal can't represent the wished for thing. > Thus what you really need to do in this situation is have two home > calendars: one for Jenny and one for Kevin - allowing f-b to be > determined separately for each. Isn't it rather strange to enforce a copy just because we don't want to include the attendee status in the freebusy request? Doesn't make this a freebusy query on a collection rather useless since it doesn't say anything about an actual user? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 4D4CD7F705; Tue, 7 Feb 2006 14:11:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 336EA14226B; Tue, 7 Feb 2006 14:11:37 -0800 (PST) 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 24333-05; Tue, 7 Feb 2006 14:11:37 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id D3FF2142266; Tue, 7 Feb 2006 14:11:36 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4290BD3405C; Tue, 7 Feb 2006 17:11:35 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Tue, 07 Feb 2006 17:11:35 -0500 X-Sasl-enc: DjhMkkEqCZ/tNi/XLNDzt7tF0CqdMgDpN6mYtChI1SPx 1139350294 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id E6868571506; Tue, 7 Feb 2006 17:11:32 -0500 (EST) Date: Tue, 07 Feb 2006 17:11:34 -0500 From: Cyrus Daboo To: Jeffrey Harris , CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: <3443CBF4E6A6A2EE03C5E446@Cyrus-Daboo.local> In-Reply-To: <43E917A3.7010704@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> <43E917A3.7010704@osafoundation.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 07 Feb 2006 22:11:37 -0000 Hi Jeffrey, --On February 7, 2006 1:56:51 PM -0800 Jeffrey Harris wrote: > Jenny and Kevin share one home calendar, Kevin doesn't have a separate > home calendar. I do mean that having a VEVENT on the home calendar > implies that Kevin is attending. Well this is the problem, depending on exactly what you are intending to do. iCalendar itself does not really specify how you deal with a shared calendar - in fact it makes shared calendars (ones where you need to derive information separately for each person it is shared to) hard. In particular, you cannot use a shared calendar for free-busy lookups where some events on the calendar affect one set of users, and others different sets. Since f-b is defined by the TRANSP and STATUS properties, and since iCalendar does not have a way to have user-specific variants of properties, you cannot separate out f-b time for each user. Thus what you really need to do in this situation is have two home calendars: one for Jenny and one for Kevin - allowing f-b to be determined separately for each. They can each overlay the other's calendar in their client to give the perception of one shared calendar. When they both attend the same event, the person that 'books' it will need to use iTIP to 'schedule' the other person to attendee. This will mean that each home calendar has its own iTIP 'instance' of the event, but a smart client can suppress display of multiple iTIP 'instances' when it does its multi-calendar overlay. The other alternative is to use metadata to indicate separate f-b status - that will of course not be interoperable as there is no way to transport that data along with iCal right now. Its also not easy to do in CalDAV since WebDAV does not have per-user properties on resources. Note the above is just my opinion on how I think the scenario you describe should work. The fact that it involves iTIP does appear to make it more complex than simply 'sharing' the same data. -- 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 28F007F719 for ; Tue, 7 Feb 2006 13:56:53 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0B703142266 for ; Tue, 7 Feb 2006 13:56:53 -0800 (PST) Message-ID: <43E917A3.7010704@osafoundation.org> Date: Tue, 07 Feb 2006 13:56:51 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> In-Reply-To: <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 07 Feb 2006 21:56:53 -0000 Hi Cyrus, >> Suppose Jenny has a work calendar and a home calendar. On February 10, >> she's going to one instance of a recurring concert series (whose >> schedule was conveniently published in an iCalendar stream) with her >> work. On February 17, she's going to a different instance with her >> husband, Kevin. >> >> In the home collection, I suppose Jenny could publish the full RRULE >> with no attendees, and set the attendee to jenny@example.com. How, then >> should John's client determine that what this means is that the instance >> with attendee jenny@example.com is the relevant instance (i.e., that >> ATTENDEE:mailto:jenny@example.com implies >> ATTENDEE:mailto:kevin@example.com)? > > I'm not quite sure what your intention is with using the ATTENDEE > property here. Do you mean that to imply that the VEVENT on the home > calendar is supposed to indicate one being attended by Jenny and thus by > implication Kevin? > > I don;t think the situation you describe is specified well enough. For > example, does Kevin have his own home calendar, or do Jenny and Kevin > both use the same home calendar? Sorry, you're right, I didn't specify clearly enough. Jenny and Kevin share one home calendar, Kevin doesn't have a separate home calendar. I do mean that having a VEVENT on the home calendar implies that Kevin is attending. I don't think the ATTENDEE property is a good match here, I'm trying to work through what I think Helge's proposing. The John above was a goof, it should be Kevin, I changed my John to Kevin, but missed one John reference :). Sincerely, Jeffrey 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 98E127F697 for ; Tue, 7 Feb 2006 13:16:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 89A5C142283 for ; Tue, 7 Feb 2006 13:16:39 -0800 (PST) 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 19328-03 for ; Tue, 7 Feb 2006 13:16:39 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00043142267 for ; Tue, 7 Feb 2006 13:16:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D0B243C707F for ; Tue, 7 Feb 2006 22:15:41 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-243-136.reverse.mdcc-fun.de [213.211.243.136]) by mail.mdlink.net (Postfix) with ESMTP id 6A6FE3C6BC4 for ; Tue, 7 Feb 2006 22:15:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <43E8FF4A.7010100@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1946200387c7108ab6705da4c7bf3b82@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Tue, 7 Feb 2006 22:16:36 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: 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: Tue, 07 Feb 2006 21:16:39 -0000 On Feb 7, 2006, at 21:12, Jeffrey Harris wrote: > Suppose Jenny has a work calendar and a home calendar. On February 10, > she's going to one instance of a recurring concert series (whose > schedule was conveniently published in an iCalendar stream) with her > work. On February 17, she's going to a different instance with her > husband, Kevin. Ok. So its a recurring event (initially with no attendees at all) with two exceptions (one with Jenny and Kevin as the attendees, the other one with Jenny and her work-group as attendees). > In the home collection, I suppose Jenny could publish the full RRULE > with no attendees, and set the attendee to jenny@example.com. Why would she set the attendee of the _full_ rrule to herself? This doesn't make sense unless she actually plans to attend every instance. > How, then should John's client determine that what this means is that > the instance with attendee jenny@example.com is the relevant instance > (i.e., that ATTENDEE:mailto:jenny@example.com implies > ATTENDEE:mailto:kevin@example.com)? I can't follow this paragraph. Who is John? Someone else? Why would a ATTENDEE:mailto:jenny@example.com every imply ATTENDEE:mailto:kevin@example.com? >> I think I begin to understand what you want to do: >> >> a) you have a rrule event as one resource in a public calendar >> collection >> >> b) you want to store the exceptions (with the different attendee) in >> the private calendar collection of 'Jenny' but keep referring the >> public event by using its UID >> >> Honestly I don't think that this makes a lot of sense for various >> reasons. > > I'm interested in ways this might not be workable, I can imagine > problems, but I'm not sure what you're referring to. Hm, I honestly have a hard time to explain this since it seems rather obvious to me :-) The server and the client needs consistent data and this can only be achieved if a single uid matches the same information. How can a client accessing the b) collection know about all the base rrule information (assuming that the exception only contains the changes)? One would need to add a URL pointing to the rrule resource (or the folder which contains the resource) instead of relying on just the uid. To summarize: I think you really want to have two copies/resource of the rrule with different exceptions. So that the work people don't see Jenny going out with her husband and the reverse. Basically a per-exception access permission. Personally I would suggest that you really copy the full event to post collections, including the base rrule. The client can then do "smart stuff" in a view combining both collections based on the same 'uid' (but it _really_ needs to be smart here to make this useful). Having inter-collection references really would complicate the protocol significantly. Eg if a client would ask the b) collection for a flattened set of events for a given timerange, the server would need to query the a) collection to find the required base information. Maybe I miss something. >> CalDAV doesn't really help you with keeping events consistent _across_ >> collections. The CalDAV rules (like uid<->resource mapping) are all >> focused on a single collection (correct me if I'm wrong ...). > It's not that I want CalDAV to help with synchronization between > collections (that would be really hard), I'm content for the client to > deal with conflicts and sync. What I'd like is for CalDAV to have a > standard way to semantically represent a subset of a recurring event > without that implying state change to the full event. Well, just copy the relevant data of the event and sync against the base collection in the client to keep them in-sync. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 2C5947F697; Tue, 7 Feb 2006 13:12:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 166E814228A; Tue, 7 Feb 2006 13:12:18 -0800 (PST) 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 15702-06; Tue, 7 Feb 2006 13:12:17 -0800 (PST) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id D153D14226E; Tue, 7 Feb 2006 13:12:17 -0800 (PST) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 789F7D33DDF; Tue, 7 Feb 2006 16:12:16 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Tue, 07 Feb 2006 16:12:16 -0500 X-Sasl-enc: BnhUiSZvYeItfRoVFONWa9ALhnJn3DEf/Gwb7w5x0dnX 1139346735 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 7D5A657146C; Tue, 7 Feb 2006 16:12:12 -0500 (EST) Date: Tue, 07 Feb 2006 16:12:13 -0500 From: Cyrus Daboo To: Jeffrey Harris , Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Message-ID: <33E5A7E5F6D6A8FC72C56AF7@Cyrus-Daboo.local> In-Reply-To: <43E8FF4A.7010100@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> <43E8FF4A.7010100@osafoundation.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList 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: Tue, 07 Feb 2006 21:12:18 -0000 Hi Jeffrey, --On February 7, 2006 12:12:58 PM -0800 Jeffrey Harris wrote: > Suppose Jenny has a work calendar and a home calendar. On February 10, > she's going to one instance of a recurring concert series (whose > schedule was conveniently published in an iCalendar stream) with her > work. On February 17, she's going to a different instance with her > husband, Kevin. > > In the home collection, I suppose Jenny could publish the full RRULE > with no attendees, and set the attendee to jenny@example.com. How, then > should John's client determine that what this means is that the instance > with attendee jenny@example.com is the relevant instance (i.e., that > ATTENDEE:mailto:jenny@example.com implies > ATTENDEE:mailto:kevin@example.com)? I'm not quite sure what your intention is with using the ATTENDEE property here. Do you mean that to imply that the VEVENT on the home calendar is supposed to indicate one being attended by Jenny and thus by implication Kevin? I don;t think the situation you describe is specified well enough. For example, does Kevin have his own home calendar, or do Jenny and Kevin both use the same home calendar? -- 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 989307F628 for ; Tue, 7 Feb 2006 12:12:59 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6183B14226B; Tue, 7 Feb 2006 12:12:59 -0800 (PST) Message-ID: <43E8FF4A.7010100@osafoundation.org> Date: Tue, 07 Feb 2006 12:12:58 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: CalDAV DevList 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: Tue, 07 Feb 2006 20:12:59 -0000 Hi Helge, Picking up this thread after long silence, I got distracted by other work... To summarize the old conversation, I've been wishing there was a standard way in CalDAV to represent a subset of a recurring event, Chandler is going to implement something like this to meet our recurrence requirements. Helge suggested that the appropriate way to do this when referring to a scheduled meeting with varying attendees is to change the attendee property for selected recurrence IDs. Now, getting back to the specifics of a use case involving Jenny, who wants to mark in her personal calendar two meetings of a recurring meeting: Helge Hess wrote: > What I don't understand is why Jenny doesn't update the resource > containing the rrule? Why do you need to create a _new_ resource just > containing the exceptions? > > [actually I can imagine situations, eg if the public resource is write > protected, but in this case you would probably need to resort to copy > the event and keep it in sync by other means, eg iMIP messages to the > organizer, which should have write access] I think I may have confused the issue by referring to a use case that maps easily to iMIP. I didn't perfectly understand the way iMIP would handle varying attendance, now I think I'm clear, thanks for the help. However, iMIP was really a small subset of the problem space I'm interested in. Calendar sharing and invitations have overlap, but they're really quite different. Here's a use case that might illuminate better the problem. Suppose Jenny has a work calendar and a home calendar. On February 10, she's going to one instance of a recurring concert series (whose schedule was conveniently published in an iCalendar stream) with her work. On February 17, she's going to a different instance with her husband, Kevin. In the home collection, I suppose Jenny could publish the full RRULE with no attendees, and set the attendee to jenny@example.com. How, then should John's client determine that what this means is that the instance with attendee jenny@example.com is the relevant instance (i.e., that ATTENDEE:mailto:jenny@example.com implies ATTENDEE:mailto:kevin@example.com)? A reasonable heuristic could be determined for the two-people-sharing case, but I think if more people are sharing, things quickly get out of hand. I think it would be preferable if there were an attendee-neutral way to specify a subset. > I think I begin to understand what you want to do: > > a) you have a rrule event as one resource in a public calendar > collection > > b) you want to store the exceptions (with the different attendee) in > the private calendar collection of 'Jenny' but keep referring the > public event by using its UID > > Honestly I don't think that this makes a lot of sense for various > reasons. I'm interested in ways this might not be workable, I can imagine problems, but I'm not sure what you're referring to. > CalDAV doesn't really help you with keeping events consistent _across_ > collections. The CalDAV rules (like uid<->resource mapping) are all > focused on a single collection (correct me if I'm wrong ...). It's not that I want CalDAV to help with synchronization between collections (that would be really hard), I'm content for the client to deal with conflicts and sync. What I'd like is for CalDAV to have a standard way to semantically represent a subset of a recurring event without that implying state change to the full event. Thanks for engaging about this, Helge. Sincerely, Jeffrey