Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id F09947F52F for ; Tue, 31 May 2005 17:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 7990A142260 for ; Tue, 31 May 2005 17:36:32 -0700 (PDT) Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09749-01 for ; Tue, 31 May 2005 17:36:32 -0700 (PDT) Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 0385B14225E for ; Tue, 31 May 2005 17:36:31 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by agminet04.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j510b4TF012101 for ; Tue, 31 May 2005 19:37:05 -0500 Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j510b4S3008548; Tue, 31 May 2005 18:37:04 -0600 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-247.vpn.oracle.com [141.144.96.247]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j510b1Ri008384; Tue, 31 May 2005 18:37:04 -0600 Message-ID: <429D032D.5050401@oracle.com> Date: Tue, 31 May 2005 20:37:01 -0400 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 Content-Type: multipart/mixed; boundary="------------060001070602020500020206" 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: Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-desruisseaux-caldav-sched-00.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, 01 Jun 2005 00:36:39 -0000 This is a multi-part message in MIME format. --------------060001070602020500020206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-desruisseaux-caldav-sched-00.txt Date: Tue, 31 May 2005 15:49:56 -0400 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 : Scheduling Extensions to CalDAV Author(s) : B. Desruisseaux, et al. Filename : draft-desruisseaux-caldav-sched-00.txt Pages : 27 Date : 2005-5-31 This document specifies a set of methods, headers and resource types that define the scheduling extension to the CalDAV protocol. CalDAV itself extends WebDAV, which extends HTTP. The new protocol elements defined here allow interoperable scheduling operations on a CalDAV repository. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-00.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-desruisseaux-caldav-sched-00.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-desruisseaux-caldav-sched-00.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. --------------060001070602020500020206 Content-Type: Message/External-body; name="draft-desruisseaux-caldav-sched-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-00.txt" Content-Type: text/plain Content-ID: <2005-5-31155643.I-D@ietf.org> --------------060001070602020500020206 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BDESRUIS/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BDESRUIS/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------060001070602020500020206-- X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4RH74so030578 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 May 2005 10:07:17 -0700 In-Reply-To: <42972CEF.2010008@rpi.edu> References: <42972CEF.2010008@rpi.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Who does the alarming? Date: Fri, 27 May 2005 10:06:56 -0700 To: Mike Douglass X-Mailer: Apple Mail (2.622) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 27 May 2005 17:07:20 -0000 I don't really know how to solve the problem of coordinating alarms between different devices. I'm not even sure, on the face of it, that it's entirely solvable. Any of the devices might be offline and unreachable yet if that's the only device the person has on them the only right thing is to sound the alarm. The best we might be able to do is to coordinate alarms between online devices. If there are three online devices and one of them gives the alarm, and the user acknowledges the alarm, that device lets the others know (through the server, in a CalDAV architecture) that the other devices can deactivate the alarm. Anyway, it would be great to have this as an extension. Lisa On May 27, 2005, at 7:21 AM, Mike Douglass wrote: > I guess this isn't caldav specific but it did give me pause for > thought. > > If there's an alarm is there any way to indicate who should carry out > the action - or should there be? For example, if you have an audio > alarm set, having your palm, cell phone and desktop all sound alarms > at the same time might be annoying or amusing depending on your > outlook - however it seems the right thing to do. > > Having a large number of emails from different sources is less likely > to amuse and doesn't seem quite as correct behaviour. > > A caldav aware server might just be essentially a store with no active > functionality or it might be fully functional - firing off alarms as > appropriate. > > -- > > 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 > > _______________________________________________ > 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 X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4RELaso019871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 May 2005 07:21:37 -0700 Received: from [128.113.124.139] (crustacean-11.dynamic.rpi.edu [128.113.124.139]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4RELZ7R004598 for ; Fri, 27 May 2005 10:21:35 -0400 Message-ID: <42972CEF.2010008@rpi.edu> Date: Fri, 27 May 2005 10:21:35 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 X-Spam-Score: 0 () Subject: [Ietf-caldav] Who does the alarming? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 27 May 2005 14:21:41 -0000 I guess this isn't caldav specific but it did give me pause for thought. If there's an alarm is there any way to indicate who should carry out the action - or should there be? For example, if you have an audio alarm set, having your palm, cell phone and desktop all sound alarms at the same time might be annoying or amusing depending on your outlook - however it seems the right thing to do. Having a large number of emails from different sources is less likely to amuse and doesn't seem quite as correct behaviour. A caldav aware server might just be essentially a store with no active functionality or it might be fully functional - firing off alarms as appropriate. -- 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 X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4QHvvso002096 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 26 May 2005 10:57:58 -0700 In-Reply-To: <3514614f99f6d2fd91a1a7e41c0b09be@opengroupware.org> References: <4295C9E1.40400@rpi.edu> <9D9D7922002EB759CE1AF0A6@ninevah.local> <3514614f99f6d2fd91a1a7e41c0b09be@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] No time-range means what? Date: Thu, 26 May 2005 10:57:50 -0700 To: Helge Hess X-Mailer: Apple Mail (2.622) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 26 May 2005 17:58:00 -0000 In general a server can refuse any request with a 507 Insufficient Storage error -- in the SEARCH draft at some point this was explicitly listed as a reasonable way to respond to a search over too wide a scope. To work for this "Storage" is loosely interpreted to include memory as well as disk :) Lisa On May 26, 2005, at 6:32 AM, Helge Hess wrote: > On May 26, 2005, at 15:17, Cyrus Daboo wrote: >> We can add a statement warning clients that this is not a great thing >> to do when the calendar is potentially large, but there may well be >> justifiable reasons for doing it. > > I would suggest adding a documented error code for the case that the > server refuses to serve a request due to a too large range (maybe 403 > plus some error structure explaining the problem). > > The issue is significant for big calendars, say a public TV program > listing. > > Greets, > 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 X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4QDWMsn004461 for ; Thu, 26 May 2005 06:32:22 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CEB5330D396; Thu, 26 May 2005 15:28:41 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 6E64C30AE5C; Thu, 26 May 2005 15:28:41 +0200 (CEST) In-Reply-To: <9D9D7922002EB759CE1AF0A6@ninevah.local> References: <4295C9E1.40400@rpi.edu> <9D9D7922002EB759CE1AF0A6@ninevah.local> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3514614f99f6d2fd91a1a7e41c0b09be@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] No time-range means what? Date: Thu, 26 May 2005 15:32:18 +0200 To: Cyrus Daboo X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 26 May 2005 13:32:24 -0000 On May 26, 2005, at 15:17, Cyrus Daboo wrote: > We can add a statement warning clients that this is not a great thing > to do when the calendar is potentially large, but there may well be > justifiable reasons for doing it. I would suggest adding a documented error code for the case that the server refuses to serve a request due to a too large range (maybe 403 plus some error structure explaining the problem). The issue is significant for big calendars, say a public TV program listing. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4QDHXso001659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 May 2005 06:17:36 -0700 Received: from [10.0.1.4] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j4QCrEIC008713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 08:53:14 -0400 Date: Thu, 26 May 2005 09:17:31 -0400 From: Cyrus Daboo To: Mike Douglass , CalDAV DevList Subject: Re: [Ietf-caldav] No time-range means what? Message-ID: <9D9D7922002EB759CE1AF0A6@ninevah.local> In-Reply-To: <4295C9E1.40400@rpi.edu> References: <4295C9E1.40400@rpi.edu> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 26 May 2005 13:17:37 -0000 Hi Mike, --On May 26, 2005 9:06:41 AM -0400 Mike Douglass wrote: > Has there been any discussion on the appropriate response when no > time-range is specified for the possibly large requests, PROPFIND, REPORT? > > Returning or filtering ALL events could be a problem, especially for > public events. Unless a range is specified, should the result be limited > to 'active' components, i.e NOW (sort of) and onwards. > > Of course, NOW might be a problem so maybe yesterday would be safer I think we should leave it as-is - i.e. no time-range (an no comp-filter providing other limits) means return everything. We can add a statement warning clients that this is not a great thing to do when the calendar is potentially large, but there may well be justifiable reasons for doing it. In some ways this is equivalent to the IMAP 'FETCH 1:*' or 'LIST "" *' issues where all data is requested instead of sub-ranges. -- Cyrus Daboo X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4QD6gso032244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 May 2005 06:06:43 -0700 Received: from [128.113.124.139] (crustacean-11.dynamic.rpi.edu [128.113.124.139]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4QD6fUT021526 for ; Thu, 26 May 2005 09:06:42 -0400 Message-ID: <4295C9E1.40400@rpi.edu> Date: Thu, 26 May 2005 09:06:41 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Spam-Score: 0 () Subject: [Ietf-caldav] No time-range means what? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 26 May 2005 13:06:46 -0000 Has there been any discussion on the appropriate response when no time-range is specified for the possibly large requests, PROPFIND, REPORT? Returning or filtering ALL events could be a problem, especially for public events. Unless a range is specified, should the result be limited to 'active' components, i.e NOW (sort of) and onwards. Of course, NOW might be a problem so maybe yesterday would be safer -- 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 X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet02.oracle.com (rgminet02.oracle.com [148.87.122.31]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4PKL2so014774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 25 May 2005 13:21:03 -0700 Received: from rgminet02.oracle.com (localhost [127.0.0.1]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j4PKKvoX027138 for ; Wed, 25 May 2005 14:20:57 -0600 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j4PKKuwm027120 for ; Wed, 25 May 2005 14:20:56 -0600 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4PKKuMK027863; Wed, 25 May 2005 14:20:56 -0600 Received: from [144.23.212.24] ([144.23.212.24]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4PKKtkC027850 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 25 May 2005 14:20:55 -0600 Message-ID: <4294DE25.1000200@oracle.com> Date: Wed, 25 May 2005 16:20:53 -0400 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 Content-Type: multipart/mixed; boundary="------------040409040501020107070705" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-06.txt] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 May 2005 20:21:04 -0000 This is a multi-part message in MIME format. --------------040409040501020107070705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-dusseault-caldav-06.txt Date: Wed, 25 May 2005 15:52:57 -0400 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-06.txt Pages : 63 Date : 2005-5-25 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 single-user calendar access, calendar sharing, and calendar publishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-06.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-06.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-06.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. --------------040409040501020107070705 Content-Type: Message/External-body; name="draft-dusseault-caldav-06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dusseault-caldav-06.txt" Content-Type: text/plain Content-ID: <2005-5-25160053.I-D@ietf.org> --------------040409040501020107070705 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BDESRU%7E1.STE/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BDESRU%7E1.STE/LOCALS%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040409040501020107070705-- X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4PEW4so010576 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 25 May 2005 07:32:04 -0700 Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PEVu57006669; Wed, 25 May 2005 09:31:56 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4PEVtT7006647; Wed, 25 May 2005 09:31:56 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4PEVtfB032433; Wed, 25 May 2005 08:31:55 -0600 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4PEVlqb032352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 25 May 2005 08:31:47 -0600 Message-ID: <42948C51.3000406@oracle.com> Date: Wed, 25 May 2005 10:31:45 -0400 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: Mike Douglass Subject: Re: [Ietf-caldav] calendar-data comp element(s) References: <429349C9.4010807@rpi.edu> In-Reply-To: <429349C9.4010807@rpi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: "ietf-caldav@osafoundation.org" X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 May 2005 14:32:07 -0000 Mike Douglass wrote: > Do we need to specify what the presence/absence of comp elements means? > > For example > > > > > > Does that mean only the VCALENDAR properties or is it another way of > saying everything? That means only the VCALENDAR properties. To get everything you would need to use: > > Another: > > > > > > > > > > > > Does that mean only return those bits of the VEVENT but everything of > the unmentioned components or should unnamed components be dropped from > the result? > That means only the VCALENDAR properties plus the specified four VEVENT properties. Cheers, Bernard X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4P0K2sn007730 for ; Tue, 24 May 2005 17:20:02 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D1FE330D6D8; Wed, 25 May 2005 02:16:19 +0200 (CEST) Received: from [192.168.0.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 4519A30D6D3; Wed, 25 May 2005 02:16:19 +0200 (CEST) In-Reply-To: <42928CB8.20907@oracle.com> References: <42928CB8.20907@oracle.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] draft-dusseault-caldav-06.txt Date: Wed, 25 May 2005 02:19:47 +0200 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: caldav DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 25 May 2005 00:20:04 -0000 On 24. Mai 2005, at 04:08 Uhr, Bernard Desruisseaux wrote: > We've just submitted CalDAV draft -06 to the IETF. Excellent. Comments below. - DAV:displayname - 4.1 Calendar Collection says: "A calendar collection MUST have a non-empty DAV:displayname property" - but 5.1 MKCALENDAR Method contains: "In the event that the DAV:displayname property is empty" - This can't happen according to 4.1? - if it must have a displayname, the MKCALENDAR method should include the initial value to ensure consistent creation? - it would be nice if the example in 4.2 would explain more exactly what the server is supposed to do if it receives a PUT containing such a resource - 400 Bad Request? 403 + CALDAV:invalid-calendar-resource? - not sure I like 5.2.1.1 (vague feeling) - "users" is a regular non-calendaring collection, I suppose it would be better not to report it as "calendar-access"? - if in your server the collections are represented as objects, this would force you to modify all collections for CalDAV even though they are generic and provide no specific calendaring features (it forces you to make a global server change for CalDAV even though the HTTP methods are resource specific) - MKCALENDAR is the only calendaring thing this collection really provides? (can be tested with OPTIONS) - maybe split in 'calendar-access' and 'calendar-container'? - is the response in 5.2.4 incorrect? - since according to 2. "MUST support WebDAV ACL [7]", shouldn't the DAV header always contain 'access-control'? - in 5.3 you removed location support, ok - but shouldn't the "if-none-match: *" be a MUST if a client attempts creation? IMHO its better to require the client to signal its intention - in 5.3 the paragraph about the .ics and .ifb suffix is IMHO superflous since you mention before: "The URL for each calendar resource is entirely arbitrary" - maybe you want to make that a SHOULD instead of a may, though this is already covered by the MIME-type of the file. IMHO extensions should not be encouraged here and the whole section be removed. - it would be nice to have an example in 5.3 which shows the CALDAV:uid-already-exists error - whats the rational behind 6.?: "A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined in this section" - is this WebDAV compliant? - why does it matter? - 7.1.1 CALDAV:view-free-busy Privilege - "It may also make sense to grant this privilege on individual calendar resources (in which case the time allocated to those calendar resources would show up as free in the free-busy rollup to an unauthorized viewer)" - I think this is wrong, the privilege has nothing to do with the freebusy value which is contained in the "fbtype" iCal property? - 8.2 - its unclear to me why you allow REPORTs on generic containers but not nested calendar folders. Doesn't that lead to exactly the same issues (duplicate uids etc)? - especially because you also seem to allow generic containers to contain leaf-calendaring resources which are then included in reports? - I would suggest to remove the "recursively" due to the nesting issues, not to mention the same DoS issues like with depth: infinity - 8.3.1 - iCalendar property queries (bigger question) - the REPORT allows to query just a subset of the iCalendar properties - doesn't that allow to construct invalid iCalendar "calendar-data" results? (eg w/o uid or date ranges?) - might be an issue for iCalendar parsers - I would suggest to return partial queries as XML (eg ) - another gain: results could be directly consumed by the oh so popular AJAX - more consistent with PROPFIND results for missing properties? "For instance, a request to retrieve the value of a property which does not exist is an error and MUST be noted with a response XML element which contains a 404 (Not Found) status value." - example would be nice ... - BTW: this is also how it works with Exchange WebDAV - iCalendar (or MIME with iCal) only when retrieving full objects - WebDAV properties when retrieving portions (using PROPFIND or DASL) - 8.3.2 - alarms - IMHO all this alarm thingy is quite problematic and using iCalendar as a storage format clashes with shared collections here. Alarms should be user-specific? - the example misses the response to the request - IMHO all transactions should be shown complete with response - 8.4.1 - relative URLs allowed? - is this allowed: REPORT /bernard/calendar/ ... ev102.ics - if yes, this should be used in the examples IMHO (no redundant information) - if no, it should be mentioned more prominent that absolute URLs are required - it should also be noted whether URLs MUST be subresources to the request URI or are allowed to live on different servers (absolute URLs suggest the latter which is confusing with WebDAV which disallows that) - 8.5.1 freebusy query - whats the gain of wrapping the freebusy iCalendar in XML here? - can't we just return a text/calendar in response to the REPORT? - accept header - vague feeling: why can't we just use GET for that. already established and highly interoperable. KISS. - generic: shouldn't all request examples properly set the "accept" header (usually to text/xml)? - might make it easier to support xCal or RDF at the same time - IMHO 9.2.1. as a "how to" mixes online and offline oriented clients a bit too much which makes it hard to differentiate the usage between those two cases. Maybe the behaviour of the two cases should be outlined in greater detail (separate sections) since they are mostly distinct problems. - a section on filters would be nice. I find that part difficult to follow/understand. OK, thats it for now ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4OFZcso023508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 May 2005 08:35:39 -0700 Received: from [128.113.124.247] (kiva-20.dynamic2.rpi.edu [128.113.124.247]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4OFZbpv002678 for ; Tue, 24 May 2005 11:35:37 -0400 Message-ID: <429349C9.4010807@rpi.edu> Date: Tue, 24 May 2005 11:35:37 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-caldav@osafoundation.org" 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Spam-Score: 0.47 () TO_ADDRESS_EQ_REAL Subject: [Ietf-caldav] calendar-data comp element(s) X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 24 May 2005 15:35:42 -0000 Do we need to specify what the presence/absence of comp elements means? For example Does that mean only the VCALENDAR properties or is it another way of saying everything? Another: Does that mean only return those bits of the VEVENT but everything of the unmentioned components or should unnamed components be dropped from the result? -- 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 X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4O29Dso028872 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 23 May 2005 19:09:14 -0700 Received: from agminet04.oracle.com (localhost [127.0.0.1]) by agminet04.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4O298Xi009185 for ; Mon, 23 May 2005 21:09:08 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet04.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4O2974n009177 for ; Mon, 23 May 2005 21:09:08 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4O297l2029748 for ; Mon, 23 May 2005 20:09:07 -0600 Received: from [192.168.1.200] (dhcp-amer-csvpn-gw2-141-144-74-250.vpn.oracle.com [141.144.74.250]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4O2919a029721 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 23 May 2005 20:09:02 -0600 Message-ID: <42928CB8.20907@oracle.com> Date: Mon, 23 May 2005 22:08:56 -0400 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] draft-dusseault-caldav-06.txt X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 24 May 2005 02:09:14 -0000 We've just submitted CalDAV draft -06 to the IETF. It's already available at the following URL: http://ietf.webdav.org/caldav/draft-dusseault-caldav-06.txt B.1 Changes in -06 a. Reworded section "Recurrence and the Data Model". b. Removed timezone collection feature. c. Removed ability for a server to return the Location header on a successful PUT request. d. Clarified restrictions on calendar resources contained in calendar collections. e. Added preconditions on PUT in calendar collections. f. Added informative "Guidelines" section, with information on locking and how to find calendar collections. g. Moved "Sychronization Operations" section in the "Guidelines" section. Cheers, Bernard X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp800.mail.sc5.yahoo.com (smtp800.mail.sc5.yahoo.com [66.163.168.179]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j4KKWAsn022341 for ; Fri, 20 May 2005 13:32:11 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.110.148 with plain) by smtp800.mail.sc5.yahoo.com with SMTP; 20 May 2005 20:32:10 -0000 Message-ID: <428E4941.20207@calconnect.org> Date: Fri, 20 May 2005 13:32:01 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.802 (*) HTML_20_30, HTML_MESSAGE, HTML_TITLE_EMPTY, HTTP_ESCAPED_HOST, MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Help Needed again - Questionnaire on Implementation of Timezones - Calconnect and Calsify X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 20:32:12 -0000 
Dear IETF-CALDAV,

This e-mail is going to several Calendaring discussion lists, so my apologies if you get it more than once (which you probably will).

This is the second questionnaire distributed by Calconnect - The Calendaring and Scheduling Consortium - as part of our work to collect specific information on how actual C&S products implement various portions of iCalendar and the related specifications.  Our TIMEZONE Technical Committee asks for your help in responding to this questionnaire to determine how Timezones are handled in actual calendaring applications.

The information collected will be analyzed and the results, with specific product identifications eliminated, will be transmitted to the incipient CALSIFY Working Group of the IETF as soon as possible.  The results will also be made generally available on the Consortium website, and will be input to Technical Committee recommendations to be formulated once the results are available.

If you are willing to help, please fill out the questionnaire below.  This is absolutely NOT limited to Consortium members; we need responses for as many products and implementations as possible for the results to be of maximum value.  

We would appreciate your response no later than 10 June 2005.

Thank you very much for your help.


Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org


------------------------------------------------------------------------------------------
Questionnaire on Timezones in iCalendar

Introduction:

This questionnaire is being used to determine support for iCalendar
(RFC2445) timezone support. The specific sections in RFC2445 that
are being queried are:

4.6.5       Time Zone Component
4.8.2.4     Date/Time Start
4.8.3       Time Zone Component Properties
     ( and sub-sections )
4.8.5.3     Recurrence Date/Times
4.8.5.4     Recurrence Rule
4.8.7.3     Last Modified
4.8.8.1     Non-standard Properties

These may involve reference to other sections.

How to answer:

Please copy the text from the '-------' divider below to the end of
this message into a new message and address it to:

    <mailto:questionnaire@calconnect.org>

To fill it out:

For 'y/n/o':

    'y' means yes
    'n' means no
    'o' means other or not applicable

    Delete two letters to leave the one for your answer.
    If you have specific comments you can add about your answers,
    please do so at the end and reference the question number to which
    the comment applies.
    
For _____________________: enter text for the answer.



-------

Product Details:

P1:		Product/Implementation Name:
        
        _____________________


Components supported:

                                   Consume         Produce
Q1:     VTIMEZONE                   y/n/o           y/n/o
Q1.1:   STANDARD                    y/n/o           y/n/o
Q1.2:   DAYLIGHT                    y/n/o           y/n/o


Properties supported:
                                
        In VTIMEZONE
                                   Consume         Produce
Q2.1:   TZID                        y/n/o           y/n/o
Q2.2:   LAST-MODIFIED               y/n/o           y/n/o
Q2.3:   TZURL                       y/n/o           y/n/o
Q2.4:   XPROP                       y/n/o           y/n/o


        In STANDARD
                                   Consume         Produce
Q3.1:   DTSTART                     y/n/o           y/n/o
Q3.2:   TZOFFSETTO                  y/n/o           y/n/o
Q3.3:   TZOFFSETFROM                y/n/o           y/n/o
Q3.4:   COMMENT                     y/n/o           y/n/o
Q3.5:   RDATE                       y/n/o           y/n/o
Q3.6:   RRULE                       y/n/o           y/n/o
Q3.7:   TZNAME                      y/n/o           y/n/o
Q3.8:   XPROP                       y/n/o           y/n/o


        In DAYLIGHT
                                   Consume         Produce
Q4.1:   DTSTART                     y/n/o           y/n/o
Q4.2:   TZOFFSETTO                  y/n/o           y/n/o
Q4.3:   TZOFFSETFROM                y/n/o           y/n/o
Q4.4:   COMMENT                     y/n/o           y/n/o
Q4.5:   RDATE                       y/n/o           y/n/o
Q4.6:   RRULE                       y/n/o           y/n/o
Q4.7:   TZNAME                      y/n/o           y/n/o
Q4.8:   XPROP                       y/n/o           y/n/o


General:
    
Q5:  Do you always send DATE-TIME
     values with a timezone?         y/n/o

Q6:  Do you always send DATE-TIME
     values in UTC or floating?      y/n/o

Q7:  Do you provide a standard
     set of timezones built-in
     to your product?                y/n/o

     if yes to Q7, then
     {
Q8:     Where did you get your
        timezone definitions?
        
        _____________________
        
Q9:     How many timezone
        definitions do you have?
        
        _____________________
        
Q10:    Do you have a special
        naming scheme for TZIDs,
        and if so what is it?
        
        _____________________
        
Q11:    Do you provide a mechanism
        for updating built-in
        timezones?                  y/n/o
        
        if yes to Q11, then
        {
Q12:        Do you adjust future
            times to account for
            timezone definition
            changes?                y/n/o
        }

     }
    
Q13: Do you accept and use
     timezone definitions from
     imported iCalendar data?       y/n/o

     if yes to Q13, then
     {   
Q14:    Do you attempt to merge
        timezone definitions with the
        same TZID when importing
        iCalendar data?             y/n/o
     }
    
Q15: When exporting timezones in
     iCalendar data (either to a file
     or via iTIP) do you send the entire
     timezone definition or just the
     set of dates needed for coverage
     of the event?

     _____________________
    
Q16: Would you use timezone
     definitions from a standard
     timezone registry if one
     were created?                   y/n/o
    
Q17: What problems would be
     involved in changing a
     timezone definition if DST
     was changed at some point
     in the future?
    
     _____________________


C1:  Comments on specific answers (include Q number for cross-reference
     to original question):

     _____________________

C2:  Comments on the format and ease of use of this questionnaire:

     _____________________

C3:  Are there any additional questions we should be asking, and if
     so what are they?

     _____________________


X-Envelope-From: TimHare@comcast.net Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4KHtdsn006688; Fri, 20 May 2005 10:55:39 -0700 Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc13) with SMTP id <20050520175534015007l7bse>; Fri, 20 May 2005 17:55:34 +0000 Message-Id: <6.2.1.2.0.20050520134840.01c912a8@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 20 May 2005 13:55:31 -0400 To: "ietf-calsify-osafoundation.org" , "ietf-caldav@osafoundation.org" From: Tim Hare Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-caldav] draft-hare-xcalendar-03 has been published. X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 May 2005 17:55:41 -0000 Draft-hare-xcalendar-03 has been made available at the Internet Drafts site. This revision of the document adds some template coding to the XSLT example to try to quote some of the items which need to be "quoted", according to section 4.3.11 (which was pointed out to me by Dan Connolly of the W3C- Thanks Dan). Note: these templates haven't been adequately tested; I ran into some delays and wanted to get the document submitted before -02 expired, during the same time period I had to update my Windows OS and lost my Java which I was using for XSLT testing. Which is all a long-winded way of saying "use at your own risk". As always, I hope this draft is of some use to those contemplating XML for calendar items; and remember it's not intended as a standards-track document but as a guideline. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4KFRvso021519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 May 2005 08:27:58 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j4KF4XIC014660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2005 11:04:34 -0400 Date: Fri, 20 May 2005 11:27:55 -0400 From: Cyrus Daboo To: Mike Douglass , CalDAV DevList Subject: Re: [Ietf-caldav] Draft-5 10.2 return-content-type Message-ID: <5944F235A253575F26CF8CEF@ninevah.cyrusoft.com> In-Reply-To: <428DFD00.7080404@rpi.edu> References: <428DFD00.7080404@rpi.edu> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 May 2005 15:28:04 -0000 Hi Mike, --On May 20, 2005 11:06:40 AM -0400 Mike Douglass wrote: > How is that supposed to be used - isn't the default for the response > "text/xml"? > The return-content-type refers to the type of data returned in the XML element, and NOT the actual HTTP response content-type (which is always XML for the REPORT). The idea here is that if we ever have alternative syntax for iCalendar objects (eg XML calendar) then the client could request that data be returned in that format as opposed to text/calendar (the default). -- Cyrus Daboo X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4KF6fso018574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 May 2005 08:06:42 -0700 Received: from [128.113.124.247] (kiva-20.dynamic2.rpi.edu [128.113.124.247]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4KF6eIb026668 for ; Fri, 20 May 2005 11:06:41 -0400 Message-ID: <428DFD00.7080404@rpi.edu> Date: Fri, 20 May 2005 11:06:40 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 X-Spam-Score: 0 () Subject: [Ietf-caldav] Draft-5 10.2 return-content-type X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 20 May 2005 15:06:49 -0000 How is that supposed to be used - isn't the default for the response "text/xml"? -- 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 X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j4JI3Msn017828 for ; Thu, 19 May 2005 11:03:22 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.110.148 with plain) by smtp805.mail.sc5.yahoo.com with SMTP; 19 May 2005 18:03:21 -0000 Message-ID: <428CD4E5.5090600@calconnect.org> Date: Thu, 19 May 2005 11:03:17 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.802 (*) HTML_20_30, HTML_MESSAGE, HTML_TITLE_EMPTY, HTTP_ESCAPED_HOST, MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Status of Calconnect Recurrence Questionnaire results, and future questionnaires X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 18:03:24 -0000 This message is going to all of the lists where I posted our original request for responses to the Consortium Recurrence Questionnaire, so many of you will see it more than once.  My apologies for the duplications.

At the beginning of April, Calconnect - The Calendaring and Scheduling Consortium - distributed a questionnaire on Recurrence implementations, and more recently I posted an update saying that we hoped to publish our results soon.

We've delayed publishing because we are still waiting for a couple of promised responses which will add considerably to the value of our results, but we have decided we have to cutoff by next Friday the 27th.  So I expect to have the results ready in early June, following the Calconnect Roundtable meeting at Duke University at the beginning of June.  I will distribute yet another note when the results are available telling everyone where to find them.

Meantime, we have our second questionnaire ready to go and I'll be posting it later today.  This one is on Timezones, and we certainly hope everyone will be as helpful in responding to this questionnaire as they were for our Recurrence questionnaire. 

We're trying something different this time: the questionnaire is being distributed in e-mail format so it can be answered offline and responded to via e-mail as well.  We hope that, in your comments, you will tell us how useful the e-mail format is as opposed to the web-based form we used for the first questionnaire.

Once again, we would like to thank everyone on these discussion lists, and especially everyone who responded to our Recurrence questionnaire. 

Best regards,

Dave Thewlis

--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
X-Envelope-From: helge.hess@opengroupware.org Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4JBVjsn014228; Thu, 19 May 2005 04:31:45 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 67D1530A371; Thu, 19 May 2005 13:28:19 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 10E0130A24F; Thu, 19 May 2005 13:28:19 +0200 (CEST) In-Reply-To: <771575B4-0DF8-4ABD-95F6-AD300226C181@opengroupware.org> References: <9e66f8d17db7e91d72526e185eed38bc@osafoundation.org> <771575B4-0DF8-4ABD-95F6-AD300226C181@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5900aca2af0ed1afbb87e7e49dec51c5@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] CalDAV Notes Date: Thu, 19 May 2005 13:31:54 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 19 May 2005 11:31:48 -0000 On May 13, 2005, at 23:48, Helge Hess wrote: > Just thoughts on this, I'm fine with the current state. Personally I > don't need to have calendars below calendars. FYI: Trumba (http://www.trumba.com ) allows for subcalendars. So apparently someone finds that useful ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4I24Wf5018746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 May 2005 19:04:33 -0700 Received: from [192.168.0.103] (vpn-785.nss.rpi.edu [128.113.211.35]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4I24GvR032471 for ; Tue, 17 May 2005 22:04:21 -0400 Message-ID: <428AA299.20405@rpi.edu> Date: Tue, 17 May 2005 22:04:09 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 X-Spam-Score: 0 () Subject: [Ietf-caldav] comp-filter and is-defined X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 18 May 2005 02:04:35 -0000 Isn't the is-defined element superfluous? Couldn't naming the component mean the same thing? Instead of have I'm having a hard time seeing where is-defined means any more than that -- 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 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4FKPJvM020182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 May 2005 13:25:22 -0700 Received: from [10.0.1.4] (pool-141-151-187-231.pitt.east.verizon.net [141.151.187.231]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j4FK2VIC004537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 May 2005 16:02:35 -0400 Date: Sun, 15 May 2005 16:25:10 -0400 From: Cyrus Daboo To: Mike Douglass , CalDAV DevList Subject: Re: [Ietf-caldav] Section 10.2 draft 5 Message-ID: <5E8C928D29A63D6511B09830@ninevah.local> In-Reply-To: <4287A479.7030408@rpi.edu> References: <4287A479.7030408@rpi.edu> X-Mailer: Mulberry/4.0.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2005 20:25:24 -0000 Hi Mike, --On May 15, 2005 3:35:21 PM -0400 Mike Douglass wrote: > #PCDATA)?> This one is correct - what is in the current draft is wrong. The comp element is optional - if it is not present all components and properties are returned (and explained in the text of that section. I will make sure this gets fixed, thanks for spotting it! -- Cyrus Daboo X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4FJZVvM017989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 15 May 2005 12:35:32 -0700 Received: from [192.168.0.103] (vpn-824.nss.rpi.edu [128.113.211.74]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4FJZTd0017153 for ; Sun, 15 May 2005 15:35:30 -0400 Message-ID: <4287A479.7030408@rpi.edu> Date: Sun, 15 May 2005 15:35:21 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Spam-Score: 0 () Subject: [Ietf-caldav] Section 10.2 draft 5 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2005 19:35:34 -0000 Should this be or ? -- 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 X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4E3XDvM023416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 20:33:14 -0700 Received: from [192.168.0.103] (vpn-773.nss.rpi.edu [128.113.211.23]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4E3X72v028769; Fri, 13 May 2005 23:33:08 -0400 Message-ID: <4285716D.2020601@rpi.edu> Date: Fri, 13 May 2005 23:33:01 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] time-range References: <4284ED1D.9020302@rpi.edu> <42854C53.5050009@oracle.com> In-Reply-To: <42854C53.5050009@oracle.com> 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 X-Spam-Score: 0 () Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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: Sat, 14 May 2005 03:33:17 -0000 I guessed something of the kind was intended. The description in 10.4 is all in terms of both start and end being present. A note to indicate that start or end may be omitted but not both might clarify things. Bernard Desruisseaux wrote: > Mike Douglass wrote: > >> Is it correct/intentional that neither start or end is required? >> > > While it doesn't make sense to neither specify "start" nor "end", > we wanted to allow one to only specify "start" or "end" to support > time-range from -infinity to a given date, or from a given date to > +infinity. > > Do you have any suggestion to improve the DTD? > > Cheers, > Bernard > > > -- 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 X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet04.oracle.com (rgminet04.oracle.com [148.87.122.33]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4E0svvM010458 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 13 May 2005 17:54:58 -0700 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by rgminet04.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4E0spUG019560; Fri, 13 May 2005 18:54:51 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4E0soZ6008005; Fri, 13 May 2005 18:54:50 -0600 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw4-141-144-96-7.vpn.oracle.com [141.144.96.7]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4E0seko007705; Fri, 13 May 2005 18:54:42 -0600 Message-ID: <42854C53.5050009@oracle.com> Date: Fri, 13 May 2005 20:54:43 -0400 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: Mike Douglass Subject: Re: [Ietf-caldav] time-range References: <4284ED1D.9020302@rpi.edu> In-Reply-To: <4284ED1D.9020302@rpi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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: Sat, 14 May 2005 00:55:00 -0000 Mike Douglass wrote: > Is it correct/intentional that neither start or end is required? > While it doesn't make sense to neither specify "start" nor "end", we wanted to allow one to only specify "start" or "end" to support time-range from -infinity to a given date, or from a given date to +infinity. Do you have any suggestion to improve the DTD? Cheers, Bernard X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DMMFvM001042 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 May 2005 15:22:18 -0700 In-Reply-To: <771575B4-0DF8-4ABD-95F6-AD300226C181@opengroupware.org> References: <9e66f8d17db7e91d72526e185eed38bc@osafoundation.org> <771575B4-0DF8-4ABD-95F6-AD300226C181@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] CalDAV Notes Date: Fri, 13 May 2005 15:21:10 -0700 To: Helge Hess X-Mailer: Apple Mail (2.622) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 13 May 2005 22:22:20 -0000 On May 13, 2005, at 2:48 PM, Helge Hess wrote: > > Who is responsible for ensuring that this is a 1:1 mapping? What > happens if two clients try to insert an event in a shared collection > (eg the same meeting proposal received by mail) - with the same UID > under different URLs? > There should be information on this situation in the spec. > > IMO: the thing which probably calls for least trouble is to specify > that the UID is to be used as the URL (with .ics extension ;-). > Obviously this would give issues with "generic clients", but those > couldn't handle 1:1 errors either. > Yep -- working on this in the next draft of the spec. Lisa X-Envelope-From: helge.hess@opengroupware.org Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DMFEvL000668; Fri, 13 May 2005 15:15:14 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6134A307EC7; Fri, 13 May 2005 23:45:25 +0200 (CEST) Received: from [192.168.0.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id F08C7307EC6; Fri, 13 May 2005 23:45:24 +0200 (CEST) In-Reply-To: <9e66f8d17db7e91d72526e185eed38bc@osafoundation.org> References: <9e66f8d17db7e91d72526e185eed38bc@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <771575B4-0DF8-4ABD-95F6-AD300226C181@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] CalDAV Notes Date: Fri, 13 May 2005 23:48:27 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 13 May 2005 22:15:17 -0000 Hi Lisa, pretty old issues ;-) Anyway, I try to give some ideas from my current POV. On 13. Mai 2005, at 21:21 Uhr, Lisa Dusseault wrote: >> ACL >> === >> - do we need this for minimum compliance? ... > When the CALSCH working group was working on CAP, the access > control -- although a difficult piece of functionality to define > and agree on -- was generally agreed to be required. Yes, access control is required for "full" operation in an office like environment (aka "groupware" ...). But it is not necessarily required for minimum compliance. Eg the popular iCalendar-over-HTTP sharing gets along quite well without (protocol level) ACLs. The same goes for WebDAV - few clients support ACLs, nevertheless its quite useful. > With WebDAV to build on, most of the work of defining ACL is > already done so now we consider mostly the implementation difficulty. Unfortunately my in-memory-knowledge on WebDAV ACLs is a bit limited. I remember that in the GroupDAV list we discussed to support a minimalistic subset which only covers "readonly" information. (AFAIK the only info which is supported by Kontact) > Who else plans to implement or would have difficulty implementing > or considers it a required use case? Without knowing the details, I'm pretty sure that we would also implement WebDAV ACLs. I have the impression its the only option which makes sense. > the question is whether a client that expected full ACL support > would typically degrade gracefully if this was all the server offered. => exactly. I find it hard to imagine how a client can usefully implement an interface to a permission system in a generic way. In practice access-control is something which is very different between servers. Of course the whole set of "new" servers which are in development can target for CalDAV /ACLwhich leaves the question whether CalDAV should/ needs-to work well with existing servers. Summary: IMO WebDAV ACLs should be an optional feature. If the server supports it, the client should offer ACL panels. If it doesn't, access control could be implemented with server specific plugins. > On the issue of how an existing server's data model works and > whether calendars are just queries or whether per object ACLs > exist... well, this is something that just must be upgraded to > support CalDAV. OK, thats basically an answer to my above question. CalDAV is not supposed to work well with existing servers and will potentially require major modifications for full compliance. Unrelated [UID <-> URL mapping]: > for example servers that do not have client-settable paths to > calendar components (servers which may be implemented on databases > and always use the UID) have an extra barrier to support PUT where > the client chooses the URL to the new component. To implement this > they have to upgrade their back-end store to include a table > mapping client-selected URLs to back-end IDs. I think I posted this question in a different mail, I wonder how this is intended to work. If I remember right we have the requirement that there is a 1:1 mapping between UID and resource in a given collection. Who is responsible for ensuring that this is a 1:1 mapping? What happens if two clients try to insert an event in a shared collection (eg the same meeting proposal received by mail) - with the same UID under different URLs? There should be information on this situation in the spec. IMO: the thing which probably calls for least trouble is to specify that the UID is to be used as the URL (with .ics extension ;-). Obviously this would give issues with "generic clients", but those couldn't handle 1:1 errors either. >> Collections >> =========== >> - you specify collection types as a complex XML property, eg: >> >> >> > xmlns:C="urn:ietf:params:xml:ns:calsch"> >> >> I "predict" that this will give issues ;-) because a lot of servers >> will map properties to simple key/stringvalue hashtables (eg >> resourcetype=collection) (although of course XML content is >> valid in >> WebDAV properties, I think few are actually prepared for this) > I don't understand this issue -- I agree servers will map > properties like this to simple booleans in their back-end store, > but since this is a read-only property, how is that a problem? Its not really a server specific issue. A lot of implementations are rather simplistic and use simple key/value tables instead of full DOM- like tres to store property sets, which works well in most cases but obviously breaks with more advanced uses of WebDAV. Summary: I think clients/servers need to deal with this to implement CalDAV. The resource typing as done by CalDAV makes sense. >> - "Calendars MUST NOT contain other calendars" >> - hm, why? I think this breaks the common Outlook model also >> uses in >> Evolution where you can nest object folders arbitary > Is the Outlook/Evolution model confirmed? I think starting with v2.0 Evolution doesn't support hierarchies anymore (at least the UI doesn't). Kontact and Apple iCal also do not support hierarchies at all. Outlook/Exchange do support arbitary hierarchies of folders and so do a lot of other servers (eg Kolab to name but one), mostly because they are focused on serving Outlook. > Is there some way to map that model to the CalDAV model -- e.g. > declare only the deepest-nested of the collections a "calendar"? Certainly you can find some hack, but it wouldn't be very natural. > Our thinking when restricting this, was that making calendars one- > level-only made it easier for a client to know how to display. We > didn't have to worry about what it "meant" to have a calendar > nested inside another calendar -- whether the events should be > included in the parent calendar or not; whether to display them > differently. Yes, someone else explained that before. Maybe this is an issue though I personally would expect the WebDAV calendar hierarchy to be self contained (no different to generic WebDAV collections). Not sure why one would expect a special meaning for the containment. Just thoughts on this, I'm fine with the current state. Personally I don't need to have calendars below calendars. >> Extension >> ========= >> 'For optimum interoperability with existing HTTP clients, CalDAV >> clients and servers MUST use the file extension ".ics"' > It will just make it easier to synchronize (perhaps with a generic > sync application) to a local file system in a way that works -- and > it's easy to do. I can't see how, but anyway. No strong oposition against .ics though such a MUST is certainly not how HTTP is supposed to work (it MUST return a proper content-type, nothing else) ... Its somewhat inconsistent to your other argumentation to allow for such "hacks" in CalDAV. >> Reports >> ======= ... >> > I agree that the use of report is one of those decisions that could > be argued a number of ways, but I don't want to introduce another > dependency (on XML-RPC or SOAP) when there's a workable WebDAV way > to do this. Since SEARCH is now not required for CalDAV support, I > think that falling back to DASL is no longer an option. I had this discussion with Julian a while back and for me the convincing point is that REPORT is already a standardized while SEARCH is just a draft. Waiting for the new draft :-) regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DJM54X014119 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 May 2005 12:22:07 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9e66f8d17db7e91d72526e185eed38bc@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] CalDAV Notes Date: Fri, 13 May 2005 12:21:59 -0700 To: Helge Hess X-Mailer: Apple Mail (2.622) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 13 May 2005 19:22:21 -0000 Helge I know you sent this mail a long time ago but we weren't ready to deal with all of this.... some of it we were already thinking of changing at the time (like moving fanout to a different spec) but weren't sure how yet. Sorry for the delay. I know some of these issues have actually been discussed in the meantime but I'm not looking up every conversation over the last 9 months to be sure :) (BTW for brevity I've omitted issues that I think are no longer an issue entirely -- you might want to compare to your original mail to see if I've made a mistake there.) On Aug 18, 2004, at 1:53 PM, Helge Hess wrote: > Hi, > > some notes on the CalDAV draft from my OGo-centric POV. Note that > those are just "rough" impressions I got from reading over it. Please > feel free to clarify or comment. > > ACL > === > - do we need this for minimum compliance? > - we already discussed this a bit and I made the suggestion of using > a capability for this (Dan correctly points out that too many > options > will be annoying for client authors) > - a lot of OpenSource servers do not have real "calendar" collections > (OGo > is in this category) > - so "calendars" are just queries and you cannot usually define an > ACLs > on it > - some servers which have "calendar" collections may not have per > object > ACLs (eg Kolab falls into this category) When the CALSCH working group was working on CAP, the access control -- although a difficult piece of functionality to define and agree on -- was generally agreed to be required. I think it even made it into some requirements document. With WebDAV to build on, most of the work of defining ACL is already done so now we consider mostly the implementation difficulty. I'd be happy to collect more information on this. I know Chandler/OSAF has a strong preference (requirement?) for having ACL functionality available; Cosmo (our server) is naturally making the same decision. Unless Cyrus or Bernard want to correct me, it's my impression ISAMET clients and server and Oracle clients and servers all implement ACL and feel it's a necessary use case to support. Who else plans to implement or would have difficulty implementing or considers it a required use case? A server might be able to get away with implementing a very cheesy, limited ACL support -- for example, one that didn't list all the other users of the system, so effectively the client could only change permissions for "all" (public) or "all authenticated". It also wouldn't surprise me if some servers enforced policy such that users were forbidden from granting 'write' or 'set-acl' privilege to public. I haven't really explored how feasible this would be -- the question is whether a client that expected full ACL support would typically degrade gracefully if this was all the server offered. On the issue of how an existing server's data model works and whether calendars are just queries or whether per object ACLs exist... well, this is something that just must be upgraded to support CalDAV. I'll point out that other servers have similar barriers to implementing CalDAV requirements -- for example servers that do not have client-settable paths to calendar components (servers which may be implemented on databases and always use the UID) have an extra barrier to support PUT where the client chooses the URL to the new component. To implement this they have to upgrade their back-end store to include a table mapping client-selected URLs to back-end IDs. Similarly, a server that doesn't currently have per-component ACL will just have to add the capability to their back-end store to support this. > > Custom Props (dead props) > ========================= > - not all servers are flexible enough to allow for this or may be slow > for custom props if they allow for them (eg OGo uses a separate SQL > table > for custom properties) > - but they might be worth it A requirement for WebDAV. CalDAV wouldn't be backward-compatible with WebDAV (and clients would have more difficulties interoperating) without it. And as you point out, it can be useful. In the early days of WebDAV, Adobe clients were testing interoperability with a server that didn't support dead properties correctly. Because the Adobe clients needed to be able to set custom props they ended up using the "owner" field of a lock to put their custom info in! This of course turned out to have its own interoperability problems. Luckily we've mostly ironed those out. > Collections > =========== > - you specify collection types as a complex XML property, eg: > > > > > I "predict" that this will give issues ;-) because a lot of servers > will map properties to simple key/stringvalue hashtables (eg > resourcetype=collection) (although of course XML content is valid in > WebDAV properties, I think few are actually prepared for this) I don't understand this issue -- I agree servers will map properties like this to simple booleans in their back-end store, but since this is a read-only property, how is that a problem? > > - "Calendars MUST NOT contain other calendars" > - hm, why? I think this breaks the common Outlook model also uses in > Evolution where you can nest object folders arbitary Is the Outlook/Evolution model confirmed? Is there some way to map that model to the CalDAV model -- e.g. declare only the deepest-nested of the collections a "calendar"? Our thinking when restricting this, was that making calendars one-level-only made it easier for a client to know how to display. We didn't have to worry about what it "meant" to have a calendar nested inside another calendar -- whether the events should be included in the parent calendar or not; whether to display them differently. > Timezones > ========= > Next draft will deal with timezones differently so I'll skip this and wait to hear your reaction to that > Extension > ========= > 'For optimum interoperability with existing HTTP clients, CalDAV > clients and servers MUST use the file extension ".ics"' > - does this really provide benefits in practice? I understand the > motiviation, > but I guess no one will ever use this in practice (like no one > mounts an > Exchange collection as a WebFolder to access items ...) It will just make it easier to synchronize (perhaps with a generic sync application) to a local file system in a way that works -- and it's easy to do. > > Reports > ======= > - this sounds like putting complex method calls on top of WebDAV, > which I do > no really like - we could use XML-RPC or SOAP for that? > - time ranges are covered by DASL > - options could be either a header (like "expand-recurrence: true") or > a > special dynamic subcollection (lisa/Calendar/expanded/) > - a header is bad because it affects HTTP style caching > - "12.1.1 Request for 'calendar-time-range'" > Sample request for 'time-range-events' report > ... > Isn't that a simple DASL query?: > SELECT dtstart, dtend, sumary, valarm > FROM /lisa/Calendar/ > WHERE dtstart<20041131 AND dtend>20031101 AND type=vevent; > No need for a custom report? I agree that the use of report is one of those decisions that could be argued a number of ways, but I don't want to introduce another dependency (on XML-RPC or SOAP) when there's a workable WebDAV way to do this. Since SEARCH is now not required for CalDAV support, I think that falling back to DASL is no longer an option. Lisa X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DJ5S4X013300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 12:05:29 -0700 Received: from [128.113.124.214] (blue-eyes-white-dragon-06.dynamic2.rpi.edu [128.113.124.214]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4DJ5SxY023034 for ; Fri, 13 May 2005 15:05:28 -0400 Message-ID: <4284FA77.1030904@rpi.edu> Date: Fri, 13 May 2005 15:05:27 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] time-range References: <4284ED1D.9020302@rpi.edu> <4284F5D1.70908@Royer.com> In-Reply-To: <4284F5D1.70908@Royer.com> 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.3 X-Spam-Score: 0 () X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 13 May 2005 19:05:32 -0000 Sorry - it was a bit vague I'm referring to the caldav time-range XML element - 10.4 in the draft Doug Royer wrote: > > Need a little bit more information from you. > > Are you talking VEVENT, RDATE, or what? > > And iCal is like a data dictionary. Its iTIP that tells you how > to construct a sharable object. See the iTIP restriction tables. > > Mike Douglass wrote: > >> Is it correct/intentional that neither start or end is required? >> > >_______________________________________________ >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 > > -- 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 X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DIjg4X011696 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 13 May 2005 11:45:44 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j4DIjbNq029047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 May 2005 11:45:39 -0700 Message-ID: <4284F5D1.70908@Royer.com> Date: Fri, 13 May 2005 12:45:37 -0600 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] time-range References: <4284ED1D.9020302@rpi.edu> In-Reply-To: <4284ED1D.9020302@rpi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080205080108010507010705" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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: Fri, 13 May 2005 18:45:46 -0000 This is a cryptographically signed message in MIME format. --------------ms080205080108010507010705 Content-Type: multipart/mixed; boundary="------------020008020804000304040006" This is a multi-part message in MIME format. --------------020008020804000304040006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Need a little bit more information from you. Are you talking VEVENT, RDATE, or what? And iCal is like a data dictionary. Its iTIP that tells you how to construct a sharable object. See the iTIP restriction tables. Mike Douglass wrote: > Is it correct/intentional that neither start or end is required? > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020008020804000304040006 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-Consuiting.com adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020008020804000304040006-- --------------ms080205080108010507010705 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC 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+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNTEzMTg0NTM3WjAjBgkqhkiG9w0BCQQxFgQU4c81Bpg49oDHRkkSLf04 /F1t5xkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAmZhOsjxZ2GyUlTRe4Bv3Nbr/WW6djDkb5v/MjswFJgElm33BSaQ4dDfeOccxUw9J ykW+xDVeIX0dV7TtYrEVoKenScPTnK66TYp3ot7g0/HikbmxQDt3zaaJjSVgl7HZmzaHqc6C EZ1SxfLFk+LiY+qdl9hNaR/x6EQ7yLr7f65t8/66FWmC0Z7zjA0tn1ddyFIy6Vt31X9dEE3w /T/fDG7UIrR3tsLqX4/p5lTlbxBHwAQeIQW8Yx8nkk7sk8g0oeUYOsxg+mRNLwAG6xvGhXun ksmwTh10qyZ9qlw+3zBa3N7zn1/MHhLOWd3yB/dc6iuNd+bczEZI46VGtPuwfwAAAAAAAA== --------------ms080205080108010507010705-- X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DI8U4X009271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 11:08:31 -0700 Received: from [128.113.124.214] (blue-eyes-white-dragon-06.dynamic2.rpi.edu [128.113.124.214]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4DI8T1K006525 for ; Fri, 13 May 2005 14:08:29 -0400 Message-ID: <4284ED1D.9020302@rpi.edu> Date: Fri, 13 May 2005 14:08:29 -0400 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 X-Spam-Score: 0 () Subject: [Ietf-caldav] time-range X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 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, 13 May 2005 18:08:33 -0000 Is it correct/intentional that neither start or end is required? -- 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 X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4CGMU4X020058 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 12 May 2005 09:22:32 -0700 In-Reply-To: <428380D1.9080603@oracle.com> References: <426EE74B.90403@Royer.com> <426FD354.7070900@oracle.com> <426FEE80.70802@Royer.com> <4270F8A3.5030005@oracle.com> <428380D1.9080603@oracle.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: From: Lisa Dusseault Subject: Re: [Ietf-caldav] 3.3 Timezones Date: Thu, 12 May 2005 09:22:13 -0700 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.622) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j4CGMU4X020058 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 16:22:34 -0000 Sounds great -- I'll work on a new draft. Lisa On May 12, 2005, at 9:14 AM, Bernard Desruisseaux wrote: > Lisa, Cyrus and myself had a discussion on time zones handling > in CalDAV. To make a short story we have decided to remove any > special handling of time zones in CalDAV. We will make sure that > the final CalDAV specification will not block us from allowing > special handling in the future. > > Cheers, > Bernard > > Bernard Desruisseaux wrote: > >> As can be read in "Comment.2" of the same section, this is still >> an open issue. >> 3.3 Timezones >> Calendar resources in CalDAV MUST be valid iCalendar objects. As >> such, an individual VTIMEZONE calendar component MUST be specified >> for each unique TZID parameter value specified in an iCalendar >> object. Unfortunately this mean that the same VTIMEZONE component >> will get sent or retrieved multiple times for each iCalendar object >> that uses the timezone. This is not efficient in terms of >> bandwidth >> usage. >> [[Comment.2: Not clear how big an issue that really is. CalDAV >> already allows clients to retrieve iCalendar objects without their >> VTIMEZONE component with the CALDAV:calendar-query REPORT. It is >> still not clear whether a client could rely only on the value of >> the >> TZID parameter, or should it always requests a VTIMEZONE component >> with at least the TZID and TZURL properties and rely on the TZURL >> as >> a unique identifier for a given time zone. CalDAV servers have no >> choice but to return complete VTIMEZONE components in iCalendar >> object retrieve with the GET method as their is no way to know if >> the >> client is a CalDAV client or a simple HTTP client. On a PUT >> request >> perhaps a CalDAV server could accept an iCalendar object with a >> VTIMEZONE object that has at least TZURL that points to a calendar >> resource that defines a time zone on the server. --desruisseaux]] >> "There is never any justification for compromising correctness for >> the sake of other concerns such as efficiency." -- Bertrand Meyer >> CalDAV MUST always return valid iCalendar objects retrieved with the >> GET method, that is, with complete VTIMEZONE components when >> necessary. >> With the CALDAV:calendar-query REPORT CalDAV clients are able to >> partially retrieve iCalendar objects, as such, clients may retrieve >> iCalendar objects without their VTIMEZONE component(s). The draft will >> need to specify what the CalDAV client may assume about the returned >> TZID if anything (e.g., they can rely on them if they are prefix with >> "/" or they can never rely on them). >> When a CalDAV client creates or update an iCalendar object with the >> PUT >> method it should provide the complete VTIMEZONE component. The draft >> will need to specify whether clients are allowed to submit iCalendar >> objects with TZID parameter value specified but no corresponding >> VTIMEZONE component(s) (e.g., yes if the TZID is prefixed by "/" or >> no otherwise) or whether clients should at least provide a VTIMEZONE >> component for each TZID parameter value specified in the iCalendar >> object, but allow them to only specify a TZURL property pointing to >> a VTIMEZONE component stored in the timezone collection set of the >> CalDAV server instead of providing the full definition. >> I personally don't think that all this added complexity is required. >> "We should forget about small efficiencies, say about 97% of the time: >> premature optimization is the root of all evil." -- Donald E. Knuth >> Cheers, >> Bernard >> Doug Royer wrote: >>> >>> Later in that same section it says: >>> >>> The timezone collection is a calendar collection that contains >>> only >>> VTIMEZONE components as separate resources within that collection. >>> >>> So when I read it, it looks to me as if that does not sufficiently >>> solve the problem. >>> >>> I read it as saying that multiple VEVENTs can point to a single >>> TZID in a timezone collection? If yes, then without a smart compare >>> function it must not be used for externally created VEVENTS. >>> As you could not guarantee that Vendor-A TZID-X was the >>> same as TZID-X in the timezone collection. >>> >>> An later in the draft it says: >>> >>> > o any top-level component that references a timezone via a >>> "TZID" >>> > property MUST include the VTIMEZONE component corresponding to >>> > that timezone id, as required by iCalendar, unless the >>> timezone is >>> > one included in the server's timezone collection, as >>> described in >>> > Section 3.3. >>> > >>> > For example, given the following iCalendar object: >>> >>> Followed by an example that does not have a TZID or VTIMEZONE. >>> >>> So, what is that saying? Is it saying that if a TZID is included >>> and no such VTIMEZONE is included, go fetch it? >>> >>> Or as the example shows, must you use UTC? >>> >>> Or is it saying something else ? >>> >>> >>> Bernard Desruisseaux wrote: >>> >>>> Doug Royer wrote: >>>> >>>>> >>>>> -05 says in part: >>>>> >>>>> > 3.3 Timezones >>>>> > >>>>> Its more complicated than that. It would need to be one VTIMEZONE >>>>> component per unique VTIMEZONE definition. >>>>> >>>>> Without standardized TZID's, there is no guarantee that TZID-X >>>>> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE. >>>> >>>> >>>> >>>> >>>> The sentence « an individual "VTIMEZONE" calendar component MUST be >>>> specified for each unique "TZID" parameter value specified in the >>>> iCalendar object » was copied verbatim from section 4.2.19 Time Zone >>>> Identifier of RFC 2445. >>> >>> >>> >>> Which does not have a separate VTIMEZONE container. So it can't have >>> a conflict. >>> >>>> While I understand what you are trying to say, this sentence is >>>> only making reference to "an iCalendar object". I can't believe >>>> a single iCalendar object would be making reference to multiple >>>> VTIMEZONE definitions with a single TZID. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4CGET4X018935 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 May 2005 09:14:29 -0700 Received: from agminet01.oracle.com (localhost [127.0.0.1]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4CGENvx017106 for ; Thu, 12 May 2005 11:14:23 -0500 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 j4CGEN3v017079 for ; Thu, 12 May 2005 11:14:23 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4CGEMNj017655 for ; Thu, 12 May 2005 10:14:22 -0600 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4CGEAja017587 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 May 2005 10:14:13 -0600 Message-ID: <428380D1.9080603@oracle.com> Date: Thu, 12 May 2005 12:14:09 -0400 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 Subject: Re: [Ietf-caldav] 3.3 Timezones References: <426EE74B.90403@Royer.com> <426FD354.7070900@oracle.com> <426FEE80.70802@Royer.com> <4270F8A3.5030005@oracle.com> In-Reply-To: <4270F8A3.5030005@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 16:14:33 -0000 Lisa, Cyrus and myself had a discussion on time zones handling in CalDAV. To make a short story we have decided to remove any special handling of time zones in CalDAV. We will make sure that the final CalDAV specification will not block us from allowing special handling in the future. Cheers, Bernard Bernard Desruisseaux wrote: > As can be read in "Comment.2" of the same section, this is still > an open issue. > > 3.3 Timezones > > Calendar resources in CalDAV MUST be valid iCalendar objects. As > such, an individual VTIMEZONE calendar component MUST be specified > for each unique TZID parameter value specified in an iCalendar > object. Unfortunately this mean that the same VTIMEZONE component > will get sent or retrieved multiple times for each iCalendar object > that uses the timezone. This is not efficient in terms of bandwidth > usage. > > [[Comment.2: Not clear how big an issue that really is. CalDAV > already allows clients to retrieve iCalendar objects without their > VTIMEZONE component with the CALDAV:calendar-query REPORT. It is > still not clear whether a client could rely only on the value of the > TZID parameter, or should it always requests a VTIMEZONE component > with at least the TZID and TZURL properties and rely on the TZURL as > a unique identifier for a given time zone. CalDAV servers have no > choice but to return complete VTIMEZONE components in iCalendar > object retrieve with the GET method as their is no way to know if the > client is a CalDAV client or a simple HTTP client. On a PUT request > perhaps a CalDAV server could accept an iCalendar object with a > VTIMEZONE object that has at least TZURL that points to a calendar > resource that defines a time zone on the server. --desruisseaux]] > > "There is never any justification for compromising correctness for > the sake of other concerns such as efficiency." -- Bertrand Meyer > > CalDAV MUST always return valid iCalendar objects retrieved with the > GET method, that is, with complete VTIMEZONE components when necessary. > > With the CALDAV:calendar-query REPORT CalDAV clients are able to > partially retrieve iCalendar objects, as such, clients may retrieve > iCalendar objects without their VTIMEZONE component(s). The draft will > need to specify what the CalDAV client may assume about the returned > TZID if anything (e.g., they can rely on them if they are prefix with > "/" or they can never rely on them). > > When a CalDAV client creates or update an iCalendar object with the PUT > method it should provide the complete VTIMEZONE component. The draft > will need to specify whether clients are allowed to submit iCalendar > objects with TZID parameter value specified but no corresponding > VTIMEZONE component(s) (e.g., yes if the TZID is prefixed by "/" or > no otherwise) or whether clients should at least provide a VTIMEZONE > component for each TZID parameter value specified in the iCalendar > object, but allow them to only specify a TZURL property pointing to > a VTIMEZONE component stored in the timezone collection set of the > CalDAV server instead of providing the full definition. > > I personally don't think that all this added complexity is required. > > "We should forget about small efficiencies, say about 97% of the time: > premature optimization is the root of all evil." -- Donald E. Knuth > > Cheers, > Bernard > > Doug Royer wrote: > >> >> Later in that same section it says: >> >> The timezone collection is a calendar collection that contains only >> VTIMEZONE components as separate resources within that collection. >> >> So when I read it, it looks to me as if that does not sufficiently >> solve the problem. >> >> I read it as saying that multiple VEVENTs can point to a single >> TZID in a timezone collection? If yes, then without a smart compare >> function it must not be used for externally created VEVENTS. >> As you could not guarantee that Vendor-A TZID-X was the >> same as TZID-X in the timezone collection. >> >> An later in the draft it says: >> >> > o any top-level component that references a timezone via a "TZID" >> > property MUST include the VTIMEZONE component corresponding to >> > that timezone id, as required by iCalendar, unless the timezone is >> > one included in the server's timezone collection, as described in >> > Section 3.3. >> > >> > For example, given the following iCalendar object: >> >> Followed by an example that does not have a TZID or VTIMEZONE. >> >> So, what is that saying? Is it saying that if a TZID is included >> and no such VTIMEZONE is included, go fetch it? >> >> Or as the example shows, must you use UTC? >> >> Or is it saying something else ? >> >> >> Bernard Desruisseaux wrote: >> >>> Doug Royer wrote: >>> >>>> >>>> -05 says in part: >>>> >>>> > 3.3 Timezones >>>> > >>>> Its more complicated than that. It would need to be one VTIMEZONE >>>> component per unique VTIMEZONE definition. >>>> >>>> Without standardized TZID's, there is no guarantee that TZID-X >>>> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE. >>> >>> >>> >>> >>> The sentence « an individual "VTIMEZONE" calendar component MUST be >>> specified for each unique "TZID" parameter value specified in the >>> iCalendar object » was copied verbatim from section 4.2.19 Time Zone >>> Identifier of RFC 2445. >> >> >> >> Which does not have a separate VTIMEZONE container. So it can't have >> a conflict. >> >>> While I understand what you are trying to say, this sentence is >>> only making reference to "an iCalendar object". I can't believe >>> a single iCalendar object would be making reference to multiple >>> VTIMEZONE definitions with a single TZID. >> >> >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet03.oracle.com (rgminet03.oracle.com [148.87.122.32]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4ADPWOg007866 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 10 May 2005 06:25:33 -0700 Received: from rgminet03.oracle.com (localhost [127.0.0.1]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j4ADPRCv007543; Tue, 10 May 2005 07:25:27 -0600 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j4ADPPag007513; Tue, 10 May 2005 07:25:26 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4ADPPpW032321; Tue, 10 May 2005 07:25:25 -0600 Received: from [144.23.219.129] (dhcp-ca-montreal-144-23-219-129.ca.oracle.com [144.23.219.129]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4ADPFIP032264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 May 2005 07:25:16 -0600 Message-ID: <4280B63A.1030700@oracle.com> Date: Tue, 10 May 2005 09:25:14 -0400 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: Jeffrey Harris Subject: Re: [Ietf-caldav] 3.3 Timezones References: <426EE74B.90403@Royer.com> <426FD354.7070900@oracle.com> <427FE6AB.50207@skyhouseconsulting.com> In-Reply-To: <427FE6AB.50207@skyhouseconsulting.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 13:25:33 -0000 Hi Jeffrey, I was not questioning the fact that an iCalendar object could make use of more than one TZID, but rather make reference to multiple VTIMEZONE components with only one TZID. No disagreement here! Cheers, Bernard Jeffrey Harris wrote: > Hi Bernard, > > [snip] > > >>While I understand what you are trying to say, this sentence is >>only making reference to "an iCalendar object". I can't believe >>a single iCalendar object would be making reference to multiple >>VTIMEZONE definitions with a single TZID. > > > Suppose I have a quarterly meeting, the first Monday of the quarter at > 9AM San Francisco time. Then my company gets bought, in the future the > quarterly meeting will be held at 5PM Stuttgart time. It's one object > with two TZIDs. > > Sincerely, > Jeffrey Harris X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.122.30]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4A2XEOg028702 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 9 May 2005 19:33:15 -0700 Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4A2X93t017664 for ; Mon, 9 May 2005 20:33:09 -0600 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 j4A2X7Rf017638 for ; Mon, 9 May 2005 20:33:08 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4A2X7DW028531 for ; Mon, 9 May 2005 20:33:07 -0600 Received: from [192.168.1.200] (dhcp-amer-csvpn-gw1-141-144-64-107.vpn.oracle.com [141.144.64.107]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4A2WvXA028477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 9 May 2005 20:32:58 -0600 Message-ID: <42801D58.4060805@oracle.com> Date: Mon, 09 May 2005 22:32:56 -0400 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] 2nd CalDAV Interop Test Event -- June 1-2, 2005 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 02:33:17 -0000 The 2nd CalDAV Interop Test Event of The Calendaring and Scheduling Consortium will take place Wednesday and Thursday, June 1-2, 2005, hosted by Duke University in Durham, North Carolina. Already more vendors than last time have confirmed their presence! A preliminary version of the scenarios that will be tested for this 2nd CalDAV Interop is available online at the following URL: http://ietf.webdav.org/caldav/iop/CalDAV-IOP-02-Test-Scenarios.doc For more information on the Interop Test Event have a look at the following page on the Calconnect.org web site: http://www.calconnect.org/iopjun2005.html Cheers, Bernard X-Envelope-From: jeffrey@skyhouseconsulting.com X-Envelope-To: Received: from mail.skyhouseconsulting.com (skyhouseconsulting.com [69.55.227.180]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j49MdgOg011162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 May 2005 15:39:43 -0700 Received: from [192.168.1.99] (unknown [216.146.255.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhouseconsulting.com (Postfix) with ESMTP id 450FF38C2020; Mon, 9 May 2005 17:39:42 -0500 (CDT) Message-ID: <427FE6AB.50207@skyhouseconsulting.com> Date: Mon, 09 May 2005 17:39:39 -0500 From: Jeffrey Harris User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] 3.3 Timezones References: <426EE74B.90403@Royer.com> <426FD354.7070900@oracle.com> In-Reply-To: <426FD354.7070900@oracle.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 22:39:45 -0000 Hi Bernard, [snip] > While I understand what you are trying to say, this sentence is > only making reference to "an iCalendar object". I can't believe > a single iCalendar object would be making reference to multiple > VTIMEZONE definitions with a single TZID. Suppose I have a quarterly meeting, the first Monday of the quarter at 9AM San Francisco time. Then my company gets bought, in the future the quarterly meeting will be held at 5PM Stuttgart time. It's one object with two TZIDs. Sincerely, Jeffrey Harris