Subject: [Ietf-calsify] What is the appropriate serialization for a recurring event with one event changed?

From: jeffrey at skyhouseconsulting.com (Jeffrey Harris)
Date: Mon Oct 3 16:41:30 2005

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

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5

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:

DTSTART;TZID=US/Pacific:20051003T090000
RRULE:FREQ=DAILY;COUNT=5
EXDATE:20051005T160000Z                #Wednesday at 9AM PDT (in UTC)

the other VEVENT has

RECURRENCE-ID:20051005T180000Z         #Wednesday at *11AM* PDT (in UTC)
DTSTART;TZID=US/Pacific:20051005T110000

Is one of these more correct than the other?  Is an EXDATE appropriate
for the original time if an event's time has been moved?  What does it
mean for a RECURRENCE-ID to reference a time that isn't already in the
recurrence set?

Sincerely,
Jeffrey

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Oct 4 00:24:29 2005

> DTSTART;TZID=US/Pacific:20051005T110000

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 
the occurrence.

> What does it 

That's the question... How shall clients interpret such VEVENTS?

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Oct 4 01:09:47 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051004/9cb34511/smime.bin

---

From: simon.vaillancourt at oracle.com (Simon Vaillancourt)
Date: Tue Oct 4 07:14:36 2005

Hello Jeffrey,
   This is a bug in our product where we don't add an RDATE to the main 
event (It's already on our todo list). You should have seen something like :

RDATE:20051005T180000Z

the other VEVENT has

As far as "Is an EXDATE appropriate for the original time if an event's 
time has been moved?".  Ideally, the meeting you store on a CalDAV 
server would remain unchanged when you retrieve it later on, but when 
plugging a CalDAV interface on top of an existing calendar store(Like we 
do at Oracle) it's a different story. For the Oracle product, we 1) 
Convert the iCalendar meeting to our internal format, 2)Do a diff of 
both meeting representations and send the detected changes to our 
calendar backend.  This conversion and diff process might explain the 
differences you see between the meeting you put in and the meeting you 
retrieve later on. I'm sure many would argue that "moving" a recurrence 
vs "deleting and creating" a recurrence is very different even if the 
expanded end result in a standard calendar UI is the same,  that's why 
we're still working on perfecting our diff and conversion algorithms.

Regards,
Simon

Jeffrey Harris wrote:

>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>  
>