Open Source im professionellen Einsatz

CalDAV soll der Groupware verschiedener Hersteller zu Interoperabilität verhelfen

Auf der Suche nach dem Groupware-Standard

Ob TCP/IP oder das Open-Document-Format: Offene Standards sind in den letzten Jahren auf dem Vormarsch. Nur in Sachen Groupware scheint bisher jeder sein eigenes Süppchen zu kochen: Schier unmöglich, mit dem Benutzer einer anderen Kalender-Lösung einen Termin per Software zu vereinbaren. Der Standard CalDAV soll nun für Abhilfe sorgen.

Gemeinsam einen Termin zu finden, ist oft nicht leicht, und wenn ein ganzes Team von Mitarbeitern zusammenkommen soll, hilft oft nur der beherzte Griff zum Telefon oder Handy. Mit moderner Groupware-Software sieht das allerdings anders aus. Der Organisator lädt die gewünschten Teilnehmer ein, und startet die Terminsuche. Die Software zeigt automatisch nur die Termine an, an denen alle eingeladenen Kollegen auch frei sind. Das gilt jedoch nur unter bestimmten Voraussetzungen: Alle Teilnehmer müssen das gleiche Groupware System verwenden, Interoperabilität gibt es faktisch nicht. Der Zugriff auf Kalender anderer Organisationen scheitert derzeit an fehlenden Standards für den Datenaustausch.

Frühe Ansätze

Das Problem ist nicht neu, schon 1996 rief Netscape eine Arbeitsgruppe ins Leben, aus der später die Arbeitsgruppe Calendaring and Scheduling CalSch der Internet Engineering Task Force IETF hervorging. Die Arbeitsgruppe verfolgte bis 2004 im wesentlichen die Spezifikation von Kalenderdaten mit dem Ziel, diese austauschbar zu machen. Dafür wurden drei Ziele angestrebt:
- Entwurf eines Datenmodells und einer textbasierten Darstellungsform von Kalenderereignissen
- Transport von Kalenderdaten über E-Mail und LDAP
- eine allgemeingültige Spezifikation in Form eines Protokolls für Kalenderzugriff und Terminplanung

Die Arbeitsgruppe orientierte sich an dem bestehenden VCAL Dateiformat und brachte nach nur zwei Jahren die RFC 2445 mit der Definition des Kalenderdatenformats ICAL (Internet Calendaring and Scheduling Core Object Specification) hervor. ICAL-Dateien mit der Dateinamenserweiterung .ics enthalten im Klartext Uhrzeit, Datum, Dauer und Metainformationen eines Termines. Die Standardisierung macht die Dateien grundsätzlich beliebig austauschbar, zum Beispiel über das iCalendar Message-Based Interoperability Protocol (iMIP), ein ebenfalls von CalSch entwickelter Standard für das Senden von Einladungen und Terminen per E-Mail.

Das Calendar Access Protocol (CAP) sollte als Übermittlungsprotokoll für Kalenderdaten den Datenaustausch zwischen beliebigen Groupwareservern ermöglichen. Es orientierte sich dazu an Protokollen wie POP und IMAP und wurde zunächst kontinuierlich weiterentwickelt. Nach 2001 kam das Projekt allerdings zum Stillstand, die Arbeitsgruppe wurde von der IETF mangels Fortschrittes eingestellt.

Apple verwendet WebDAV

Der Grund dafür nicht nur lag in der mangelnden Akzeptanz für das komplexe Modell, sondern auch in der wachsenden Konkurrenz: Apple präsentierte 2002 als erster Hersteller eine ICAL-basierte Kalenderanwendung namens iCal, die das Speichern der Termine auf Webservern erlaubte. Die Anwendung verwendete WebDAV, um Lese-und Schreibrechte zu verwalten und Kalenderdaten zu veröffentlichen.

Apples Kalenderanwendung iCal setzte als erstes Programm das ICAL-FOrmat zusammen mit WebDAV ein.

Das "Web-based Distributed Authoring and Versioning Protokoll" WebDAV (RFC 2518 und RFC 3744) setzt auf HTTP auf und bietet neben Erstellen, Löschen, Verändern und Locking von Dateien auch die Möglichkeit, Metadaten wie Versionsnummern zu speichern. Benutzer konnten so gemeinsam Termine verwalten und Gruppentermine anlegen. Da die meisten Webserver WebDAV unterstützen, war ein neues Protokoll wie CAP nicht mehr notwendig. Ical über WebDAV verbreitete sich rasch, Apple versetzte CAP quasi den Todesstoß.

Anstoß zu CalDAV

Doch auch wenn die Kombination ICAL/WebDAV Vorteile gegenüber CAP hatte, eignete sie sich mangels effizienter Suchmechanismen nur beschränkt für den Einsatz in Unternehmen mit vielen Mitarbeitern und einer dementsprechend hohen Anzahl von Kalendern. Der Server liefert nur Daten, die Logik für Suchanfragen und Terminplanung muss komplett von der Kalenderapplikation übernommen werden. In vielen Szenarien ist es jedoch wünschenswert, dass der Server Abfrage und Suche übernimmt. Da das Gespann Ical/WebDAV das nicht leisten kann, wurde das CalDAV Protokoll geboren. Lisa Dusseault von der Open Source Applications Foundation OSA reichte 2003 einen Entwurf an die IETF ein, und schnell fanden sich zahlreiche namhafte Hersteller, die das Projekt unterstützten.

Das CalDAV Protokoll sollte folgende Fähigkeiten abbilden:
- Pflege des Kalenders durch den Benutzer (lesen, schreiben, mehrere Kalender parallel)
- Abfragen: Clients oder Personen sollen Kriterien abfragen können und Kalender durchsuchen können, um beispielsweise Frei/Belegt-Informationen zu erhalten.
- Berechtigungen: Benutzer sollen einstellen können, wer welche Aktionen im Kalender ausführen darf.

Nach fast vierjähriger Arbeit wurde Mitte März 2007 die RFC 4791 fertig gestellt und CalDAV als erstes Datenaustauschformat für Kalenderdaten festgelegt. Einen Einblick in das Protokoll gibt der Kasten "Ein CalDav-Dialog".

Im Kopf der RFC tauchen als unterstützende Firmen Apple und Oracle auf, beides Hersteller großer Business-Groupware Lösungen und Unterstützer des Calconnect Consortiums. Diese Organisation verfolgt unter tatkräftiger Hilfe zahlreicher Big Player das Ziel, Kalenderdaten und Terminplanung interoperabel zu gestalten. Die Liste der Mitglieder liest sich wie ein Who is Who der Hersteller von kommerzieller Collaboration Software: Neben Oracle und Apple finden sich hier IBM, Google, Novell, die Mozilla Foundation, OSAF, diverse Universitäten und wissenschaftliche Institute wie das MIT oder das Jet Propulsion Lab der NASA. Microsoft ist nicht dabei.

Ein CalDav-Dialog

Ein Client fragt den Server "cal.example.com" nach Frei/Belegt-Informationen
für den Kalendern des Benutzers "bernard" unter "/bernard/work"
im Zeitraum 04.01.2006 14:00 und 05.01.2006, 22:00 (diese Beispiele
stammen aus RFC 4791):

REPORT /bernard/work/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:time-range start="20060104T140000Z"
end="20060105T220000Z"/>
</C:free-busy-query>

Der Server antwortet kurz und knapp, mit Frei/Belegt Informationen für
diesen Zeitraum: um 15:00 und um 19:00 am 04.01. stehen bereits Termine
im Kalender, einer davon (15:00) ist als "Tentative" gekennzeichnet.

HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: text/calendar
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VFREEBUSY
DTSTAMP:20050125T090000Z
DTSTART:20060104T140000Z
DTEND:20060105T220000Z
FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
FREEBUSY:20060104T190000Z/PT1H
END:VFREEBUSY
END:VCALENDAR

In Calconnects Presseerklärung zur CalDAV-RFC vom 20. März 2007 lobt Don Deutsch (Vice President Standards Strategy and Architecture, Oracle) CalDAV als "aufregendste Entwicklung in den vergangenen 12 Jahren unseres Engagements für offene Kalenderstandards".

Die Großen sind an Bord

Die proprietären Hersteller scheinen die Notwendigkeit erkannt zu haben. Zahlreiche Quellen belegen, dass gerade die Großen wie IBM, Oracle und Apple offene Formate als den Schlüssel zur Zukunft der Groupware sehen. Und auch der Open-Source-Welt kommt die Öffnung der kommerziellen Software zu einem freien, standardisierten Format gelegen.

Propretäre Groupware-Produkte sprechen dank CalDAV mit Open-Source-Clients: Dieter Fritzsche von Bynari sagte gegenüber Linux-Magazin Online: "Wir unterstützen CalDAV in unserem Webclient 5.0, um die Mozilla Programme Lightning und Sunbird sowie Evolution mit Daten zu versorgen." CalDAV wird so nach Angaben des Herstellers bereits seit Version 4.3 gemäß den RFC-Entwürfen unterstützt.

Scalix, selbst in der Calconnect Gruppe aktiv, arbeitet ebenfalls seit geraumer Zeit an der CalDAV-Unterstützung und wird voraussichtlich mit der übernächsten Release Anfang Mai serverseitig CalDAV anbieten. Auch Zarafa hat früh reagiert und bereits den Drafts der RFC entsprechend CalDAV grundlegend implementiert. Das Release Ende Juli soll weitgehende CalDAV-Unterstützung beinhalten. Wie Scalix und Bynari orientiert sich auch Zarafa dabei an den Features der Clients und testet beispielsweise mit Thunderbird/Lightning.

Auch Lightning, die Kalender-Erweiterung für Mozilla Thunderbird, spricht CalDAV.

Der Teufel steckt in der Implementierung

Auch der Client des vom Osnabrücker Consulting-Unternehmen Intevation mitentwickelten Groupware-Servers Kolab kann Termine und Frei-/Belegt-Informationen aus CalDAV-Datenquellen einbinden.

Allerdings verweist Bernhard Reiter von Intevation auch auf mögliche Probleme, die ein Protokoll wie CalDAV mitbringen kann. Die Entwickler von Kolab hatten zu Beginn auf ICAL Dateien gesetzt, praktische Probleme mit Anwendungen zwangen die Entwickler dann allerdings zum Umstieg auf das eigene Kolab-XML-Format: "Ich bin ein CalDAV Skeptiker. (...)", so Bernhard Reiter. "Die richtigen Schwierigkeiten für Kompatibilität liegen nicht in der Übertragung von Daten sondern in der Festlegung des Verhaltens der Anwendungen." Offensichtlich besteht bei diversen Anwendungen noch Nachholbedarf bei der standardkonformen ICAL-Interpretation. Kolab speichert Kalenderdaten in einem eigenen XML-Format als E-Mail Anhang im IMAP-Storage.

Helge Hess vom Opengroupware-Projekt war selbst an der Gestaltung der RFC 4791 beteiligt und hält CalDAV für einen wichtigen Schritt. Zum allerersten mal sei ein Protokoll, das eine Anbindung von Kalenderdaten ermöglicht, standardisiert worden. Und ICAL ist heute das einzige Format, dass allen gängigen Clients und Servern unterstützt wird.

Allerdings glaubt auch er nicht daran, dass der Standard komplett implementiert werden wird: "Die Hersteller werden wohl [nur] das Subset implementieren, das die verbreiteten Clients (Sunbird, Apples iCal) an CalDAV implementieren. Native Clients benötigen typischerweise nur einen Bruchteil des Standards, zum Beispiel sind die serverseitigen Suchfunktionen hier überflüssig, da der Client dies ohnehin selbst auf seinem Offline-Cache implementiert." Metainformationen wie Serientermine oder Wiederholungen seien in der RFC immer noch recht komplex umgesetzt, meint Hess und rechnet auch aus diesem Grund nicht mit vollständigen CalDAV-Server-Implementationen.

Wer darf was?

Kopfschmerzen bereiten ebenfalls noch Zugriffsrechte und Berechtigungen: Während Authentifizierung und Verschlüsselung durch das HTTPS-Protokoll und SSL abgedeckt werden können, bestehen derzeit Probleme bei der Implementation der Zugriffsrechte, da hier viele verschiedene Rechtemodelle und Freigabeschemata existieren. Diese unter einen Hut zu bringen ist eine scchwierige Aufgabe.

Helge Hess verspricht sich daher viel von der aktuellen Entwicklung rund um den Standard GroupDAV, eine schlanke, performantere Variante von WebDAV speziell für Groupware-Anwendungen. GroupDAV ist derzeit im Stadium eines Entwurfs, an dem Opengroupware und KDE tatkräftig arbeiten.

KDE (im Bild Kontact) und Opengroupware arbeiten am Standard GroupDAV.

Gute Zukunftsaussichten für CalDAV

Durch CalDAV wird ein großer Teil der Arbeit aus dem (proprietären) Client in den Server verlagert. Im Zeitalter von Mobilgeräten und Webclients ist dies durchaus von Vorteil: Groupware-Kommunikation wird dadurch einen Schritt näher an klassische Server-Client Architektur rücken, wo der Client nur für die Darstellung zuständig ist. Auch wenn der CalDAV Standard nur teilweise umgesetzt wird, ist das doch ein Schritt, den Helge Hess begrüßt: "Ein teilweise inmplementierter Standard ist immer noch besser als gar kein Standard."

Vielleicht wird die Terminplanung mit Hilfe von CalDAV irgendwann über Unternehmensgrenzen hinweg möglich. Die Hersteller von proprietärer und Open-Source-Groupware sind sehr optimistisch und engagieren sich dafür, CalDAV weiterzubringen. Offen ist allerdings, ob sich die Hersteller auf eine RFC-konforme Interpretation für komplexere Einträge einigen können. Ob die Arbeit dann vom Server oder vom Client erledigt wird, dürfte dem Anwender dann egal sein, solange er seine Termine auch mit Mitarbeitern anderer Unternehmen planen kann. (mhu)

Ausgabe 10/2014

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook