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

Christian Mollekopf mollekopf at kolabsys.com
Mon Feb 27 15:39:31 CET 2012

On Monday 27 February 2012 10.23:08 Florian v. Samson wrote:
> 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.

Hey Florian,

It's great to hear somebody from the community is actually reading this 
document =) I realize it's quite a bit of work to review it, but I believe 
this specification is really rather important for the interoperability of Kolab 
clients, so the more input we get, the better. So thanks for your input.

> a. Two suggestions for clarification
> a1. In # Transparency
>      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.

I changed it to:

''Specifies, if an event is free/busy-relevant.''

* "OPAQUE": The event is visible in freebusy time searches.
* "TRANSPARENT": The event is invisible in freebusy time searches.

If not specified this property '''SHALL''' default to "OPAQUE".
Events with the transparency set to "TRANSPARENT" '''MUST NOT''' be used in 
any free/busy time searches/generation.

This to be more general  on what the opacity applies(not limited to f/b 
searches), but stricter in how the information is interpreted.

> a2. In # Todo
>     and # 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 (#
> 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.

I couldn't find any useful information on the topic in the v2 specification.

* I still don't really get the concept of a f/b opaque event which is 
"free"... how is that different from a f/b transparent event? Of course you 
gain the information that the user explicitly set this time to free (i.e. he's 
sure that it's free, and didn't just not enter events there yet), but I don't 
see a real usecase here and think it's a bit overly complex.

* Also tentative seems overkill (if it means "I MIGHT be blocked")

* busy looks like the same as opaque.

* outoffice seems to mix with the location of the event, so also not a really 
clean solution.

Given that this property doesn't exist in xcal and is nowhere used (AFAIK) I'd 
rather leave this property out for now (we can still add it at a later stage 
if we see a real need for it) and map free to "TRANSPARENT" and the other 
three to "OPAQUE" (for the conversion of existing properties of this type).

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

Thanks =)

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

Sorry, I'm not following you here.
The classification is purely informal and has nothing to do with actual access 
control such as IMAP-ACLs (and I take it, you agree with me that far).
This is also what  Classification in RFC 5545 describes.
Of course a client is free to implement i.e. special authorization needs based 
on this property, but he can not rely on other clients to do the same.
So it's not a directly security relevant property, it's just here to inform 
the user that he shouldn't print that information and distribute it on the 
street if it's marked as "confidential".

Do you think this is not clear from the current wording and should be specified 
more clearly?

> 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=Conve
> rsion_Issues> c2. Chapter 6 (starting PDF-page 17), especially chapters
> 6.4.x of
> <http://sourceforge.net/projects/evolution-kolab/files/Feinspezifikation_Se
> curMobI_hh_2010-08-19.pdf> c3. RFC reference for Kolab2:
> <http://sourceforge.net/apps/trac/evolution-kolab/wiki/RFCReference>

Thanks for your input.


> Cheers & HTH
>    Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20120227/4d117a0c/attachment.sig>

More information about the format mailing list