[Ietf-calsify] Re: calsify and kcal

Reinhold Kainhofer reinhold at kainhofer.com
Sat Jun 3 16:57:08 PDT 2006

Hash: SHA1

Hello Eliot,

Am Samstag, 3. Juni 2006 17:46 schrieb Eliot Lear:
> My name is Eliot Lear and I am one of the co-chairs of the IETF calsify
> working group.  We are currently revising our charter and re-enlivening
> the group.  I see that you have done a lot of work on kcal, and I was
> wondering if you wanted to comment on shortcomings or interoperability
> issues you've found with RFCs 2445, 2446, and 2447.  We maintain an
> active list now, if you're not already on it.  It's
> ietf-calsify at osafoundation.org.
> Are you interested in participating?

Thanks a lot for the hint. I've been subscribed for about two years now, and I 
have mainly concerns about the recurrence rules (the examples are rather 
trivial, the border cases and cases that would need clarification are not 
included in the RFC). But also some other areas might/should be cleared.

- -) For example, the P1D vs. PT24H discussion (whether there is a difference, 
which of them should be deprecated/removed, etc). My stance is written in 
P1D means that the event ends exactly at the same (local) time the next day, 
even if that is only 23 hours or 25 hours later due to a DST shift, while 
P24H is always exactly 24 hours. Maybe an example highlighting these 
differences might help.

- -) But then we also have the problem what should happen if the end date of a 
DURATION: P1D event does not exist:

For RRULEs it's clear that the occurence (start tiem) simply doesn't happen 
(as it's "out of scope"), but here the start time exists, only the end time 

- -) For recurring events, nothing in the RFC 2445  tells you how to properly 
calculate the end date/time (see 
I suppose it should be start date/time of the occurrence plus the duration, 
calculated from the initial DTSTART and DTEND (or DURATION), right? RFC 2446 
has one sentence for VTODOS, but RFC 2445 doesn't even have that.
Now, the problem is, how do we calculate the duration of the initial DTSTART 
and DTEND? In particular, is there a way to express a daily recurrence rule 
that specifies an event that always starts at 01:00 and ends at 13:00 (both 
local time)? The problems again appear when DST shifts happen.

- -) Section 4.3.10 says:
   "If BYxxx rule part values are found which are beyond the available
   scope (ie, BYMONTHDAY=30 in February), they are simply ignored."

Here an example should be given (what the available scope is and what ignored 
means here). E.g.

  DTSTART;TZID=Europe/Vienna: 20050201T120000
results in occurrences on 1 Feb 2006, 30 May 2006, 30 Aug 2006, 30 Nov 2006, 
30 May 2006.
I.e. "they are simply ignored" means that the whole occurrence is ignored, not 
the rule part value (which would result in the day being taken from the 

- -) End date not inclusive: For date/times, the non-inclusive end date/time is 
clear, but for date-only events, most (all?) implementations understand the 
non-inclusive end date as the first day after the event. E.g. DTEND: 20060604 
means that the event goes on until June 3. The consensus was to clear this up 
in the RFC and define this as standard (although I suppose this will 
introduce some inconsistency somewhere. I thought about this a while back, 
but can't remember now).
Frank Dawson explained somewhere that it was actually intended to mean that 
the event's end is 20060604T23:59:59... But it seems no-one implemented it 
this way.

When I re-wrote the whole recurrence class for libkcal, I had several cases 
where the RFC should be made more clear, but I seem to have deleted my mails 
to calsify in my mail client. It's been on my to-do list for ages to write 
them down and send them again to calsify for consideration of the revised 
draft, but I haven't found the time for it yet. I think I sent them to 

Okay, I found some mails:

- -) The interaction between the BY* rule parts should be exemplified. I wrote 
several examples in 
I didn't give the answers there, but they now most seem pretty clear to me and 
they might help in understanding how the rrule parts are supposed to be 

If you think they are all trivial to answer, or not realistic cases, look at 
all VTIMEZONE definitions:

The whole thread contains lots of thoughts about how rrules are actually 
supposed to be evaluated, which is far from trivial as soon as multiple BY* 
parts are involved.

- -) In one of the cases above, I (or rather Sam Roberts) think the RFC has an 
error which resulted in all these "wrong"(?) VTIMEZONE definitions:

- -) RFC 2445 says in section 4.3.10 "The "DTSTART" property 
value, if specified, counts as the first occurrence.". The "if specified" in 
this context is supposed to mean "if it matches the BY* rules", or "if it 
would be generated as a recurrence date by the RRULE". 
It does not mean if it is specified (i.e. exists) in the VEVENT at all.

- -) section "Recurrence Rule" says 
"   The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
   property pair, specified within the iCalendar object defines the
   first instance of the recurrence. "

Here, "first instance of the recurrence" does NOT mean the recurrence 
generated by that particular RRULE, but it rather means the whole set of 
occurences of the event (which is calculated of the DTSTART + RRULE dates + 
RDATE - EXRULE dates - EXDATE). This is particularly important as otherwise 
an EXRULE would always exclude the original start date/time.

I also found a web page where it was described to include some paragraph in a 
possible rfc 2445 revision, but I can't find that page again.... 

- -- 
- ------------------------------------------------------------------
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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
Version: GnuPG v1.4.3 (GNU/Linux)


More information about the Ietf-calsify mailing list