Basic rationale of the KEP #2 design

[Florian v. Samson]

Dear Georg,

Am Mittwoch, 2. März 2011 um 16:50:15 schrieb Georg C. F. Greve:
> 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.

Well, it is a usual situation that some implementations of a specification 
fail to fully adhere to it.  The common solution is to fix the broken 
implementation.
But KEP#2 pursues the reversal of that: break the specification in order to 
adapt it to a single broken client.  IMO, this is not the right way for an 
initiative to handle their specifications, if losing reputation and 
fairness is something to be avoided. 

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

Again, I can see that this is valid for Kontact, but not for all other 
clients, e.g. a MS-Outlook plugins.

> They typically use the system wide database, which for all systems except
> Windows is based upon Olson, ...

Please do read my mail fully: the programming environment is not "Windows" 
or "Linux" for many Kolab-clients, as I pointed out.
What can e.g. a Synckolab expect to exist on a platform it is installed?
IMO the answer is just "Thunderbird / Seamonkey and its XUL-environment".
So does it help by any means that there might be an Olson database somewhere 
on the platform, or something similar, but somewhat different if that 
platform is Windows?
No.

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

Yes, that is exactly it: the user's intent in which timezone that event is 
taking place is not recorded.
So the fix is to ...
a. introduce a timezone-tag to record that user intent.
b. save the timzeone-information for that timezone, covering at least the 
period of time all recurrences of that span.
This is all it needs, nothing more.

> Even static encoding for all its other shortcomings would not remove that
> dependency, 

It does not bear more or less shortcomings that relying on an external 
database: the freshness of the source has to be maintained.
You simply state that for Olson, this is nothing KEP#2 has to care about, as 
the operating system will: I do not believe that this will be that simple 
in practice and you will sooner or later have to think about schemes to 
notify other clients via the Kolab format about the release-date or version 
of the tz-database used.

> as clients would still need to display the results of their 
> calculations on the grounds of the local timezone databases.

Georg, please do not model everything from the Kontact programmers 
perspective, only: E.g. for evolution-kolab Evolution takes care of this 
and this is nothing which has to be implemented in the format parser.
Hence your statement is not true.

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

This can just as well archived with an in-format tz-information/definition.
It definitely does not need a database for that as you claim here.

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

Oh, I was not aware that a standardisation body formally approved the Olson 
database: I would appreciate a pointer to ISO, IEEE or any national 
standards body (DIN etc.), if that is really the case.

Nevertheless, your point is off topic: you clearly stipulate in KEP#2 to 
implement a Kolab-client by using the Olson database.  

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

Hold on: you are saying by demanding a specific technical implementation in 
KEP#2 (specifically using the Olson database), which can only be fulfilled 
under very specific circumstances you are limiting the error potential.  I 
tend to agree, but this will happen by effectively eliminating other 
Clients but Kontact to be able to make use of KEP#2.  It is easy then for 
Kontact to be interoperable with itself.  What a great achievement that 
would be! 

A database can never be a standard, it might adhere to one.  I am seriously 
interested to know which one, as this information was not communicated in 
the lengthy discussion on this list.

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

Georg, please leave the source of tz-infos up to the implementers, you have 
not provided a single reason why this *source* must be the same for all, 
except that you think it is easier if it is the same for all.  It sure 
would, but even Olson databases do get updated and so the assumption is 
wrong.

> The minimum we require is an encompassing set of geographical IDs with
> mapping to time zone information. 

Yes, I would call them "timezone-identifier" and "timezone-definition"; if 
that is what you meant, we do agree on this.

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

Yes, so do I remember.  So what, you might as well argue that the Windows 
TZ-infos do exist on about 90% of all PCs in the field so it is logical to 
force Kolab-client implementers to use that.

Again: Do not stipulate specific implementation in a specification.  This is 
fundamentally wrong.  Always!
As well as the whole discussion about technical details is very strange, as 
long as the basic design principles (backward compatibility, 
interoperability etc.) have not been discussed on a non-technical level in 
the first place.

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

Then you must have read different e-mails or read the same mails 
fundamentally different.

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

Hendrick welcomed just a single version, which was the single one which used 
the date-time tag as defined in the current Kolab-format (no full RFC3339).
These fortunate changes have been revised away by you a long time ago.

In both central points discussed (i.e. the date-time tag and mandating the 
use of the Olson database) the proposal made by the Evolution connector 
developers was distinctively different from "KEP#2 as it currently stands".

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

From what I read on the mailing list this is not true for Gunnar, Hendrik, 
and Shawn.  
All others (as I stated) either work for Kolab-Systems or develop Kontact.

I think your statement "This is incorrect" above is unsubstantiated.

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

Sorry, I read Joon's contributions entirely different.  After the initial 
discussion his last postings clearly have shown he acknowledges the issue, 
but not the proposed solution (current KEP#2).

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

So you expect most clients not to implement KEP#2, e.g. evolution-kolab (a 
project initiated and lead by me)?
(Maybe you are not aware that I also was the technical lead on the BSI side 
for the Kolab2 project.)

Regards	
	Florian