KEP-0009.txt

Georg Greve greve at kolabsys.com
Thu Aug 18 08:09:26 CEST 2011


 KEP-0009.txt |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

New commits:
commit bb0199f858dd59c8a92121cfaa057985505c18ae
Author: Georg Greve <greve at kolabsys.com>
Date:   Thu Aug 18 08:08:46 2011 +0200

    Included feedback from Florian & Jeroen

diff --git a/KEP-0009.txt b/KEP-0009.txt
index d1c3bcd..122a5a7 100644
--- a/KEP-0009.txt
+++ b/KEP-0009.txt
@@ -18,14 +18,14 @@ This Kolab Enhancement Proposal (KEP) <ref name"kep">[[KEP:1]] Bootstrapping the
 
 The mechanisms defined in this KEP include
 # ANNOTATE annotations, both private and shared (new)
-# ANNOTATEMORE annotations, both private and public (modified)
+# METADATA annotations, both private and public (modified, previously ANNOTATEMORE)
 # 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
+# METADATA 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.
@@ -46,13 +46,13 @@ 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>. 
+From its inception in 2003 and up until and including Kolab Format 2.0, the Kolab Groupware Solution has been using [http://tools.ietf.org/html/draft-daboo-imap-annotatemore-05 draft version 5 of the ANNOTATEMORE proposal] 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'''.
+With application of this changeset against the Kolab Format 2.0, all clients '''MUST''' conform to {{rfc|4564}} '''only'''. Usage of ANNOTATEMORE will be deprecated, unsupported and not compliant with the Kolab Format resulting from application of this changeset.
 
 === 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.
+RFC 4564 provides means for public and private annotations. Both kinds MAY be used in the Kolab Groupware Solution, but each annotations usage in all namespaces MUST be defined in a single KEP to avoid namespace confusion.
 
 === Values ===
 
@@ -73,9 +73,9 @@ The following changes to the Kolab Format are part of the changeset against Kola
 ====  /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';
+* There MUST be at most a single folder of type 'configuration' with the subtype 'default' per user;
 * 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';
+* Shared folders of the type 'configuration' '''SHALL NOT''' carry the subtype 'default';
 
 ==== Kolab XML object type: 'configuration' ====
 





More information about the commits mailing list