[CLSABRT, NEW DRAFT] KEP #9: Storage of configuration and application control information
Georg C. F. Greve
greve at kolabsys.com
Fri Sep 2 17:14:38 CEST 2011
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:
http://kolab.org/pipermail/kolab-format/2011-September/001445.html
and the resulting updated draft is now available in its usual place:
KEP 9: Storage of configuration and application control information
http://wiki.kolab.org/User:Greve/Drafts/KEP:9
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
Then hopefully we can re-issue the closing call some time next week.
Best regards,
Georg
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110902/8429db9c/attachment.sig>
More information about the format
mailing list