Thread 2: On recurrence exceptions
Georg C. F. Greve
greve at kolabsys.com
Wed Nov 3 10:43:07 CET 2010
While we're discussing time issues, there is one more thing that is pending
resolution for some time now: Recurrence exceptions.
For those who no longer remember the discussion, or joined afterwards, like
me, here is a pointer to a mail with Martin's proposal and assessment at the
time, and pointers to the discussion that took place before:
Summarizing what I understood for those who do not care to dig into the past:
The proposal at the time was to introduce two new tags,
* <exclusion> - to model exceptions from recurrence
* <subevent> - to model single instance modifications
This is what the Kolab specification says about tags that are not understood:
"If a client sees a tag it does not understand, this tag must be preserved
and saved back to the file. This allows for client specific tags. Outlook
writes it client specific tags directly in a tnef file that is saved as an
So this approach would be backward compatible, and exceptions should this way
not be broken/stripped out by existing/older clients.
XML wise, it would look like this:
So the exclusion would "break" the chain, and if no subevent exists, this
instance is simply cancelled. Where a subevent exists, it models ONLY the
modification for this ONE instanc - and inherits everything else from the
This seems a sensible and robust solution to me, and perfectly in line with
the Kolab design, so I'd like to invite input as to issues this would not
resolve or even cause, as well as counter-proposals.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format