Questions regarding details of recurrence rules

Hi Guys,
I already sent this to ietf-calendar, but didn't get any definitive response
so far. It may be a bit off-topic here, but I'm still hoping for an answer
that helps me getting RFC 2445-RRULEs completely correct. For the most part,
the RFC is clear to me, but there are some details that are not clear. I
encountered them when I tested my new recurrence implementation which tries
to implement every aspect of rrules, exrules, rdates and exdates.
The examples below sometimes might look like nitpicking, but I deliberately
designed them to make little details of the RFC clear.
These issues might be a language problem on my side, or an unclear wording in
the RFC. In any case, I'd like to know how the RFC really meant those things
to work.
1) About the BYDAY rule part: Let's start with some examples
RRULE:FREQ=YEARLY;BYDAY=3SU
Okay, that's the third sunday of the year. But what exactly is
RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
Is this the fith sunday in the year, if it is also in february? Or is it the
fifth sunday in february? And it can be even less clear from rfc 2445. What
is
RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2,7
Is this the fifth sunday of the year, if it's in either February or July?
Or is it the fifth sunday of both february and July?
Or is it the fifth sunday of febrary and july together (i.e. in feb if the
feb in a leap year has 5 sundays, or the first sunday of july in all other
years)?

Dear Folks,
This is a followup reminder to my e-mail of May 24th requesting assistance in responding to a Calconnect questionnaire on Timezones. Our original target date for responses was June 10th. We're received several responses but hope that with a little more time others will be able to help us. If you've not responded but have a calendaring implementation, we would appreciate it very much if you could take a few minutes to respond to our questionnaire.
We've extended the target date another week to Monday, June 20th -- and so you don't have to rummage around and find my previous e-mail, the questionniare (which is in e-mail format so you can fill it out and e-mail it back) is included below.
Thank you very much for your help.
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 <at> calconnect.org
------------------------------------------------------------------------------------------
Questionnaire on Timezones in iCalendar
Introduction:
This questionnaire is being used to determine support for iCalendar
(RFC2445) timezone support. The specific sections in RFC2445 that
are being queried are:
4.6.5 Time Zone Component
4.8.2.4 Date/Time Start
4.8.3 Time Zone Component Properties
( and sub-sections )
4.8.5.3 Recurrence Date/Times
4.8.5.4 Recurrence Rule
4.8.7.3 Last Modified
4.8.8.1 Non-standard Properties
These may involve reference to other sections.
How to answer:
Please copy the text from the '-------' divider below to the end of
this message into a new message and address it to:
<mailto:questionnaire <at> calconnect.org>
To fill it out:
For 'y/n/o':
'y' means yes
'n' means no
'o' means other or not applicable
Delete two letters to leave the one for your answer.
If you have specific comments you can add about your answers,
please do so at the end and reference the question number to which
the comment applies.
For _____________________: enter text for the answer.
-------
Product Details:
P1: Product/Implementation Name:
_____________________
Components supported:
Consume Produce
Q1: VTIMEZONE y/n/o y/n/o
Q1.1: STANDARD y/n/o y/n/o
Q1.2: DAYLIGHT y/n/o y/n/o
Properties supported:
In VTIMEZONE
Consume Produce
Q2.1: TZID y/n/o y/n/o
Q2.2: LAST-MODIFIED y/n/o y/n/o
Q2.3: TZURL y/n/o y/n/o
Q2.4: XPROP y/n/o y/n/o
In STANDARD
Consume Produce
Q3.1: DTSTART y/n/o y/n/o
Q3.2: TZOFFSETTO y/n/o y/n/o
Q3.3: TZOFFSETFROM y/n/o y/n/o
Q3.4: COMMENT y/n/o y/n/o
Q3.5: RDATE y/n/o y/n/o
Q3.6: RRULE y/n/o y/n/o
Q3.7: TZNAME y/n/o y/n/o
Q3.8: XPROP y/n/o y/n/o
In DAYLIGHT
Consume Produce
Q4.1: DTSTART y/n/o y/n/o
Q4.2: TZOFFSETTO y/n/o y/n/o
Q4.3: TZOFFSETFROM y/n/o y/n/o
Q4.4: COMMENT y/n/o y/n/o
Q4.5: RDATE y/n/o y/n/o
Q4.6: RRULE y/n/o y/n/o
Q4.7: TZNAME y/n/o y/n/o
Q4.8: XPROP y/n/o y/n/o
General:
Q5: Do you always send DATE-TIME
values with a timezone? y/n/o
Q6: Do you always send DATE-TIME
values in UTC or floating? y/n/o
Q7: Do you provide a standard
set of timezones built-in
to your product? y/n/o
if yes to Q7, then
{
Q8: Where did you get your
timezone definitions?
_____________________
Q9: How many timezone
definitions do you have?
_____________________
Q10: Do you have a special
naming scheme for TZIDs,
and if so what is it?
_____________________
Q11: Do you provide a mechanism
for updating built-in
timezones? y/n/o
if yes to Q11, then
{
Q12: Do you adjust future
times to account for
timezone definition
changes? y/n/o
}
}
Q13: Do you accept and use
timezone definitions from
imported iCalendar data? y/n/o
if yes to Q13, then
{
Q14: Do you attempt to merge
timezone definitions with the
same TZID when importing
iCalendar data? y/n/o
}
Q15: When exporting timezones in
iCalendar data (either to a file
or via iTIP) do you send the entire
timezone definition or just the
set of dates needed for coverage
of the event?
_____________________
Q16: Would you use timezone
definitions from a standard
timezone registry if one
were created? y/n/o
Q17: What problems would be
involved in changing a
timezone definition if DST
was changed at some point
in the future?
_____________________
C1: Comments on specific answers (include Q number for cross-reference
to original question):
_____________________
C2: Comments on the format and ease of use of this questionnaire:
_____________________
C3: Are there any additional questions we should be asking, and if
so what are they?
_____________________

VERSION value in iCal-Basic

Doug Royer <Doug <at> Royer.com>
2005-06-19 04:10:51 GMT

It is by belief that iCal-Basic is compatible to implementations.
That is the changes are clarifying existing components, properties,
and parameters and reduces the number of them.
I believe that it is possible for an RFC-2445 implementation
to have generated an iCal-Basic object (except new properties
which it would ignore per 2445).
So, I am proposing that iCal-Basic have a VERSION value
of:
VERSION:2.0;2.1
Specifying that it is newer (2.1) and can be read by existing (2.0)
parsers and implementations.
There is no change to the 2445 VERSION property needed to support this
value. The existing 2445 VERSION property supports a range
of VERSION property values.
--
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
We Do Standards - You Need Standards

Re: VERSION value in iCal-Basic

Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> It is by belief that iCal-Basic is compatible to implementations.
> That is the changes are clarifying existing components, properties,
> and parameters and reduces the number of them.
>
> I believe that it is possible for an RFC-2445 implementation
> to have generated an iCal-Basic object (except new properties
> which it would ignore per 2445).
>
> So, I am proposing that iCal-Basic have a VERSION value
> of:
>
> VERSION:2.0;2.1
>
> Specifying that it is newer (2.1) and can be read by existing (2.0)
> parsers and implementations.
>
> There is no change to the 2445 VERSION property needed to support this
> value. The existing 2445 VERSION property supports a range
> of VERSION property values.
And since calsify is about using only what is supported by most
implementations: How many implementations actually support this range? My
guess is approximately 0.
I wonder how implementations behave when they encounter such a VERSION? If
they accept it and parse it, then fine. But I suspect that there are
implementations out there that compare the version string with "2.0" and
produce an error message otherwise. This should not happen, of course.
At least libkcal (KDE's calendar library including support for iCalendar)
fails with such a VERSION...
Mozilla calendar seems to ignore the VERSION altogether (but hangs while
importing such a file, no idea what's the exact reason).
And Evolution also ignores the VERSION completely (i.e. if the version is
"4.0", evolution also imports it just fine... Which it shouldn't, I guess?)
So far, there was no other calendar version that tried to be compatible with
2445, so this was a working approach, but with calsify things change...
Reinhold
--
--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
* K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer

Re: VERSION value in iCal-Basic

Doug Royer <Doug <at> royer.com>
2005-06-19 19:43:22 GMT

After looking into it, Mozilla uses libical.
So filed bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=298177
Reinhold Kainhofer wrote:
> Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
>
>>It is by belief that iCal-Basic is compatible to implementations.
>>That is the changes are clarifying existing components, properties,
>>and parameters and reduces the number of them.
>>
>>I believe that it is possible for an RFC-2445 implementation
>>to have generated an iCal-Basic object (except new properties
>>which it would ignore per 2445).
>>
>>So, I am proposing that iCal-Basic have a VERSION value
>>of:
>>
>> VERSION:2.0;2.1
>>
>>Specifying that it is newer (2.1) and can be read by existing (2.0)
>>parsers and implementations.
>>
>>There is no change to the 2445 VERSION property needed to support this
>>value. The existing 2445 VERSION property supports a range
>>of VERSION property values.
>
>
> And since calsify is about using only what is supported by most
> implementations: How many implementations actually support this range? My
> guess is approximately 0.
> I wonder how implementations behave when they encounter such a VERSION? If
> they accept it and parse it, then fine. But I suspect that there are
> implementations out there that compare the version string with "2.0" and
> produce an error message otherwise. This should not happen, of course.
>
> At least libkcal (KDE's calendar library including support for iCalendar)
> fails with such a VERSION...
> Mozilla calendar seems to ignore the VERSION altogether (but hangs while
> importing such a file, no idea what's the exact reason).
> And Evolution also ignores the VERSION completely (i.e. if the version is
> "4.0", evolution also imports it just fine... Which it shouldn't, I guess?)
>
> So far, there was no other calendar version that tried to be compatible with
> 2445, so this was a working approach, but with calsify things change...
>
> Reinhold
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify <at> osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify--
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
We Do Standards - You Need Standards

Re: VERSION value in iCal-Basic

Doug Royer <Doug <at> royer.com>
2005-06-19 19:25:39 GMT

Reinhold Kainhofer wrote:
> Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
>
>>It is by belief that iCal-Basic is compatible to implementations.
>>That is the changes are clarifying existing components, properties,
>>and parameters and reduces the number of them.
>>
>>I believe that it is possible for an RFC-2445 implementation
>>to have generated an iCal-Basic object (except new properties
>>which it would ignore per 2445).
>>
>>So, I am proposing that iCal-Basic have a VERSION value
>>of:
>>
>> VERSION:2.0;2.1
>>
>>Specifying that it is newer (2.1) and can be read by existing (2.0)
>>parsers and implementations.
>>
>>There is no change to the 2445 VERSION property needed to support this
>>value. The existing 2445 VERSION property supports a range
>>of VERSION property values.
>
>
> And since calsify is about using only what is supported by most
> implementations: How many implementations actually support this range? My
> guess is approximately 0.
By 'this range', do you mean the one that I am proposing as a new one?
> I wonder how implementations behave when they encounter such a VERSION? If
> they accept it and parse it, then fine. But I suspect that there are
> implementations out there that compare the version string with "2.0" and
> produce an error message otherwise. This should not happen, of course.
I do not think we have a choice. Mandating that we never use all of
the VERSION property value types simply because some did not do it
correctly will keep iCal from never being fixed.
For those that ignore it, it will not matter ether way.
For those that look at it and do not support CALSIFY,
it should not matter as they also support 2.0.
For those that support CALSIFY, they now know what to expect.
For those that crash or hang - well that was going to happen at
some point anyway in recent time as that was the entire purpose
of VERSION is to allow content type version control.
> At least libkcal (KDE's calendar library including support for iCalendar)
> fails with such a VERSION...
Libical is open source so that is easy to fix.
> Mozilla calendar seems to ignore the VERSION altogether (but hangs while
> importing such a file, no idea what's the exact reason).
> And Evolution also ignores the VERSION completely (i.e. if the version is
> "4.0", evolution also imports it just fine... Which it shouldn't, I guess?)
I follow the Mozilla development. It will also be an easy fix.
> So far, there was no other calendar version that tried to be compatible with
> 2445, so this was a working approach, but with calsify things change...
I think we agree. We need to start fixing things so that we have more
compatibility.
--
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
We Do Standards - You Need Standards

email alarms + description

Mike Douglass <douglm <at> rpi.edu>
2005-06-21 15:37:17 GMT

RFC 2445 states (4.6.6) that the description property is required for an
email alarm and will be used for the message body.
I'd prefer to see this as an optional property.
I'm implementing automatic mailing of (public) events to subscribed
users and I'll probably do so by setting alarms on the events.
An appropriate message body is probably a displayable form of the event,
with the actual event as an ics attachment.
I could populate all the alarm objects with the text form of the event
but that's a bit wasteful. In any case I'd like the user to be able to
signify the default mode by just leaving out the property.
The same could be said of the alarm summary. By default I'd fill it with
the event summary.
--
--
Mike Douglass douglm <at> rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies 518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180