[Kolab-devel] Closing Call: KEP #9

[Georg C. F. Greve]

On Friday 02 September 2011 09.52:11 Aleksander Machniak wrote:
> While JSON format allows unicode characters in the object, PHP's
> json_encode() encodes non-ascii characters to entities (\uXXXX). So, the
> question is, do we need to "encapsulate" it with base64 here?

FWIW, that is a good question.

The last time we discussed this we gathered that we weren't certain to which 
extent we could rely on the JSON encoding to be sufficiently robust. So IIRC we 
just slapped on a Base 64 encoding for good measure.

Not sure whether the Horde annotation has gone the same way, but I suspect it 
might, because it is not so easy to find out what exactly RFC 5464 is supposed 
to support in terms of values.

That said, my ignorance on this particular point was annoying me, so I finally 
took the time to dig through the RFCs to find out what we actually CAN store.

The answer is now documented here:

http://wiki.kolab.org/User:Greve/Drafts/KEP:9#Background:_Requirements_by_RFC_5257
http://wiki.kolab.org/User:Greve/Drafts/KEP:9#Background:_Requirements_by_RFC_5464

In short: RFC 5257 allows UTF-8, RFC 5464 allows strings or binaries.

So the Base 64 encoding done by both the Z-Push backend and the Horde client 
should in fact be unnecessary for a RFC 5464 compliant server (Note: we have 
been working against draft 5 in the past, maybe it was necessary there).

In that case I strongly opt for dropping the superfluous Base 64 encoding, 
which will also make the annotations more human readable for power admins.

JSON is a good choice overall, and in conversation with Gunnar it seems he is 
not adverse to using it for Horde preference storage, as well, all the more so 
as KEP 12 will require him to touch that code anyhow.

I'll officially announce the new draft in a moment.

Hopefully we can see that the way it is specified now is good, so we can 
hopefully re-issue the closing call 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/faf37dec/attachment.sig>