KEP-0009.txt

[Georg Greve]

 KEP-0009.txt |   84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

New commits:
commit 265427ffcb2fb0f19b86b7732c076eaa8f5b395c
Author: Georg Greve <greve at kolabsys.com>
Date:   Tue Jul 5 19:45:37 2011 +0200

    First draft, still lots of work to do

diff --git a/KEP-0009.txt b/KEP-0009.txt
new file mode 100644
index 0000000..da79d78
--- /dev/null
+++ b/KEP-0009.txt
@@ -0,0 +1,84 @@
+{{kep
+ |number=9
+ |ticketnumber=
+ |title=Storage of configuration information, new folder- and object type
+ |author=Georg Greve
+ |author_email=greve at kolabsys.com
+ |status=draft
+ |type=design
+ |creation_date=
+ |obsoleted_by=
+ |related=
+}}
+
+
+== Abstract ==
+
+This Kolab Enhancement Proposal (KEP) <ref name"kep">[[KEP:1]] Bootstrapping the KEP process</ref> defines part of a changeset applied against Kolab XML version 1.0 of Kolab Format 2.0 to introduce a new folder-type 'configuration' as well as new object type 'configuration' for usage in all non-email folders. The purpose is to establish a mechanism that allows configuration information and application specific behaviour to be configured and coordinated across different Kolab clients to achieve more consistency in how Kolab clients represent user data.
+
+== Update to the XML Format ==
+
+The following changes to the Kolab Format are part of the changeset against Kolab XML version 1.0 as described by Kolab Format 2.0:
+
+===  /vendor/kolab/folder-type: 'configuration' ===
+
+* In addition to the existing <type>[.<subtype>] values for value.shared defined by Kolab Format 2.0, the /vendor/kolab/folder-type annotation '''MAY''' be set to 'configuration' or 'configuration.default';
+* There '''MUST NEVER''' be more than one folder per user with the subtype 'default';
+* A folder of type 'configuration' '''MUST''' only contain objects of Kolab XML object type 'configuration' (see below);
+* The subtype of the configuration folder-type for shared folders '''MUST NEVER''' be set to 'default';
+
+=== Kolab XML object type: 'configuration' ===
+
+* The mimetype for 'configuration' type objects is 'application/x-vnd.kolab.configuration';
+* Common fields for 'configuration' type objects are 'uid', 'creation-date', 'last-modification-date', 'type';
+* The 'type' field '''SHALL''' define the type of configuration information stored in the object and the specific fields for the object;
+* The individual configuration object types '''SHALL''' be defined in individual KEP proposals;
+
+==== Example ====
+
+An example configuration object might look as follows, assuming that XML version 1.1 incorporates the changeset defined by this KEP and that the object version begins at 1.1 to track the corresponding other fields that have been modified by other KEPs as part of the same change set:
+
+ <?xml version="1.1" encoding="UTF-8"?>
+ <configuration version="1.1">
+   <!-- Common fields -->
+   <uid>(string, no default)</uid>
+   <creation-date>(datetime, no default)</creation-date>
+   <last-modification-date>(datetime, no default)</last-modification-date>
+   <type>(string, no default)</type>
+   
+   <!-- Type specific fields -->
+   ... type specific fields ...
+ </configuration>
+
+=== Client Behaviour: Parsing configuration data ===
+
+* Clients '''SHALL''' parse folders of folder-type 'configuration' starting from the least to the most significant folder, followed by parsing the applicable non-email folder for 'configuration' type objects;
+* Clients '''SHALL''' only follow the most significant value for any given configuration parameter, configuration values set by less significant sources '''SHALL''' be overridden by more significant sources;
+* The order of parsing beginning with the least significant category of folder '''SHALL''' be as follows:
+# Shared folder(s) with folder-type value.shared set to 'configuration';
+# Folder(s) of other users with folder-type value.shared set to 'configuration' or 'configuration.default';
+# Folder of current user with folder-type value.shared set to 'configuration.default';
+# Folder(s) of current user with folder-type value.shared set to 'configuration';
+# 'configuration' type objects for current folder '''NOT''' of folder-type 'email' or 'configuration';
+* If there is more than one folder in any of categories listed above, folders shall be parsed in alphabetical order traversing through the hierarchy as they appear in the IMAP folder tree according to {{rfc|3501}} <ref name="rfc3501">{{rfc|3501|title=INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1}}</ref> and its updates;
+* If there is more than one configuration object in any given folder of the same type affecting the same/overlapping configuration objects/values '''AND''' there is no other policy for treating this case defined in the particular configuration object definition, objects '''SHALL''' be interpreted in the order of their 'creation-date' from the oldest to the youngest configuration object.
+
+== Upgrade Path ==
+
+This KEP adds new functionality and folder types that will not be understood by older clients.
+
+{{note|Clarification possibility|Kolab Format 2.0 is not very explicit about how clients should treating folder and object types unknown to them, so substantial differences between clients are possible.}}
+
+== Rationale ==
+
+There have been repeated discussions about how and where to store configuration for application specific settings in the Kolab Groupware Solution. In some cases, these ended up in annotations themselves (e.g. Z-Push configuration <ref name"zpc">Z-Push Configuration Details: [[Z_push:Configuration]]</ref>) in other cases they ended up in LDAP (e.g. free/busy list generation interval). Either option has a variety of drawbacks, including lack of offline capability, difficulties to define ACLs on such configuration data, and the issues that LDAP schema extensions cause for integration into larger environments.
+
+While for the two examples above those were manageable with the respective approaches, they were prohibitive in other cases, such as storing color coding of categories for consistency across clients. A possible solution was suggested by Bernhard Reiter<ref name="ber">2010-08-27: Bernhard Reiter: [http://kolab.org/pipermail/kolab-format/2010-August/000919.html Where to store different configurations]</ref> during the discussion on where to store Z-Push configuration data and became the basis of this KEP.
+
+== References ==
+
+{{Reflist}}
+
+== Copyright ==
+
+This document has been placed in the public domain.