[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