CalDAV

CalDAV is an Internet standard allowing a client to access scheduling information on a remote server. It extends WebDAV (HTTP-based protocol for data manipulation) specification and uses iCalendar format for the data. The protocol is defined by RFC 4791.

-- Wikipedia

People

Jan Schneider

Description

Horde, specifically the Kronolith and Nag modules for calendaring and tasks management, support CalDAV in two ways: it can be used as a CalDAV server for external calendar clients, providing a central cloud storage for multiple devices of the users. And it can use an external CalDAV server as a calendar client on its own, to display this server's events inside Horde.

Horde utilizes the 3rd party SabreDAV library for the grunt work of implementing the CalDAV and related protocols.

Full CalDAV support has been added with Horde 5.1/Kronolith 4.1/Nag 4.1.

Configuration

The Horde_Dav library is automatically pulled in as a dependency when installing Kronolith or Nag. The necessary database tables can be created as usual from the Horde configuration screen or via horde-db-migrate. The storage backend for all DAV operations has to be enabled in the Horde configuration screen.

Service Discovery

Some CalDAV clients support automatic discovery of the CalDAV service end points just by providing the user's email address or a host name. To enable service discovery, redirect aliases have to be set in your web server's configuration. The redirect target is either the horde/rpc/ directory if you have "pretty" URLs enabled in your Horde configuration, or the horde/rpc.php file otherwise. This is an example for Apache web servers:

RedirectPermanent /.well-known/caldav /horde/rpc/

See your web server's documentation about how to set up redirects.

DNS

Service Discovery can also be implemented via DNS setup. Please refer to SabreDAV Service Discovery for details.

Client configuration

There are two different kind of CalDAV service end points which may or may not be supported by different clients:

• Principal URLs are single URLs for each individual user. These provide information about the user himself, and all of his available (CalDAV and CardDAV) resources.
• Calendar URLs are URLs for each individual calendar (or task list). Clients not supporting Principal URLs require users to enter each Calendar URL individually. They are also required if users want to suscribe to shared calendars or task lists of other users.

Both types of URLs can be retrieved from the calendars' and task lists' edit forms. In the Kronolith/Nag interface click on the edit icon next to an calendar/task list name and copy the required URL from there.

Features

This is a list of devices known to work with Horde's CalDAV implementation. Please update if you gather new information, or have more detailed knowledge about the supported features or versions.

Client/Device	Principal URLs	Calendar URLs	Service Discovery	Notes
Desktop Clients
Thunderbird/Lightning	No	Yes		Confirmed with Thunderbird
Thunderbird/TbSync	Yes	Yes		TB 68.*-69.*, works with Provider for CalDAV & CardDAV (also with Provider for Exchange ActiveSync
Outlook CalDav Synchronizer (Outlook CalDAV Plugin)	Yes	Yes	Yes
Apple iCal	Yes		Yes	Confirmed with iCal 5.0/OS X 10.7
Evolution	Yes	Yes		Confirmed with Evolution 3.22
Mobile Devices
DAVx5 (Android)	Yes	Yes	Yes
CalendarSync (Android)	Yes	Yes	Yes
CalDAV-Sync (Android)	Yes		Yes
iOS	Yes		Yes
BlackBerry	Yes	Yes		Tested with BB10 simulator

Issues with moving horde

- Moving horde's webroot or changing from pretty to traditional urls may break caldav/carddav requests. Fixing involves the client re-discovering the calendar (thunderbird: unsubscribe, re-register)

Know Missing features (by app)

Kronolith/Calendar

- Some handling of unknown properties (like X-Mozilla-Something)

Nag/Tasks

- Support for long icalendar vtodo summaries / nag task titles
- Some handling of unknown properties (like X-Mozilla-Something)
- Multiple attendees/assignees

Turba/Addressbook

- Not dropping properties unmapped to the backend
- incomplete handling of backend-driven changes behind turba's back (namely LDAP)