[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