Subject: [Ietf-calsify] Period values in RDATEs

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Thu Dec 21 10:23:08 2006

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 (Cyrus Daboo)
Date: Thu Dec 21 12:53:10 2006

Hi Jeffrey,

> 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: 
<http://trac.macosforge.org/projects/calendarserver/ticket/20>.

-- 
Cyrus Daboo

Date: Thu, 21 Dec 2006 12:51:59 -0800
From: Cyrus Daboo <[email-masked]>
To: Jeffrey Harris <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Period values in RDATEs

Hi Jeffrey,

> 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: 
<http://trac.macosforge.org/projects/calendarserver/ticket/20>.

-- 
Cyrus Daboo

Date: Thu, 21 Dec 2006 10:22:10 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Period values in RDATEs

Hi Folks,

Sincerely,
Jeffrey

Date: Mon, 18 Dec 2006 08:29:09 -0800
From: "David C. Thewlis" <[email-masked]>
Organization: DCTA Inc.
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] CalConnect Roundtable VIII and Interoperabilty Testing Event January 29-February 2, 2007 - Announcement and Registration Open
Reply-To: [email-masked], [email-masked]

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 � [email-masked] 
<mailto:[email-masked]>

--------------060407050804010702020501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
The IOP test event will run from noon Monday the 29th of January
through noon Wednesday the 31st.<br>
<br>
The Roundtable will begin with lunch at 1230 on Wednesday January 31st
and go to noon on Friday February 2nd.<br>
<br>
More information, logistics and registration information for both the
Roundtable and the IOP test event may be found on the CalConnect web
site at <a href="http://www.calconnect.org/roundtable8.html">http://www.calconnect.org/roundtable8.html</a>.&nbsp;
And feel free to call me (telephone numbers below) or e-mail me with
any questions or comments.<br>
<br>
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.<br>
<br>
This notice is being sent to multiple calendar-related lists; my
apologies if you receive this more than once.&nbsp; <br>
<br>
We look forward to welcoming you to Provo!<br>
<br>
Best regards,<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

--------------060407050804010702020501--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Date: Thu, 14 Dec 2006 08:54:35 -0800
To: Reinhold Kainhofer <[email-masked]>
Cc: [email-masked]

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

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Dec 14, 2006, =
at 2:38 AM, Reinhold Kainhofer wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><P style=3D"margin: 0.0px 0.0px 0.0px 10.0px; font: 12.0px =
Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">RFC2445 won't go away,<SPAN =
class=3D"Apple-converted-space">=A0</SPAN></FONT></P> </BLOCKQUOTE><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; =
min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Sure, it will still be rfc 2445, but it will be marked as =
deprecated and<SPAN class=3D"Apple-converted-space">=A0</SPAN></FONT></P> =
<P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">superseded by 2445bis, which =
does no longer allow these recurrences, right?</FONT></P> =
</BLOCKQUOTE></DIV><BR><DIV>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.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Another option is to move =
the "extended recurrence rules" features to a separate section with =
health warnings and a discussion of applicability.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>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:</DIV><DIV><SPAN =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</SPAN>- 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</DIV><DIV><SPAN class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</SPAN>- 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"?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV></BODY></HTML>=

--Apple-Mail-1-976997732--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: "Tim Hare" <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Date: Thu, 14 Dec 2006 15:28:11 +0100
Cc: CALSIFY Mailinglist <[email-masked]>

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: [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: "Chris Bryant" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Date: Thu, 14 Dec 2006 08:50:44 -0500
Organization: USA.NET
Z-USANET-MsgId: XID262kLNNYv0318X36

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

>
> 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  <[email-masked]> 
>>> 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                           [email-masked]
>> 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
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>
> 

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Date: Thu, 14 Dec 2006 11:38:58 +0100

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: [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: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Date: Wed, 13 Dec 2006 20:14:55 -0800
To: Mike Douglass <[email-masked]>
Cc: [email-masked]

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  
>> <[email-masked]> 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                           [email-masked]
> 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Wed, 13 Dec 2006 13:58:43 -0500
From: Mike Douglass <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Cc: [email-masked]

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:
>
>> 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                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Wed, 13 Dec 2006 13:24:43 -0500
From: Cyrus Daboo <[email-masked]>
To: Mike Douglass <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Cc: [email-masked]

Hi Mike,

--On December 13, 2006 10:54:49 AM -0500 Mike Douglass <[email-masked]> 
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

Date: Wed, 13 Dec 2006 16:58:57 +0100
From: Eliot Lear <[email-masked]>
To: Mike Douglass <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Cc: [email-masked]

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

Date: Wed, 13 Dec 2006 10:54:49 -0500
From: Mike Douglass <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Cc: [email-masked]

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: [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/
> -----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

Date: Wed, 13 Dec 2006 09:34:49 -0500
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session

Hi Reinhold,

--On December 13, 2006 3:26:52 PM +0100 Reinhold Kainhofer 
<[email-masked]> 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

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, [email-masked], , 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
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Date: Wed, 13 Dec 2006 14:27:50 -0000
Cc: [email-masked]
Subject: [Ietf-calsify] Inconsistent BNF for "the following is optional and may occur more than once"

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

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] summary of issues discussed in the jabber session
Date: Wed, 13 Dec 2006 15:26:52 +0100

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/

Date: Wed, 13 Dec 2006 14:52:20 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] summary of issues discussed in the jabber session

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

Date: Tue, 12 Dec 2006 16:47:46 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder: jabber session in 15 minutes!

[email-masked].  See you there!

Eliot

Date: Mon, 11 Dec 2006 17:46:27 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] continuing our jabber session

Our last jabber session was held on Thursday.  You can review the log 
here <http://www3.ietf.org/meetings/ietf-logs/calsify/2006-12-07.html>.  
We agreed to continue our jabber conversation tomorrow at 8:00am PST / 
4:00pm UTC.  Looking forward to seeing you on the chat!

Eliot

Content-class: urn:content-classes:message
Date: Fri, 8 Dec 2006 11:58:04 +0200
From: <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] Draft minutes for IETF67 posted

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

Date: Thu, 07 Dec 2006 15:46:07 +0000
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber session in 15 minutes

See you then!