Basic rationale of the KEP #2 design

[Georg C. F. Greve]

Dear Florian,

On Wednesday 02 March 2011 15.06:34 Florian v. Samson wrote:
> 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.

That requirement exists on paper, yes, but as we found out in the discussions 
last year, not all clients meet it and it can therefore not be relied upon.


> 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;

Kolab Format parsers already depend upon timezone databases to interpret the 
storage format in order translate UTC to local time zones.

They typically use the system wide database, which for all systems except 
Windows is based upon Olson, but they fail to deal with recurrences correctly 
because the user's intent could not be stored and thus clients guessed, and in 
many situations necessarily guessed wrongly.

Even static encoding for all its other shortcomings would not remove that 
dependency, as clients would still need to display the results of their 
calculations on the grounds of the local timezone databases.

The dependency upon a database is created by the fact that there is no 
mathematical formula to calculate the outcome of the various political 
processes that govern DST, so is rooted in social/political phenomena.


> 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.

Olson is not so much an implementation, but a standard.

Focussing on one standard, and one standard only for any given purpose is 
typically a sane choice in my experience, as it limits the error potential.

Adding other sources for this kind of information will lead to more geographic 
identifiers that all clients will need to support in order to be compatible and 
interoperable, so more flexibility here will increase the implementors burden.

The minimum we require is an encompassing set of geographical IDs with mapping 
to time zone information. After intensive search, there was clear consensus in 
this group that in fact the Olson database is the best fit and most closely 
resembles the Open Standard in this field.


> Consequently all implementers of Kolab clients have expressed issues with
> KEP#2, which are still present in its current state, [...]

This is incorrect.

KEP#2 as it currently stands has come quite close to the original proposal 
made by the Evolution connector developers and has in fact been explcitly 
welcomed by Hendrik Helwich. It has over time incorporated input from the 
Outlook connectors, the Horde developers, the ActiveSync backend developers, 
the Kontact developers and the server maintainers.

In its current form it has explicitly been accepted for implementation by

	- Gunnar Wrobel (Horde & Server-Side Kolab-Format/-Storage)
	- Hendrik Helwich (Evolution)
	- Till Adam (Kontact)
	- Volker Krause (Kontact)
	- Allen Winter (Kontact)
	- Shawn Walker (Bynari Outlook Connector)
	- Alain Abbas (Z-Push - using Kolab-Format/-Storage)
	- Jeroen van Meeuwen (Kolab Server)
	- Christoph Wickert (Kolab Server)

I have made effort to seek out all these parties individually, as I have sought 
out the Kontact developers. Only three people work directly with/for Kolab 
Systems, by the way.

The SyncKolab developer has not engaged in the discussion, unfortunately, but 
naturally we'll do what we can to help him to meet KEP#2 as easily and as well 
as possible.

People still voicing reluctance have been:

	- Joon Radley (Toltec Connector)
	- Bernhard Reiter (Kontact)
	- Florian v. Samson

Because Joon Radley's input was mostly based on the premise that the issue did 
not exist, it was hard to incorporate, other than scrapping KEP#2 in its 
entirety and leaving the issue unresolved. 

Since everyone else, including Bernhard Reiter and yourself, agree the issue 
exists, this did not seem like the most sensible approach.

All other proposals that have been made have been thoroughly discussed within 
the last half year, and have turned out to be more complex, fragile or error 
prone than the approach that ended up making it into KEP#2.

This leaves the question of RFC3339 and its superset ISO8601 you raised.

As both are referenced by many other standards and RFC3339 in particular is 
the RFC for date and time on the internet, it would appear likely that they 
are in fact widely available on networked operating systems, and in fact the 
only people speaking out against them at the moment are those who are not 
personally working on any client.

While seeking consensus on this difficult and complex issue for the past six 
months now, I have to admit that when there is an impasse I ultimately give 
more weight to the people working on the Kolab clients who will find themselves 
on the implementing side of this KEP.

With 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/20110302/69091598/attachment.sig>