From: Boris Kraut Date: Wed, 12 Dec 2012 22:03:02 +0100 Category: Message-ID: <20121212220302.uUJLzT@silberbruch> Organization: Keywords: Comments: To: undisclosed-recipients: ; Subject: [.plan] IMAP, WebDAV, CardDAV und CalDAV 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:forrestgump@example.com > 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/