Basic rationale of the KEP #2 design

Florian v. Samson florian.samson at
Wed Mar 2 15:06:34 CET 2011

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 

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.


More information about the format mailing list