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

Christian Mollekopf mollekopf at kolabsys.com
Tue Feb 28 01:08:50 CET 2012


Hi Florian,

On Monday 27 February 2012 19.50:11 you wrote:
> 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.
> 

Indeed, good call.

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

Ok, good to know.

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

We can add this at a later stage as a new optional property of the format. Of 
course all clients need to be upgraded if the new format is used in a Kolab 
environment, otherwise the property would of course be deleted again.
(if the client overwrites an object with a newer version of the format, which 
is bad behavior)

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

I get your point and can see the additional information expressed by this 
setting, but:

- The setting is only valid if the opacity is set to OPAQUE, and we should try 
to avoid such conditional settings as far as possible, because they add a lot 
of complexity to the format.

- Kolab Format v2 used this as a replacement for the OPACITY setting, so the 
potential for conflicting use of the property is high.

- I don't know of any real usecase of the setting. I understand that there is 
a potential usecase, but I don't believe it's overly useful and don't know of 
any user-interface where this setting is actually exposed. It's not in Kontact 
or Roundcube for sure. So I reckon it has been used as a replacement of 
OPACITY anyways.

- Interoperability is questionable since the setting is Kolab specific and not 
existing in RFC 5545.

- It's also questionable that clients will add a user-interface for a kolab 
specific setting.

We should try to keep the format as simple as possible, and right now I don't 
see a reason to add it, but potential problems with adding it.

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

Which would mean they don't comply to RFC 5545.

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

Or any other RFC 5545 compliant client.

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

It's explicitly not per RFC 5545 
(https://tools.ietf.org/html/rfc5545#section-3.8.1.3):

    "Additionally,
      due to the "blind" nature of most exchange processes using this
      memo, these access classifications cannot serve as an enforcement
      statement for a system receiving an iCalendar object.  Rather,
      they provide a method for capturing the intention of the calendar
      owner for the access to the calendar component."

Changing the purpose of the property is something that I would really like to 
avoid.

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

Ok, I understand. I don't think this would be a good idea, because that is an 
explicitly not supported usecase of the property. The property is preserved 
anyways though, just not for the additional reason

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

Yes, it's always good to get another point of view. Thanks again.

Cheers,
Christian

> 	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/20120228/46d1c5ac/attachment.sig>


More information about the format mailing list