Toltec connector and exceptions to recurring events

[Bernhard Reiter]

Hi Alan,

On Friday 27 May 2005 15:27, Alan J Collison wrote:
> Just so I'm clear, are you suggesting that the Toltec connector should
> be doing something different?  Or are you suggesting that the
> case I described is "rare" and so isn't a concern?

did some of the discussion and Martin's answer
shed more light on the issue for you?
As you can see there, the Kolab-format is not perfect yet,
but those recurrence rules are complicated.
Many humans just use the workaround to make simple
appointments or rules and deal with the shortcomings of 
the software in this way. This is what doesn't make this critical.

Bernhard

> Asking this in another way, suppose I need to import the following
> event generated by Apple's iCal and convert to a kolab data format:
>
> BEGIN:VEVENT
> DURATION:PT1H
> ATTENDEE;CN="Bubba Smith":mailto:bubba at collison.net
> LOCATION:My Office
> DTSTAMP:20050527T124609Z
> UID:263E7ABC-CEAD-11D9-96DB-000A959D1452
> SEQUENCE:4
> ORGANIZER;CN="Alan Collison":mailto:alan at collison.net
> STATUS:CONFIRMED
> DTSTART;TZID=US/Eastern:20050527T160000
> SUMMARY:Test Event
> DESCRIPTION:Test of recurring event.
> RRULE:FREQ=WEEKLY;INTERVAL=1
> END:VEVENT
> BEGIN:VEVENT
> DTSTART;TZID=US/Eastern:20050603T160000
> LOCATION:Boardroom
> UID:263E7ABC-CEAD-11D9-96DB-000A959D1452
> RECURRENCE-ID;TZID=US/Eastern:20050603T160000
> DURATION:PT1H
> END:VEVENT
>
> What should this event look like in kolab's data format?  Also, this
> example of an Outlook event (actually, it's an update notice to a recurring
> event indicating a change in location for a single instance):
>
> BEGIN:VCALENDAR
> METHOD:REQUEST
> PRODID:Microsoft CDO for Microsoft Exchange
> VERSION:2.0
> BEGIN:VTIMEZONE
> TZID:(GMT-07.00) Mountain Time (US & Canada)
> X-MICROSOFT-CDO-TZID:12
> BEGIN:STANDARD
> DTSTART:16010101T020000
> TZOFFSETFROM:-0600
> TZOFFSETTO:-0700
> RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
> END:STANDARD
> BEGIN:DAYLIGHT
> DTSTART:16010101T020000
> TZOFFSETFROM:-0700
> TZOFFSETTO:-0600
> RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU
> END:DAYLIGHT
> END:VTIMEZONE
> BEGIN:VEVENT
> DTSTAMP:20050502T210742Z
> DTSTART;TZID="(GMT-07.00) Mountain Time (US & Canada)":20050523T153000
> SUMMARY:Updated: Recurring event test step 1
> UID:040000008200E00074C5B7101A82E00800000000D026C9E61F4FC501000000000000000
>  01000000052C7EFF3B688FF4F95A3B5113FE6951C
> ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Collison,
>   Alan":MAILTO:alan at collison.net
> ORGANIZER;CN="Collison, Bubba":MAILTO:bubba at collison.net
> LOCATION:Your office
> DTEND;TZID="(GMT-07.00) Mountain Time (US & Canada)":20050523T160000
> DESCRIPTION:Moving location to "Your office" for one occurance on 5/23.
> RECURRENCE-ID;TZID="(GMT-07.00) Mountain Time (US & Canada)":20050523T15300
>  0
> SEQUENCE:0
> PRIORITY:5
> CLASS:
> CREATED:20050502T210743Z
> LAST-MODIFIED:20050502T210743Z
> STATUS:CONFIRMED
> TRANSP:OPAQUE
> X-MICROSOFT-CDO-BUSYSTATUS:FREE
> X-MICROSOFT-CDO-INSTTYPE:3
> X-MICROSOFT-CDO-INTENDEDSTATUS:FREE
> X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
> X-MICROSOFT-CDO-IMPORTANCE:1
> X-MICROSOFT-CDO-OWNERAPPTID:897734613
> BEGIN:VALARM
> ACTION:DISPLAY
> DESCRIPTION:REMINDER
> TRIGGER;RELATED=START:-PT00H15M00S
> END:VALARM
> END:VEVENT
> END:VCALENDAR
>
> What should the final kolab data for the origianl event + the update
> look like?
>
> Neither of these examples is a rare occurrence: changes in location, time,
> or some other detail of individual instances of a recurring event
> happen all the time.  So, what I'm trying to understand is how these
> cases are intended to be handled in kolab.
>
> If these cases can be handled in the kolab format, it's not clear to
> me how for all variations, particularly since only one 'recurrence' tag
> is allowed (even though the iCalendar RFC allows for multiple
> RRULE's). If they cannot be handled
> consistently, then that seems like a major compatiblity issue with
> existing calendar clients.  I'm hoping I just don't understand
> something about the kolab storage format :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/format/attachments/20050603/9f957420/attachment.p7s>