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

Florian v. Samson florian.samson at bsi.bund.de
Mon Feb 27 19:50:11 CET 2012


Hi Christian,

a quick reply, as I am out-of-office for the rest of the week.

Am Montag, 27. Februar 2012, 15:39 schrieb: Christian Mollekopf
> On Monday 27 February 2012 10.23:08 Florian v. Samson wrote:
> [...]
> 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 do I, that why I forced myself to finally do it, as nobody else  
posted his findings on the list.  So I concluded, maybe nobody outside 
of Kolabsys has reviewed this, yet.

> so the more input we get, the better. So thanks for your input.
>
> > 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.
>
> 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.

Thanks, this is looking good.

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

See below.  

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

Not really IMO.
Think of these categories as ...
- outofoffice:  Absent, i.e. busy and unreachable
- busy:            Busy, but basically reachable in house
- tentative:    Likely busy
- free:             Not busy (Useful for presence-phases, where one has 
to be sitting somewhere, but has no task allocated yet; or creating 
pseudo-events, which do not block the time, as reminders; etc.)

Outofoffice does *not* specify any location, it simply states "absent". 

Historically, I believe, this setting originates from the introduction 
of XFB-support.  
Sorry, I would have to research again (as I completely forgot over all 
those years) all the extra abilities XFBs (Extended Free-Busy Lists) 
provide compared to the classic, simple FBs.  But AFAIR XFBs can 
distinguish these subtle differences (FBs sure cannot, as they only 
know "free" or "busy") (although my memory may play tricks on me).
If so, then they should, IMO.

How the XFB-data is actually displayed is another, different story.

Maybe asking someone else might help, who has not ceased administrating 
Kolab-Servers more than half a decade ago (like myself), e.g. Bernhard 
Reiter.  Or finding proper XFB- and FB-specifications, which I have not 
found immediately on the net.

> Given that this property doesn't exist in xcal and is nowhere used
> (AFAIK) 

Oh, I missed to also insert this here:
> > 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'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) 

Uh, not really: Once Kolab-Clients implement this altering and adding 
things in this spec will be a major upheaval.  IMO your "we can still 
add it at a later stage" is only valid, as long as this KEP#17 ist 
still in draft-status.

> and map free to 
> "TRANSPARENT" and the other three to "OPAQUE" (for the conversion of
> existing properties of this type).

As stated: these two setting are IMHO and memory mostly unrelated, as 
they express different things.
You can employ such a mapping between them, but to me this is like 
mapping a small set of pretty different colours (e. g. red, green, 
blue, yellow) to black & white (no shades of grey): feasible, but the 
outcome may be surprising.

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

Yes, but we *know* this (the informational character of this setting) 
only for Kolab-Clients; this setting may be crucial on PIM-Clients 
attached to other groupware-servers, which depend on this setting for 
some kind of access control.

> This is also what 3.8.1.3.  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. 

Yes. 

> So it's not a directly security relevant property, 

.. for Kolab-clients ...

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

This is where I disagree, as I see at least the "minimalistic use-case" 
above (repeated three paras below).

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

This becomes clear from reading your words, which is basically the fact 
that it is unclear and up to the client, what to do with this setting.

This is, why I suggested considering the addition of some statement 
similar to:
> > [One] ... purpose ... [is] 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. 


Ups, this email was neither quickly written or short.
Anyway, hope it helped
	Florian




More information about the format mailing list