Subject: [.plan] IMAP, WebDAV, CardDAV und CalDAV
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Wed, 12 Dec 2012 22:03:02 +0100

Auch wenn ich fuer mich Mail zum Fundament meiner "Unified Messaging"-
Strategie gewaehlt habe, ich also so ziemlich alles in Mails speichre,
was irgendwie Sinn macht -- von Mails, ueber meine Artikel bis hin zu
Kontakten und meiner TODO-Liste -- und daher die Frage, wie Mails zu
speichern, zu uebertragen und zu verfassen/bearbeiten sind, fuer mich
einen grossen Stellenwert hat, so hat sich die Welt da draussen ja
eher fuer HTTP, diverse krude Formate und leckerer XML(artiger) Magie
entschieden. 

Den IMAP-Teil der Ueberschrift spare ich mir fuer einen Artikel ueber
mein aktuelles Mail-Setup auf, weil er evtl. doch etwas groesser
werden koennte. Hier moechte ich nur kurz etwas zu CalDAV und CardDAV
sagen mit den ich mich nun gezwungener Massen auseinandersetzen
musste. Weil ich immer gegen die Cloud-Anbieter schiesse, musste ich
jetzt mal Farbe bekennen: "Du sagst immer, das geht auch anders.
Entweder du zeigst jetzt wie oder wir nehmen halt, was wir kriegen und
syncen unsere Kontakte mit Google, Apple oder $Clouddienst."

== Das Format ==

Das Format um Kontakte zu exportieren/importieren habe ich hier schon
mehrfach angesprochen und nennt sich vCard [0]. Es ist standardisiert
und wird von den meisten Smartphones, Mailclients und auch sozialen
Netzwerken unterstuetzt -- bei letzteren ist zumindest die Import-
moeglichkeit vorhanden und leicht zu finden, Export geht meist auch,
aber nur ueber Umwege. Es ist ein simples Plaintext-Format, dass
zwischen zwei Anfangs- und Endmarken Eigenschaften, ggf. zusaetzliche
Attribute und deren Werte festhaelt, z.B.:

> BEGIN:VCARD
> VERSION:2.1
> N:Gump;Forrest
> FN:Forrest Gump
> TEL;WORK;VOICE:(111) 555-1212
> TEL;HOME;VOICE:(404) 555-1212
> [...]
> EMAIL;PREF;INTERNET:[email-masked]
> REV:20080424T195243Z
> END:VCARD

Die Dateiendung ist meist .vcf und es ist moeglich auch mehrere
Kontakte in einer Datei zu haben, was Im- und Export sehr vereinfacht.

Was etwas problematisch ist, ist dass es neben der weit verbreiteten
Version 2.1 -- viele Telefone -- auch noch 3.0 und 4.0 gibt, deren
Verbreitung und Unterstuetzung noch etwas hinterherhinkt. Dazu gesellt
sich inzwischen auch noch ein XML-Dialekt -- weil: alles ist ja
besser, wenn man XML drauf wirft --, xCard, der z.B. von XMPP
verwendet wird.

Im gleichen Atemzug wurde neben vCard auch noch der vCalendar [1] bzw.
kur vCal eingefuehrt, dessen Datenformat etwas komplexer ist, aber
sich analog zu vCard verhaelt. Prominentestes Beispiel ist Apples
iCal, dessen Langnamen -- iCalendar -- inzwischen der offizielle Name
fuer vCal ist. Intern spricht das Format weitehrin von VCALENDAR.

Neben einzelnen vEvents -- also typischen Kalender-Eintraegen -- gibt
es auch noch Informationen ueber die Free/Busy-Time, TODO-Listen-
Eintraege (VTODO) oder ganze Journals (VJOURNAL) -- und ja, ich habe
mir schon ueberlegt meinen "Blog" komplett als vJournal-Eintraege
anzubieten.

== Das Protokoll ==

Das HTTP so beliebt ist, ist natuerlich eine grosse Luege, denn
beliebt sind (bzw. waren) lange eignetlich nur wenige Teile von HTTP.
Konkret wurde sehr viel ueber HTTP GET abgewickelt, was eigentlich
andere HTTP Methoden laufen sollte. Im Web besinnt sich ein Teil
dieser Moeglichkeiten, was unter anderem unter dem Stichwort REST [5]
laeuft -- auch wenn das wiederum deutlich mehr beschreibt. 

Im Gegensatz zu dem weitverbreiteten "alles mittels GET" Ansatzes,
gibt es auch noch die Erweiterung von HTTP durch eigene, inzwischen
auch wieder standardisierte Methoden. So bietet WebDAV [2]
beispielsweise zusaetzliche Methoden an, die fuer eine bessere
Ablage/Upload/Download/Verwaltung von remoten Dateien sehr nuetzlich
sind. Man kann also einen WebDAV-Server wie jeden Netzspeicher a la
NFS- oder Sambashares nutzen. Prinzipiell ist das natuerlich auch mit
reinem HTTP moeglich -- Stichwort HTTP-FS -- aber bei weitem nicht so
komfortabel.

Ich bin zu unwissend, um genau sagen zu koennen, ob es besser ist ein
eigenes, genau auf die Anforderungen zugeschnittenes Protokoll zu
nutzen, oder eben eine solche Erweiterung zu nutzen. Fuer mich sieht
das ja einfach nach einer weiteren Ebene in der Abstraktionspyramide
aus. Wie dem auch sei: WebDAV bietet jedenfalls neben Features wie
SSL, Versionierung und feiner einstellbaren Zugriffsrechten das
Killefeature schlechthin: Es kommt mit restriktiven Firewalls, die nur
das Web durchlassen klar. Ist natuerlich keine Sache des Protokolls
selbst, sondern eher des aktuellen Zeitgeist, wo Admins der Meinung
isnd HTTP so im Griff zu haben, dass sie das gut absichern koennen,
insbesondere weil ihre Nutzer ja sowieso nur das Web brauchen. Gut,
aber das ist nen anderes Thema...

Gegenueber diversen Clouddiensten, die zwar irgendwie doch durch
Firewall und Webproxy nach aussen kommen, scheint der Vorteil auf der
Hand zu liegen: WebDAV ist ein Standard. Man kann eigene Server
aufmachen und ist damit nicht an einen Anbieter gebunden. Es gibt eine
Vielzahl an Clients, aus der man sich einen aussuchen kann -- meistens
ist im Basissystem schon ein passender enthalten -- oder man
entwickelt eben einen an eigene Vorstellungen angepassten Client
selbst. 

Aber auch WebDAV moechte ich erstmal gar nicht weiter eingehen, denn
das eigentliche Thema -- das wie ueblich nur noch einen kleinen Teil
des Artikels ausmacht -- soll CalDAV und CarDAV sein. Beides sind --
wie die Namen schon vermuten laesst -- auf WebDAV und damit HTTP
aufbauende Standards, die sich nicht nur um irgendwelche Dateien
kuemmern, sondern speziell um Kontakte (vCards => CardDAV [3]) bzw.
Kalender (iCal => CalDAV [4]).

Ohne mich naeher mit den eigentlichen Protokollen beschaeftigt zu
haben, scheint es wie bei HTTP und HTML ne Mischung aus Plaintext fuer
den Headerbereich und XML fuer den sendenden Client zu geben. Die
zurueckgelieferten Daten sind im o.g. vCard- bzw. iCal-Fomat; momentan
also nocht Plaintext. Ich weiss gerade auch nicht, ob man z.B. auch
direkt xCards anfordern kann. Ich lass auch die ganze
Push/Pull-Problematik weg, das einzige was etwas unschoen ist, ist
dass prinzipbedingt mein Kontakt immer mehr ueber sich selbst weiss,
als ich. D.h. wenn er seine Adresse aendert, weiss das erstmal nur er.
Wie dies Aenderung dann zu mir bzw. zu meinem Server kommt ist erstmal
offen. Bei Unternehmen ist das ja -- zumindest was die Mitarbeiter
angeht -- klar. Da gibt es ja eine Hierarchie, eine zentrale Stelle,
die solche Daten generiert, aktualisiert und verwaltet. Doch schon bei
Kontakten nach aussen bzw. bei einer eher privaten Nutzung wirds
sumpfig: Soll ich nen oeffentlich schreib (aber nicht lesbaren) Teil
haben, auf den Kontakte updates pushen? Oder schicken die mir dann
Mails (wenn sie dran denken)? Finger (yay) und XMPP haben sich des
Problems dadurch entledigt, dass die Clients der Nutzer
Kontaktinformation an ihren Server veteilen koennen, und der jeweilige
Interessent dann zumindest diesen oeffentlichen Teil lesen kann, im
Prinzip also bei jedem Verbinden seine lokal gespeicherten
vCards/xCards aktualisieren kann. Problem hier: Kaum jemand machts und
ich weiss auch nicht ob ich es aus Datenschutzgruenden empfehlen
sollte. Aber auch das ist erstmal egal. CalDAV und CarDAV sind sowohl
standardisiert als auch breit verfuegbar. Wenn jemand sich nicht eine
eigene Loesung frickeln will, ist das der "way to go".

== Die Software ==

Fuer Desktops gibt es eigentlichen Clients wie Sand am Meer,
interessanter ist der mobile Bereich. Die ganzen iDevices sprechen
CalDAV und CardDAV in neueren Versionen schon von Haus aus, Android
noch nicht -- warum auch, dann wuerden die Leute ja nicht mehr zur
Google Experience greifen. Von daher lohnt sich nen Blick auf die
diversen Vergleichs-Listen [6][7]. Kostenpflichtig -- mit der Hoffung
nach 1.0 Open Source Software zu werden -- sind CalDAV-Sync [8] und
CardDAV-Sync [9], das ganze in komplett frei und GPLv3 infiziert gibt
es unter dem Namen aCal [10]. Bei letzterem ist aber schade, dass es
zum einen so viele Berechtigungen anfordert und zum anderen, dass es
sich nicht sehr gut in die bestehende Kontakt- und Kalender-Apps
integriert. Fuer Leute mit Custom-ROMs vielleicht nicht ganz so
wichtig, aber wer nur nen Stock-Android nutzt wird da eher
abgeschreckt. Die GUI gefaellt mir auch ueberhaupt nicht, aber man
kann ja nicht alles haben.

Jetzt wirds aber endlich interessant. Wie sieht die ganze Sache den
serverseitig aus? Auch hier verweise ich erstmal auf Wikipedia und
ihre Vergleichs- und Informationsseiten. Das erste was auffaellt:
CardDAV und CalDAV gibt's meist im Doppelpack, was ja auch naheliegend
ist.

OwnCloud [12] ist eigentlich die Antwort, mit der ich mir den ganzen
Text haette sparen koennen. Fuer den Endanwender bietet es eine auf
PHP basierende all-in-one Loesung. WebDAV, CalDAV, CardDAV (alles wohl
basierend auf SabreDAV [13]) und zu allem noch ne aufgeraeumte
Weboberflaeche. Zusaetzlich kann man auch noch ueber diverse Plugins
weitere Funktionalitaet nachruesten: Musikplayer, Feedreader usw. Die
Installation sollte recht einfach sein, es gibt auch genuegend
Anleitungen -- auch in Videoform -- dazu. 

Die andere Alternative, die oft genannt wird, wenn man etwas weniger
zusaetzliche Features braucht und nur an einer reinern CalDAV/CardDAV-
Loesung interessiert ist, nennt sich DaviCal [14]. Auch sie basiert
auf PHP und sollte aehnlich leicht einzurichten sein, wie OwnCloud.

Beide bzw. alle drei Loesungen haben mir nicht so zugesagt, weder
wollte ich ein eigenes Webfrontend dazu, noch bin ich sonderlich
erpicht auf PHP. Als Alternativen habe ich mir deswegen Radicale [16]
und Apples Calendar (and Contact) Server [15] angeschaut. Beide sind
(grossteils) in Python geschrieben, sind reine Server und
unterscheiden sich aber im Funktionsumfang bzw. im Entwicklungsziel.
Waehrend Apple's Loesung wohl nahezu die komplette Bandbreite abdeckt
und (hoffentlich) gegen die Standards geschrieben wird, versucht man
bei Radicale nicht jeden Furz aus den RFCs umzusetzen, sondern
entwickelt gegen die ind er Praxis anzutreffenden Client-
Implementierungen. Das klingt erstmal schlecht, macht aber durchaus
Sinn, wenn man sich mal selbst durch die ganzen Feinheiten der
verschiedenen noetigen RFCs wuehlt.

Die Basisinstallation ist bei beiden relativ einfach und beschraenkt
sich bei den meisten Distributionen darauf, dass das entsprechende
Paket installiert wird und man den Dienst startet. Abzueglich der
Downloadzeit war Radicale selbst unter Windows in knapp fuenf Minuten
aufgesetzt: PortablePython runterladen, Radicale runterladen, alles
entpacken und ein `python radicale.py`. Auch wenn ich sonst ein ganz
schoener RFC-Juenger bin, gefaellt mir der Ansatz von Radicale
eigentlich extrem gut. Auch die Tatsache, dass es bis auf Pyhton keine
Dependencies mitschleppt bzw. diese nur fuer Zusatzfeatures braucht,
ist sehr ansprechend. Ich muss daran noch etwas rumprobieren, ob damit
alles noetige auch in gewuenschter Art funktioniert, aber vor erst
habe ich mich fuer Apple's Calendar Server entschieden; full-featured
und RFC-Konformitaet sind schon zwei sehr gute Argumente.

== Die Konfiguration ==

Eigentlich der Punkt, den die meisten Ressourcen und Blogs im Internet
am ausgedehntesten Behandeln. Wir gings eher um einen groben
Ueberblick, wie das alles zusammenspielt und woher das kommt, deswegen
moechte ich hier auch nicht mehr schreiben. Einfach mal eine VM
erstellen und ausprobieren; grob:

 - Paket installieren (im Falle von Debian leider eine etwas
   abgehangene Version...)
 - DocumentRoot anlegen; Berechtigungen vergeben (caldavd:caldavd)
 - Platte mit 'user_xattr' mounten
 - /etc/caldavd/accounts.xml anpassen (Struktur ergibt sich beim
   lesen; ich muss noch schauen, wie man das direkt an PAM koppeln
   kann bzw. ob das ueberhaupt eine gute Idee ist)
 - /etc/caldavd/caldavd.plist anpassen (die wichtigsten Einstellungen
   duerften Hostname, BindAddresses, EnableSSL, RedirectHTTPtoHTTPS,
   SSLCertificate, SSLPrivateKey und DocumentRoot sein)
 - Ich finde den Punkt XMPP-Notifier sehr interessant
 - /etc/default/calendarserver anpassen, um den Server standardmaessig
   beim Hochfahren mitzustarten
 - Starten
 - https://hostname:port/calendars/users/username/calendar/ aufrufen;
   je nach Anwendung ggf. mit caldav://

[0] http://en.wikipedia.org/wiki/VCard
[1] http://en.wikipedia.org/wiki/VCalendar
[2] http://en.wikipedia.org/wiki/Webdav
[3] http://en.wikipedia.org/wiki/CardDAV
[4] http://en.wikipedia.org/wiki/CalDAV
[5] http://en.wikipedia.org/wiki/Representational_state_transfer
[6] http://wiki.davical.org/w/CalDAV_Clients
[7] http://wiki.davical.org/w/CalDAV_Clients/Android 
[8] http://dmfs.org/caldav/
[9] http://dmfs.org/carddav/
[10] http://acal.me/wiki/Main_Page
[11] http://caldav4j.googlecode.com/
[12] http://owncloud.org/
[13] http://code.google.com/p/sabredav/
[14] http://www.davical.org/
[15] http://trac.calendarserver.org/
[16] http://radicale.org/