summaryrefslogtreecommitdiff
path: root/KEP-0003.txt
diff options
context:
space:
mode:
authorGeorg Greve <greve@kolabsys.com>2011-05-31 16:59:07 (GMT)
committerGeorg Greve <greve@kolabsys.com>2011-05-31 16:59:07 (GMT)
commite4cfc96de2bc13a3dfd12b30d67334a4a42d9e35 (patch)
treec84754473d2fb7093cef86ccf70d075c83053a11 /KEP-0003.txt
parentd65b0bed2223acd8ac53db624d14d978f123e1fb (diff)
downloadkeps-e4cfc96de2bc13a3dfd12b30d67334a4a42d9e35.tar.gz
Included feedback from http://kolab.org/pipermail/kolab-format/2011-May/001348.html and some smaller stylistic things.
Diffstat (limited to 'KEP-0003.txt')
-rw-r--r--KEP-0003.txt22
1 files changed, 13 insertions, 9 deletions
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 ==