[CLSABRT, NEW DRAFT] KEP #9: Storage of configuration and application control information
wrobel at horde.org
Mon Sep 12 05:47:35 CEST 2011
Quoting "Georg C. F. Greve" <greve at kolabsys.com>:
> Dear all,
> Gunnar asked a "good question" (tm) and in the result I think it
> made sense to
> get back to the drafting table on the issue of values for annotations.
> Gunnar's mail and the resulting thread are here:
> and the resulting updated draft is now available in its usual place:
> KEP 9: Storage of configuration and application control information
> The most important changes are:
> (a) Clarify this is binding for the '/vendor/kolab/' namespace
> Third party applications SHOULD conform, but can decide otherwise
> if they have strong reasons. They MUST however document what they
> are doing so there is no undocumented annotation shipped
> (b) Clarify explicitly which RFC allows which kinds of values, and wrap
> it into UTF-8 as string or JSON explicit rule, with an emergency
> fallback for Base64 in case we run into issues we cannot foresee.
> (c) Rationale for the whole thing added to document the background.
> Please take a look and make sure it is consistent and sensible.
> Please also help me confirm that
> (a) Cyrus & Dovecot *actually* conform to the UTF-8 rule
> (b) Our Z-Push backend *actually* encodes to UTF-8 JSON
The problem never was the backend server but our Kolab specific PHP patch.
> Then hopefully we can re-issue the closing call some time next week.
> Best regards,
> Georg C. F. Greve
> Chief Executive Officer
> Kolab Systems AG
> Zürich, Switzerland
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
> pgp: 86574ACA Georg C. F. Greve
The Horde Project
e: wrobel at horde.org
t: +49 700 6245 0000
pgp: 9703 43BE
More information about the format