CalDAV: Timezones by Reference

The CalDAV Calendar Access protocol allows clients to access calendar data stored on a server in the iCalendar data format. In iCalendar, calendar data that uses local time in any of its date and/or time values is specified as a date-time value in combination with a timezone identifier ("TZID" property parameter). The timezone identifier refers to a timezone definition (a "VTIMEZONE" component) that has all of the rules required to determine local time UTC offsets for the corresponding timezone. In many cases, these "VTIMEZONE" components can be larger, octet-wise, than the events or tasks which make use of them. However, iCalendar currently requires all iCalendar objects ("VCALENDAR" components) that refer to a timezone via its identifier to also include the corresponding "VTIMEZONE" component. This leads to inefficiencies in the CalDAV protocol because large amounts of "VTIMEZONE" data are continuously being exchanged, and for the most part these timezone definitions are unchanging. This is of particular problem to mobile or limited devices, with limited network bandwidth, cpu processing, and power constraints. A set of standard timezone definitions are available at the IANA Timezone Registry. That registry provides the "raw" data for timezone definitions, and those can be converted into iCalendar "VTIMEZONE" components for use in iCalendar applications, as well as converted into other formats for use by other applications (e.g., "zoneinfo" files often found on Unix-based operating systems). A new Timezone Service protocol is available that allows iCalendar applications to retrieve these standard timezone definitions in a timely and accurate fashion, instead of relying on possibly infrequent system updates of timezone data that frequently result in mismatched calendar data and resulting missed meetings between calendar users. Another benefit of the Timezone Service is that it provides a single "reference" for standard timezone data that CalDAV clients and servers can make use of to "agree" on standard timezone definitions, and thus eliminate the need to exchange the data for those. This specification defines a new mode of operation for CalDAV clients and servers which allow them to exchange iCalendar data without the need to send "VTIMEZONE" components for known, standard timezone definitions. This can significantly reduce the amount of data that needs to be sent between client and server, giving rise to performance and efficiency improvements for each of them. Discussion of this Internet-Draft is taking place on the mailing list <https://www.ietf.org/mailman/listinfo/caldav>.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Other notations used in this memo follow the notations of .

Note that this specification only defines changes to iCalendar data sent or received via the CalDAV protocol (both and , and extensions). If CalDAV clients and servers also offer alternative means of sending or receiving iCalendar data, they MUST follow the requirements of those alternative protocols in regards to whether timezone definitions are required or not.

A CalDAV server MUST have one or more associated timezone services that provides data for the set of standard timezones known to the server and expected to be used by clients. A CalDAV server advertises the set of timezone services it makes use of via a CALDAV:timezone-service-set WebDAV property (see ) defined on calendar home collections. Clients can use the timezone services listed in this property to fetch up to date timezone definitions for the standard timezone identifiers in iCalendar data retrieved from the server. This allows clients to keep their "built-in" timezone definitions up to date. It also allows clients to use an "on-demand" model for populating their local timezone definition cache, only fetching a timezone definition when it is first seen in calendar data. This can be beneficial to limited devices that might not be able to store the full set of standard timezone definitions, and might only "ship" with a limited set based on the region where the device is sold. When making use of the timezone services advertised by a CalDAV server, clients MUST follow all the requirements of the timezone service protocol, taking care to refresh timezone data in a timely fashion.

Observation and experiments have shown that, in the vast majority of cases, CalDAV clients typically ignore timezone definitions in data received from servers, and instead make use of their own "built-in" definitions for the corresponding timezone identifier. This means that it is reasonable for CalDAV servers to unilaterally decide not to send "VTIMEZONE" components for standard timezones that clients are expected to have "built-in" (i.e., IANA timezones). Servers that follow this specification MUST NOT send "VTIMEZONE" components in iCalendar data to clients, when the timezone identifier and corresponding timezone definitions are available on any of the advertised timezone services. If a non-standard timezone is used in the iCalendar data, servers MUST include the corresponding "VTIMEZONE" component, as they would in the absence of support for this extension.

In addition to servers not sending standard timezone definitions to clients in iCalendar data, this specification also allows clients not to include timezone definitions when sending iCalendar data to the server. In order for that to work, clients need to know that the server is capable of handling that situation, as currently servers might not be able to. A server that allows clients to not send standard timezone definitions in iCalendar data MUST include "calendar-no-timezone" as a field in the DAV response header from an OPTIONS request on a calendar home collection or calendar collection. Clients MUST check for the presence of that field in the DAV response header before changing their behavior as per . Note that, as per , clients might send timezone definitions for timezones that are not advertised by any of the timezone services associated with the server. In that case, servers have various choices: Servers can preserve the original timezone definitions in the iCalendar data sent by the client, so that those can be returned to that or other clients who subsequently request iCalendar data. Servers can refuse to accept any unknown/non-standard timezones, in which case they MUST reject the HTTP request containing such data using a WebDAV precondition code of CALDAV:valid-timezone. Servers can, with appropriate knowledge, map the unknown/non-standard timezone to a standard timezone definition that accurately matches the one supplied by the client. In doing so, servers will need to re-write the iCalendar data to make use of the new standard timezone identifier chosen by the mapping procedure.

Clients MUST expect servers to not include standard timezone definitions in any iCalendar data they receive from the server. Clients MUST retrieve standard timezone definitions from the set of timezone services advertised from the server, or a known, trusted, third party service. When a server advertises the "calendar-no-timezone" field in a DAV response header (as per ): Clients SHOULD remove standard timezone definitions from iCalendar data they send to the server, provided the corresponding timezone identifier is one available via any of the server's advertised timezone services. Clients MUST send timezone definitions in iCalendar data for any timezone identifiers not available via any of the server's advertised timezone services. Clients MUST be prepared for the server to reject such data or map the timezone to one in the set of standard timezones provided by the server's associated timezone services (as per ).

TBD: WebDAV property containing a list of DAV:hrefs pointing to the timezone services used by the server.

This specification does not introduce any new security concerns beyond those addressed in CalDAV and iCalendar.

No IANA actions are needed.

Thanks to Mike Douglass, and Andrew McMillan. This specification came about via discussions at the Calendaring and Scheduling Consortium.