Basic rationale of the KEP #2 design

Joon Radley joon at
Wed Mar 2 18:23:07 CET 2011

On 02 Mar 2011, at 4:06 PM, Florian v. Samson wrote:

> Georg, all,
> I still fail understand the basic approach being taken in KEP#2 after 
> reading through the extensive discussion over the last couple of months, 
> again.  Hence I will write up a top-down description my understanding of 
> then situation and the partial lack thereof.
> Looking at the basic design decisions of the current Kolab Format, the 
> choice of XML along with the clear statement that any XML-tags unknown to a 
> client must be ignored was made to allow for easy extension of the Kolab 
> Format (among many other properties) while retaining backward 
> compatibility, by specifying new XML-tags.  Any other measure to extend the 
> Kolab Format implicitly breaks backward compatibility, which must be 
> avoided for a specification with many implementations in order to stay 
> commercially successful, as it loads the burden of maintaining two 
> implementations for (at least) a while on every implementer and carries the 
> risk of an format fork, if not all implementers (are able to) follow the 
> incompatible format changes, for technical or other (e.g. costs) reasons.  
> Only if a design issue can solely be cured by altering existing XML-tag 
> definitions in the Kolab Format such an approach is inevitable, which is 
> not the case for the design issues KEP#2 is trying to address.  (I will 
> come up with a suggestion in a follow-up email.)
> I also do not comprehend on a more practical level of design, why an 
> external technical dependency has to be introduced, specifically on a 
> timezone database.  Currently there is no necessity for a Kolab Format 
> parser to depend on any other software components; this property can and 
> should be retained, as it is used by many implementers.  Specifically the 
> Olson database seems to be excellent per se, but a good specification 
> should not stipulate a decided implementation and preclude others, as long 
> as the required properties of the Kolab format can be attained.
> Consequently all implementers of Kolab clients have expressed issues with 
> KEP#2, which are still present in its current state, with the sole 
> exception some of the Kontact client implementers from Kolab Systems (Georg 
> Greve and Jeroen van Meeuwen):
> a. All have expressed reluctance to significantly change existing parser 
> code for KEP#2 and to maintain two incompatible variants of their 
> individual Kolab format parser in parallel, specifically Hendrik Helwich 
> (Syncphony and Evolution-kolab), Gunnar Wrobel (Horde) and Christian 
> Hilberg (Evolution-kolab).
> b. Gunnar, Hendrik, Christian and Bernhard Reiter (Kontact) have also 
> expressed reluctance to depend on external software libraries, e.g. for 
> parsing date-time tags with full RFC3339 support.  Hence, extending the 
> existing date-time tag to cover full RFC3339 compliance either forces a 
> client implementor to spent a significant programming effort or to depend 
> on an external library.
> c. The same applies to SyncKolab (Nico Berger's Thunderbird plug-in) and to 
> the Toltec and Bynari MS-Outlook plugins, from what I gathered from Joon 
> Radley's (Toltec) and Shawn Walker's (Bynari) postings on this list.
> d. In certain programming environments the mandated external dependency on 
> the Olson database and the suggested one on a RFC3339 parsing library is 
> extremely hard to impossible to fulfil.  Joon and Shawn clearly stated so 
> multiple times for the perspective from an MS-OL plug-in and supposedly the 
> same applies for the Synckolab Thunderbird plug-in in its Mozilla's 
> JavaScript & XML "XUL" environment.  Please accept that these programming 
> environments bear many more constraints than a regular MS-Windows (as 
> addressed by Georg) or Java (as noted by Jeroen) environment.
> e. It is more than likely, that a. - d. also applies to the Konsec MS-OL 
> plug-in.
> The stated inability of at least two major Kolab clients to follow the 
> proposed changes in the Kolab Format on a structural level makes me worry 
> about the future of the Kolab environment as a whole: the fact that 
> multiple Kolab clients on different operating systems- and PIM-environments 
> (Windows, GNU/Linux, Kontact, MS-Outlook, WWW, etc.) are well established 
> and interoperable always has been a big asset.  To loose that by separating 
> the Kolab clients in those which do support the new format version and 
> those which do not, will significantly hurt the attractiveness of Kolab.
> So I kindly ask the proponents of KEP#2 to help me and others to understand 
> why the fundamental design considerations of KEP#2 must create these 
> significant hurdles for the whole Kolab environment.
> Thanks
> 	Florian
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at

I agree with Florian 100%.

Best Regards

Joon Radley

Cell: +27 (0)83 368 8557
Fax: +27 (0)86 547 2353
E-mail: support at

More information about the format mailing list