Basic rationale of the KEP #2 design

[Georg C. F. Greve]

Dear Florian,

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.

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

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, as broken 
clients will continue to be in the wild for years to come.

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, 
as it would be 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.


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

The only question is which one it uses. So if that database is not Olson 
already, SyncKolab should be able to fall back on the same mapping table the 
Outlook connectors would use.


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

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.


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

Clients then have to choose between which one to follow, and unless you want 
to declare the database authoritative (arriving back at the current KEP#2), or 
updates of the static information (leading to unsurmountable issues in 
permissions and ensuring everyone received an update), you then have to 
enforce static time zone information, which means every event ultimately has 
its own, event-specific time zone that no longer resembles what the user meant 
to specify when the DST rules change.


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

Because it incorporates a calendar, it necessarily incorporates some database. 
The question again is, which one? Olson would come to mind, but maybe they 
actually use the Windows time zone database. 

The evolution team should be able to tell you which one it is.


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

This is all the KEP#2 actually requires, IIRC.

If you have another database that gives you the timezone data for this set of 
locations, you're free to use that. In fact there is even the expectation that 
the services based upon the Douglass RFC would become that source.


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

Some people prefer private mail or other channels in order not to get dragged 
into a discussion they fear will cost them more time than they can afford.


> 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

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

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

He was also the person to first suggest storage in local time in the beginning 
of the discussion. So both these rather fundamental points which came from the 
Evolution client made it into the final KEP.


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

Hendrik, see above.

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

Naturally the mapping database will be an issue for all clients, but that is 
something we can work collectively on and that Kolab Systems has volunteered 
to maintain and continue to provide.

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/20110303/5c677939/attachment.sig>