Basic rationale of the KEP #2 design - Part 1

Florian v. Samson florian.samson at bsi.bund.de
Tue Mar 15 13:59:22 CET 2011


Georg,

Am Freitag, 11. März 2011 um 20:30:56 schrieb Georg C. F. Greve:
> On Friday 11 March 2011 16.41:08 Florian v. Samson wrote:
> > That is one reason why specifications must never follow or adapt to
> > broken implementations.
>
> Indeed. 

Good, so let us create a solution for the identified TZ-issues, which 
compatible with the existing Kolab-format.

> Which is why KEP #2 does not follow or adapt to the current 
> broken specification and implementation, 

A specification cannot be "broken", as it defines things to be this or that 
way, except for the case where a specification itself contains clearly 
conflicting statements.
So the current Kolab-format is by no means "broken", it just has 
the "little" disadvantage that all timestamps are in UTC only without a 
separate timezone identifier, so changing the reference time for an event 
to properly represent a local time needs some more information and 
therefore new XML-tags.

> but proposes a clean solution that the implementations can then adapt to.

The "solution" KEP2 is a clean cut from the existing Kolab-format, as it is 
incompatible, but that does not automatically make KEP2 a cleaner solution 
than other ones.

> > Please be clear: which "several clients"?  I only read
> > Kontact-developers stating that on this list.
>
> Joon said that the Toltec connector also does not preserve nested XML
> tags, so both implementations that are mentioned as the reference
> implementations for version 2 of the format do not show the behaviour
> upon which you suggest we rely. 

Sorry, I did not state anything such.
You seem to completely misunderstand any of the more abstract and generic 
points I made, which go beyond a single, specific technical issue.

I do not comprehend, why you are so eagerly discussing XML-tag preservation 
in technical detail, after you stated that this shall be solved separately 
(and I did and do agree).  I made clear at least twice, that I merely 
highlighted the general design principle of preserving tags in the 
Kolab-format and that we should definitely maintain that as a principle.

Now, leaving the general principles aside for a second and diving into the 
nitty-gritty details which dominated the discussion and the modeling of / 
thinking about a evolved Kolab-format on this list so far, unfortunately: 
Sure it might make sense to provide some additional time (though it has been 
years already) for broken clients to finally conform to what always has 
been stated in the Kolab-format.  In contrast to many other things we 
discuss here on this list AFAIK nobody mentioned a fundamental technical or 
design hurdle for Kontact (and maybe also Toltec) to preserve all tags in 
the foreseeable future.

Furthermore top level tags seem to be preserved by all existing clients: 
so all the detours which have been taken in various directions throughout 
this conversation about preserving tags are IMHO superfluous here (= in 
this thread), as they are irrelevant for ...
a. recognising the underlying design principle in the existing Kolab-format.
b. extending the Kolab-format as intended by its original developers, by 
introducing new tags.  It imposes no hard restriction, if we limit that to 
top-level tags, currently.

> > 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 stated before, I agree with your suggestion to fix all clients to
> start preserving all XML tags. But as we know this is not currently
> something they do, we cannot rely upon it for this particular KEP.

You are proposing to model the specification (KEP2, here) following certain 
client implementations, again, which is something you denied at the 
beginning of your mail.

Even the two reference clients (and those two have been the reference 
clients since the Kolab2 development started) constitute references only 
for those cases, where the specification is unclear, imprecise, ambiguous, 
or even inconsistent or things are simply unspecified (as the case for most 
behavioural aspects of a Kolab-client): in all other cases, the 
Kolab-format specification is mandatory and binding for all Kolab-clients, 
and any particular client's behaviour is irrelevant.

> This is in no way "loosening" the specification, 

What else is the "loose parsing" about you and Jeroen are pushing for so 
hard?
It is for allowing clients to utilise the specification in a very lax 
manner!

> So you're saying with absolute certainty that the Thunderbird and
> Lightning APIs definitely do not offer RFC3339 parsing, nor timezone
> management?
>
> So you're 100% certain that Evolution does not offer APIs for tz support?

Georg, IMO this is completely the wrong approach: if you are seriously 
interested in having as many Kolab-clients as there are interested 
initiatives / companies, you should ask yourself "can I expect any 
PIM-Client, which may be extended to become a Kolab-client in the future, 
to have an integrated and easily accessible full RFC3339 implementation".
The answer is "No", hence you are introducing a significant hurdle for other 
PIM-Clients to become Kolab-Clients and for existing Kolab-Clients to 
support version 2 of the Kolab-format, if KEP2 in its current state woud 
become that v2.

Especially for Thunderbird and Lightning with their often heavily changing 
APIs I cannot tell with the "absolute certainty" you requested (as I looked 
at those APIs a while ago, when I retraced Synckolabs design and its 
limitations), though I am quite sure that no RFC3339-parsing API was 
introduced, as it simply makes no sense.  And even if a full RFC3339 parser 
would be accessible, those APIs seem to be redesigned with every major 
release, so they are not future proof at all. 

But, as I wrote above, it simply makes no sense for any of those clients to 
offer a RFC3339-parsing API, as Plug-ins mainly just pass and receive 
iCal-objects (for all kinds of events): how they are dissected somewhere 
inside the PIM-client is not and must not be of the plug-in's concern 
and/or business.  This seems to be MS-Outlook's approach as well, from what 
I extracted out of Joon's and Shawn's statements.

The hassle starts when one intents to do more in/from a Plug-in than the 
plugin-API-developers have anticipated (this is an generic statement!), 
once again experienced in the evolution-kolab project (only this is 
specific to evolution) and before many times with Synckolab (e.g. no IMAP 
annotations accessible through Thunderbird's IMAP-API). 
In those cases one briefly considers extending or altering the API, but 
while that option exists in theory (well, not for MS-Outlook), it is 
practically infeasible in all cases, due to the lack of resources (time, 
money, humans; and the efforts of maintaining that code in the future) as 
well as the reluctance of upstream to accept changes which only accommodate 
a single plug-in in the first place.


I split my reply in two parts in order to keep some topics apart, especially 
the important topic "central in-format TZ-data vs. individual local 
TZ-databases".
Part 2 will be following immediately.


Regards
	Florian




More information about the format mailing list