From cbryant-ical at corp.usa.net Tue May 10 11:59:22 2005 From: cbryant-ical at corp.usa.net (cbryant-ical@corp.usa.net) Date: Tue May 10 11:59:36 2005 Subject: [Ietf-calsify] VTODO questions Message-ID: <538JeJs8w7648S18.1115751562@uwdvg018.cms.usa.net> I have some questions about VTODO interoperability that I was hoping somebody on the calsify list could help me answer. We are currently trying to implement todos into our server with the goal of being as interoperable as possible with other calendar servers/clients. I know RFC 2445 has a lot of shortfalls regarding VTODOs, but we're willing to live with some of these shortcomings if it increases our interoperability. At this point though, I am having difficulty determining what clients and servers we would be able to interoperate with. Can anyone point me at some calendar clients and servers that support assigning and responding to VTODOs with iMIP? Has calsify or any other group tried to quantify the level of interoperability that exists with VTODOs? Are there any interoperability test reports for this? Is calsify looking at what to do about VTODOs, or are VTODOs used so little right now that standardization of these is considered a low priority? Thanks, Chris Bryant From tantek at technorati.com Thu May 12 14:39:35 2005 From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=) Date: Thu May 12 14:39:50 2005 Subject: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification Message-ID: In my opinion it is not clear in the spec (either RFC2445 or the iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a VEVENT. E.g.: BEGIN:VEVENT LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia SUMMARY:Web Essentials 05 DTEND:20050930T093000Z DTSTART:20050928T230000Z URL:http://we05.com/ RDATE;VALUE=PERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ 20050930T0930Z END:VEVENT The RDATE is saying this event takes place in two discrete chunks over the course of two days. The DTSTART/DTEND combo is saying the event takes place for 34.5 hours straight. Which should the CUA "choose" from those two options? Is this an invalid VEVENT? Thanks, Tantek -- Tantek ?elik Senior Technologist, Technorati, Inc. tantek@technorati.com -- Tantek ?elik Technorati, Inc. tantek@technorati.com 415-254-9656 (Mobile) From Doug at Royer.com Thu May 12 15:14:03 2005 From: Doug at Royer.com (Doug Royer) Date: Thu May 12 15:14:18 2005 Subject: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification In-Reply-To: References: Message-ID: <4283D52B.8070209@Royer.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050512/d02b761c/smime.bin From tantek at technorati.com Thu May 12 15:42:56 2005 From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=) Date: Thu May 12 15:43:02 2005 Subject: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification In-Reply-To: <4283D52B.8070209@Royer.com> References: <4283D52B.8070209@Royer.com> Message-ID: <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> But look at the times. The first instance overlaps the other two entirely. Are you saying that is valid? And if so, how is a CUA possibly expected to represent that in some meaningful form to the user? Warn them that two or more instances of the same meeting are occurring at the same time? The spec says that exact RRULE/RDATE event instance duplicates are supposed to be tossed, but says nothing about having the same meeting take place twice at the same time which makes no sense. Why is it useful for the spec to allow this? How do implementations handle/display/edit this VEVENT? Thanks, Tantek On May 13, 2005, at 7:14 AM, Doug Royer wrote: > > It has 3 instances, not 2. > > iCal-Basic deprecated DTEND, so it would be (assuming I > did my time math correctly: > > BEGIN:VEVENT > LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia > SUMMARY:Web Essentials 05 > DTSTART:20050928T230000Z > DURATION:+PT34H30M > RDATE;VALUE=PERIOD:20050928T230000Z/PT9H,20050929T213000Z/PT20H30M > END:VEVENT > > The first instance starts at 0050928T230000Z and ends 34.5 hours later. > The second instance starts at 20050928T230000Z and ends 9.0 hours > later. > The third instance starts at 20050929T213000Z and ends 20.5 hours > later. > > Tantek ?elik wrote: >> In my opinion it is not clear in the spec (either RFC2445 or the >> iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an >> RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a >> VEVENT. >> E.g.: >> BEGIN:VEVENT >> LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia >> SUMMARY:Web Essentials 05 >> DTEND:20050930T093000Z >> DTSTART:20050928T230000Z >> URL:http://we05.com/ >> RDATE;VALUE=PERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ >> 20050930T0930Z >> END:VEVENT >> The RDATE is saying this event takes place in two discrete chunks >> over the course of two days. >> The DTSTART/DTEND combo is saying the event takes place for 34.5 >> hours straight. >> Which should the CUA "choose" from those two options? >> Is this an invalid VEVENT? >> Thanks, >> Tantek >> -- >> Tantek ?elik >> Senior Technologist, Technorati, Inc. >> tantek@technorati.com >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > > We Do Standards - You Need Standards > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- Tantek ?elik Senior Technologist, Technorati, Inc. tantek@technorati.com From camerost at exchange.microsoft.com Thu May 12 17:01:17 2005 From: camerost at exchange.microsoft.com (Cameron Stillion) Date: Thu May 12 17:01:27 2005 Subject: [Ietf-calsify] VTODO questions Message-ID: <1198328AFDBF5841B27E40C40C3315370347630F@df-chewy-msg.exchange.corp.microsoft.com> So far, the extent of VTODO "simplification" and "clarification" for the purposes of interoperability have amounted to this: Deprecation. Tasks as a datatype, IMHO, belong in a separate specification - when and if there is adequate interest in such a standard. Muddying the waters with tasks is one of the things that has likely kept iCal from becoming a standard for the past few years. (...think of it as including your pet political hack for a kickback in the next tax cut bill...) Cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of cbryant-ical@corp.usa.net Sent: Tuesday, May 10, 2005 11:59 AM To: Calsify Subject: [Ietf-calsify] VTODO questions I have some questions about VTODO interoperability that I was hoping somebody on the calsify list could help me answer. We are currently trying to implement todos into our server with the goal of being as interoperable as possible with other calendar servers/clients. I know RFC 2445 has a lot of shortfalls regarding VTODOs, but we're willing to live with some of these shortcomings if it increases our interoperability. At this point though, I am having difficulty determining what clients and servers we would be able to interoperate with. Can anyone point me at some calendar clients and servers that support assigning and responding to VTODOs with iMIP? Has calsify or any other group tried to quantify the level of interoperability that exists with VTODOs? Are there any interoperability test reports for this? Is calsify looking at what to do about VTODOs, or are VTODOs used so little right now that standardization of these is considered a low priority? Thanks, Chris Bryant _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From Doug at Royer.com Thu May 12 17:29:38 2005 From: Doug at Royer.com (Doug Royer) Date: Thu May 12 17:29:48 2005 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? In-Reply-To: <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> Message-ID: <4283F4F2.30608@Royer.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050512/3d4e7d17/smime-0001.bin From tantek at technorati.com Thu May 12 17:48:30 2005 From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=) Date: Thu May 12 17:47:34 2005 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? In-Reply-To: <4283F4F2.30608@Royer.com> References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> Message-ID: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> Thanks for the answers Doug. Some follow up below. On May 12, 2005, at 5:29 PM, Doug Royer wrote: > > > Tantek ?elik wrote: >> But look at the times. >> The first instance overlaps the other two entirely. >> Are you saying that is valid? > > Yes. > >> And if so, how is a CUA possibly expected to represent that in some >> meaningful form to the user? > > Odd - yes. Valid - yes. > >> Warn them that two or more instances of the same meeting are >> occurring at the same time? > > That's up to the CUA. > >> The spec says that exact RRULE/RDATE event instance duplicates are >> supposed to be tossed, but says nothing about having the same meeting >> take place twice at the same time which makes no sense. Why is it >> useful for the spec to allow this? > > I do not recall there being a discussion on this topic. > > Might be a good discussion. > > Where iCal-Basic says (4.10.3 Recurrence Date/Times, > page 82): > > > ...Where duplicate instances are generated by the "RDATE" > properties, only one recurrence is considered. ... > > > If iCal-Basic said: > > ...Where duplicate instances are generated by the "RDATE" > properties, only one recurrence is considered. > All instance times in a "VEVENT" component with the > same "UID" property value MUST NOT overlap each other. > ... > > (I need to spend more time on the exact language) > > Would anyone object? Reinhold said something that made it immediately obvious to me why this made sense. On May 12, 2005, at 3:53 PM, Reinhold Kainhofer wrote: > Am Freitag, 13. Mai 2005 00:42 schrieb Tantek ?elik: >> The spec says that exact RRULE/RDATE event instance duplicates are >> supposed to be tossed, but says nothing about having the same meeting >> take place twice at the same time which makes no sense. ?Why is it >> useful for the spec to allow this? > > Because an event is not neccessarily a meeting, where you can only > attend > once... > > Reinhold Thanks Reinhold. Your explanation made me think of the following example: A museum tour that leaves on the hour every hour while the museum is open, from the information desk, and lasts two hours, with the last one of the day leaving two hours before the museum closing time. Doug, what do you think, would that be a reasonable use of overlapping repeating event times? >> How do implementations handle/display/edit this VEVENT? > > You would have to try different CUA's to find out. Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn that it looks like it has NO SUPPORT FOR RDATE. :( I'm beginning to understand the pain some of the veterans of this list have been dealing with. Tantek -- Tantek ?elik Senior Technologist, Technorati, Inc. tantek@technorati.com From Doug at Royer.com Thu May 12 21:33:38 2005 From: Doug at Royer.com (Doug Royer) Date: Thu May 12 21:33:55 2005 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? In-Reply-To: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> <211a53e3759e5fab6a268c64493ef1ad@technorati.com> Message-ID: <42842E22.5000909@Royer.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050512/b8b31c41/smime.bin From sroberts at uniserve.com Fri May 13 16:30:39 2005 From: sroberts at uniserve.com (Sam Roberts) Date: Fri May 13 16:31:17 2005 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? In-Reply-To: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> <211a53e3759e5fab6a268c64493ef1ad@technorati.com> Message-ID: <20050513233038.GA493@ensemble.local> Quoting tantek@technorati.com, on Thu, May 12, 2005 at 05:48:30PM -0700: > Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn > that it looks like it has NO SUPPORT FOR RDATE. :( > > I'm beginning to understand the pain some of the veterans of this list > have been dealing with. Some of those veterans are trying to deprecate RRULE (which iCal.app does support) in favor of always using RDATE. Its not clear that this will cause a decrease in pain. Cheers, Sam From Doug at Royer.com Fri May 13 16:37:34 2005 From: Doug at Royer.com (Doug Royer) Date: Fri May 13 16:38:35 2005 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? In-Reply-To: <20050513233038.GA493@ensemble.local> References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> <211a53e3759e5fab6a268c64493ef1ad@technorati.com> <20050513233038.GA493@ensemble.local> Message-ID: <42853A3E.6070002@Royer.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050513/3f5b41af/smime.bin From reinhold at kainhofer.com Fri May 13 17:44:01 2005 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Fri May 13 17:44:16 2005 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? In-Reply-To: <20050513233038.GA493@ensemble.local> References: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> <20050513233038.GA493@ensemble.local> Message-ID: <200505140244.03692.reinhold@kainhofer.com> Am Samstag, 14. Mai 2005 01:30 schrieb Sam Roberts: > Quoting tantek@technorati.com, on Thu, May 12, 2005 at 05:48:30PM -0700: > > Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn > > that it looks like it has NO SUPPORT FOR RDATE. :( > > > > I'm beginning to understand the pain some of the veterans of this list > > have been dealing with. > > Some of those veterans are trying to deprecate RRULE (which iCal.app > does support) in favor of always using RDATE. Its not clear that this > will cause a decrease in pain. KOrganizer also doesn't support RDATE (it simply doesn't fit the typical recurrence pattern that an ordinary user would use). Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050514/14e83d9c/attachment.bin From Dave.Thewlis at calconnect.org Thu May 19 11:04:48 2005 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Thu May 19 11:04:56 2005 Subject: [Ietf-calsify] Status of Calconnect Recurrence Questionnaire results, and future questionnaires Message-ID: <428CD540.4050109@calconnect.org> An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050519/d7c8ea5b/attachment.htm From daniele.tiles at gmail.com Fri May 20 03:15:37 2005 From: daniele.tiles at gmail.com (Daniele Tiles) Date: Fri May 20 03:15:41 2005 Subject: [Ietf-calsify] About TZID... Message-ID: <6bd837ee050520031516dcfc72@mail.gmail.com> Hi! I'm a student graduating at the University of Bologna (Italy) and I have to develop a WS able to convert the lesson's timetable into an iCalendar...I've some problems understanding the TimeZone Identifier: I've read that "...Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]" I've searched through Internet, but I'm not able to understand: do I have to install this database? How does it work? Where can I find the correct lists of TZID? Do you think it's better to define a VTimeZone component? Thanks to everyone Daniele P.S.: If someone is interested why a lesson's timetable should have a TZID...well, it may happen that the timetables have been defined when a professor is abroad for a convention...so I thought it's quite important... P.P.S.: I've got another problem: most of the professor at my university use Outlook2003...and I've discovered with my mentor that some optional rfc2445 properties are required properties for this program...do you know where I could find the Microsoft specification for iCalendar? From TimHare at comcast.net Fri May 20 10:55:31 2005 From: TimHare at comcast.net (Tim Hare) Date: Fri May 20 10:55:42 2005 Subject: [Ietf-calsify] draft-hare-xcalendar-03 has been published. Message-ID: <6.2.1.2.0.20050520134840.01c912a8@mail.comcast.net> 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. From Dave.Thewlis at calconnect.org Fri May 20 13:32:50 2005 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Fri May 20 13:33:01 2005 Subject: [Ietf-calsify] Help Needed again - Questionnaire on Implementation of Timezones - Calconnect and Calsify Message-ID: <428E4972.8080702@calconnect.org> An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050520/ae8883c1/attachment.htm From Doug at Royer.com Fri May 27 13:27:56 2005 From: Doug at Royer.com (Doug Royer) Date: Fri May 27 13:28:13 2005 Subject: [Ietf-calsify] Quiet - must be good? Message-ID: <429782CC.5010900@Royer.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4696 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050527/4edf0143/smime.bin 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 j4RKS2so013108 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 27 May 2005 13:28:05 -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 j4RKRuD8001242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 May 2005 13:27:59 -0700 Message-ID: <429782CC.5010900@Royer.com> Date: Fri, 27 May 2005 14:27:56 -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: Calsify Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000909000801060703030306" 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 Subject: [Ietf-calsify] Quiet - must be good? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 20:28:10 -0000 This is a cryptographically signed message in MIME format. --------------ms000909000801060703030306 Content-Type: multipart/mixed; boundary="------------020609030701030705040505" This is a multi-part message in MIME format. --------------020609030701030705040505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As I have not seen any issues here, I am going to update draft iCal-Basic with the DURATION discussion here plus the other iCal issues that were posted here. It should be out in a week or so.. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020609030701030705040505 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 --------------020609030701030705040505-- --------------ms000909000801060703030306 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 9w0BCQUxDxcNMDUwNTI3MjAyNzU2WjAjBgkqhkiG9w0BCQQxFgQUehHeR5PQHrsqo33hrpr/ jPXUDOUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAA7UEecyLC5sYYpT33RlMUwZ4rAca049N+D32dR0Wz97C/VK5HCTYPppKX3sabLxh ONI8cLon3WPPDFVE/1b5Flpzg7q6nso2VZ+JwVtczANKUlMjCEgjwYnVEj9rtC0Ma8SQlhxZ q1tieew7J33bMlUIG499gEEUFSP7M5UWvlHMy+Gl0eZUT3y2nwahF6pS9421xUFXILRusyiq VU+PvBGXXOCJkcChPk9g9Njn3W+UacQlycka85IP4w41PTWL0x2ZskYEQyMZ33txSM9UcYDG 02FozByYxwdwfrgdQXpL/z8fDkaZ4+Qk8WzGgWHBrfHGGwUPZpA6vmHQAJnQbAAAAAAAAA== --------------ms000909000801060703030306-- X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j4KKWwsn022403 for ; Fri, 20 May 2005 13:32:58 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.110.148 with plain) by smtp814.mail.sc5.yahoo.com with SMTP; 20 May 2005 20:32:58 -0000 Message-ID: <428E4972.8080702@calconnect.org> Date: Fri, 20 May 2005 13:32:50 -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-calsify 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-calsify] Help Needed again - Questionnaire on Implementation of Timezones - Calconnect and Calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 20:32:59 -0000 
Dear IETF-CALSIFY,

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-calsify] draft-hare-xcalendar-03 has been published. X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org 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: daniele.tiles@gmail.com X-Envelope-To: Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4KAFcsn032631 for ; Fri, 20 May 2005 03:15:38 -0700 Received: by rproxy.gmail.com with SMTP id g11so751350rne for ; Fri, 20 May 2005 03:15:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=k9GQAc9yqosO5nP57WqmYYRMMEw9jk7WegTGPxvMU+lypk6fxNg/2RslUeMVYUFwh7k9nr52J7Q29glfCxkg7b4/CWEVMYdKiCyABIKkAXnO4092BOvf8MRBXSU0c3bFIdKAgHiHZfuopTXz77mCo09M/gKZIHMvL3/NpH97Ck4= Received: by 10.38.74.75 with SMTP id w75mr1695742rna; Fri, 20 May 2005 03:15:38 -0700 (PDT) Received: by 10.39.1.22 with HTTP; Fri, 20 May 2005 03:15:37 -0700 (PDT) Message-ID: <6bd837ee050520031516dcfc72@mail.gmail.com> Date: Fri, 20 May 2005 12:15:37 +0200 From: Daniele Tiles To: ietf-calsify@osafoundation.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.537 () DNS_FROM_RFC_ABUSE,HTML_00_10,HTML_MESSAGE,RCVD_BY_IP Content-Disposition: inline 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 j4KAFcsn032631 Subject: [Ietf-calsify] About TZID... X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Daniele Tiles List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 10:15:39 -0000 Hi! I'm a student graduating at the University of Bologna (Italy) and I have to develop a WS able to convert the lesson's timetable into an iCalendar...I've some problems understanding the TimeZone Identifier: I've read that "...Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]" I've searched through Internet, but I'm not able to understand: do I have to install this database? How does it work? Where can I find the correct lists of TZID? Do you think it's better to define a VTimeZone component? Thanks to everyone Daniele P.S.: If someone is interested why a lesson's timetable should have a TZID...well, it may happen that the timetables have been defined when a professor is abroad for a convention...so I thought it's quite important... P.P.S.: I've got another problem: most of the professor at my university use Outlook2003...and I've discovered with my mentor that some optional rfc2445 properties are required properties for this program...do you know where I could find the Microsoft specification for iCalendar? X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp809.mail.sc5.yahoo.com (smtp809.mail.sc5.yahoo.com [66.163.168.188]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j4JI4rsn018282 for ; Thu, 19 May 2005 11:04:53 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.110.148 with plain) by smtp809.mail.sc5.yahoo.com with SMTP; 19 May 2005 18:04:52 -0000 Message-ID: <428CD540.4050109@calconnect.org> Date: Thu, 19 May 2005 11:04:48 -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-calsify 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-calsify] Status of Calconnect Recurrence Questionnaire results, and future questionnaires X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 18:04:53 -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: reinhold@kainhofer.com X-Envelope-To: Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4E0i8vM010000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 May 2005 17:44:10 -0700 Received: from heisenberg (chello062178130194.6.13.tuwien.teleweb.at [62.178.130.194]) (authenticated bits=0) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-1) with ESMTP id j4E0i5v9025248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 14 May 2005 02:44:07 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: Calsify Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? Date: Sat, 14 May 2005 02:44:01 +0200 User-Agent: KMail/1.8 References: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> <20050513233038.GA493@ensemble.local> In-Reply-To: <20050513233038.GA493@ensemble.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3994635.n2XghWykIc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505140244.03692.reinhold@kainhofer.com> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 00:44:12 -0000 --nextPart3994635.n2XghWykIc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Samstag, 14. Mai 2005 01:30 schrieb Sam Roberts: > Quoting tantek@technorati.com, on Thu, May 12, 2005 at 05:48:30PM -0700: > > Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn > > that it looks like it has NO SUPPORT FOR RDATE. :( > > > > I'm beginning to understand the pain some of the veterans of this list > > have been dealing with. > > Some of those veterans are trying to deprecate RRULE (which iCal.app > does support) in favor of always using RDATE. Its not clear that this > will cause a decrease in pain. KOrganizer also doesn't support RDATE (it simply doesn't fit the typical=20 recurrence pattern that an ordinary user would use). Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain= er --nextPart3994635.n2XghWykIc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBChUnTTqjEwhXvPN0RAnfIAJ9jfhcLK96a5Zaco4nfAlfEUKGIKgCeMdI/ CG4rwEhjXH0XAR9IOjhImUA= =2UuI -----END PGP SIGNATURE----- --nextPart3994635.n2XghWykIc-- 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 j4DNbhvM005585 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Fri, 13 May 2005 16:37: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 j4DNbZTS032550 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 13 May 2005 16:37:38 -0700 Message-ID: <42853A3E.6070002@Royer.com> Date: Fri, 13 May 2005 17:37:34 -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: Calsify Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> <211a53e3759e5fab6a268c64493ef1ad@technorati.com> <20050513233038.GA493@ensemble.local> In-Reply-To: <20050513233038.GA493@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070508050601000903090102" 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-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 23:38:23 -0000 This is a cryptographically signed message in MIME format. --------------ms070508050601000903090102 Content-Type: multipart/mixed; boundary="------------030907070709040808040800" This is a multi-part message in MIME format. --------------030907070709040808040800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > Quoting tantek@technorati.com, on Thu, May 12, 2005 at 05:48:30PM -0700: > >>Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn >>that it looks like it has NO SUPPORT FOR RDATE. :( >> >>I'm beginning to understand the pain some of the veterans of this list >>have been dealing with. > > > Some of those veterans are trying to deprecate RRULE (which iCal.app > does support) ... However not fully, so no, they do not support RRULE, they support part of RRULE as defined in 2445/2446 > ... in favor of always using RDATE. Its not clear that this > will cause a decrease in pain. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030907070709040808040800 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 --------------030907070709040808040800-- --------------ms070508050601000903090102 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 9w0BCQUxDxcNMDUwNTEzMjMzNzM0WjAjBgkqhkiG9w0BCQQxFgQUeHQFQg677rdenraONAao T/paW70wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAgwsR9rx7oBxMQjtcpVlAgiHUAYY4zpoGzHcWt9TkruODaK3YjrGDRu6O27vHOQj6 nEfiVzJfqfl1fP0pVFWdj1dnE0B5MXzXU0fSfHG5gLRU2edIfLr5vPCvbrd4Q3w8tLni5KVe 4yrVMChoJTEWavSm37Y/qiBvimU7z6ZxOeFXvtbMbXzj5njwVpk8ROydK8S41N8793P+muu2 ej9jRXuo0+On+ISxu5sS4ScuNQZZ38FJ7bOhefVF1YbhWT+mooBQQSsmNF/KwOZSRvpuk57c q9O+GU+VkiQbS9U0LXWDXjBuxbG1hLsAwZDIqyqcGAKauB3rvlpWU7FDeP7cHgAAAAAAAA== --------------ms070508050601000903090102-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: Received: from tomts36-srv.bellnexxia.net (tomts36-srv.bellnexxia.net [209.226.175.93]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4DNVAvL005068 for ; Fri, 13 May 2005 16:31:10 -0700 Received: from ensemble.local ([70.50.117.89]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050513233109.YUCB16985.tomts36-srv.bellnexxia.net@ensemble.local> for ; Fri, 13 May 2005 19:31:09 -0400 Received: by ensemble.local (Postfix, from userid 501) id 9EB6C43E69A; Fri, 13 May 2005 19:30:39 -0400 (EDT) Date: Fri, 13 May 2005 19:30:39 -0400 From: Sam Roberts To: Calsify Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? Message-ID: <20050513233038.GA493@ensemble.local> Mail-Followup-To: Calsify References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> <211a53e3759e5fab6a268c64493ef1ad@technorati.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 23:31:13 -0000 Quoting tantek@technorati.com, on Thu, May 12, 2005 at 05:48:30PM -0700: > Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn > that it looks like it has NO SUPPORT FOR RDATE. :( > > I'm beginning to understand the pain some of the veterans of this list > have been dealing with. Some of those veterans are trying to deprecate RRULE (which iCal.app does support) in favor of always using RDATE. Its not clear that this will cause a decrease in pain. Cheers, Sam 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 j4D4Xi4X009280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 12 May 2005 21:33:46 -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 j4D4Xck3006798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 May 2005 21:33:41 -0700 Message-ID: <42842E22.5000909@Royer.com> Date: Thu, 12 May 2005 22:33:38 -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: Calsify Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> <211a53e3759e5fab6a268c64493ef1ad@technorati.com> In-Reply-To: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050709000301000303020503" 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-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 04:33:53 -0000 This is a cryptographically signed message in MIME format. --------------ms050709000301000303020503 Content-Type: multipart/mixed; boundary="------------010904090607040609050300" This is a multi-part message in MIME format. --------------010904090607040609050300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Yes - that is the way the IETF works. Make a firm proposal and you find the truth! :-) > Reinhold said something that made it immediately obvious to me why this= =20 > made sense. >=20 > On May 12, 2005, at 3:53 PM, Reinhold Kainhofer wrote: >=20 >> Am Freitag, 13. Mai 2005 00:42 schrieb Tantek =C7elik: >> >>> The spec says that exact RRULE/RDATE event instance duplicates are >>> supposed to be tossed, but says nothing about having the same meeting= >>> take place twice at the same time which makes no sense. Why is it >>> useful for the spec to allow this? >> >> >> Because an event is not neccessarily a meeting, where you can only att= end >> once... >> >> Reinhold >=20 >=20 > Thanks Reinhold. Your explanation made me think of the following examp= le: >=20 > A museum tour that leaves on the hour every hour while the museum is=20 > open, from the information desk, and lasts two hours, with the last one= =20 > of the day leaving two hours before the museum closing time. >=20 > Doug, what do you think, would that be a reasonable use of overlapping = > repeating event times? --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------010904090607040609050300 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 --------------010904090607040609050300-- --------------ms050709000301000303020503 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 9w0BCQUxDxcNMDUwNTEzMDQzMzM4WjAjBgkqhkiG9w0BCQQxFgQU+4hr2I3Kk30tvBO05A9C ucH0ERkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAiw2x8XxrWnHbrY69b0cnJC4ZuBYvOji1r8VTVJETGbnC8raNXSYFdFZ2DgSw4k1M xB9k/6QME9WbtTR9Xzfmb4jzr1MCY8t89o0vUkzeOeM8DnoYdAoJC4rKvl2+FtvcpLSaWJAZ CMzPRNMLwLuvIFk367gAuXj8oy/V3ohH6xMXLpk00CdpP7qcV+T8Zpwg7a8qwOhmDD1uNlyn uazMwpXJMbIKAn2N3oxvM9kii8vCqDhBji4JWFwW5GGW45gnBCiiTEJ7T6HC8Kg0lozz/QrT IOtFHzyEzssYm4nE+QJM2CqHrLoYHqayqNc0X5R9Sxv8EZJ9Ob2DL/SWiRQ/TwAAAAAAAA== --------------ms050709000301000303020503-- X-Envelope-From: tantek@technorati.com X-Envelope-To: Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4D0lV4X024924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2005 17:47:31 -0700 Received: from [IPv6:::1] (localhost.technorati.com [127.0.0.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id CF3262127E8 for ; Thu, 12 May 2005 17:48:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <4283F4F2.30608@Royer.com> References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> <4283F4F2.30608@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <211a53e3759e5fab6a268c64493ef1ad@technorati.com> From: =?ISO-8859-1?Q?Tantek_=C7elik?= Subject: Re: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? Date: Thu, 12 May 2005 17:48:30 -0700 To: Calsify X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () 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 j4D0lV4X024924 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 00:47:33 -0000 Thanks for the answers Doug. Some follow up below. On May 12, 2005, at 5:29 PM, Doug Royer wrote: > > > Tantek Çelik wrote: >> But look at the times. >> The first instance overlaps the other two entirely. >> Are you saying that is valid? > > Yes. > >> And if so, how is a CUA possibly expected to represent that in some >> meaningful form to the user? > > Odd - yes. Valid - yes. > >> Warn them that two or more instances of the same meeting are >> occurring at the same time? > > That's up to the CUA. > >> The spec says that exact RRULE/RDATE event instance duplicates are >> supposed to be tossed, but says nothing about having the same meeting >> take place twice at the same time which makes no sense. Why is it >> useful for the spec to allow this? > > I do not recall there being a discussion on this topic. > > Might be a good discussion. > > Where iCal-Basic says (4.10.3 Recurrence Date/Times, > page 82): > > > ...Where duplicate instances are generated by the "RDATE" > properties, only one recurrence is considered. ... > > > If iCal-Basic said: > > ...Where duplicate instances are generated by the "RDATE" > properties, only one recurrence is considered. > All instance times in a "VEVENT" component with the > same "UID" property value MUST NOT overlap each other. > ... > > (I need to spend more time on the exact language) > > Would anyone object? Reinhold said something that made it immediately obvious to me why this made sense. On May 12, 2005, at 3:53 PM, Reinhold Kainhofer wrote: > Am Freitag, 13. Mai 2005 00:42 schrieb Tantek Çelik: >> The spec says that exact RRULE/RDATE event instance duplicates are >> supposed to be tossed, but says nothing about having the same meeting >> take place twice at the same time which makes no sense.  Why is it >> useful for the spec to allow this? > > Because an event is not neccessarily a meeting, where you can only > attend > once... > > Reinhold Thanks Reinhold. Your explanation made me think of the following example: A museum tour that leaves on the hour every hour while the museum is open, from the information desk, and lasts two hours, with the last one of the day leaving two hours before the museum closing time. Doug, what do you think, would that be a reasonable use of overlapping repeating event times? >> How do implementations handle/display/edit this VEVENT? > > You would have to try different CUA's to find out. Well I tried MacOSX iCal.app 1.5.5 (v670) and was disheartened to learn that it looks like it has NO SUPPORT FOR RDATE. :( I'm beginning to understand the pain some of the veterans of this list have been dealing with. Tantek -- Tantek Çelik Senior Technologist, Technorati, Inc. tantek@technorati.com 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 j4D0Th4X023660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 12 May 2005 17:29:45 -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 j4D0Td8v004406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 May 2005 17:29:41 -0700 Message-ID: <4283F4F2.30608@Royer.com> Date: Thu, 12 May 2005 18:29:38 -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: Calsify References: <4283D52B.8070209@Royer.com> <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> In-Reply-To: <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080208000204010701000702" 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 Subject: [Ietf-calsify] Should ovelapped instances be allowed in a single VEVENT ? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 00:29:47 -0000 This is a cryptographically signed message in MIME format. --------------ms080208000204010701000702 Content-Type: multipart/mixed; boundary="------------050301080705040602080602" This is a multi-part message in MIME format. --------------050301080705040602080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Tantek =C7elik wrote: > But look at the times. >=20 > The first instance overlaps the other two entirely. >=20 > Are you saying that is valid? Yes. > And if so, how is a CUA possibly expected to represent that in some=20 > meaningful form to the user? Odd - yes. Valid - yes. > Warn them that two or more instances of the same meeting are occurring = > at the same time? That's up to the CUA. > The spec says that exact RRULE/RDATE event instance duplicates are=20 > supposed to be tossed, but says nothing about having the same meeting=20 > take place twice at the same time which makes no sense. Why is it=20 > useful for the spec to allow this? I do not recall there being a discussion on this topic. Might be a good discussion. Where iCal-Basic says (4.10.3 Recurrence Date/Times, page 82): ...Where duplicate instances are generated by the "RDATE" properties, only one recurrence is considered. ... If iCal-Basic said: ...Where duplicate instances are generated by the "RDATE" properties, only one recurrence is considered. All instance times in a "VEVENT" component with the same "UID" property value MUST NOT overlap each other. ... (I need to spend more time on the exact language) Would anyone object? > How do implementations handle/display/edit this VEVENT? You would have to try different CUA's to find out. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------050301080705040602080602 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 --------------050301080705040602080602-- --------------ms080208000204010701000702 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 9w0BCQUxDxcNMDUwNTEzMDAyOTM4WjAjBgkqhkiG9w0BCQQxFgQU0iPurbm9PyriZ7G/Tarx F/X0BPYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAVQAnSgMRNDBQmgu7JR3mUntqRZD5PF+6G7CjUnGNJB0RzXS+xho/ZFvtpjKtWe2r dRyVj3D1lF7oyup/gMj0fhYYm2iIHN7SN+ap1JUdkb14BDfD+MfXCkk/8e6kY28eY5c3Si1q 3WeFwcO4LgTHmwUF9mgVOYOf7PfrcfvVnD9YUFiX0w0lZDSzt0w63vYyczUx6Ij/USCV6o2Q 4/rL5nI0CQ/wqc/xLDylddRjTBJiyNGtWeKCcTZj0aKNL7ZNqu7WuuO9B6BBfQgfQcPHMhB5 UoNZzGE05p0PfZFwfWpRWOYW1xeMjt+c+6LOHtG5eGl42lKlzH3ATsyMS5tT/gAAAAAAAA== --------------ms080208000204010701000702-- X-Envelope-From: camerost@exchange.microsoft.com X-Envelope-To: Received: from mail1.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.76.156]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4D01M4W022119 for ; Thu, 12 May 2005 17:01:22 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail1.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 17:01:19 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 17:01:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-calsify] VTODO questions Date: Thu, 12 May 2005 17:01:17 -0700 Message-ID: <1198328AFDBF5841B27E40C40C3315370347630F@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-calsify] VTODO questions Thread-Index: AcVVlCRO4kN91ybDQiOd6JYGyYPz+gACGEuQ From: "Cameron Stillion" To: , "Calsify" X-OriginalArrivalTime: 13 May 2005 00:01:21.0553 (UTC) FILETIME=[E5458010:01C5574E] X-Spam-Score: 0 () 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 j4D01M4W022119 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 00:01:24 -0000 So far, the extent of VTODO "simplification" and "clarification" for the purposes of interoperability have amounted to this: Deprecation. Tasks as a datatype, IMHO, belong in a separate specification - when and if there is adequate interest in such a standard. Muddying the waters with tasks is one of the things that has likely kept iCal from becoming a standard for the past few years. (...think of it as including your pet political hack for a kickback in the next tax cut bill...) Cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of cbryant-ical@corp.usa.net Sent: Tuesday, May 10, 2005 11:59 AM To: Calsify Subject: [Ietf-calsify] VTODO questions I have some questions about VTODO interoperability that I was hoping somebody on the calsify list could help me answer. We are currently trying to implement todos into our server with the goal of being as interoperable as possible with other calendar servers/clients. I know RFC 2445 has a lot of shortfalls regarding VTODOs, but we're willing to live with some of these shortcomings if it increases our interoperability. At this point though, I am having difficulty determining what clients and servers we would be able to interoperate with. Can anyone point me at some calendar clients and servers that support assigning and responding to VTODOs with iMIP? Has calsify or any other group tried to quantify the level of interoperability that exists with VTODOs? Are there any interoperability test reports for this? Is calsify looking at what to do about VTODOs, or are VTODOs used so little right now that standardization of these is considered a low priority? Thanks, Chris Bryant _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: tantek@technorati.com X-Envelope-To: Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4CMgw4X017149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2005 15:42:58 -0700 Received: from [IPv6:::1] (localhost.technorati.com [127.0.0.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id 098B5212869 for ; Thu, 12 May 2005 15:44:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <4283D52B.8070209@Royer.com> References: <4283D52B.8070209@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <808ad26b7b9e833b1cf07ea634d8ee0d@technorati.com> From: =?ISO-8859-1?Q?Tantek_=C7elik?= Subject: Re: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification Date: Fri, 13 May 2005 07:42:56 +0900 To: Calsify X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () 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 j4CMgw4X017149 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 22:42:59 -0000 But look at the times. The first instance overlaps the other two entirely. Are you saying that is valid? And if so, how is a CUA possibly expected to represent that in some meaningful form to the user? Warn them that two or more instances of the same meeting are occurring at the same time? The spec says that exact RRULE/RDATE event instance duplicates are supposed to be tossed, but says nothing about having the same meeting take place twice at the same time which makes no sense. Why is it useful for the spec to allow this? How do implementations handle/display/edit this VEVENT? Thanks, Tantek On May 13, 2005, at 7:14 AM, Doug Royer wrote: > > It has 3 instances, not 2. > > iCal-Basic deprecated DTEND, so it would be (assuming I > did my time math correctly: > > BEGIN:VEVENT > LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia > SUMMARY:Web Essentials 05 > DTSTART:20050928T230000Z > DURATION:+PT34H30M > RDATE;VALUE=PERIOD:20050928T230000Z/PT9H,20050929T213000Z/PT20H30M > END:VEVENT > > The first instance starts at 0050928T230000Z and ends 34.5 hours later. > The second instance starts at 20050928T230000Z and ends 9.0 hours > later. > The third instance starts at 20050929T213000Z and ends 20.5 hours > later. > > Tantek Çelik wrote: >> In my opinion it is not clear in the spec (either RFC2445 or the >> iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an >> RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a >> VEVENT. >> E.g.: >> BEGIN:VEVENT >> LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia >> SUMMARY:Web Essentials 05 >> DTEND:20050930T093000Z >> DTSTART:20050928T230000Z >> URL:http://we05.com/ >> RDATE;VALUE=PERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ >> 20050930T0930Z >> END:VEVENT >> The RDATE is saying this event takes place in two discrete chunks >> over the course of two days. >> The DTSTART/DTEND combo is saying the event takes place for 34.5 >> hours straight. >> Which should the CUA "choose" from those two options? >> Is this an invalid VEVENT? >> Thanks, >> Tantek >> -- >> Tantek Çelik >> Senior Technologist, Technorati, Inc. >> tantek@technorati.com >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > > We Do Standards - You Need Standards > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- Tantek Çelik Senior Technologist, Technorati, Inc. tantek@technorati.com 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 j4CMEB4X014735 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 12 May 2005 15:14:12 -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 j4CME3CV002981 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 12 May 2005 15:14:05 -0700 Message-ID: <4283D52B.8070209@Royer.com> Date: Thu, 12 May 2005 16:14:03 -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: Calsify Subject: Re: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000804010504060809030607" 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-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 22:14:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000804010504060809030607 Content-Type: multipart/mixed; boundary="------------030402040707040708070108" This is a multi-part message in MIME format. --------------030402040707040708070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable It has 3 instances, not 2. iCal-Basic deprecated DTEND, so it would be (assuming I did my time math correctly: BEGIN:VEVENT LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia SUMMARY:Web Essentials 05 DTSTART:20050928T230000Z DURATION:+PT34H30M RDATE;VALUE=3DPERIOD:20050928T230000Z/PT9H,20050929T213000Z/PT20H30M END:VEVENT The first instance starts at 0050928T230000Z and ends 34.5 hours later. The second instance starts at 20050928T230000Z and ends 9.0 hours later. The third instance starts at 20050929T213000Z and ends 20.5 hours later. Tantek =C7elik wrote: > In my opinion it is not clear in the spec (either RFC2445 or the =20 > iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an = > RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a VEVENT.= >=20 > E.g.: >=20 >=20 > BEGIN:VEVENT > LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia > SUMMARY:Web Essentials 05 > DTEND:20050930T093000Z > DTSTART:20050928T230000Z > URL:http://we05.com/ > RDATE;VALUE=3DPERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ = > 20050930T0930Z > END:VEVENT >=20 >=20 > The RDATE is saying this event takes place in two discrete chunks over = =20 > the course of two days. >=20 > The DTSTART/DTEND combo is saying the event takes place for 34.5 hours = =20 > straight. >=20 > Which should the CUA "choose" from those two options? >=20 > Is this an invalid VEVENT? >=20 > Thanks, >=20 > Tantek >=20 >=20 > --=20 > Tantek =C7elik > Senior Technologist, Technorati, Inc. > tantek@technorati.com >=20 >=20 >=20 > --=20 > Tantek =C7elik > Technorati, Inc. > tantek@technorati.com > 415-254-9656 (Mobile) >=20 >=20 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030402040707040708070108 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 --------------030402040707040708070108-- --------------ms000804010504060809030607 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 9w0BCQUxDxcNMDUwNTEyMjIxNDAzWjAjBgkqhkiG9w0BCQQxFgQUadStREYk8OWd6U98QXqD 2qCN2EkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAER1QgchzOV0zUY9OTojTw1H7hB2nI4+JczC/LYxHAI9H34J4AwPN8Z1JSFL9GRYp QmEdApLVoq77Lk4a2exS7JmfKaP+KrzDTX8GtlYE9RPs9wB9ceMKLau5BnyPhSfVI6IIFbZa YDZ978TntddpCuM5lCu/vQuieg77ig32TqaELEfNAv8g+dcUCPNpqGzKW2HYsFlOfSef9e6i Hb5kesSLF2IoW75sZDr2zdoLsYPnvDf59/gkJgCCmwUOcbrHgQHiBOEYVmRTxU5Cd6uIwyOl Wm72Wu+5g8sr1D1SoLgEPka/sA3VId9wu+Eaw810EoHkrEQeZwAHEblfxOyXMQAAAAAAAA== --------------ms000804010504060809030607-- X-Envelope-From: tantek@technorati.com X-Envelope-To: Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4CLdh4X012380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2005 14:39:44 -0700 Received: from [IPv6:::1] (localhost.technorati.com [127.0.0.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id 017D021283F for ; Thu, 12 May 2005 14:41:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: Calsify From: =?ISO-8859-1?Q?Tantek_=C7elik?= Date: Fri, 13 May 2005 06:39:35 +0900 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.207 () UPPERCASE_25_50 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 j4CLdh4X012380 Subject: [Ietf-calsify] RDATE vs. DTEND/DURATION clarification X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 21:39:48 -0000 In my opinion it is not clear in the spec (either RFC2445 or the iCal-BASIC draft) what a CUA is supposed to do when it sees *both* an RDATE and DTEND in a VEVENT, or both an RDATE and DURATION in a VEVENT. E.g.: BEGIN:VEVENT LOCATION:University of Technology Sydney (UTS)\, Sydney\, Australia SUMMARY:Web Essentials 05 DTEND:20050930T093000Z DTSTART:20050928T230000Z URL:http://we05.com/ RDATE;VALUE=PERIOD:20050928T230000Z/20050929T0800Z,20050929T213000Z/ 20050930T0930Z END:VEVENT The RDATE is saying this event takes place in two discrete chunks over the course of two days. The DTSTART/DTEND combo is saying the event takes place for 34.5 hours straight. Which should the CUA "choose" from those two options? Is this an invalid VEVENT? Thanks, Tantek -- Tantek Çelik Senior Technologist, Technorati, Inc. tantek@technorati.com -- Tantek Çelik Technorati, Inc. tantek@technorati.com 415-254-9656 (Mobile) X-Envelope-From: cbryant-ical@corp.usa.net X-Envelope-To: Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j4AIxWOf004634 for ; Tue, 10 May 2005 11:59:32 -0700 Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by cmsout01.mbox.net (Postfix) with ESMTP id 1A9707816B for ; Tue, 10 May 2005 18:59:25 +0000 (GMT) Received: from ca28 [165.212.11.128] by cmsout01.mbox.net via smtad (C8.MAIN.3.21U); Tue, 10 May 2005 18:59:26 GMT X-USANET-Source: 165.212.11.128 IN cbryant-ical@corp.usa.net ca28 X-USANET-MsgId: XID178JeJs8A8950X01 Received: from uwdvg018.cms.usa.net [165.212.8.18] by ca28 (ASMTP/) via mtad (C8.MAIN.3.21E) with ESMTP id 225JeJs8X0380M28; Tue, 10 May 2005 18:59:24 GMT X-USANET-Auth: 165.212.8.18 AUTO cbryant-ical@corp.usa.net uwdvg018.cms.usa.net Received: from 165.212.225.1 [165.212.225.1] by uwdvg018.cms.usa.net (USANET web-mailer CM.0402.7.24); Tue, 10 May 2005 18:59:22 -0000 Date: Tue, 10 May 2005 14:59:22 -0400 From: cbryant-ical@corp.usa.net To: Calsify X-Mailer: USANET web-mailer (CM.0402.7.24) Mime-Version: 1.0 Message-ID: <538JeJs8w7648S18.1115751562@uwdvg018.cms.usa.net> Content-Type: text/plain; charset=ISO-8859-1 Z-USANET-MsgId: XID225JeJs8y0380X28 X-Spam-Score: 1.709 (*) NO_REAL_NAME,RCVD_NUMERIC_HELO 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 j4AIxWOf004634 Subject: [Ietf-calsify] VTODO questions X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 18:59:35 -0000 I have some questions about VTODO interoperability that I was hoping somebody on the calsify list could help me answer. We are currently trying to implement todos into our server with the goal of being as interoperable as possible with other calendar servers/clients. I know RFC 2445 has a lot of shortfalls regarding VTODOs, but we're willing to live with some of these shortcomings if it increases our interoperability. At this point though, I am having difficulty determining what clients and servers we would be able to interoperate with. Can anyone point me at some calendar clients and servers that support assigning and responding to VTODOs with iMIP? Has calsify or any other group tried to quantify the level of interoperability that exists with VTODOs? Are there any interoperability test reports for this? Is calsify looking at what to do about VTODOs, or are VTODOs used so little right now that standardization of these is considered a low priority? Thanks, Chris Bryant