Thread 2: On recurrence exceptions

Georg C. F. Greve greve at
Wed Nov 3 10:43:07 CET 2010

Hi all,

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 
unreferenced attachment."

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.

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at
t: +41 78 904 43 33

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list