From lear at cisco.com Thu Dec 7 07:46:07 2006 From: lear at cisco.com (Eliot Lear) Date: Thu Dec 7 07:46:22 2006 Subject: [Ietf-calsify] jabber session in 15 minutes Message-ID: <4578373F.1040903@cisco.com> See you then! From aki.niemi at nokia.com Fri Dec 8 01:58:04 2006 From: aki.niemi at nokia.com (aki.niemi@nokia.com) Date: Fri Dec 8 01:58:41 2006 Subject: [Ietf-calsify] Draft minutes for IETF67 posted Message-ID: All, We've posted the draft minutes to the proceedings: http://www3.ietf.org/proceedings/06nov/minutes/calsify.txt If you have comments, please send them to the list or to the chairs. Cheers, Aki From lear at cisco.com Mon Dec 11 08:46:27 2006 From: lear at cisco.com (Eliot Lear) Date: Mon Dec 11 08:46:36 2006 Subject: [Ietf-calsify] continuing our jabber session Message-ID: <457D8B63.7040105@cisco.com> Our last jabber session was held on Thursday. You can review the log here . We agreed to continue our jabber conversation tomorrow at 8:00am PST / 4:00pm UTC. Looking forward to seeing you on the chat! Eliot From lear at cisco.com Tue Dec 12 07:47:46 2006 From: lear at cisco.com (Eliot Lear) Date: Tue Dec 12 07:47:55 2006 Subject: [Ietf-calsify] reminder: jabber session in 15 minutes! Message-ID: <457ECF22.4060409@cisco.com> calsify@jabber.ietf.org. See you there! Eliot From lear at cisco.com Wed Dec 13 05:52:20 2006 From: lear at cisco.com (Eliot Lear) Date: Wed Dec 13 05:52:25 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session Message-ID: <45800594.4000807@cisco.com> Dear all, Here is a summary of each of the issues we've discussed in the last two jabber sessions. It is the chairs' intent that we not have another jabber session until after the 1st of the year, due to holidays. The chairs further wish the participants an enjoyable holiday and a happy New Year. As to the Issues, here they are: Issue Number Brief Description Resolution -------------------------------------------------------------------------- 19 IANA Considerations Eliot to propose text. 27 How long is a day? No resolution yet. This has to do with DST transitions. 36 Section 4.1 use of X-Name Consensus to drop "bilateral" and encourage use of IANA and to add some BCP text. 42 4.6.6 Alarm component restrict. Consensus: remove restriction. 47 4.8.6.3 trigger relative to DATE Prefer configured timezone. Fall back to UTC. 55 Remove SECONDLY, MINUTELY, Nuke BYSEC and SECONDLY. BYSEC and BYMIN Also nuke MINUTELY. This leaves open the question of BYMINUTE. More issue resolutions to follow after the end of the year. Cheers, Eliot From reinhold at kainhofer.com Wed Dec 13 06:26:52 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Wed Dec 13 06:27:08 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <45800594.4000807@cisco.com> References: <45800594.4000807@cisco.com> Message-ID: <200612131526.56228.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 13. Dezember 2006 14:52 schrieb Eliot Lear: > 55 ? ? ? ? ? ? Remove SECONDLY, MINUTELY, ? ? ? ?Nuke BYSEC and SECONDLY. > ? ? ? ? ? ? ? ?BYSEC and BYMIN ? ? ? ? ? ? ? ? ? Also nuke MINUTELY. ?This > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?leaves open the question > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?of BYMINUTE. ARGH!!! Why would you do that? In my eyes, these frequencies and these BY* rule parts are the most uncontroversial of all rule parts. The other rule parts create the problems for us. In KDE we have a dedicated alarm application (not for event reminders, but for all sorts of things that you want to be reminded of) that makes available all alarms as events to applications that use iCalendar format. You can't imagine how useful that stuff is. E.g. Set a quick alarm to remove the cake or the pizza from the oven in 15 Minutes. That alarm will automatically appear in your calendaring app (that watches the iCalendar file). Or set an alarm that reminds you every 1.5 hours (=90 minutes) to take a break from the computer. I also like these alarms to show up in my calendar (which is a completely different application, so we need to have a format for data exchange, which is exactly iCalendar). Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, 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 maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgA2wTqjEwhXvPN0RAizhAJ92rcHFGcj90XqZ4wrdDSrRS248VQCgsoVG QiX+0KyOPRweqSitvQNmglE= =3JLu -----END PGP SIGNATURE----- From Nigel.Swinson at rockliffe.com Wed Dec 13 06:27:50 2006 From: Nigel.Swinson at rockliffe.com (Nigel Swinson) Date: Wed Dec 13 06:27:18 2006 Subject: [Ietf-calsify] Inconsistent BNF for "the following is optional and may occur more than once" Message-ID: <002b01c71ec2$df2e7140$0202fea9@nigelhome> Minor nits: BNF for DTDue says: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-03#section-3.8.2.3 dueparam = *( + ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once - *(";" xparam) + (";" xparam) ) BNF for DTStart says: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-03#section-3.8.2.4 dtstparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once - *(";" xparam) + (";" xparam) ) The *(";" xparam) bit is I believe unintentionally inconsistent with the other values like DTEnd and I think the * should be dropped relying instead on the top level *() of the param token. Also there's a missing newline in the dueparam making the formatting inconsistent with the others. Cheers Nigel From cyrus at daboo.name Wed Dec 13 06:34:49 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Dec 13 06:35:03 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <200612131526.56228.reinhold@kainhofer.com> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> Message-ID: Hi Reinhold, --On December 13, 2006 3:26:52 PM +0100 Reinhold Kainhofer wrote: > ARGH!!! Why would you do that? > In my eyes, these frequencies and these BY* rule parts are the most > uncontroversial of all rule parts. The other rule parts create the > problems for us. > > In KDE we have a dedicated alarm application (not for event reminders, > but for all sorts of things that you want to be reminded of) that makes > available all alarms as events to applications that use iCalendar format. > > You can't imagine how useful that stuff is. E.g. Set a quick alarm to > remove the cake or the pizza from the oven in 15 Minutes. That alarm > will automatically appear in your calendaring app (that watches the > iCalendar file). > > Or set an alarm that reminds you every 1.5 hours (=90 minutes) to take a > break from the computer. I also like these alarms to show up in my > calendar (which is a completely different application, so we need to > have a format for data exchange, which is exactly iCalendar). Using a VALARM inside a VEVENT isn't sufficient? Just wanting to know why you choose to represent 'alarms' as events... -- Cyrus Daboo From douglm at rpi.edu Wed Dec 13 07:54:49 2006 From: douglm at rpi.edu (Mike Douglass) Date: Wed Dec 13 07:52:58 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <200612131526.56228.reinhold@kainhofer.com> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> Message-ID: <45802249.1070207@rpi.edu> I absolutely agree. The arguments for removal of these options seem to be based on nobody using them - however there don't seem to be many places where they are made available. This holds true for some of the other simplification suggestions. That is, until applications make these options available we cannot tell how much they would be used. Removal of these options just guarantees icalendar data will never be used in certain areas Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Mittwoch, 13. Dezember 2006 14:52 schrieb Eliot Lear: > >> 55 Remove SECONDLY, MINUTELY, Nuke BYSEC and SECONDLY. >> BYSEC and BYMIN Also nuke MINUTELY. This >> leaves open the question >> of BYMINUTE. >> > > ARGH!!! Why would you do that? > In my eyes, these frequencies and these BY* rule parts are the most > uncontroversial of all rule parts. The other rule parts create the problems > for us. > > In KDE we have a dedicated alarm application (not for event reminders, but for > all sorts of things that you want to be reminded of) that makes available all > alarms as events to applications that use iCalendar format. > > You can't imagine how useful that stuff is. E.g. Set a quick alarm to remove > the cake or the pizza from the oven in 15 Minutes. That alarm will > automatically appear in your calendaring app (that watches the iCalendar > file). > > Or set an alarm that reminds you every 1.5 hours (=90 minutes) to take a break > from the computer. I also like these alarms to show up in my calendar (which > is a completely different application, so we need to have a format for data > exchange, which is exactly iCalendar). > > Cheers, > Reinhold > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, 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 maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFgA2wTqjEwhXvPN0RAizhAJ92rcHFGcj90XqZ4wrdDSrRS248VQCgsoVG > QiX+0KyOPRweqSitvQNmglE= > =3JLu > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 From lear at cisco.com Wed Dec 13 07:58:57 2006 From: lear at cisco.com (Eliot Lear) Date: Wed Dec 13 07:59:06 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <45802249.1070207@rpi.edu> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> Message-ID: <45802341.8080806@cisco.com> First the obvious comment. We always confirm our consensus positions on mailing lists. If this one doesn't hold we will need to back off. That having been said, let's be clear: if a feature isn't used now, it's not likely to be used in the future. RFC 2445 has been out there a VERY LONG TIME. Also, if that feature is actually making it more difficult for people to implement the rest of the specification, then having it costs us quite a bit. Eliot From cyrus at daboo.name Wed Dec 13 10:24:43 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Dec 13 10:25:03 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <45802249.1070207@rpi.edu> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> Message-ID: <6340ECD74D5B8D024EF708BA@caldav.apple.com> Hi Mike, --On December 13, 2006 10:54:49 AM -0500 Mike Douglass wrote: > The arguments for removal of these options seem to be based on nobody > using them - however there don't seem to be many places where they are > made available. This holds true for some of the other simplification > suggestions. > > That is, until applications make these options available we cannot tell > how much they would be used. > > Removal of these options just guarantees icalendar data will never be > used in certain areas But perhaps the application developers choose not to make them available precisely because their own surveys/requirements from users did not show any demand. Its not necessarily because the developers were "too lazy" to implement. Just from a personal standpoint I can tell you that I have never had cause to create an hourly, minutely or secondly event even though the client I use allows that via UI. Though I have used the VALARM repeat capability to have alarms trigger at five minute intervals leading up to the start of an event. That's why I would like to know why Reinhold choose to use VEVENTs. My feeling is that you can use VALARM for those cases and if you want to see something on the calendar, then the client can quite easily display the VALARM "instances" using an appropriate widget in the UI. -- Cyrus Daboo From douglm at rpi.edu Wed Dec 13 10:58:43 2006 From: douglm at rpi.edu (Mike Douglass) Date: Wed Dec 13 10:56:57 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <6340ECD74D5B8D024EF708BA@caldav.apple.com> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> <6340ECD74D5B8D024EF708BA@caldav.apple.com> Message-ID: <45804D63.50208@rpi.edu> I hope I wasn't trying to accuse anyone of laziness. I'd have to accuse myself first... The allowable storage and transport formats will usually be a superset of what's implemented in any given ui and that's probably reasonable enough. I doubt we'll put seconds and minutes in our user ui but I am considering their use for internal events. Alarms will probably work in most cases as will very simple recurrences but the point of recurrences is they allow for greater complexity where needed. My recollection of a brief walk around vendor booths was that most weren't even aware there was a calendar data 'standard' available for use and where the use of seconds and minutes might be appropriate they aren't being used because vendors don't even use icalendar. Triggering system events such as backup or synch seems to be an ideal use for icalendar and rather more undarstandable than cron. Unlikely if we drop seconds and minutes. As it so happens we're just implementing recurrences in our ui and it is hard, but the main obstacle to me is the RFC - not what we're trying to implement. Clearly inconsistencies need to be resolved and the various traps for the unwary documented so that we all take a consistent approach but I'd hope that wouldn't result in a loss of functionality. Cyrus Daboo wrote: > Hi Mike, > > --On December 13, 2006 10:54:49 AM -0500 Mike Douglass > wrote: > >> The arguments for removal of these options seem to be based on nobody >> using them - however there don't seem to be many places where they are >> made available. This holds true for some of the other simplification >> suggestions. >> >> That is, until applications make these options available we cannot tell >> how much they would be used. >> >> Removal of these options just guarantees icalendar data will never be >> used in certain areas > > But perhaps the application developers choose not to make them > available precisely because their own surveys/requirements from users > did not show any demand. Its not necessarily because the developers > were "too lazy" to implement. > > Just from a personal standpoint I can tell you that I have never had > cause to create an hourly, minutely or secondly event even though the > client I use allows that via UI. Though I have used the VALARM repeat > capability to have alarms trigger at five minute intervals leading up > to the start of an event. That's why I would like to know why Reinhold > choose to use VEVENTs. My feeling is that you can use VALARM for those > cases and if you want to see something on the calendar, then the > client can quite easily display the VALARM "instances" using an > appropriate widget in the UI. > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 From lisa at osafoundation.org Wed Dec 13 20:14:55 2006 From: lisa at osafoundation.org (Lisa Dusseault) Date: Wed Dec 13 20:15:03 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <45804D63.50208@rpi.edu> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> <6340ECD74D5B8D024EF708BA@caldav.apple.com> <45804D63.50208@rpi.edu> Message-ID: <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> Since I'm one of the advocates for removing some of the recurrence "feaures", I'll clarify that this might only hold for interpersonal scheduling. I'm hoping Reinhold never schedules me for meetings every fifteen minutes, and one of the reasons is that my client doesn't have the functionality to let me alter that recurrence pattern to something more reasonable. RFC2445 won't go away, any application that wants to use more complex recurrence rules can. A personal alarm application (I've used "fob" in the past and it sounds like what Reinhold's talked about) might use a different set of recurrence features than interpersonal scheduling. Is there a need for interoperability for that kind of use case? Do personal alarm applications ever even export and import alarm data? Lisa On Dec 13, 2006, at 10:58 AM, Mike Douglass wrote: > I hope I wasn't trying to accuse anyone of laziness. I'd have to > accuse myself first... The allowable storage and transport formats > will usually be a superset of what's implemented in any given ui > and that's probably reasonable enough. I doubt we'll put seconds > and minutes in our user ui but I am considering their use for > internal events. Alarms will probably work in most cases as will > very simple recurrences but the point of recurrences is they allow > for greater complexity where needed. > > My recollection of a brief walk around vendor booths was that most > weren't even aware there was a calendar data 'standard' available > for use and where the use of seconds and minutes might be > appropriate they aren't being used because vendors don't even use > icalendar. > > Triggering system events such as backup or synch seems to be an > ideal use for icalendar and rather more undarstandable than cron. > Unlikely if we drop seconds and minutes. > > As it so happens we're just implementing recurrences in our ui and > it is hard, but the main obstacle to me is the RFC - not what we're > trying to implement. Clearly inconsistencies need to be resolved > and the various traps for the unwary documented so that we all take > a consistent approach but I'd hope that wouldn't result in a loss > of functionality. > > Cyrus Daboo wrote: >> Hi Mike, >> >> --On December 13, 2006 10:54:49 AM -0500 Mike Douglass >> wrote: >> >>> The arguments for removal of these options seem to be based on >>> nobody >>> using them - however there don't seem to be many places where >>> they are >>> made available. This holds true for some of the other simplification >>> suggestions. >>> >>> That is, until applications make these options available we >>> cannot tell >>> how much they would be used. >>> >>> Removal of these options just guarantees icalendar data will >>> never be >>> used in certain areas >> >> But perhaps the application developers choose not to make them >> available precisely because their own surveys/requirements from >> users did not show any demand. Its not necessarily because the >> developers were "too lazy" to implement. >> >> Just from a personal standpoint I can tell you that I have never >> had cause to create an hourly, minutely or secondly event even >> though the client I use allows that via UI. Though I have used the >> VALARM repeat capability to have alarms trigger at five minute >> intervals leading up to the start of an event. That's why I would >> like to know why Reinhold choose to use VEVENTs. My feeling is >> that you can use VALARM for those cases and if you want to see >> something on the calendar, then the client can quite easily >> display the VALARM "instances" using an appropriate widget in the UI. >> > > -- > > Mike Douglass douglm@rpi.edu > Senior Systems Programmer > Communication & Collaboration Technologies 518 276 6780(voice) > 2809 > (fax) > Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From reinhold at kainhofer.com Thu Dec 14 02:38:58 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Thu Dec 14 02:39:24 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> References: <45800594.4000807@cisco.com> <45804D63.50208@rpi.edu> <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> Message-ID: <200612141139.13461.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 14. Dezember 2006 05:14 schrieb Lisa Dusseault: > Since I'm one of the advocates for removing some of the recurrence > "feaures", I'll clarify that this might only hold for interpersonal > scheduling. I completely agree. That's why we don't have sub-daily recurrences in our personal calendar application "KOrganizer" (http://www.korganizer.org/, which is terribly out of date). But the alarm application "KAlarm" (http://www.astrojar.org.uk/linux/kalarm.html), does have hourly and minutely recurrences, because for alarms it makes sense to have it. However, rfc 2445 is not only about interpersonal scheduling. As the introduction says, it's meant as a general format for calendar data exchange, and we use iCalendar for exchanging data between applications (copying event/tasks/journal entries(=notes) from application to another using the clipboard, or making the data available as an .ics file that can also shown by the calendar application, etc.) > I'm hoping Reinhold never schedules me for meetings > every fifteen minutes, and one of the reasons is that my client > doesn't have the functionality to let me alter that recurrence > pattern to something more reasonable. > > RFC2445 won't go away, Sure, it will still be rfc 2445, but it will be marked as deprecated and superseded by 2445bis, which does no longer allow these recurrences, right? > any application that wants to use more complex > recurrence rules can. A personal alarm application (I've used "fob" > in the past and it sounds like what Reinhold's talked about) might > use a different set of recurrence features than interpersonal > scheduling. Is there a need for interoperability for that kind of > use case? Yes, definitely. I never thought there might, until I started showing the entries in the personal alarm application in my calendar application. It's really useful to finally see e.g. the regularly schedulled breaks away from the computer in the calendar. Or to see the time periods in your calendar application, when you worked on some projects, which you entered into your time tracking application (KTimetracker in our case: http://wiki.kde.org/tiki-index.php?page=KTimeTracker). Granted, in that case you don't have any recurrences, but there are other issues (like related-to superprojects (=VTODO), custom properties to store the combined time your worked on a project, etc.) > Do personal alarm applications ever even export and import > alarm data? KAlarm stores it's data in an .ics file, so other applications (like KOrganizer or evolution) can simply load this file and show the alarms as events in your schedule... Cheers, Reinhold PS: Just for your information, here's a list of various KDE applications that use iCalendar as its native format for data storage and/or exchange with other applications: - -) Kontact (KDE's full PIM suite, http://kontact.org/, makes use of the applications listed below) - -) KOrganizer (KDE's calendar application: Events, Tasks, Journals) - -) KAlarm (KDE's alarm applications, Alarms saved as events with a VALARM) - -) KArm (time tracker, projects saved as VTODO, time periods you worked on a project saved as VEVENT with RELATED-TO prop set) - -) KNotes (sticky notes application, Notes saved as VJOURNAL) - -) TaskJuggler (Complex project manager, project plan automatically exported as .ics) - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, 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 maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgSnRTqjEwhXvPN0RAk5YAKDXmbFjY5D5Nm2tCMxqGbmdSUObmwCeNmrD eBGbvmKCVlParHAhbJws8A8= =J8l0 -----END PGP SIGNATURE----- From cbryant-ical at corp.usa.net Thu Dec 14 05:50:44 2006 From: cbryant-ical at corp.usa.net (Chris Bryant) Date: Thu Dec 14 05:50:55 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session References: <45800594.4000807@cisco.com><200612131526.56228.reinhold@kainhofer.com><45802249.1070207@rpi.edu><6340ECD74D5B8D024EF708BA@caldav.apple.com><45804D63.50208@rpi.edu> <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> Message-ID: <001201c71f86$db92faf0$6401a8c0@corp.usa.net> It seems to me that there is a common set of recurrence types that most interpersonal scheduling tools try to accomodate. Lisa's proposal addresses these types. It seems that we could work out some wording that says that interpersonal scheduling tools should limit their recurrence rules to a specific set. This would allow creators and consumers of this data to simplify their implementations, only supporting that specific set of rules. We could keep the hourly/minutely/secondly specs in the rfc, but people would need to be aware that even well behaving consumers of this data would be free to just ignore those rules or fail to process the event containing those rules. If there are scheduling tools that desire to exchange hourly/minutely/secondly events, there would still be a standard format by which this would be done. Chris ----- Original Message ----- From: "Lisa Dusseault" To: "Mike Douglass" Cc: Sent: Wednesday, December 13, 2006 11:14 PM Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session > > Since I'm one of the advocates for removing some of the recurrence > "feaures", I'll clarify that this might only hold for interpersonal > scheduling. I'm hoping Reinhold never schedules me for meetings every > fifteen minutes, and one of the reasons is that my client doesn't have > the functionality to let me alter that recurrence pattern to something > more reasonable. > > RFC2445 won't go away, any application that wants to use more complex > recurrence rules can. A personal alarm application (I've used "fob" in > the past and it sounds like what Reinhold's talked about) might use a > different set of recurrence features than interpersonal scheduling. Is > there a need for interoperability for that kind of use case? Do personal > alarm applications ever even export and import alarm data? > > Lisa > > On Dec 13, 2006, at 10:58 AM, Mike Douglass wrote: > >> I hope I wasn't trying to accuse anyone of laziness. I'd have to accuse >> myself first... The allowable storage and transport formats will usually >> be a superset of what's implemented in any given ui and that's probably >> reasonable enough. I doubt we'll put seconds and minutes in our user ui >> but I am considering their use for internal events. Alarms will probably >> work in most cases as will very simple recurrences but the point of >> recurrences is they allow for greater complexity where needed. >> >> My recollection of a brief walk around vendor booths was that most >> weren't even aware there was a calendar data 'standard' available for >> use and where the use of seconds and minutes might be appropriate they >> aren't being used because vendors don't even use icalendar. >> >> Triggering system events such as backup or synch seems to be an ideal >> use for icalendar and rather more undarstandable than cron. Unlikely if >> we drop seconds and minutes. >> >> As it so happens we're just implementing recurrences in our ui and it is >> hard, but the main obstacle to me is the RFC - not what we're trying to >> implement. Clearly inconsistencies need to be resolved and the various >> traps for the unwary documented so that we all take a consistent >> approach but I'd hope that wouldn't result in a loss of functionality. >> >> Cyrus Daboo wrote: >>> Hi Mike, >>> >>> --On December 13, 2006 10:54:49 AM -0500 Mike Douglass >>> wrote: >>> >>>> The arguments for removal of these options seem to be based on nobody >>>> using them - however there don't seem to be many places where they are >>>> made available. This holds true for some of the other simplification >>>> suggestions. >>>> >>>> That is, until applications make these options available we cannot >>>> tell >>>> how much they would be used. >>>> >>>> Removal of these options just guarantees icalendar data will never be >>>> used in certain areas >>> >>> But perhaps the application developers choose not to make them >>> available precisely because their own surveys/requirements from users >>> did not show any demand. Its not necessarily because the developers >>> were "too lazy" to implement. >>> >>> Just from a personal standpoint I can tell you that I have never had >>> cause to create an hourly, minutely or secondly event even though the >>> client I use allows that via UI. Though I have used the VALARM repeat >>> capability to have alarms trigger at five minute intervals leading up >>> to the start of an event. That's why I would like to know why Reinhold >>> choose to use VEVENTs. My feeling is that you can use VALARM for those >>> cases and if you want to see something on the calendar, then the client >>> can quite easily display the VALARM "instances" using an appropriate >>> widget in the UI. >>> >> >> -- >> >> Mike Douglass douglm@rpi.edu >> Senior Systems Programmer >> Communication & Collaboration Technologies 518 276 6780(voice) 2809 >> (fax) >> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 >> >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > From reinhold at kainhofer.com Thu Dec 14 06:28:11 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Thu Dec 14 06:36:27 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <200612141352.kBEDqirU001965@tuvok.kom.tuwien.ac.at> References: <200612141352.kBEDqirU001965@tuvok.kom.tuwien.ac.at> Message-ID: <200612141528.15900.reinhold@kainhofer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 14. Dezember 2006 14:54 schrieben Sie: > Excuse me for asking a perhaps-too-obvious question, but have you > deprecated X- things in recurrences? If not, can Kalarm et al devise a > scheme which uses X-properties to provide what is needed? No, because then we don't have interoperatobility with any other application. If some other application already supports a similar feature, the two applications would not be able to exchange that data, unless both use the same, well-defined scheme. This scheme of course would need to be published, preferrable in an RFC, so we can as well include it in RFC 2445 instead of artificially creating the need for yet-another standards-extension. And most important: It should not matter which application generated a given recurrence. So proprietary X-... extensions are a bad thing. I'm currently not working together with the KAlarm or the KTimeTracker developers at all. They simply generate iCalendar, and my application is able to understand iCalendar, so these two applications automagically work together without doing any special cases for KAlarm support in KOrganizer or Evolution or Apple iCal. > I'm concerned that trying to retain too many of the possibilities in the > current iCalendar moves us away from the goal of the WG which is to produce > something simpler that promotes interoperability among implementations. > Retaining interoperability within components of one software suite, while > not a bad goal, doesn't advance the state of calendaring in the way that > the WG was chartered to do. I always saw iCalendar as a specification that defines a superset of basically everything that any calendar application ever wanted to do. Hardly anybody would implement every aspect, but if an application wanted to implement, say, minutely recurrences, there is a well-defined and interoperable way to do this. While it's not guaranteed that any application will understand every detail (How many applications do not implement the LANG param? Or how many applications do not implement recurring alarms?), at least those applications that support a given feature can exchange data without having to invent something new. And they have a defined way to interpret the exchanged data consistently. That last point was not really there in rfc 2445 because of some inconsistencies and misunderstandings in the RFC. And fixing that is the most important aspect for me. Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, 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 maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgV9/TqjEwhXvPN0RAl7SAJ9SP3iOzXbWLcqbKp3Y6t/1tWFG/wCfYi5z 2OErBSZbItqa3xUCaWSWJwY= =dMBP -----END PGP SIGNATURE----- From lisa at osafoundation.org Thu Dec 14 08:54:35 2006 From: lisa at osafoundation.org (Lisa Dusseault) Date: Thu Dec 14 08:54:42 2006 Subject: [Ietf-calsify] summary of issues discussed in the jabber session In-Reply-To: <200612141139.13461.reinhold@kainhofer.com> References: <45800594.4000807@cisco.com> <45804D63.50208@rpi.edu> <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> <200612141139.13461.reinhold@kainhofer.com> Message-ID: On Dec 14, 2006, at 2:38 AM, Reinhold Kainhofer wrote: >> >> RFC2445 won't go away, > > Sure, it will still be rfc 2445, but it will be marked as > deprecated and > superseded by 2445bis, which does no longer allow these > recurrences, right? Maybe. That's one option which would make the document appear to be easier to read, which might be good PR. I've heard from some implementors before that they wouldn't do recurrences at all because it was all too complicated. While I think that's a bogus objection, it might be expedient to make some compromise. Another option is to move the "extended recurrence rules" features to a separate section with health warnings and a discussion of applicability. Another option is to keep the full recur rule features in RFC 2445bis, but in iTIP -- which explains how to use iCalendar it for interpersonal scheduling anyway -- rule out certain features (make them illegal in scheduling requests). This has two potential drawbacks depending on your view: - makes RFC2445bis just about as complicated as RFC2445 (would probably end up longer as we add more explanation!) and just as daunting to readers/implementors, even if they don't have to implement quite as much any more - doesn't address calendar export/import. Is it reasonable to expect that all personal calendar applications should be able to import, display, and allow the user to edit, VEVENTS with recurrences such as "every five minutes"? Lisa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20061214/b1a17f67/attachment-0001.html From dthewlis at dcta.com Mon Dec 18 08:29:09 2006 From: dthewlis at dcta.com (David C. Thewlis) Date: Mon Dec 18 08:30:17 2006 Subject: [Ietf-calsify] CalConnect Roundtable VIII and Interoperabilty Testing Event January 29-February 2, 2007 - Announcement and Registration Open Message-ID: <4586C1D5.8010306@dcta.com> The Calendaring and Scheduling Consortium has opened Registration for its Roundtable VIII and associated CalConnect Interoperability Test Event, which will be hosted by Novell in Provo, Utah, on January 29 through February 2, 2006. The IOP test event will run from noon Monday the 29th of January through noon Wednesday the 31st. The Roundtable will begin with lunch at 1230 on Wednesday January 31st and go to noon on Friday February 2nd. More information, logistics and registration information for both the Roundtable and the IOP test event may be found on the CalConnect web site at http://www.calconnect.org/roundtable8.html. And feel free to call me (telephone numbers below) or e-mail me with any questions or comments. Topical agendas for the technical committee meetings, and more detailed information about the testing planned at the IOP test event, will be posted to the CalConnect website as we get nearer to the event. This notice is being sent to multiple calendar-related lists; my apologies if you receive this more than once. We look forward to welcoming you to Provo! 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20061218/a552efd1/attachment.htm From jeffrey at osafoundation.org Thu Dec 21 10:22:10 2006 From: jeffrey at osafoundation.org (Jeffrey Harris) Date: Thu Dec 21 10:23:08 2006 Subject: [Ietf-calsify] Period values in RDATEs Message-ID: <458AD0D2.2050509@osafoundation.org> Hi Folks, Do any clients out there serialize recurrence rules using RDATEs with PERIOD value? I haven't seen any recurrence rules like this in the wild, and allowing two very different ways to serialize modifications to recurring events has always struck me as not very helpful for implementors or for people trying to wrap their heads around icalendar recurrence. Could we remove PERIOD value RDATEs from rfc2445bis? Sincerely, Jeffrey From cyrus at daboo.name Thu Dec 21 12:51:59 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Dec 21 12:53:10 2006 Subject: [Ietf-calsify] Period values in RDATEs In-Reply-To: <458AD0D2.2050509@osafoundation.org> References: <458AD0D2.2050509@osafoundation.org> Message-ID: <45BC3EF82877ACE7CE1EB620@da0304a-dhcp40.apple.com> Hi Jeffrey, --On December 21, 2006 10:22:10 AM -0800 Jeffrey Harris wrote: > Do any clients out there serialize recurrence rules using RDATEs with > PERIOD value? > > I haven't seen any recurrence rules like this in the wild, and allowing > two very different ways to serialize modifications to recurring events > has always struck me as not very helpful for implementors or for people > trying to wrap their heads around icalendar recurrence. > > Could we remove PERIOD value RDATEs from rfc2445bis? I have seen this - it triggered an error in an iCal library I wrote that did not support PERIODs in RDATEs. I think I saw this in Notes generated iCal data. There are some valid use cases where using PERIOD is handy, though all it does is allow you to not have to have an explicitly overridden instance when all you want to do is change the duration of one or two instances. PS I share your pain: . -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 64F317F9D7; Thu, 21 Dec 2006 12:53:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 68FFA14226D; Thu, 21 Dec 2006 12:52:15 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26883-05; Thu, 21 Dec 2006 12:52:15 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D0B8A14226B; Thu, 21 Dec 2006 12:52:14 -0800 (PST) Received: from da0304a-dhcp40.apple.com (A17-221-46-90.apple.com [17.221.46.90]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kBLKq412017804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Dec 2006 15:52:10 -0500 Date: Thu, 21 Dec 2006 12:51:59 -0800 From: Cyrus Daboo To: Jeffrey Harris , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Period values in RDATEs Message-ID: <45BC3EF82877ACE7CE1EB620@da0304a-dhcp40.apple.com> In-Reply-To: <458AD0D2.2050509@osafoundation.org> References: <458AD0D2.2050509@osafoundation.org> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 20:53:08 -0000 Hi Jeffrey, --On December 21, 2006 10:22:10 AM -0800 Jeffrey Harris wrote: > Do any clients out there serialize recurrence rules using RDATEs with > PERIOD value? > > I haven't seen any recurrence rules like this in the wild, and allowing > two very different ways to serialize modifications to recurring events > has always struck me as not very helpful for implementors or for people > trying to wrap their heads around icalendar recurrence. > > Could we remove PERIOD value RDATEs from rfc2445bis? I have seen this - it triggered an error in an iCal library I wrote that did not support PERIODs in RDATEs. I think I saw this in Notes generated iCal data. There are some valid use cases where using PERIOD is handy, though all it does is allow you to not have to have an explicitly overridden instance when all you want to do is change the duration of one or two instances. PS I share your pain: . -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 38F927F99B; Thu, 21 Dec 2006 10:23:06 -0800 (PST) Received: from [192.168.2.33] (adsl-218-46-37.asm.bellsouth.net [68.218.46.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 01786142279; Thu, 21 Dec 2006 10:22:12 -0800 (PST) Message-ID: <458AD0D2.2050509@osafoundation.org> Date: Thu, 21 Dec 2006 10:22:10 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Ietf-calsify] Period values in RDATEs X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 18:23:06 -0000 Hi Folks, Do any clients out there serialize recurrence rules using RDATEs with PERIOD value? I haven't seen any recurrence rules like this in the wild, and allowing two very different ways to serialize modifications to recurring events has always struck me as not very helpful for implementors or for people trying to wrap their heads around icalendar recurrence. Could we remove PERIOD value RDATEs from rfc2445bis? Sincerely, Jeffrey Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6EDF07F67C for ; Mon, 18 Dec 2006 08:30:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9CB7314225A for ; Mon, 18 Dec 2006 08:29:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29272-05 for ; Mon, 18 Dec 2006 08:29:22 -0800 (PST) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3FD5A142257 for ; Mon, 18 Dec 2006 08:29:22 -0800 (PST) Received: from [75.111.46.70] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.52) id 1GwLMc-0004T2-D0; Mon, 18 Dec 2006 08:29:18 -0800 Message-ID: <4586C1D5.8010306@dcta.com> Date: Mon, 18 Dec 2006 08:29:09 -0800 From: "David C. Thewlis" Organization: DCTA Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ietf-calsify list Content-Type: multipart/alternative; boundary="------------060407050804010702020501" X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dthewlis@dcta.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - dcta.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=AWL, HTML_20_30, HTML_MESSAGE, HTML_TITLE_EMPTY X-Spam-Level: Subject: [Ietf-calsify] CalConnect Roundtable VIII and Interoperabilty Testing Event January 29-February 2, 2007 - Announcement and Registration Open X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org, dthewlis@dcta.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2006 16:30:15 -0000 This is a multi-part message in MIME format. --------------060407050804010702020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The Calendaring and Scheduling Consortium has opened Registration for its Roundtable VIII and associated CalConnect Interoperability Test Event, which will be hosted by Novell in Provo, Utah, on January 29 through February 2, 2006. The IOP test event will run from noon Monday the 29th of January through noon Wednesday the 31st. The Roundtable will begin with lunch at 1230 on Wednesday January 31st and go to noon on Friday February 2nd. More information, logistics and registration information for both the Roundtable and the IOP test event may be found on the CalConnect web site at http://www.calconnect.org/roundtable8.html. And feel free to call me (telephone numbers below) or e-mail me with any questions or comments. Topical agendas for the technical committee meetings, and more detailed information about the testing planned at the IOP test event, will be posted to the CalConnect website as we get nearer to the event. This notice is being sent to multiple calendar-related lists; my apologies if you receive this more than once. We look forward to welcoming you to Provo! 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 --------------060407050804010702020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Calendaring and Scheduling Consortium has opened Registration for its Roundtable VIII and associated CalConnect Interoperability Test Event, which will be hosted by Novell in Provo, Utah, on January 29 through February 2, 2006.

The IOP test event will run from noon Monday the 29th of January through noon Wednesday the 31st.

The Roundtable will begin with lunch at 1230 on Wednesday January 31st and go to noon on Friday February 2nd.

More information, logistics and registration information for both the Roundtable and the IOP test event may be found on the CalConnect web site at http://www.calconnect.org/roundtable8.html.  And feel free to call me (telephone numbers below) or e-mail me with any questions or comments.

Topical agendas for the technical committee meetings, and more detailed information about the testing planned at the IOP test event, will be posted to the CalConnect website as we get nearer to the event.

This notice is being sent to multiple calendar-related lists; my apologies if you receive this more than once. 

We look forward to welcoming you to Provo!

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
--------------060407050804010702020501-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C54D17F62F for ; Thu, 14 Dec 2006 08:54:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B688014224C for ; Thu, 14 Dec 2006 08:54:39 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10671-01; Thu, 14 Dec 2006 08:54:39 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0DA11142249; Thu, 14 Dec 2006 08:54:39 -0800 (PST) In-Reply-To: <200612141139.13461.reinhold@kainhofer.com> References: <45800594.4000807@cisco.com> <45804D63.50208@rpi.edu> <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> <200612141139.13461.reinhold@kainhofer.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-1-976997732 Message-Id: From: Lisa Dusseault Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Date: Thu, 14 Dec 2006 08:54:35 -0800 To: Reinhold Kainhofer X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.9 tagged_above=-50.0 required=4.0 tests=AWL, HTML_40_50, HTML_MESSAGE, RCVD_IN_SORBS_DUL X-Spam-Level: * Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 16:54:40 -0000 --Apple-Mail-1-976997732 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 14, 2006, at 2:38 AM, Reinhold Kainhofer wrote: >> >> RFC2445 won't go away, > > Sure, it will still be rfc 2445, but it will be marked as > deprecated and > superseded by 2445bis, which does no longer allow these > recurrences, right? Maybe. That's one option which would make the document appear to be easier to read, which might be good PR. I've heard from some implementors before that they wouldn't do recurrences at all because it was all too complicated. While I think that's a bogus objection, it might be expedient to make some compromise. Another option is to move the "extended recurrence rules" features to a separate section with health warnings and a discussion of applicability. Another option is to keep the full recur rule features in RFC 2445bis, but in iTIP -- which explains how to use iCalendar it for interpersonal scheduling anyway -- rule out certain features (make them illegal in scheduling requests). This has two potential drawbacks depending on your view: - makes RFC2445bis just about as complicated as RFC2445 (would probably end up longer as we add more explanation!) and just as daunting to readers/implementors, even if they don't have to implement quite as much any more - doesn't address calendar export/import. Is it reasonable to expect that all personal calendar applications should be able to import, display, and allow the user to edit, VEVENTS with recurrences such as "every five minutes"? Lisa --Apple-Mail-1-976997732 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 14, 2006, = at 2:38 AM, Reinhold Kainhofer wrote:


RFC2445 won't go away,=A0


Sure, it will still be rfc 2445, but it will be marked as = deprecated and=A0

=

superseded by 2445bis, which = does no longer allow these recurrences, right?

=

Maybe.=A0 That's one option which would make = the document appear to be easier to read, which might be good PR.=A0 = I've heard from some implementors before that they wouldn't do = recurrences at all because it was all too complicated. While I think = that's a bogus objection, it might be expedient to make some = compromise.

Another option is to move = the "extended recurrence rules" features to a separate section with = health warnings and a discussion of applicability.

Another option is to keep = the full recur rule features in RFC 2445bis, but in iTIP -- which = explains how to use iCalendar it for interpersonal scheduling anyway -- = rule out certain features (make them illegal in scheduling requests).=A0 = This has two potential drawbacks depending on your view:
- makes = RFC2445bis just about as complicated as RFC2445 (would probably end up = longer as we add more explanation!) and just as=A0 daunting to = readers/implementors, even if they don't have to implement quite as much = any more
- doesn't address calendar = export/import.=A0 Is it reasonable to expect that all personal calendar = applications should be able to import, display, and allow the user to = edit, VEVENTS with recurrences such as "every five = minutes"?

Lisa
= --Apple-Mail-1-976997732-- Return-Path: X-Original-To: Ietf-calsify@osafoundation.org Delivered-To: Ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1D24A7F555 for ; Thu, 14 Dec 2006 06:36:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0DF4F14224B for ; Thu, 14 Dec 2006 06:36:26 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04534-10 for ; Thu, 14 Dec 2006 06:36:24 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0CB06142246 for ; Thu, 14 Dec 2006 06:36:23 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBEESGve015299; Thu, 14 Dec 2006 15:28:18 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: "Tim Hare" Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Date: Thu, 14 Dec 2006 15:28:11 +0100 User-Agent: KMail/1.9.5 References: <200612141352.kBEDqirU001965@tuvok.kom.tuwien.ac.at> In-Reply-To: <200612141352.kBEDqirU001965@tuvok.kom.tuwien.ac.at> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612141528.15900.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CALSIFY Mailinglist X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 14:36:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 14. Dezember 2006 14:54 schrieben Sie: > Excuse me for asking a perhaps-too-obvious question, but have you > deprecated X- things in recurrences? If not, can Kalarm et al devise a > scheme which uses X-properties to provide what is needed? No, because then we don't have interoperatobility with any other application. If some other application already supports a similar feature, the two applications would not be able to exchange that data, unless both use the same, well-defined scheme. This scheme of course would need to be published, preferrable in an RFC, so we can as well include it in RFC 2445 instead of artificially creating the need for yet-another standards-extension. And most important: It should not matter which application generated a given recurrence. So proprietary X-... extensions are a bad thing. I'm currently not working together with the KAlarm or the KTimeTracker developers at all. They simply generate iCalendar, and my application is able to understand iCalendar, so these two applications automagically work together without doing any special cases for KAlarm support in KOrganizer or Evolution or Apple iCal. > I'm concerned that trying to retain too many of the possibilities in the > current iCalendar moves us away from the goal of the WG which is to produce > something simpler that promotes interoperability among implementations. > Retaining interoperability within components of one software suite, while > not a bad goal, doesn't advance the state of calendaring in the way that > the WG was chartered to do. I always saw iCalendar as a specification that defines a superset of basically everything that any calendar application ever wanted to do. Hardly anybody would implement every aspect, but if an application wanted to implement, say, minutely recurrences, there is a well-defined and interoperable way to do this. While it's not guaranteed that any application will understand every detail (How many applications do not implement the LANG param? Or how many applications do not implement recurring alarms?), at least those applications that support a given feature can exchange data without having to invent something new. And they have a defined way to interpret the exchanged data consistently. That last point was not really there in rfc 2445 because of some inconsistencies and misunderstandings in the RFC. And fixing that is the most important aspect for me. Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, 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 maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgV9/TqjEwhXvPN0RAl7SAJ9SP3iOzXbWLcqbKp3Y6t/1tWFG/wCfYi5z 2OErBSZbItqa3xUCaWSWJwY= =dMBP -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2EE167F66D for ; Thu, 14 Dec 2006 05:50:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F2D2142254 for ; Thu, 14 Dec 2006 05:50:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06316-05 for ; Thu, 14 Dec 2006 05:50:51 -0800 (PST) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by laweleka.osafoundation.org (Postfix) with ESMTP id E64DF14224B for ; Thu, 14 Dec 2006 05:50:50 -0800 (PST) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by cmsout02.mbox.net (Postfix) with ESMTP id 48AC84CAAF for ; Thu, 14 Dec 2006 13:50:49 +0000 (GMT) Received: from cmsapps01.cms.usa.net [165.212.11.136] by cmsout02.mbox.net via smtad (C8.MAIN.3.32M); Thu, 14 Dec 2006 13:50:49 GMT X-USANET-Source: 165.212.11.136 IN cbryant-ical@corp.usa.net cmsapps01.cms.usa.net X-USANET-MsgId: XID089kLNNYx1990X02 Received: from cbryantlt2 [165.212.225.4] by cmsapps01.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.31J) with ESMTP id 262kLNNYv0318M36; Thu, 14 Dec 2006 13:50:47 GMT X-USANET-Auth: 165.212.225.4 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <001201c71f86$db92faf0$6401a8c0@corp.usa.net> From: "Chris Bryant" To: References: <45800594.4000807@cisco.com><200612131526.56228.reinhold@kainhofer.com><45802249.1070207@rpi.edu><6340ECD74D5B8D024EF708BA@caldav.apple.com><45804D63.50208@rpi.edu> <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Date: Thu, 14 Dec 2006 08:50:44 -0500 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Z-USANET-MsgId: XID262kLNNYv0318X36 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 13:50:53 -0000 It seems to me that there is a common set of recurrence types that most interpersonal scheduling tools try to accomodate. Lisa's proposal addresses these types. It seems that we could work out some wording that says that interpersonal scheduling tools should limit their recurrence rules to a specific set. This would allow creators and consumers of this data to simplify their implementations, only supporting that specific set of rules. We could keep the hourly/minutely/secondly specs in the rfc, but people would need to be aware that even well behaving consumers of this data would be free to just ignore those rules or fail to process the event containing those rules. If there are scheduling tools that desire to exchange hourly/minutely/secondly events, there would still be a standard format by which this would be done. Chris ----- Original Message ----- From: "Lisa Dusseault" To: "Mike Douglass" Cc: Sent: Wednesday, December 13, 2006 11:14 PM Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session > > Since I'm one of the advocates for removing some of the recurrence > "feaures", I'll clarify that this might only hold for interpersonal > scheduling. I'm hoping Reinhold never schedules me for meetings every > fifteen minutes, and one of the reasons is that my client doesn't have > the functionality to let me alter that recurrence pattern to something > more reasonable. > > RFC2445 won't go away, any application that wants to use more complex > recurrence rules can. A personal alarm application (I've used "fob" in > the past and it sounds like what Reinhold's talked about) might use a > different set of recurrence features than interpersonal scheduling. Is > there a need for interoperability for that kind of use case? Do personal > alarm applications ever even export and import alarm data? > > Lisa > > On Dec 13, 2006, at 10:58 AM, Mike Douglass wrote: > >> I hope I wasn't trying to accuse anyone of laziness. I'd have to accuse >> myself first... The allowable storage and transport formats will usually >> be a superset of what's implemented in any given ui and that's probably >> reasonable enough. I doubt we'll put seconds and minutes in our user ui >> but I am considering their use for internal events. Alarms will probably >> work in most cases as will very simple recurrences but the point of >> recurrences is they allow for greater complexity where needed. >> >> My recollection of a brief walk around vendor booths was that most >> weren't even aware there was a calendar data 'standard' available for >> use and where the use of seconds and minutes might be appropriate they >> aren't being used because vendors don't even use icalendar. >> >> Triggering system events such as backup or synch seems to be an ideal >> use for icalendar and rather more undarstandable than cron. Unlikely if >> we drop seconds and minutes. >> >> As it so happens we're just implementing recurrences in our ui and it is >> hard, but the main obstacle to me is the RFC - not what we're trying to >> implement. Clearly inconsistencies need to be resolved and the various >> traps for the unwary documented so that we all take a consistent >> approach but I'd hope that wouldn't result in a loss of functionality. >> >> Cyrus Daboo wrote: >>> Hi Mike, >>> >>> --On December 13, 2006 10:54:49 AM -0500 Mike Douglass >>> wrote: >>> >>>> The arguments for removal of these options seem to be based on nobody >>>> using them - however there don't seem to be many places where they are >>>> made available. This holds true for some of the other simplification >>>> suggestions. >>>> >>>> That is, until applications make these options available we cannot >>>> tell >>>> how much they would be used. >>>> >>>> Removal of these options just guarantees icalendar data will never be >>>> used in certain areas >>> >>> But perhaps the application developers choose not to make them >>> available precisely because their own surveys/requirements from users >>> did not show any demand. Its not necessarily because the developers >>> were "too lazy" to implement. >>> >>> Just from a personal standpoint I can tell you that I have never had >>> cause to create an hourly, minutely or secondly event even though the >>> client I use allows that via UI. Though I have used the VALARM repeat >>> capability to have alarms trigger at five minute intervals leading up >>> to the start of an event. That's why I would like to know why Reinhold >>> choose to use VEVENTs. My feeling is that you can use VALARM for those >>> cases and if you want to see something on the calendar, then the client >>> can quite easily display the VALARM "instances" using an appropriate >>> widget in the UI. >>> >> >> -- >> >> Mike Douglass douglm@rpi.edu >> Senior Systems Programmer >> Communication & Collaboration Technologies 518 276 6780(voice) 2809 >> (fax) >> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 >> >> _______________________________________________ >> Ietf-calsify mailing list >> Ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E72DE7F64E for ; Thu, 14 Dec 2006 02:39:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D87F414224B for ; Thu, 14 Dec 2006 02:39:22 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04089-03 for ; Thu, 14 Dec 2006 02:39:19 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B8C22142249 for ; Thu, 14 Dec 2006 02:39:18 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBEAdEES003717 for ; Thu, 14 Dec 2006 11:39:16 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Date: Thu, 14 Dec 2006 11:38:58 +0100 User-Agent: KMail/1.9.5 References: <45800594.4000807@cisco.com> <45804D63.50208@rpi.edu> <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> In-Reply-To: <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612141139.13461.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 10:39:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 14. Dezember 2006 05:14 schrieb Lisa Dusseault: > Since I'm one of the advocates for removing some of the recurrence > "feaures", I'll clarify that this might only hold for interpersonal > scheduling. I completely agree. That's why we don't have sub-daily recurrences in our personal calendar application "KOrganizer" (http://www.korganizer.org/, which is terribly out of date). But the alarm application "KAlarm" (http://www.astrojar.org.uk/linux/kalarm.html), does have hourly and minutely recurrences, because for alarms it makes sense to have it. However, rfc 2445 is not only about interpersonal scheduling. As the introduction says, it's meant as a general format for calendar data exchange, and we use iCalendar for exchanging data between applications (copying event/tasks/journal entries(=notes) from application to another using the clipboard, or making the data available as an .ics file that can also shown by the calendar application, etc.) > I'm hoping Reinhold never schedules me for meetings > every fifteen minutes, and one of the reasons is that my client > doesn't have the functionality to let me alter that recurrence > pattern to something more reasonable. > > RFC2445 won't go away, Sure, it will still be rfc 2445, but it will be marked as deprecated and superseded by 2445bis, which does no longer allow these recurrences, right? > any application that wants to use more complex > recurrence rules can. A personal alarm application (I've used "fob" > in the past and it sounds like what Reinhold's talked about) might > use a different set of recurrence features than interpersonal > scheduling. Is there a need for interoperability for that kind of > use case? Yes, definitely. I never thought there might, until I started showing the entries in the personal alarm application in my calendar application. It's really useful to finally see e.g. the regularly schedulled breaks away from the computer in the calendar. Or to see the time periods in your calendar application, when you worked on some projects, which you entered into your time tracking application (KTimetracker in our case: http://wiki.kde.org/tiki-index.php?page=KTimeTracker). Granted, in that case you don't have any recurrences, but there are other issues (like related-to superprojects (=VTODO), custom properties to store the combined time your worked on a project, etc.) > Do personal alarm applications ever even export and import > alarm data? KAlarm stores it's data in an .ics file, so other applications (like KOrganizer or evolution) can simply load this file and show the alarms as events in your schedule... Cheers, Reinhold PS: Just for your information, here's a list of various KDE applications that use iCalendar as its native format for data storage and/or exchange with other applications: - -) Kontact (KDE's full PIM suite, http://kontact.org/, makes use of the applications listed below) - -) KOrganizer (KDE's calendar application: Events, Tasks, Journals) - -) KAlarm (KDE's alarm applications, Alarms saved as events with a VALARM) - -) KArm (time tracker, projects saved as VTODO, time periods you worked on a project saved as VEVENT with RELATED-TO prop set) - -) KNotes (sticky notes application, Notes saved as VJOURNAL) - -) TaskJuggler (Complex project manager, project plan automatically exported as .ics) - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, 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 maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgSnRTqjEwhXvPN0RAk5YAKDXmbFjY5D5Nm2tCMxqGbmdSUObmwCeNmrD eBGbvmKCVlParHAhbJws8A8= =J8l0 -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7AF357F66D for ; Wed, 13 Dec 2006 20:15:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6C03514224C for ; Wed, 13 Dec 2006 20:15:00 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29912-06; Wed, 13 Dec 2006 20:14:59 -0800 (PST) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 690D514223D; Wed, 13 Dec 2006 20:14:59 -0800 (PST) In-Reply-To: <45804D63.50208@rpi.edu> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> <6340ECD74D5B8D024EF708BA@caldav.apple.com> <45804D63.50208@rpi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <475A2606-35FB-4035-9983-0341AE5A36E7@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Date: Wed, 13 Dec 2006 20:14:55 -0800 To: Mike Douglass X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.9 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_IN_SORBS_DUL X-Spam-Level: * Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 04:15:01 -0000 Since I'm one of the advocates for removing some of the recurrence "feaures", I'll clarify that this might only hold for interpersonal scheduling. I'm hoping Reinhold never schedules me for meetings every fifteen minutes, and one of the reasons is that my client doesn't have the functionality to let me alter that recurrence pattern to something more reasonable. RFC2445 won't go away, any application that wants to use more complex recurrence rules can. A personal alarm application (I've used "fob" in the past and it sounds like what Reinhold's talked about) might use a different set of recurrence features than interpersonal scheduling. Is there a need for interoperability for that kind of use case? Do personal alarm applications ever even export and import alarm data? Lisa On Dec 13, 2006, at 10:58 AM, Mike Douglass wrote: > I hope I wasn't trying to accuse anyone of laziness. I'd have to > accuse myself first... The allowable storage and transport formats > will usually be a superset of what's implemented in any given ui > and that's probably reasonable enough. I doubt we'll put seconds > and minutes in our user ui but I am considering their use for > internal events. Alarms will probably work in most cases as will > very simple recurrences but the point of recurrences is they allow > for greater complexity where needed. > > My recollection of a brief walk around vendor booths was that most > weren't even aware there was a calendar data 'standard' available > for use and where the use of seconds and minutes might be > appropriate they aren't being used because vendors don't even use > icalendar. > > Triggering system events such as backup or synch seems to be an > ideal use for icalendar and rather more undarstandable than cron. > Unlikely if we drop seconds and minutes. > > As it so happens we're just implementing recurrences in our ui and > it is hard, but the main obstacle to me is the RFC - not what we're > trying to implement. Clearly inconsistencies need to be resolved > and the various traps for the unwary documented so that we all take > a consistent approach but I'd hope that wouldn't result in a loss > of functionality. > > Cyrus Daboo wrote: >> Hi Mike, >> >> --On December 13, 2006 10:54:49 AM -0500 Mike Douglass >> wrote: >> >>> The arguments for removal of these options seem to be based on >>> nobody >>> using them - however there don't seem to be many places where >>> they are >>> made available. This holds true for some of the other simplification >>> suggestions. >>> >>> That is, until applications make these options available we >>> cannot tell >>> how much they would be used. >>> >>> Removal of these options just guarantees icalendar data will >>> never be >>> used in certain areas >> >> But perhaps the application developers choose not to make them >> available precisely because their own surveys/requirements from >> users did not show any demand. Its not necessarily because the >> developers were "too lazy" to implement. >> >> Just from a personal standpoint I can tell you that I have never >> had cause to create an hourly, minutely or secondly event even >> though the client I use allows that via UI. Though I have used the >> VALARM repeat capability to have alarms trigger at five minute >> intervals leading up to the start of an event. That's why I would >> like to know why Reinhold choose to use VEVENTs. My feeling is >> that you can use VALARM for those cases and if you want to see >> something on the calendar, then the client can quite easily >> display the VALARM "instances" using an appropriate widget in the UI. >> > > -- > > Mike Douglass douglm@rpi.edu > Senior Systems Programmer > Communication & Collaboration Technologies 518 276 6780(voice) > 2809 > (fax) > Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0F2887F96F for ; Wed, 13 Dec 2006 10:56:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F3D0214224D for ; Wed, 13 Dec 2006 10:56:55 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22783-05 for ; Wed, 13 Dec 2006 10:56:55 -0800 (PST) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B3F5142247 for ; Wed, 13 Dec 2006 10:56:54 -0800 (PST) Received: from [128.113.124.224] (blue-eyes-white-dragon-16.dynamic2.rpi.edu [128.113.124.224]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id kBDIugAo020187; Wed, 13 Dec 2006 13:56:42 -0500 Message-ID: <45804D63.50208@rpi.edu> Date: Wed, 13 Dec 2006 13:58:43 -0500 From: Mike Douglass User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> <6340ECD74D5B8D024EF708BA@caldav.apple.com> In-Reply-To: <6340ECD74D5B8D024EF708BA@caldav.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 18:56:56 -0000 I hope I wasn't trying to accuse anyone of laziness. I'd have to accuse myself first... The allowable storage and transport formats will usually be a superset of what's implemented in any given ui and that's probably reasonable enough. I doubt we'll put seconds and minutes in our user ui but I am considering their use for internal events. Alarms will probably work in most cases as will very simple recurrences but the point of recurrences is they allow for greater complexity where needed. My recollection of a brief walk around vendor booths was that most weren't even aware there was a calendar data 'standard' available for use and where the use of seconds and minutes might be appropriate they aren't being used because vendors don't even use icalendar. Triggering system events such as backup or synch seems to be an ideal use for icalendar and rather more undarstandable than cron. Unlikely if we drop seconds and minutes. As it so happens we're just implementing recurrences in our ui and it is hard, but the main obstacle to me is the RFC - not what we're trying to implement. Clearly inconsistencies need to be resolved and the various traps for the unwary documented so that we all take a consistent approach but I'd hope that wouldn't result in a loss of functionality. Cyrus Daboo wrote: > Hi Mike, > > --On December 13, 2006 10:54:49 AM -0500 Mike Douglass > wrote: > >> The arguments for removal of these options seem to be based on nobody >> using them - however there don't seem to be many places where they are >> made available. This holds true for some of the other simplification >> suggestions. >> >> That is, until applications make these options available we cannot tell >> how much they would be used. >> >> Removal of these options just guarantees icalendar data will never be >> used in certain areas > > But perhaps the application developers choose not to make them > available precisely because their own surveys/requirements from users > did not show any demand. Its not necessarily because the developers > were "too lazy" to implement. > > Just from a personal standpoint I can tell you that I have never had > cause to create an hourly, minutely or secondly event even though the > client I use allows that via UI. Though I have used the VALARM repeat > capability to have alarms trigger at five minute intervals leading up > to the start of an event. That's why I would like to know why Reinhold > choose to use VEVENTs. My feeling is that you can use VALARM for those > cases and if you want to see something on the calendar, then the > client can quite easily display the VALARM "instances" using an > appropriate widget in the UI. > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E18BA7F6CD for ; Wed, 13 Dec 2006 10:24:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D39A014225B for ; Wed, 13 Dec 2006 10:24:59 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21525-03 for ; Wed, 13 Dec 2006 10:24:59 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1394114225A for ; Wed, 13 Dec 2006 10:24:58 -0800 (PST) Received: from [17.101.35.156] ([17.101.35.156]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kBDIOmjY010811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 13:24:50 -0500 Date: Wed, 13 Dec 2006 13:24:43 -0500 From: Cyrus Daboo To: Mike Douglass , Reinhold Kainhofer Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Message-ID: <6340ECD74D5B8D024EF708BA@caldav.apple.com> In-Reply-To: <45802249.1070207@rpi.edu> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> X-Mailer: Mulberry/4.0.7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 18:25:00 -0000 Hi Mike, --On December 13, 2006 10:54:49 AM -0500 Mike Douglass wrote: > The arguments for removal of these options seem to be based on nobody > using them - however there don't seem to be many places where they are > made available. This holds true for some of the other simplification > suggestions. > > That is, until applications make these options available we cannot tell > how much they would be used. > > Removal of these options just guarantees icalendar data will never be > used in certain areas But perhaps the application developers choose not to make them available precisely because their own surveys/requirements from users did not show any demand. Its not necessarily because the developers were "too lazy" to implement. Just from a personal standpoint I can tell you that I have never had cause to create an hourly, minutely or secondly event even though the client I use allows that via UI. Though I have used the VALARM repeat capability to have alarms trigger at five minute intervals leading up to the start of an event. That's why I would like to know why Reinhold choose to use VEVENTs. My feeling is that you can use VALARM for those cases and if you want to see something on the calendar, then the client can quite easily display the VALARM "instances" using an appropriate widget in the UI. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0054A7F771 for ; Wed, 13 Dec 2006 07:59:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E55F414224B for ; Wed, 13 Dec 2006 07:59:04 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20021-01 for ; Wed, 13 Dec 2006 07:59:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id 36FC1142249 for ; Wed, 13 Dec 2006 07:59:04 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2006 07:59:04 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBDFx2cN012540; Wed, 13 Dec 2006 07:59:02 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBDFwxio023779; Wed, 13 Dec 2006 07:59:00 -0800 (PST) Received: from [212.254.247.6] ([10.61.65.119]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kBDFhUGp028484; Wed, 13 Dec 2006 07:43:31 -0800 Message-ID: <45802341.8080806@cisco.com> Date: Wed, 13 Dec 2006 16:58:57 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Douglass Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> <45802249.1070207@rpi.edu> In-Reply-To: <45802249.1070207@rpi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=474; t=1166025542; x=1166889542; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20summary=20of=20issues=20discussed=20 in=20the=20jabber=20session |Sender:=20; bh=fvewUl70E6LK9NYFkhRQjtSgvCbHY7m7NQmkdxKBCDc=; b=OBA5S8vBSUbJItH7Env39o/vKBuJ/GkXXd1vPK3BNOqkgYiYUEjX0IrunZCpZC+DPST3mg+G Y4FOoLbp/k2qGwH6vousKsC2W0vwud8SwDYrPTGxPS7qWEbcSZhM0bnL; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=474; t=1166024612; x=1166888612; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-calsify]=20summary=20of=20issues=20discussed=20 in=20the=20jabber=20session |Sender:=20 |To:=20Mike=20Douglass=20; bh=fvewUl70E6LK9NYFkhRQjtSgvCbHY7m7NQmkdxKBCDc=; b=N7taRFM4wTz0OM305Mm0YDSjfz+IT4fjrnziAiaYINqwCQArLkf79Aro0ak82XvcUJAqOFn5 yhN+24QQK9xM/LCyzwW5ng5rPpamyIfNf4PaWfVrKPEY+f1QC60ibBoH; Authentication-Results: sj-dkim-2; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 15:59:05 -0000 First the obvious comment. We always confirm our consensus positions on mailing lists. If this one doesn't hold we will need to back off. That having been said, let's be clear: if a feature isn't used now, it's not likely to be used in the future. RFC 2445 has been out there a VERY LONG TIME. Also, if that feature is actually making it more difficult for people to implement the rest of the specification, then having it costs us quite a bit. Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F0D157F76D for ; Wed, 13 Dec 2006 07:52:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E1E0E14224B for ; Wed, 13 Dec 2006 07:52:56 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19811-07 for ; Wed, 13 Dec 2006 07:52:54 -0800 (PST) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 27EA8142249 for ; Wed, 13 Dec 2006 07:52:53 -0800 (PST) Received: from [128.113.124.224] (blue-eyes-white-dragon-16.dynamic2.rpi.edu [128.113.124.224]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id kBDFqnLR018622; Wed, 13 Dec 2006 10:52:49 -0500 Message-ID: <45802249.1070207@rpi.edu> Date: Wed, 13 Dec 2006 10:54:49 -0500 From: Mike Douglass User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Reinhold Kainhofer Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> In-Reply-To: <200612131526.56228.reinhold@kainhofer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 15:52:57 -0000 I absolutely agree. The arguments for removal of these options seem to be based on nobody using them - however there don't seem to be many places where they are made available. This holds true for some of the other simplification suggestions. That is, until applications make these options available we cannot tell how much they would be used. Removal of these options just guarantees icalendar data will never be used in certain areas Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Mittwoch, 13. Dezember 2006 14:52 schrieb Eliot Lear: > >> 55 Remove SECONDLY, MINUTELY, Nuke BYSEC and SECONDLY. >> BYSEC and BYMIN Also nuke MINUTELY. This >> leaves open the question >> of BYMINUTE. >> > > ARGH!!! Why would you do that? > In my eyes, these frequencies and these BY* rule parts are the most > uncontroversial of all rule parts. The other rule parts create the problems > for us. > > In KDE we have a dedicated alarm application (not for event reminders, but for > all sorts of things that you want to be reminded of) that makes available all > alarms as events to applications that use iCalendar format. > > You can't imagine how useful that stuff is. E.g. Set a quick alarm to remove > the cake or the pizza from the oven in 15 Minutes. That alarm will > automatically appear in your calendaring app (that watches the iCalendar > file). > > Or set an alarm that reminds you every 1.5 hours (=90 minutes) to take a break > from the computer. I also like these alarms to show up in my calendar (which > is a completely different application, so we need to have a format for data > exchange, which is exactly iCalendar). > > Cheers, > Reinhold > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, 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 maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFgA2wTqjEwhXvPN0RAizhAJ92rcHFGcj90XqZ4wrdDSrRS248VQCgsoVG > QiX+0KyOPRweqSitvQNmglE= > =3JLu > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CDD777F668 for ; Wed, 13 Dec 2006 06:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE4FC142254 for ; Wed, 13 Dec 2006 06:35:01 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16808-06 for ; Wed, 13 Dec 2006 06:35:00 -0800 (PST) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 00CBF14224D for ; Wed, 13 Dec 2006 06:34:59 -0800 (PST) Received: from [17.101.35.156] ([17.101.35.156]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kBDEYsEa010104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Dec 2006 09:34:56 -0500 Date: Wed, 13 Dec 2006 09:34:49 -0500 From: Cyrus Daboo To: Reinhold Kainhofer , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Message-ID: In-Reply-To: <200612131526.56228.reinhold@kainhofer.com> References: <45800594.4000807@cisco.com> <200612131526.56228.reinhold@kainhofer.com> X-Mailer: Mulberry/4.0.7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 14:35:01 -0000 Hi Reinhold, --On December 13, 2006 3:26:52 PM +0100 Reinhold Kainhofer wrote: > ARGH!!! Why would you do that? > In my eyes, these frequencies and these BY* rule parts are the most > uncontroversial of all rule parts. The other rule parts create the > problems for us. > > In KDE we have a dedicated alarm application (not for event reminders, > but for all sorts of things that you want to be reminded of) that makes > available all alarms as events to applications that use iCalendar format. > > You can't imagine how useful that stuff is. E.g. Set a quick alarm to > remove the cake or the pizza from the oven in 15 Minutes. That alarm > will automatically appear in your calendaring app (that watches the > iCalendar file). > > Or set an alarm that reminds you every 1.5 hours (=90 minutes) to take a > break from the computer. I also like these alarms to show up in my > calendar (which is a completely different application, so we need to > have a format for data exchange, which is exactly iCalendar). Using a VALARM inside a VEVENT isn't sufficient? Just wanting to know why you choose to represent 'alarms' as events... -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 43E6B7F66F for ; Wed, 13 Dec 2006 06:27:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 34DC714224C for ; Wed, 13 Dec 2006 06:27:17 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18213-09 for ; Wed, 13 Dec 2006 06:27:14 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF26F14224D for ; Wed, 13 Dec 2006 06:27:14 -0800 (PST) X-Spam-Score-scoring_explanation: (100%) OBFUSCATED_WORD2_ERECTION X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 5a738d6700634088472e2308852664d4 X-Spam-Score-Summary: 20, 1.5, 0, 5a23130ac85841ee, 446e7e04378f28f1, nigel.swinson@rockliffe.com, , RULES_HIT:355:379:539:540:541:542:543:567:877:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1683:1711:1730:1747:1766:1792:1801:2073:2075:2078:2317:2393:2525:2553:2559:2564:2682:2685:2691:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3352:3636:3770:3865:3866:3868:3869:3870:3871:3934:3936:3938:4250:4605:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: windows-1252 Received: from nigelhome (unverified [10.42.44.151]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.5) with ESMTP id ; Wed, 13 Dec 2006 06:27:14 -0800 Message-ID: <002b01c71ec2$df2e7140$0202fea9@nigelhome> From: "Nigel Swinson" To: Date: Wed, 13 Dec 2006 14:27:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 5 X-MSMail-Priority: Low X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Inconsistent BNF for "the following is optional and may occur more than once" X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 14:27:17 -0000 Minor nits: BNF for DTDue says: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-03#section-3.8.2= .3 dueparam =3D *( + ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=3D" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once - *(";" xparam) + (";" xparam) ) BNF for DTStart says: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-03#section-3.8.2= .4 dtstparam =3D *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=3D" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once - *(";" xparam) + (";" xparam) ) The *(";" xparam) bit is I believe unintentionally inconsistent with the = other values like DTEnd and I think the * should be dropped relying = instead on the top level *() of the param token. Also there's a missing = newline in the dueparam making the formatting inconsistent with the = others. Cheers Nigel Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 275EB7F64F for ; Wed, 13 Dec 2006 06:27:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 19534142256 for ; Wed, 13 Dec 2006 06:27:06 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18213-08 for ; Wed, 13 Dec 2006 06:27:02 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3CE9C14224C for ; Wed, 13 Dec 2006 06:27:02 -0800 (PST) Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBDEQuCw017445 for ; Wed, 13 Dec 2006 15:26:59 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session Date: Wed, 13 Dec 2006 15:26:52 +0100 User-Agent: KMail/1.9.5 References: <45800594.4000807@cisco.com> In-Reply-To: <45800594.4000807@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612131526.56228.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 14:27:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 13. Dezember 2006 14:52 schrieb Eliot Lear: > 55             Remove SECONDLY, MINUTELY,        Nuke BYSEC and SECONDLY. >                BYSEC and BYMIN                   Also nuke MINUTELY.  This >                                                  leaves open the question >                                                  of BYMINUTE. ARGH!!! Why would you do that? In my eyes, these frequencies and these BY* rule parts are the most uncontroversial of all rule parts. The other rule parts create the problems for us. In KDE we have a dedicated alarm application (not for event reminders, but for all sorts of things that you want to be reminded of) that makes available all alarms as events to applications that use iCalendar format. You can't imagine how useful that stuff is. E.g. Set a quick alarm to remove the cake or the pizza from the oven in 15 Minutes. That alarm will automatically appear in your calendaring app (that watches the iCalendar file). Or set an alarm that reminds you every 1.5 hours (=90 minutes) to take a break from the computer. I also like these alarms to show up in my calendar (which is a completely different application, so we need to have a format for data exchange, which is exactly iCalendar). Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, 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 maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgA2wTqjEwhXvPN0RAizhAJ92rcHFGcj90XqZ4wrdDSrRS248VQCgsoVG QiX+0KyOPRweqSitvQNmglE= =3JLu -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CF0697F4F9 for ; Wed, 13 Dec 2006 05:52:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE76F14224D for ; Wed, 13 Dec 2006 05:52:24 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16880-09 for ; Wed, 13 Dec 2006 05:52:23 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6030C14224B for ; Wed, 13 Dec 2006 05:52:23 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 13 Dec 2006 05:52:23 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBDDqNO4015939 for ; Wed, 13 Dec 2006 05:52:23 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBDDqMio006325 for ; Wed, 13 Dec 2006 05:52:22 -0800 (PST) Received: from [212.254.247.6] ([10.61.65.119]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kBDDar5e023471 for ; Wed, 13 Dec 2006 05:36:54 -0800 Message-ID: <45800594.4000807@cisco.com> Date: Wed, 13 Dec 2006 14:52:20 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1548; t=1166017943; x=1166881943; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20summary=20of=20issues=20discussed=20in=20the=20jabber=20sessi on |Sender:=20; bh=gQ1bwbo7k5QBo9QQRPXLAXpFUqMFhWYovQPzKeogOVQ=; b=bPe4s/kvaIWktYMdIJuLrrdvEg8bO+Y9J+SgHr5D22HZp4jzkUK8qPc6SiXhqbTFsSWNzZfr 3i8zMJVr7gpInsHOr4CZftxg19L8motCso21HknumIUvqY6xgAMpqDs/; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1548; t=1166017015; x=1166881015; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20summary=20of=20issues=20discussed=20in=20the=20jabber=20sessi on |Sender:=20 |To:=20=22ietf-calsify@osafoundation.org=22=20; bh=gQ1bwbo7k5QBo9QQRPXLAXpFUqMFhWYovQPzKeogOVQ=; b=C5h/heUScxW1J+lm/R0DsnRTvlegTVD4VfTYC89nUivZY2M3QID1y4BazxAvZEh3u6M5/gcA c+uI3p2BDKyutkeb8sBRiZ22DGByhtGLXatnGSJYuwKSMjgm5RzhC4Er; Authentication-Results: sj-dkim-1; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] summary of issues discussed in the jabber session X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 13:52:25 -0000 Dear all, Here is a summary of each of the issues we've discussed in the last two jabber sessions. It is the chairs' intent that we not have another jabber session until after the 1st of the year, due to holidays. The chairs further wish the participants an enjoyable holiday and a happy New Year. As to the Issues, here they are: Issue Number Brief Description Resolution -------------------------------------------------------------------------- 19 IANA Considerations Eliot to propose text. 27 How long is a day? No resolution yet. This has to do with DST transitions. 36 Section 4.1 use of X-Name Consensus to drop "bilateral" and encourage use of IANA and to add some BCP text. 42 4.6.6 Alarm component restrict. Consensus: remove restriction. 47 4.8.6.3 trigger relative to DATE Prefer configured timezone. Fall back to UTC. 55 Remove SECONDLY, MINUTELY, Nuke BYSEC and SECONDLY. BYSEC and BYMIN Also nuke MINUTELY. This leaves open the question of BYMINUTE. More issue resolutions to follow after the end of the year. Cheers, Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A9E047F67D for ; Tue, 12 Dec 2006 07:47:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A85514225D for ; Tue, 12 Dec 2006 07:47:53 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01041-03 for ; Tue, 12 Dec 2006 07:47:52 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C5EA14225B for ; Tue, 12 Dec 2006 07:47:52 -0800 (PST) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 12 Dec 2006 07:47:52 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBCFlqVV015833 for ; Tue, 12 Dec 2006 07:47:52 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBCFlpOV015877 for ; Tue, 12 Dec 2006 07:47:51 -0800 (PST) Received: from [212.254.247.6] ([10.61.81.111]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kBCFWNRa003394 for ; Tue, 12 Dec 2006 07:32:26 -0800 Message-ID: <457ECF22.4060409@cisco.com> Date: Tue, 12 Dec 2006 16:47:46 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=50; t=1165938472; x=1166802472; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20reminder=3A=20jabber=20session=20in=2015=20minutes! |Sender:=20; bh=93PmPM9DKuts4IsGPxF48a8Vz9tTxEPkWeDOSSHxbmE=; b=OEXMZJTU/xzdzPrW03mWGF4TP5wzulKP6H3uVWNL8YDR4dV5UVK3oFh3GroxSIeeM/1dQYRI Jp8Cy9nV8DO08rlwareAlbzjbV+tphQECz5AXyQjIpy5vSn5fd+j1IIJ; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=51; t=1165937546; x=1166801546; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20reminder=3A=20jabber=20session=20in=2015=20minutes! |Sender:=20 |To:=20=22ietf-calsify@osafoundation.org=22=20; bh=+CUo/m+PWu46Zq7uc1ijZFk3aSYLaaWBcx19NcB5yPA=; b=WfUlx8h3BgevvwvqexYjA7awsI5m93oKsTSldRlP9j6tf6MYVO2FvVuvQE9TMMPhXAQF9uue PorzsWM1zuEafNlbpSfOlhnNkJ7aVTCtkRQEL7vW1P6FJZGHrilXNn+3; Authentication-Results: sj-dkim-8; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] reminder: jabber session in 15 minutes! X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 15:47:53 -0000 calsify@jabber.ietf.org. See you there! Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 67EA17F673 for ; Mon, 11 Dec 2006 08:46:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5984D142246 for ; Mon, 11 Dec 2006 08:46:34 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06707-08 for ; Mon, 11 Dec 2006 08:46:33 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id 033C2142250 for ; Mon, 11 Dec 2006 08:46:32 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 11 Dec 2006 08:46:30 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBBGkUZr025116 for ; Mon, 11 Dec 2006 08:46:30 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBBGkUin013843 for ; Mon, 11 Dec 2006 08:46:30 -0800 (PST) Received: from [212.254.247.5] ([10.61.81.182]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kBBGV84R013597 for ; Mon, 11 Dec 2006 08:31:09 -0800 Message-ID: <457D8B63.7040105@cisco.com> Date: Mon, 11 Dec 2006 17:46:27 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=286; t=1165855590; x=1166719590; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20continuing=20our=20jabber=20session |Sender:=20; bh=iDpyiyvsMIDd2C7DMNt1SB5KKeHyszI2LC1SZHEXG9U=; b=Y/WRYLeZqMwKS4w+YwgYHwjhjic/h3zF7wFBCT7adF5bCWYo4knLco95ze/0hSAQGX0yPDoi RUKaMb2kLSnwPP5m1msgG0h0qt4+z64vzGc+ubmvRk8dln4NkRCTtWnT; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=286; t=1165854669; x=1166718669; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20continuing=20our=20jabber=20session |Sender:=20 |To:=20=22ietf-calsify@osafoundation.org=22=20; bh=iDpyiyvsMIDd2C7DMNt1SB5KKeHyszI2LC1SZHEXG9U=; b=agBs+ExgqhrznihZsyIju7O760Ed+SzJhEtul8KaJCcIQeknx43yoLa5NRzlPMuYahufphGV H/RHOXBCwHSOQJ9uLjjFCWUfeoGIEEiOvxOo2zg2Edpc4Iweso6E/yHX; Authentication-Results: sj-dkim-4; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] continuing our jabber session X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2006 16:46:34 -0000 Our last jabber session was held on Thursday. You can review the log here . We agreed to continue our jabber conversation tomorrow at 8:00am PST / 4:00pm UTC. Looking forward to seeing you on the chat! Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4EB4B8072B for ; Fri, 8 Dec 2006 01:58:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4004F142266 for ; Fri, 8 Dec 2006 01:58:40 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32474-02 for ; Fri, 8 Dec 2006 01:58:36 -0800 (PST) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 97C92142262 for ; Fri, 8 Dec 2006 01:58:35 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB89vUD1027105 for ; Fri, 8 Dec 2006 11:58:12 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 11:58:06 +0200 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 11:58:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Dec 2006 11:58:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for IETF67 posted Thread-Index: Accar1q+Oamis0+dQoSihsxzxwbPKA== From: To: X-OriginalArrivalTime: 08 Dec 2006 09:58:06.0191 (UTC) FILETIME=[5B9C2FF0:01C71AAF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061208115812-68BEFBB0-7C90E0F2/0-0/0-0 X-Nokia-AV: Clean X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, NO_REAL_NAME X-Spam-Level: Subject: [Ietf-calsify] Draft minutes for IETF67 posted X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 09:58:40 -0000 All, We've posted the draft minutes to the proceedings: http://www3.ietf.org/proceedings/06nov/minutes/calsify.txt If you have comments, please send them to the list or to the chairs. Cheers, Aki Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 07BE18067B for ; Thu, 7 Dec 2006 07:46:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA736142255 for ; Thu, 7 Dec 2006 07:46:19 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21407-02 for ; Thu, 7 Dec 2006 07:46:17 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id A93ED142253 for ; Thu, 7 Dec 2006 07:46:17 -0800 (PST) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2006 07:46:16 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kB7FkGi9017919 for ; Thu, 7 Dec 2006 07:46:16 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB7Fk8io013232 for ; Thu, 7 Dec 2006 07:46:14 -0800 (PST) Received: from [10.100.0.100] ([10.61.65.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kB7FV2CP007082 for ; Thu, 7 Dec 2006 07:31:03 -0800 Message-ID: <4578373F.1040903@cisco.com> Date: Thu, 07 Dec 2006 15:46:07 +0000 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15; t=1165506376; x=1166370376; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20jabber=20session=20in=2015=20minutes |Sender:=20; bh=iCWMmEMTcT9BeYFvWjuzso8pPTM0XLLuAKmcZrBrC+E=; b=jYovRAx5aCNvEvglBGUVKtRI0VLUTc8rZW8Iv5JQ1KH+1Vfnnji2fVJgXXTOXCmJpWYpeLaw lxosxZnO5BMW0pTVBZIZnMXNVHoB9+AQXEMsTpc2ts8iDlwh28ZfIVOS; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15; t=1165505463; x=1166369463; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20jabber=20session=20in=2015=20minutes |Sender:=20 |To:=20=22ietf-calsify@osafoundation.org=22=20; bh=iCWMmEMTcT9BeYFvWjuzso8pPTM0XLLuAKmcZrBrC+E=; b=mjcZRFbfpzkoeIzxthkBotNxrdTXeP51nLQJnllWhSfifhk2U+8t6l9HApmeaQ73KTgvbcLt c6jeBbCcPcD8lV4u8x43wc6+HK9WDaPoss/l4RvxindFCcEB9QaEfDUB; Authentication-Results: sj-dkim-5; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, TO_ADDRESS_EQ_REAL X-Spam-Level: Subject: [Ietf-calsify] jabber session in 15 minutes X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2006 15:46:20 -0000 See you then!