KEP-0003.txt

[Georg Greve]

 KEP-0003.txt |   22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

New commits:
commit e4cfc96de2bc13a3dfd12b30d67334a4a42d9e35
Author: Georg Greve <greve at kolabsys.com>
Date:   Tue May 31 18:59:07 2011 +0200

    Included feedback from http://kolab.org/pipermail/kolab-format/2011-May/001348.html and some smaller stylistic things.

diff --git a/KEP-0003.txt b/KEP-0003.txt
index eb382ca..0356593 100644
--- a/KEP-0003.txt
+++ b/KEP-0003.txt
@@ -22,18 +22,18 @@ The solution is to introduce a hierarchically nested 'subevent' sub-tag for an e
 
 == Update to the XML Format ==
 
-The following changes for recurrence storage in Kolab XML is part of the changest for version 1.1 of the 'event' object:
+The following changes for recurrence storage in Kolab XML are part of the changeset applied against version 1.0 of the 'event' and 'task' object types of Kolab Format 2.0:
 
-* Clients '''MUST''' treat the date of the 'exclusion' as the Recurrence ID<ref name="rfc2445">[[RFC:2445 | RFC2445: Internet Calendaring and Scheduling Core Object Specification, 4.8.4.4 Recurrence ID]]</ref> where applicable, in particular iTIP<ref name="rfc2446">[[RFC:2446 | RFC2446: iCalendar Transport-Independent Interoperability Protocol (iTIP)]]</ref> handling.
-* A 'subevent' XML tag '''MAY''' be added hierarchically nested within an 'exclusion' to a 'recurrence' of an 'event' object.
-* There '''MAY''' 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''' specify are: 'uid' and 'recurrence'
+* Clients '''MUST''' treat the date of the 'exclusion' as the Recurrence ID<ref name="rfc5545">[[RFC:5545 | RFC5545: Internet Calendaring and Scheduling Core Object Specification, 3.8.4.4 Recurrence ID]]</ref> where applicable, in particular iTIP<ref name="rfc5546">[[RFC:5546 | RFC5546: iCalendar Transport-Independent Interoperability Protocol (iTIP)]]</ref> handling;
+* A 'subevent' XML tag '''MAY''' be added hierarchically nested within an 'exclusion' to a 'recurrence' of an 'event' object;
+* There '''MAY''' 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''' specify 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
+Moving one instance of a recurring event from date1, a normal date in the recurrence cycle, to new-date1 with a recurrence exception created at 21:15:12 UTC on 1st of May 2011 and last modified at 23:12:51 UTC on 2nd of May 2011 would express itself as follows:
 
  <event>
  ...
@@ -42,6 +42,8 @@ Moving one instance of a recurring event from date1, a normal date in the recurr
      <exclusion>date1
        <subevent>
          <start-date>new-date1</start-date>
+         <creation-date>2011-05-01T21:15:12Z</creation-date>
+         <last-modification-date>2011-05-02T23:12:51Z</last-modification-date>
        </subevent>
      </exclusion>
    </recurrence>
@@ -50,9 +52,11 @@ Moving one instance of a recurring event from date1, a normal date in the recurr
 
 == Upgrade Path ==
 
-New clients that correspond to 'event' objects of version 1.1 will be fully compatible with older data sets.
+New clients that correspond to 'event' and 'task' objects of the Kolab Format after application of this KEP 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 1.0 version 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 format whenever feasible.
+Older clients can continue to behave as before at their own choice, and will remain consistent with the version 1.0 of the 'event' and 'task' object types in Kolab Format 2.0 and no data will be lost or corrupted. So whilst this is important, it is not urgent. 
+
+Older clients that do not implement the Kolab Format after application of this KEP will however not be able to display recurrence exceptions of newer clients properly, so it is '''STRONGLY''' recommended to move to the newer format as soon as possible.
 
 == References ==