[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