Basic rationale of the KEP #2 design

Florian v. Samson florian.samson at bsi.bund.de
Fri Mar 11 16:41:08 CET 2011


Georg,

Am Donnerstag, 3. März 2011 um 11:22:16 schrieb Georg C. F. Greve:
> On Wednesday 02 March 2011 19.20:09 Florian v. Samson wrote:
> > 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.
>
> There seems to be a fundamental misunderstanding here.

Oh, unfortunately this appears to be true ...

> KEP#2 and the issue of maintaining unknown XML tags are entirely
> unrelated.

... as you seem to have completely missed my point about the generic design 
of the Kolab-Format and the resulting principal ways to extend it 
accordingly.  
Instead, you only look on the immediate technical consequences, again:

> Fixing one will not affect the other, nor will fixing the XML tag
> preservation mean that we can suddenly rely on all clients to behave
> properly, 

And I do disagree with your assessment, that 
> as broken clients will continue to be in the wild for years to 
> come.
It will only take at most few years for those affected client-versions (only 
a few, as it seems) to be updated naturally.

As you are seriously proposing to force *all* Kolab-clients to support two 
incompatible format-versions forever (or at least as long as there is a 
single Kolab-client around, which still only supports the original 
Kolab-Format), is a nice example why there is the overarching principle 
that implementations must follow specifications, not vice versa (as you are 
arguing for, repeatedly):
The consequences of a broken specification are much longer lasting, as it 
can only be abandoned, when *all* implementations have implemented a fixed 
version of that specification, due to interoperability.  In contrast to 
that for abandoning a broken implementation it takes only a fixed release 
of that single implementation.
That is one reason why specifications must never follow or adapt to broken 
implementations.

> On the issue of tag preservation: Naturally the tag preservation SHOULD
> be fixed, but several clients requested this not be done too fast or too
> strongly, 

Please be clear: which "several clients"?  I only read Kontact-developers 
stating that on this list.  Has it been in one of the many telephone calls 
and private e-mail exchanges you cannot enumerate and hence name anymore?

IMO it must be fixed in those clients, and loosening the specification is 
a "anti-fix", as it calls all clients to use more leeway.

> as it would be an invasive change for them on the parser level 
> and might be too disruptive.

Oh, I am surprised to read this statement from you, as KEP#2 is for most 
Kolab-clients way more of "an invasive change for them on the parser level 
and might be too disruptive".

> > > 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.
>
> Kontact & Horde are just the ones on which it was easiest to demonstrate
> for the purpose of the KEP. But as explained in the KEP, this issue
> affects all clients equally, because it is rooted in insufficient data
> stored in the Kolab XML upon which all clients rely.

Yes, we all know for months already, that it needs some TZ-identifier and 
TZ-data for this TZ.

Still, this is no rely to my statement above: it is simply not true that 
all "Kolab Format parsers already depend upon timezone databases".

And please be clear on terms, as you are continuously mixing up 
1. "Kolab Format parser" and "Kolab client"
2. Timezone identifiers, timezone data / definition and timezone database

All those terms address technically different things and aspects.

> > What can e.g. a Synckolab expect to exist on a platform it is
> > installed?
>
> It does not need to expect anything beyond its regular requirements.
>
> Because Lightning is a calendar, it already requires a database for DST
> data.

Exactly, but not Synckolab!  
Synckolab is bound to the APIs Thunderbird and Lightning offer, if one does 
not intend to come up with an awkward and clumsy design. 
The same applies to kolab-evolution, which is limited to the APIs a 
camel-provider can use, if one avoids invasive changes in Evolution which 
will not be accepted upstream, anyway.

> The only question is which one it uses. 

Sorry that is incorrect, as explained above.

> > 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.
>
> There has been a very lengthy discussion why it is not that easy.

Yes, I read it back then and reread it 1,5 weeks ago.

> The concept has been tried in iCalendar, likely because they also could
> not agree on one approach and thus allowed both, and leads to
> inconsistent client behaviour.

Please name your "one", "both" and "inconsistent client behaviour" 
specifically.
The permanent repetition of unsubstantiated statements does not make them 
easier to believe, rather the opposite.
I personally think, that if the iCal-spec would have been in its current 
state in 2002/2003, most likely the Kolab-format would wrap that in proper 
XML while omitting some legacy stuff in there.  This spec evolved quite 
well over last few years.

> > 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.
>
> I do not have the time to summarize the debate in all its aspects, so let
> me try to summarize just some key points quickly.
>
> Having geographical ID and static encoding side by side provides two
> conflicting specifications as soon as the static encoding violates the
> actual time zone information.

You used the term "static encoding" in a couple of your e-mails on this 
list, but I was unable to find any definition provided (missing in KEP#2 as 
well).
Still, I did not propose by any means to record information which might be 
conflicting to itself, hence your point is not applicable, anyway.

> > E.g. for evolution-kolab Evolution takes care of this
> > and this is nothing which has to be implemented in the format parser.
>
> The client is evolution, not the evolution-kolab plugin.

Again, we are discussing Kolab-format parsers, not clients: please do keep 
them apart throughout this discussion.
PIM-Client internals are often inaccessible from their plug-in APIs: this 
also applies to Outlook plug-ins and Synckolab.

> > 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,
>
> The reason is simple.
>
> Any client must be able to understand what a certain geographical
> identifier identifies when editing an event. If all clients could freely
> choose such geographical identifiers, then "Friesland/Wackersdorf" would
> be a valid geographical identifier that all clients globally must be able
> to interpret.

You are confusing timezone identifiers, timezone data / definition and 
timezone database here.
You correctly provided a reason, why we must agree on and specify timezone 
identifiers (you call them geographical identifiers here): interoperability 
on the format-level.

But you always lacked and still do lack any reason why ...
a. the *source* for the timezone data must be a database
b. this *source* must be the same database for all (actually this point was 
weakened by you, lately)

> > Then you must have read different e-mails or read the same mails
> > fundamentally different.
>
> Not all communication takes place in email on list, as explained.

Consequently they do not exist for the readers of this list.

> > 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).
>
> Then we indeed read email differently:
>
>   http://kolab.org/pipermail/kolab-format/2010-December/001184.html

Yes we do.  Any of us needed some time to fully comprehend the various 
aspects and depth of the timezone issue.  Sure, that applies to Henrick as 
well, and it was RFC3339 limited to UTC only: please do read his mail you 
referenced.
RFC3339 limited to Zulu (UTC) and without many of its extras (milliseconds 
etc.) is also exactly what Joon and I propose.

> It was in fact Hendrik's proposal to use RFC3339 for this purpose

Sorry, that is not true: the proposal for RFC3339 came from you.

>   http://kolab.org/pipermail/kolab-format/2010-December/001180.html

This is a nice example how many of us slowly came to the conclusion that UTC 
together with an tz-id (he modelled it as an simple offset at that time, 
which turned out to be insufficient) is a good solution.
This is exactly what Joon and I propose.

> > From what I read on the mailing list this is not true for Gunnar,
> > Hendrik, and Shawn.
>
> Gunnar has been regularly consulted personally to make sure the server
> side clients do not have major issues with this KEP. His last statements
> always were that he sees no problem implementing KEP#2 and will do so.
>
> If he told you something else I'd be quite surprised.

I do refrain from referring to private e-mail exchanges without quoting 
them: I do not care, these conversations are not transparent at all to 
anybody on this list!  
I read his (very few) mails on this list and his statements there were 
different from what you purport.

> Shawn has written only a few days ago to this list that they are working
> on implementing the KEP:
> 	http://kolab.org/pipermail/kolab-format/2011-February/001219.html

So does Joon, and he is not at all happy with it.
Shawn's statements have been generally negative as I read them.


Regards
	Florian




More information about the format mailing list