2 commits - KEP-0009.txt
Georg Greve
greve at kolabsys.com
Fri Jul 29 15:46:49 CEST 2011
KEP-0009.txt | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 64 insertions(+), 10 deletions(-)
New commits:
commit 5703c9e1825ba876dd1469dba7718007216d3058
Merge: aad0d0e... 952dd4f...
Author: Georg Greve <greve at kolabsys.com>
Date: Fri Jul 29 16:47:43 2011 +0300
Merge branch 'master' of ssh://git.kolabsys.com/git/keps
commit aad0d0ef17d8f85bf55bfdde3b38a3669d7b05f7
Author: Georg Greve <greve at kolabsys.com>
Date: Fri Jul 29 16:42:13 2011 +0300
Update based on http://kolab.org/pipermail/kolab-format/2011-July/001380.html http://kolab.org/pipermail/kolab-format/2011-July/001382.html and http://kolab.org/pipermail/kolab-format/2011-July/001383.html
diff --git a/KEP-0009.txt b/KEP-0009.txt
index da79d78..d1c3bcd 100644
--- a/KEP-0009.txt
+++ b/KEP-0009.txt
@@ -1,7 +1,7 @@
{{kep
|number=9
|ticketnumber=
- |title=Storage of configuration information, new folder- and object type
+ |title=Storage of configuration and application control information
|author=Georg Greve
|author_email=greve at kolabsys.com
|status=draft
@@ -14,27 +14,77 @@
== 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.
+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. In addition, this KEP clarifies and documents some of the existing mechanisms for storing configuration and application control information.
-== Update to the XML Format ==
+The mechanisms defined in this KEP include
+# ANNOTATE annotations, both private and shared (new)
+# ANNOTATEMORE annotations, both private and public (modified)
+# Configuration XML objects and specialised folders for their storage (new)
+
+Mechanisms not further defined in this KEP are those relying on the Directory Service, typically based on LDAP (see {{rfc|4511}} <ref name="rfc4511">{{rfc|4511|title=Lightweight Directory Access Protocol (LDAP): The Protocol}}</ref>). These mechanisms form part of the toolset available for storing configuration and application control information, but are so case specific that no overarching mechanisms can be usefully defined in this KEP.
+
+All four mechanisms of
+# ANNOTATE annotations, both private and shared
+# ANNOTATEMORE annotations, both private and public
+# Configuration XML objects and specialised folders for their storage
+# Directory Service information
+form part of the comprehensive toolset for storing configuration and application control information used by the Kolab Groupware Solution. Any configuration or application control use case is free to choose one or more of these mechanisms to define its particular scenario. It is explicitly foreseen that applications will mix these approaches as and where is appropriate and useful to achieve the most robust, flexible and comprehensive solution possible.
+
+== Configuration storage in message annotations ==
+
+This is a '''new''' mechanism:
+
+=== IMAP ANNOTATE RFC 5256 message annotations ===
+
+The Kolab Groupware Solution currently does not make use of message annotations according to {{rfc|5256}} <ref name="rfc5256">{{rfc|5256|title=Internet Message Access Protocol - ANNOTATE Extension}}</ref>, but it has been argued that in some cases such annotations would be the most efficient approach, e.g. single-message encryption and ACL scenarios of groupware items.
+
+As this mechanism is closely related on a conceptual level to the folder annotations according to RFC 5464 it shall inherit all the general rules for usage of RFC 5464 folder annotations defined below.
+
+== Configuration storage in folder annotations ==
+
+This is a '''modificaton and clarification of an existing''' mechanism:
+
+=== IMAP METADATA RFC 5464 folder annotations ===
+
+From its inception in 2003 and up until and including Kolab Format 2.0, the Kolab Groupware Solution has been using the <a href="http://tools.ietf.org/id/draft-daboo-imap-annotatemore-17.txt">ANNOTATEMORE proposal</a> which has been finalized in February 2009 into the IMAP METADATA Extension defined in {{rfc|4564}} <ref name="rfc4564">{{rfc|4564|title=The IMAP METADATA Extension}}</ref>.
+
+The Kolab Format that results from this changeset against the Kolab Format 2.0 will consider usage of the ANNOTATEMORE proposal deprecated and specify {{rfc|4564}} '''only'''.
+
+=== Public and private annotations ===
+
+RFC 4564 provides means for public and private annotations. Both kinds MAY be used in the Kolab Groupware Solution, but the same annotation name MUST only ever be used once for either a private or a public annotation.
+
+=== Values ===
+
+Simple values for both private and public annotations SHOULD be plain text whenever possible.
+
+Where array serialization or hashing is required because a value cannot be stored as plain text or contains illegal characters, values MUST be stored according to {{rfc|4627}}<ref name="rfc4627">{{rfc|4627|title=The application/json Media Type for JavaScript Object Notation (JSON)}}</ref>, the JavaScript Object Notation (JSON).
+
+No other encoding MUST be used.
+
+== Configuration storage in XML objects ==
+
+This is a '''new''' mechanism:
+
+=== 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' ===
+==== /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' ===
+==== 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 ====
+===== 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:
@@ -50,7 +100,7 @@ An example configuration object might look as follows, assuming that XML version
... type specific fields ...
</configuration>
-=== Client Behaviour: Parsing configuration data ===
+==== Client Behaviour: Parsing folder based XML 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;
@@ -63,7 +113,7 @@ An example configuration object might look as follows, assuming that XML version
* 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 ==
+=== Upgrade Path ===
This KEP adds new functionality and folder types that will not be understood by older clients.
@@ -71,9 +121,13 @@ This KEP adds new functionality and folder types that will not be understood by
== 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.
+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). Some scenarios have thus far only been theoretically examined, e.g. use of individual message annotations.
+
+Any such choice has advantages and disadvantages, specific properties that make it well suited for one, but not another scenario, e.g. offline storage yes/no, ability to share with others, ability to be determined by admin without user influence, and so on and so forth.
+
+So the Kolab Community has come to understand it needs a toolset of approaches to storing configuration and coordination data from which we need to choose carefully for every individual use case and issue we seek to address. Besides the approaches that are already in use, this KEP also defines a new approach that 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.
-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.
+The resulting set of four clearly defined mechanisms that can be mixed, matched and applied to the various scenarios should result in an encompassing set of options while ensuring these are used '''consistently''' across scenarios to simplify the life of all participants in the community.
== References ==
More information about the commits
mailing list