[Ietf-calsify] What is the appropriate serialization for a
recurring event with one event changed?
reinhold at kainhofer.com
Tue Oct 4 00:24:17 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
Am Dienstag, 4. Oktober 2005 01:41 schrieb Jeffrey Harris:
> Hi Folks,
> I've been working a bit with Oracle's CalDAV server and Apple's iCal,
> and they have pretty different behaviors when serializing a recurring
> event with a change to one event.
> Lets take, for example, a daily event, starting Monday at 9AM, last
> occurrence Friday at 9AM. If I change Wednesday's event to 11AM, what
> should the resulting stream look like?
> iCal exports this as two VEVENTs, one has (omitting lots of other lines):
> the other VEVENT has
> RECURRENCE-ID:20051005T160000Z #Wednesday at 9AM PDT (in UTC)
> DTSTART;TZID=US/Pacific:20051005T110000 #Wednesday at 11AM PDT
> Oracle's stream also has two VEVENTs:
> EXDATE:20051005T160000Z #Wednesday at 9AM PDT (in UTC)
> the other VEVENT has
> RECURRENCE-ID:20051005T180000Z #Wednesday at *11AM* PDT (in UTC)
I think that's wrong. This RECURRENCE-ID specifies the occurrence of the RRULE
that is changed by that VEVENT. Since Wed 11 AM PDT is not part of the
RRULE, I'm not sure how this should be interpreted by a client... Shall it
still occur? Or shall it simply be ignored because that RECURRENCE-ID does
not exist in the RRULE.
The correct way is iCal's way, where no EXDATE is necessary (since the
RECURRENCE-ID already says that that specific event on October 5 was changed
from 9AM to 11AM).
> Is one of these more correct than the other?
Yes, iCal's is correct, I think.
> Is an EXDATE appropriate
> for the original time if an event's time has been moved?
No, that's not needed, since RECURRENCE-ID should give the original time of
> What does it
> mean for a RECURRENCE-ID to reference a time that isn't already in the
> recurrence set?
That's the question... How shall clients interpret such VEVENTS?
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Ietf-calsify