[Ietf-calsify] Re: calsify and kcal
reinhold at kainhofer.com
Sat Jun 3 16:57:08 PDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
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.
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
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 188.8.131.52 "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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Ietf-calsify