1 From: Boris Kraut <krt@nurfuerspam.de>
\r
2 Date: Wed, 12 Dec 2012 22:03:02 +0100
\r
4 Message-ID: <20121212220302.uUJLzT@silberbruch>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: [.plan] IMAP, WebDAV, CardDAV und CalDAV
\r
11 Auch wenn ich fuer mich Mail zum Fundament meiner "Unified Messaging"-
\r
12 Strategie gewaehlt habe, ich also so ziemlich alles in Mails speichre,
\r
13 was irgendwie Sinn macht -- von Mails, ueber meine Artikel bis hin zu
\r
14 Kontakten und meiner TODO-Liste -- und daher die Frage, wie Mails zu
\r
15 speichern, zu uebertragen und zu verfassen/bearbeiten sind, fuer mich
\r
16 einen grossen Stellenwert hat, so hat sich die Welt da draussen ja
\r
17 eher fuer HTTP, diverse krude Formate und leckerer XML(artiger) Magie
\r
20 Den IMAP-Teil der Ueberschrift spare ich mir fuer einen Artikel ueber
\r
21 mein aktuelles Mail-Setup auf, weil er evtl. doch etwas groesser
\r
22 werden koennte. Hier moechte ich nur kurz etwas zu CalDAV und CardDAV
\r
23 sagen mit den ich mich nun gezwungener Massen auseinandersetzen
\r
24 musste. Weil ich immer gegen die Cloud-Anbieter schiesse, musste ich
\r
25 jetzt mal Farbe bekennen: "Du sagst immer, das geht auch anders.
\r
26 Entweder du zeigst jetzt wie oder wir nehmen halt, was wir kriegen und
\r
27 syncen unsere Kontakte mit Google, Apple oder $Clouddienst."
\r
32 Das Format um Kontakte zu exportieren/importieren habe ich hier schon
\r
33 mehrfach angesprochen und nennt sich vCard [0]. Es ist standardisiert
\r
34 und wird von den meisten Smartphones, Mailclients und auch sozialen
\r
35 Netzwerken unterstuetzt -- bei letzteren ist zumindest die Import-
\r
36 moeglichkeit vorhanden und leicht zu finden, Export geht meist auch,
\r
37 aber nur ueber Umwege. Es ist ein simples Plaintext-Format, dass
\r
38 zwischen zwei Anfangs- und Endmarken Eigenschaften, ggf. zusaetzliche
\r
39 Attribute und deren Werte festhaelt, z.B.:
\r
45 > TEL;WORK;VOICE:(111) 555-1212
\r
46 > TEL;HOME;VOICE:(404) 555-1212
\r
48 > EMAIL;PREF;INTERNET:forrestgump@example.com
\r
49 > REV:20080424T195243Z
\r
52 Die Dateiendung ist meist .vcf und es ist moeglich auch mehrere
\r
53 Kontakte in einer Datei zu haben, was Im- und Export sehr vereinfacht.
\r
55 Was etwas problematisch ist, ist dass es neben der weit verbreiteten
\r
56 Version 2.1 -- viele Telefone -- auch noch 3.0 und 4.0 gibt, deren
\r
57 Verbreitung und Unterstuetzung noch etwas hinterherhinkt. Dazu gesellt
\r
58 sich inzwischen auch noch ein XML-Dialekt -- weil: alles ist ja
\r
59 besser, wenn man XML drauf wirft --, xCard, der z.B. von XMPP
\r
62 Im gleichen Atemzug wurde neben vCard auch noch der vCalendar [1] bzw.
\r
63 kur vCal eingefuehrt, dessen Datenformat etwas komplexer ist, aber
\r
64 sich analog zu vCard verhaelt. Prominentestes Beispiel ist Apples
\r
65 iCal, dessen Langnamen -- iCalendar -- inzwischen der offizielle Name
\r
66 fuer vCal ist. Intern spricht das Format weitehrin von VCALENDAR.
\r
68 Neben einzelnen vEvents -- also typischen Kalender-Eintraegen -- gibt
\r
69 es auch noch Informationen ueber die Free/Busy-Time, TODO-Listen-
\r
70 Eintraege (VTODO) oder ganze Journals (VJOURNAL) -- und ja, ich habe
\r
71 mir schon ueberlegt meinen "Blog" komplett als vJournal-Eintraege
\r
77 Das HTTP so beliebt ist, ist natuerlich eine grosse Luege, denn
\r
78 beliebt sind (bzw. waren) lange eignetlich nur wenige Teile von HTTP.
\r
79 Konkret wurde sehr viel ueber HTTP GET abgewickelt, was eigentlich
\r
80 andere HTTP Methoden laufen sollte. Im Web besinnt sich ein Teil
\r
81 dieser Moeglichkeiten, was unter anderem unter dem Stichwort REST [5]
\r
82 laeuft -- auch wenn das wiederum deutlich mehr beschreibt.
\r
84 Im Gegensatz zu dem weitverbreiteten "alles mittels GET" Ansatzes,
\r
85 gibt es auch noch die Erweiterung von HTTP durch eigene, inzwischen
\r
86 auch wieder standardisierte Methoden. So bietet WebDAV [2]
\r
87 beispielsweise zusaetzliche Methoden an, die fuer eine bessere
\r
88 Ablage/Upload/Download/Verwaltung von remoten Dateien sehr nuetzlich
\r
89 sind. Man kann also einen WebDAV-Server wie jeden Netzspeicher a la
\r
90 NFS- oder Sambashares nutzen. Prinzipiell ist das natuerlich auch mit
\r
91 reinem HTTP moeglich -- Stichwort HTTP-FS -- aber bei weitem nicht so
\r
94 Ich bin zu unwissend, um genau sagen zu koennen, ob es besser ist ein
\r
95 eigenes, genau auf die Anforderungen zugeschnittenes Protokoll zu
\r
96 nutzen, oder eben eine solche Erweiterung zu nutzen. Fuer mich sieht
\r
97 das ja einfach nach einer weiteren Ebene in der Abstraktionspyramide
\r
98 aus. Wie dem auch sei: WebDAV bietet jedenfalls neben Features wie
\r
99 SSL, Versionierung und feiner einstellbaren Zugriffsrechten das
\r
100 Killefeature schlechthin: Es kommt mit restriktiven Firewalls, die nur
\r
101 das Web durchlassen klar. Ist natuerlich keine Sache des Protokolls
\r
102 selbst, sondern eher des aktuellen Zeitgeist, wo Admins der Meinung
\r
103 isnd HTTP so im Griff zu haben, dass sie das gut absichern koennen,
\r
104 insbesondere weil ihre Nutzer ja sowieso nur das Web brauchen. Gut,
\r
105 aber das ist nen anderes Thema...
\r
107 Gegenueber diversen Clouddiensten, die zwar irgendwie doch durch
\r
108 Firewall und Webproxy nach aussen kommen, scheint der Vorteil auf der
\r
109 Hand zu liegen: WebDAV ist ein Standard. Man kann eigene Server
\r
110 aufmachen und ist damit nicht an einen Anbieter gebunden. Es gibt eine
\r
111 Vielzahl an Clients, aus der man sich einen aussuchen kann -- meistens
\r
112 ist im Basissystem schon ein passender enthalten -- oder man
\r
113 entwickelt eben einen an eigene Vorstellungen angepassten Client
\r
116 Aber auch WebDAV moechte ich erstmal gar nicht weiter eingehen, denn
\r
117 das eigentliche Thema -- das wie ueblich nur noch einen kleinen Teil
\r
118 des Artikels ausmacht -- soll CalDAV und CarDAV sein. Beides sind --
\r
119 wie die Namen schon vermuten laesst -- auf WebDAV und damit HTTP
\r
120 aufbauende Standards, die sich nicht nur um irgendwelche Dateien
\r
121 kuemmern, sondern speziell um Kontakte (vCards => CardDAV [3]) bzw.
\r
122 Kalender (iCal => CalDAV [4]).
\r
124 Ohne mich naeher mit den eigentlichen Protokollen beschaeftigt zu
\r
125 haben, scheint es wie bei HTTP und HTML ne Mischung aus Plaintext fuer
\r
126 den Headerbereich und XML fuer den sendenden Client zu geben. Die
\r
127 zurueckgelieferten Daten sind im o.g. vCard- bzw. iCal-Fomat; momentan
\r
128 also nocht Plaintext. Ich weiss gerade auch nicht, ob man z.B. auch
\r
129 direkt xCards anfordern kann. Ich lass auch die ganze
\r
130 Push/Pull-Problematik weg, das einzige was etwas unschoen ist, ist
\r
131 dass prinzipbedingt mein Kontakt immer mehr ueber sich selbst weiss,
\r
132 als ich. D.h. wenn er seine Adresse aendert, weiss das erstmal nur er.
\r
133 Wie dies Aenderung dann zu mir bzw. zu meinem Server kommt ist erstmal
\r
134 offen. Bei Unternehmen ist das ja -- zumindest was die Mitarbeiter
\r
135 angeht -- klar. Da gibt es ja eine Hierarchie, eine zentrale Stelle,
\r
136 die solche Daten generiert, aktualisiert und verwaltet. Doch schon bei
\r
137 Kontakten nach aussen bzw. bei einer eher privaten Nutzung wirds
\r
138 sumpfig: Soll ich nen oeffentlich schreib (aber nicht lesbaren) Teil
\r
139 haben, auf den Kontakte updates pushen? Oder schicken die mir dann
\r
140 Mails (wenn sie dran denken)? Finger (yay) und XMPP haben sich des
\r
141 Problems dadurch entledigt, dass die Clients der Nutzer
\r
142 Kontaktinformation an ihren Server veteilen koennen, und der jeweilige
\r
143 Interessent dann zumindest diesen oeffentlichen Teil lesen kann, im
\r
144 Prinzip also bei jedem Verbinden seine lokal gespeicherten
\r
145 vCards/xCards aktualisieren kann. Problem hier: Kaum jemand machts und
\r
146 ich weiss auch nicht ob ich es aus Datenschutzgruenden empfehlen
\r
147 sollte. Aber auch das ist erstmal egal. CalDAV und CarDAV sind sowohl
\r
148 standardisiert als auch breit verfuegbar. Wenn jemand sich nicht eine
\r
149 eigene Loesung frickeln will, ist das der "way to go".
\r
154 Fuer Desktops gibt es eigentlichen Clients wie Sand am Meer,
\r
155 interessanter ist der mobile Bereich. Die ganzen iDevices sprechen
\r
156 CalDAV und CardDAV in neueren Versionen schon von Haus aus, Android
\r
157 noch nicht -- warum auch, dann wuerden die Leute ja nicht mehr zur
\r
158 Google Experience greifen. Von daher lohnt sich nen Blick auf die
\r
159 diversen Vergleichs-Listen [6][7]. Kostenpflichtig -- mit der Hoffung
\r
160 nach 1.0 Open Source Software zu werden -- sind CalDAV-Sync [8] und
\r
161 CardDAV-Sync [9], das ganze in komplett frei und GPLv3 infiziert gibt
\r
162 es unter dem Namen aCal [10]. Bei letzterem ist aber schade, dass es
\r
163 zum einen so viele Berechtigungen anfordert und zum anderen, dass es
\r
164 sich nicht sehr gut in die bestehende Kontakt- und Kalender-Apps
\r
165 integriert. Fuer Leute mit Custom-ROMs vielleicht nicht ganz so
\r
166 wichtig, aber wer nur nen Stock-Android nutzt wird da eher
\r
167 abgeschreckt. Die GUI gefaellt mir auch ueberhaupt nicht, aber man
\r
168 kann ja nicht alles haben.
\r
170 Jetzt wirds aber endlich interessant. Wie sieht die ganze Sache den
\r
171 serverseitig aus? Auch hier verweise ich erstmal auf Wikipedia und
\r
172 ihre Vergleichs- und Informationsseiten. Das erste was auffaellt:
\r
173 CardDAV und CalDAV gibt's meist im Doppelpack, was ja auch naheliegend
\r
176 OwnCloud [12] ist eigentlich die Antwort, mit der ich mir den ganzen
\r
177 Text haette sparen koennen. Fuer den Endanwender bietet es eine auf
\r
178 PHP basierende all-in-one Loesung. WebDAV, CalDAV, CardDAV (alles wohl
\r
179 basierend auf SabreDAV [13]) und zu allem noch ne aufgeraeumte
\r
180 Weboberflaeche. Zusaetzlich kann man auch noch ueber diverse Plugins
\r
181 weitere Funktionalitaet nachruesten: Musikplayer, Feedreader usw. Die
\r
182 Installation sollte recht einfach sein, es gibt auch genuegend
\r
183 Anleitungen -- auch in Videoform -- dazu.
\r
185 Die andere Alternative, die oft genannt wird, wenn man etwas weniger
\r
186 zusaetzliche Features braucht und nur an einer reinern CalDAV/CardDAV-
\r
187 Loesung interessiert ist, nennt sich DaviCal [14]. Auch sie basiert
\r
188 auf PHP und sollte aehnlich leicht einzurichten sein, wie OwnCloud.
\r
190 Beide bzw. alle drei Loesungen haben mir nicht so zugesagt, weder
\r
191 wollte ich ein eigenes Webfrontend dazu, noch bin ich sonderlich
\r
192 erpicht auf PHP. Als Alternativen habe ich mir deswegen Radicale [16]
\r
193 und Apples Calendar (and Contact) Server [15] angeschaut. Beide sind
\r
194 (grossteils) in Python geschrieben, sind reine Server und
\r
195 unterscheiden sich aber im Funktionsumfang bzw. im Entwicklungsziel.
\r
196 Waehrend Apple's Loesung wohl nahezu die komplette Bandbreite abdeckt
\r
197 und (hoffentlich) gegen die Standards geschrieben wird, versucht man
\r
198 bei Radicale nicht jeden Furz aus den RFCs umzusetzen, sondern
\r
199 entwickelt gegen die ind er Praxis anzutreffenden Client-
\r
200 Implementierungen. Das klingt erstmal schlecht, macht aber durchaus
\r
201 Sinn, wenn man sich mal selbst durch die ganzen Feinheiten der
\r
202 verschiedenen noetigen RFCs wuehlt.
\r
204 Die Basisinstallation ist bei beiden relativ einfach und beschraenkt
\r
205 sich bei den meisten Distributionen darauf, dass das entsprechende
\r
206 Paket installiert wird und man den Dienst startet. Abzueglich der
\r
207 Downloadzeit war Radicale selbst unter Windows in knapp fuenf Minuten
\r
208 aufgesetzt: PortablePython runterladen, Radicale runterladen, alles
\r
209 entpacken und ein `python radicale.py`. Auch wenn ich sonst ein ganz
\r
210 schoener RFC-Juenger bin, gefaellt mir der Ansatz von Radicale
\r
211 eigentlich extrem gut. Auch die Tatsache, dass es bis auf Pyhton keine
\r
212 Dependencies mitschleppt bzw. diese nur fuer Zusatzfeatures braucht,
\r
213 ist sehr ansprechend. Ich muss daran noch etwas rumprobieren, ob damit
\r
214 alles noetige auch in gewuenschter Art funktioniert, aber vor erst
\r
215 habe ich mich fuer Apple's Calendar Server entschieden; full-featured
\r
216 und RFC-Konformitaet sind schon zwei sehr gute Argumente.
\r
219 == Die Konfiguration ==
\r
221 Eigentlich der Punkt, den die meisten Ressourcen und Blogs im Internet
\r
222 am ausgedehntesten Behandeln. Wir gings eher um einen groben
\r
223 Ueberblick, wie das alles zusammenspielt und woher das kommt, deswegen
\r
224 moechte ich hier auch nicht mehr schreiben. Einfach mal eine VM
\r
225 erstellen und ausprobieren; grob:
\r
227 - Paket installieren (im Falle von Debian leider eine etwas
\r
228 abgehangene Version...)
\r
229 - DocumentRoot anlegen; Berechtigungen vergeben (caldavd:caldavd)
\r
230 - Platte mit 'user_xattr' mounten
\r
231 - /etc/caldavd/accounts.xml anpassen (Struktur ergibt sich beim
\r
232 lesen; ich muss noch schauen, wie man das direkt an PAM koppeln
\r
233 kann bzw. ob das ueberhaupt eine gute Idee ist)
\r
234 - /etc/caldavd/caldavd.plist anpassen (die wichtigsten Einstellungen
\r
235 duerften Hostname, BindAddresses, EnableSSL, RedirectHTTPtoHTTPS,
\r
236 SSLCertificate, SSLPrivateKey und DocumentRoot sein)
\r
237 - Ich finde den Punkt XMPP-Notifier sehr interessant
\r
238 - /etc/default/calendarserver anpassen, um den Server standardmaessig
\r
239 beim Hochfahren mitzustarten
\r
241 - https://hostname:port/calendars/users/username/calendar/ aufrufen;
\r
242 je nach Anwendung ggf. mit caldav://
\r
245 [0] http://en.wikipedia.org/wiki/VCard
\r
246 [1] http://en.wikipedia.org/wiki/VCalendar
\r
247 [2] http://en.wikipedia.org/wiki/Webdav
\r
248 [3] http://en.wikipedia.org/wiki/CardDAV
\r
249 [4] http://en.wikipedia.org/wiki/CalDAV
\r
250 [5] http://en.wikipedia.org/wiki/Representational_state_transfer
\r
251 [6] http://wiki.davical.org/w/CalDAV_Clients
\r
252 [7] http://wiki.davical.org/w/CalDAV_Clients/Android
\r
253 [8] http://dmfs.org/caldav/
\r
254 [9] http://dmfs.org/carddav/
\r
255 [10] http://acal.me/wiki/Main_Page
\r
256 [11] http://caldav4j.googlecode.com/
\r
257 [12] http://owncloud.org/
\r
258 [13] http://code.google.com/p/sabredav/
\r
259 [14] http://www.davical.org/
\r
260 [15] http://trac.calendarserver.org/
\r
261 [16] http://radicale.org/
\r
projects / krt-msg / blob