Free Busy
From Kolab Wiki
.png){kind=small}
It is still under construction and content may change. Do not rely on the information on this page.
Contents |
Overview
For a general description of what the free/busy system should be able to do please, see FreeBusy_in_Kolab_3.0
For an initial overview, please also see the visualisation of the free/busy system and its components.
Definitions
- Simple Free/Busy (SFB)
- Free/Busy information that contains nothing but a users status, displaying the user as free, busy, tentative, out of office.
- Extended Free/Busy (XFB)
- Free/Busy information that contains the Simple Free/Busy information, plus the headings of events. Read access should by default only be available for properly authorized, specific users.
Concerns
- Security
- Free/Busy information is generated from calendaring data, thus security of the free/busy systems is essential to keep calendar (and potentially other) data secure
- Performance
- Generating free/busy information includes interpretation of calendar events, including calculation of recurring events, which themselves require time zone handling, and can be quite resource consuming. This leads to a pre-generated free/busy approach, which requires caching, which in turn creates security challenges, such as which permissions to use on the server to (re)generate free/busy cache?
Note that this also leads to generating/updating the f/b info much more often than actually required, which could lead to another performance bottleneck
Free/busy system components
The free/busy system consists of three major components which will be individually described in their design:
- Partial Free/Busy Generator
- Taking raw data, in particular original calendar payload, and generate partial free/busy objects as Extended Free/Busy Lists (XFB), one object per resource
- Requires time zone logic & recurrence calculation, may be implemented on the basis of Server Side Akonadi as well as Client Side Akonadi, or an independent, simpler component
- Free/Busy Aggregator
- Aggregates the partial free/busy objects provided by the Partial Free/Busy Generator, above, into aggregated Simple and Extended Free/Busy Lists.
- Free/Busy Server
- HTTP server, can be an independent HTTP server, an apache client/sub-process, or based upon the Cyrus CalDAV server. Requests authentication from user and with that authentication provides the most detailed free/busy information for the target user (XFB, SFB, None) based upon the cache ACLs and system settings (SFB available anonymously?)
Cache
All cached information shall be stored in IMAP using IMAP ACLs for access control like the rest of Kolab.
The structure of directories shall be:
shared/freebusy[@domain.tld] shared/freebusy/<user>[@domain.tld]
user/<user>/freebusy[@domain.tld]
where all directories shall be of new type 'freebusy' containing one or more objects of type 'freebusy'.
This right now has two new types for freebusy. The folder is probably inevitable (is it?), but the object type might be calendar, perhaps. Christian?. Yes, iCalendar vFreebusy objects.
Partial lists can be updated by making use of x-uid and only updating changed events (respectively remove/add events from the list).
Folders
- shared/freebusy[@domain.tld]
- Contains the aggregated Simple Free Busy information for all users, one object containing one complete SFB object for one user, as it would be served for any regular authenticated or anonymous free/busy request.
- Only the freebusy service user MAY write to this folder
- For installations where free/busy information should be served to anonymous requests from the internet, a service user might be set up for this purpose.
- shared/freebusy/<user>[@domain.tld]
- This folder is created for a user to share Extended Free Busy information with other users, granting these users (or the 'anonymous' user[1]) read access to this folder.
- user/<user>/freebusy[@domain.tld]
- The folder for partial free/busy information in Extended Free Busy or Simple Free Busy format (always choose the most detailed format available, may be limited to SFB for externally imported resources), one object per resource where a resource is one of
- A calendar on the local server
- A calendar on a remote server
- The aggregated/complete free/busy information from a remote server
Configuration
Configuration resides in
- The permissions on shared/freebusy[@domain.tld] folder (for global options on Simple Free Busy)
- The existance of the shared/freebusy/<user>[@domain.tld] folder
- The folder ACLs for shared/freebusy/<user>[@domain.tld]
- The free busy configuration objects according to KEP:9 in the users Configuration folder hierarchy
- These objects will typically provide information which calendars or free/busy information to access on which server and how
- OPTIONAL: Free busy list configuration objects according to KEP:9 in user/<user>/freebusy[@domain.tld] detailing which named lists to generate from which partial lists.
Free/busy object
The individual objects in the folders of 'freebusy' type shall carry the following meta information:
- type: Simple or Extended Free Busy Information (not required)
The differentiation is not required, either extended information is available or not.
- user: User ID of the user for which this free/busy information is valid (see organizer property)
- name: Symbolic name for this free/busy information which is used (a) for the user interface when configuring the free/busy system, and (b) for the free/busy URL (stored as Mime-Header)
Free/busy information is typically accessed through URLs such as http(s)://my-domain.de/freebusy/<user>/<name>.ifb which allows to have more than one free busy list per user. This allows for scenarios where functional users or resources can provide different sets of free/busy information.
- default: Boolean value whether this is the free/busy object that should be served as the generic free/busy list for requests to http(s)://my-domain.de/freebusy/<user>.ifb (stored as Mime-Header)
Kolab Object Storage Format
The partial as well as the aggregated lists shall be stored as xCal vfreebusy objects wrapped in a Kolab-Object Mime Message.
property-freebusy = element freebusy {
element parameters {
element fbtypeparam { element text { BUSY } },
element x-event {
element x-summary ?,
element x-uid ?,
element x-location ?
} ?
},
value-period+
}
- one freebusy property per event
- multiple periods for recurring events (within the dtstart/dtend range)
- x-properties for XFB capabilities, ultimately allowing to get to the blocking event using the uid
vfreebusy = element vfreebusy {
element properties {
element uid { text-uid },
element dtstamp { #Last modification date },
element dtstart { #Start date } ?,
element dtend { #Start date } ?,
element organizer { #user CN },
property-freebusy *
}
}
- "uid": UID of the vfreebusy object
- "dtstamp": timestamp when the freebusy object was generated
- "dtstart"/"dtend": timeframe for which the freebusy data is valid
- "organizer": cn of the user for which the data was generated
element icalendar {
element vcalendar {
element properties {
element prodid { #Product ID },
element version { #xCal Version },
element x-kolab-version { #Kolab XML Version },
element method { element text { PUBLISH } }
},
element components {
vfreebusy
}
}
}
- The aggregated list have the same format but contain a list of partial vfreebusy object uids as mime header to check if the object needs regenerating.
Generator
The generator SHALL always run with the credentials of the user it is generating partial free/busy information for. It SHALL only access the local server through properly secured and authenticated IMAP.
As the only component in the system it must be capable of handling time zones including standard time vs DST and calculate recurrences.
The generator SHOULD be triggered
- when the data in any relevant resource has changed
- on regular intervals
- (since external resources may have changed without notifying us, and since no change may have occured and the free/busy time window may eventually have moved into the past)
This can be achieved by
- clients triggering the generator, e.g. web client, native clients, or ActiveSync calling a particular URL, possibly through the server itself
- (in the future) message bus action from Cyrus
The generator is the most resource intensive component. Technologies that could implement this function include Akonadi and its components.
Because this is the most resource intensive task, regeneration SHALL only take place upon necessity (older than <n> days, where <n> is a system configuration parameter, or changed).
The generator should be able to launch agents that retrieve information from other resources:
The generator could be implemented as Akonadi-Proxy-Agent operating on top of an Akonadi-IMAP-Resource. Further plugins could be added as F/B Retrieval Agents, getting published f/b information from various sources. As the IMAP-Resource would be running under user credentials, the Agent to get the could get to all its required configurations, as well as having access to the partial f/b list storage folder. This agent could then be used on the server as well as the client. The f/b generation would be triggered by the arrival of new objects in the imap store, where the IMAP sync can be triggered manually, by a time interval or PUSH (needs to be implemented first).
The generator requires a configured timeframe for which recurrences should be expanded (which are potentially endless). It probably would also make sense to limit the used events to that timeframe (who needs f/b of 10year old events).
Generator Agents
Generator agents receive
- the credentials of the user they are running for on the local server (allowing them to write partial free/busy lists via IMAP to the local server)
- the credentials of the account they are supposed to retrieve free busy data from in order to place it into the local cache for partial free busy lists of this server
The simplest agent would be a Kolab Free Busy Agent that uses IMAP to connect to a remote Kolab server, pull down the respective XFB list and then use IMAP to store it on the local server.
More complex agents would use the various Microsoft and other protocols and ways of accessing free busy data to then store them via IMAP in the partial free busy container on the local server.
Aggregator
The aggregator SHALL always run as the freebusy service user.
As recurrences have already been dealt with by the generator, the aggregator can be comparatively simple. It should connect to the local server via IMAP, check for special named free busy list configurations, and then generate all respective lists. A run of the aggregator might look as follows:
- Connect to server via IMAP
- Request all folders that contain partial free busy information and iterate:
- Get last change & configuration for named free busy lists
- Check whether generated lists are still up to date, if yes continue iteration with next user
- For each configuration (use all if none and for default):
- Assemble all partial lists into XFB list, always using the best data available
- (there may be overlap between lists due to re-import between servers and overlapping events. if there is a busy block with XFB information and a busy block with the same parameters purely as SFB information, take the XFB information. Also, the most busy value wins - a person with overlapping 'busy' and 'tentative' areas is 'busy' in the overlap.)
- Store XFB list into shared/freebusy/<user>[@domain.tld] via IMAP
- Strip subject lines to get SFB information
- Store SFB list into shared/freebusy[@domain.tld] via IMAP
The format of the aggregated list could just be plain old iCal, as that is what free busy requestors expect. Should be clarified.
IMO we rather store them as xCal as well, as we need that parser as part of libkolabxml anyways and I expect Kolab clients to consume the f/b lists through IMAP anyways (where they can use libkolabxml and have offline functionality). The server needs to do the conversion this way, but that can be wrapped in a library function.
The aggregator can be launched via cron job, message bus or any other mechanism. It should run with the granularity of actuality that is desired for the free busy information.
Server
The server SHALL always run on a least priority system user, obtaining credentials of the user requesting free busy information for the actual request.
Where those credentials are enough to obtain XFB information, the server shall provide the user with XFB information. Otherwise SFB information shall be provided.
System configuration may also make SFB information available to unauthenticated requests, in which case a service account should be provided in configuration.
Where a properly authenticated request has occured for free busy by a local user, the server SHALL also trigger the generator for that user before terminating.
The Server mainly provides a way for clients to obtain the published freebusy information over HTTP, and is therefore an additional service for non-Kolab-Clients (which get the same data through IMAP). Since XFB is a custom Kolab-Extension I see no reason to provide XFB here.
References / Footnotes
- ↑ The 'anonymous' user authenticates through the ANONYMOUS SASL mechanism and is therefore an 'unauthenticated' user rather then 'any authenticated' user (anyone)
