[NEW KEP] KEP #17: Kolab XML Format 3.0

Florian v. Samson florian.samson at bsi.bund.de
Mon Feb 27 10:23:08 CET 2012


Hello Christian,

after a thorough walk through KEP #17 (revision #12454 of 2012-02-22) 
<http://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17>, I like it a lot 
and would like to provide some feedback after my first glance at it.

a. Two suggestions for clarification

a1. In # 1.4.2.1.7 Transparency
IMO
     Specifies, if an event is free/busy-relevant, i.e. evaluated in 
free/busy-time searches.
instead of
   Specifies if an event shows up in freebusy time searches.
describes the intention better and clearer in conjunction with the 
additional context already provided by the two following bullet-points.
I am not sure, if that is in line with current behaviour, but as this is 
regularly an area of user complaints (often: setting appears to be 
non-functional and/or inconsistent across different Kolab-clients), a 
proper (behavioural) definition in the Kolab Format v3 is a big step 
forward.

a2. In # 1.4.2.3 Todo
    and # 1.4.2.4 Event
As "show-time-as is one of free, tentative, busy, or outofoffice", it is 
about *how* a free/busy-relevant may be displayed in an (extended) 
free/busy-list. This aspect is orthogonal to transp (# 1.4.2.1.7).
OTOH, if I remember correctly that time-frames explicitly marked 
as "free" (by show-time-as) cannot by differentiated in (X)FBs from 
unallocated "free" times, then there is an some overlap in meaning. If 
my memory was wrong, Kolab3 IMHO should express "free" and simply 
unallocated times differently when generating (X)FBs.
Also, IIRC, transp solely controls relevance of an incidence (e.g. 
event) for generating free/busy-lists, while show-time-as also has to 
be evaluated for automated resource handling. I would hope for some 
information on this in the Kolab Format specification v2, but have not 
taken a look, yet.

b. # 1.4.1.6 Classification
As access to Kolab-objects is controlled by IMAP-ACLs, and their 
F/B-relevance by transp (see a1., above), IIRC no clear decision was 
ever met, what behaviour this ought to control. (For Kolab 2.2.4 with 
Kontact-E35 and most, if not all other Kolab-Clients, IMHO this setting 
changes no behaviour at all.) You captured this very nicely.
But thus this is an open space, which may be filled by some guidance how 
the Classification might be utilised. A minimalistic purpose might be 
the ability to display, set and store (and hence preserve) the 
Classification for and from external iCal-objects, e.g. for / from 
other Groupwares, where this setting matters.

c. Some bits of these documents may contain helpful and/or interesting 
information WRT KEP #17 as well as issues to avoid:
c1. "Conversion Issues": 
<http://sourceforge.net/apps/mediawiki/evolution-kolab/index.php?title=Conversion_Issues>
c2. Chapter 6 (starting PDF-page 17), especially chapters 6.4.x of 
<http://sourceforge.net/projects/evolution-kolab/files/Feinspezifikation_SecurMobI_hh_2010-08-19.pdf>
c3. RFC reference for Kolab2: 
<http://sourceforge.net/apps/trac/evolution-kolab/wiki/RFCReference>

Cheers & HTH
   Florian




More information about the format mailing list