Subject: [Ietf-calsify] summary of issues discussed in the jabber session

From: lear at cisco.com (Eliot Lear)
Date: Wed Dec 13 05:52:25 2006

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 (Reinhold Kainhofer)
Date: Wed Dec 13 06:27:08 2006

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: [email-masked], 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/

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Dec 13 06:35:03 2006

Hi Reinhold,

--On December 13, 2006 3:26:52 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

> 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 (Mike Douglass)
Date: Wed Dec 13 07:52:58 2006

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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFgA2wTqjEwhXvPN0RAizhAJ92rcHFGcj90XqZ4wrdDSrRS248VQCgsoVG
> QiX+0KyOPRweqSitvQNmglE=
> =3JLu
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>   

-- 

Mike Douglass                           [email-masked]
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 (Eliot Lear)
Date: Wed Dec 13 07:59:06 2006

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 (Cyrus Daboo)
Date: Wed Dec 13 10:25:03 2006

Hi Mike,

> Removal of these options just guarantees icalendar data will never be

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 (Mike Douglass)
Date: Wed Dec 13 10:56:57 2006

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 
> <[email-masked]> wrote:
>
> 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.
>

--

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Dec 13 20:15:03 2006

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

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Dec 14 02:39:24 2006

Am Donnerstag, 14. Dezember 2006 05:14 schrieb Lisa Dusseault:
> 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  
> 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 
> 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)

- --

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Thu Dec 14 05:50:55 2006

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" <[email-masked]>
To: "Mike Douglass" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 13, 2006 11:14 PM
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber 
session

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

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Thu Dec 14 08:54:42 2006

> superseded by 2445bis, which does no longer allow these  

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