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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kolab-format
Subject:    KEP 3 (2010-11-18): Introduction of 'subevent' sub-tag for
From:       "Georg C. F. Greve" <greve () kolabsys ! com>
Date:       2010-11-18 9:29:11
Message-ID: 201011181029.12358.greve () kolabsys ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]

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@kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve

["KEP-3.txt" (text/plain)]

KEP: 3
Title: Introduction of 'subevent' sub-tag for 'exclusion' from 'recurrence'
Version: $Revision$
Last-Modified: $Date$
Author: Georg Greve <greve@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:

["KEP-3.pdf" (application/pdf)]
["signature.asc" (application/pgp-signature)]

_______________________________________________
Kolab-format mailing list
Kolab-format@kolab.org
https://kolab.org/mailman/listinfo/kolab-format

[prev in list] [next in list] [prev in thread] [next in thread] 