Basic rationale of the KEP #2 design
Georg C. F. Greve
greve at kolabsys.com
Wed Mar 2 16:50:15 CET 2011
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
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
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 C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format