KEP 3 (2010-11-18): Introduction of 'subevent' sub-tag for 'exclusion' from 'recurrence'

[Georg C. F. Greve]

Hi all,

Jeroen is already working on trying to put together some proposed tooling and 
process parameters for the KEP process. Until that is in place, I'll work with 
the date of the draft in the subject line to allow us to keep track of the 
draft.

This revision already includes the Recurrence ID brought up by Sergio to 
address the iTIP handling. It also includes lists of illegal and mandatory 
fields the subevent MUST or MUST NOT define, which Jeroen raised.

Sergio: Do you think this works?

Jeroen: Is this what you had in mind? 

ALL: Opinions about the changes, and the field lists?

Open question: This is still based on the deep nesting, which Bernhard pointed 
out some older clients might mangle despite what the format spec says.

There are fundamentally two options here:

 (a) IGNORE the problem: Newer clients will necessarily write recurrences in 
ways which older clients won't understand, so older clients won't ever be able 
to understand them, so only old or new clients should ever be used on any data 
set.

 (b) UNNEST the structure: This will separate the exclusion date (a.k.a. 
Recurrence ID) from the subevent, which could then hold a mandatory Recurrence 
ID tag to allow finding it again. This is less elegant and puts a higher burden 
on the clients which for instance need to ensure to not leave around orphaned 
subevents and such.

Are there opinions on these choices?

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
KEP: 3
Title: Introduction of 'subevent' sub-tag for 'exclusion' from 'recurrence'
Version: $Revision$
Last-Modified: $Date$
Author: Georg Greve <greve at kolabsys.com>
Status: Draft
Type: Design
Content-Type: text/x-rst
Created: 2010-11-17

Abstract
========

The Kolab storage format models allows recurrence to have 'non-occurence' exceptions already, but it does not allow to have 'modification' exceptions, e.g. change of time or location. The way this has been handled is to create a 'non-occurence' exception, and then create a separate event for that day with the default values of the recurring event.

This has been understood as a suboptimal solution for a long time because the clients cannot easily connect that new event with the recurring event for future modifications, while the user logically sees them as connected.

The solution is to introduce a hierarchically nested 'subevent' sub-tag for an exception, which takes all default values from the recurring event itself, and only contains the differences to these default values. [1]

Update to the XML Format
========================

The type for datetime storage in Kolab XML is modified as follows:

* Clients **MUST** treat the date of the 'exclusion' as the Recurrence ID [2] where applicable, in particular iTIP [3] handling.
* A 'subevent' XML tag **MAY** be added hierarchically nested within an 'exclusion' to a 'recurrence' of an 'event' object.
* There **MUST** be only one 'subevent' per 'exclusion.
* All event values of the 'subevent' default to the 'event' within which it is nested. Values within 'subevent' change these values for this 'exception' from the 'recurrence' only.
* Fields for 'event' that 'subevent' **MUST NOT** use/override are: *'uid'* and *'recurrence'*
* Fields that 'subevent' **MUST** define are: *'creation-date'* and *'last-modification-date'*

Example
-------

Moving one instance of a recurring event from date1, a normal date in the recurrence cycle, to new-date1 would express itself as follows

  <event>
  ...

    <recurrence>
    ...

      <exclusion>date1

        <subevent>

          <start-date>new-date1</start-date>

        </subevent>

      </exclusion>

    </recurrence>

  </event>


Upgrade Path
============

When this KEP becomes active, the version number of the Kolab Storage Format specification will be updated to 2.1.

New clients that correspond to 2.1 will be fully compatible with older data sets.

Older clients can continue to behave as before at their own choice, and will remain consistent with the 2.0 specification and no data will be lost or corrupted. So whilst this is important, it is not urgent. Older clients will however not be able to display recurrence exceptions of newer clients properly, so it is highly recommended to move to the newer 2.1 format when feasible.

References
==========

.. [1] event XML 1.1 (fix recurrances), Konold
   (http://kolab.org/pipermail/kolab-format/2008-December/000876.html)

.. [2] RFC2445: Internet Calendaring and Scheduling Core Object Specification, 4.8.4.4 Recurrence ID
   (http://www.ietf.org/rfc/rfc2445.txt)

.. [3] RFC2446: iCalendar Transport-Independent Interoperability Protocol (iTIP)
   (http://www.ietf.org/rfc/rfc2446.txt)


Copyright
=========

This document has been placed in the public domain.

..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KEP-3.pdf
Type: application/pdf
Size: 15100 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20101118/cb9d3cc4/attachment.pdf>
-------------- 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: <http://lists.kolab.org/pipermail/format/attachments/20101118/cb9d3cc4/attachment.sig>