Network Working Group | C. Daboo |
Internet-Draft | Apple |
Intended status: Standards Track | August 26, 2014 |
Expires: February 27, 2015 |
CalDAV: Time Zones by Reference
draft-ietf-tzdist-caldav-timezone-ref-00
This document defines an extension to the CalDAV calendar access protocol to allow clients and servers to exchange iCalendar data without the need to send full time zone data.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The CalDAV [RFC4791] Calendar Access protocol allows clients to access calendar data stored on a server in the iCalendar [RFC5545] 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 time zone identifier ("TZID" property parameter). The time zone identifier refers to a time zone definition (a "VTIMEZONE" component) that has all of the rules required to determine local time UTC offsets for the corresponding time zone. 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 time zone 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 time zone 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 time zone definitions are available at the IANA hosted time zone database [RFC6557]. That database provides the "raw" data for time zone 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 Time Zone Data Distribution Service [I-D.ietf-tzdist-service] protocol is available that allows iCalendar applications to retrieve these standard time zone definitions in a timely and accurate fashion, instead of relying on possibly infrequent system updates of time zone data that frequently result in mismatched calendar data and resulting missed meetings between calendar users. Another benefit of the Time Zone Data Distribution Service is that it provides a single "reference" for standard time zone data that CalDAV clients and servers can make use of to "agree" on standard time zone 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 time zone 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 tzdist working group mailing list <tzdist@ietf.org>.
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 [RFC2119].
Other notations used in this memo follow the notations of [RFC4791].
Note that this specification only defines changes to iCalendar data sent or received via the CalDAV protocol (both [RFC4791] and [RFC6638], 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 time zone definitions are required or not.
A CalDAV server MUST have one or more associated time zone services [I-D.ietf-tzdist-service] that provides data for the set of standard time zones known to the server and expected to be used by clients. A CalDAV server advertises the set of time zone services it makes use of via a CALDAV:timezone-service-set WebDAV property (see Section 5.1) defined on calendar home collections. Clients can use the time zone data distribution services listed in this property to fetch up to date time zone definitions for the standard time zone identifiers in iCalendar data retrieved from the server. This allows clients to keep their "built-in" time zone definitions up to date. It also allows clients to use an "on-demand" model for populating their local time zone definition cache, only fetching a time zone 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 time zone definitions, and might only "ship" with a limited set based on the region where the device is sold.
When making use of the time zone data distribution services advertised by a CalDAV server, clients MUST follow all the requirements of the time zone data distribution service protocol, taking care to refresh time zone data in a timely fashion.
Observation and experiments have shown that, in the vast majority of cases, CalDAV clients typically ignore time zone definitions in data received from servers, and instead make use of their own "built-in" definitions for the corresponding time zone identifier. This means that it is reasonable for CalDAV servers to unilaterally decide not to send "VTIMEZONE" components for standard time zones that clients are expected to have "built-in" (i.e., IANA time zones).
Servers that follow this specification MUST NOT send "VTIMEZONE" components in iCalendar data to clients, when the time zone identifier and corresponding time zone definitions are available on any of the advertised time zone data distribution services. If a non-standard time zone 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 time zone definitions to clients in iCalendar data, this specification also allows clients not to include time zone 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 time zone 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 Section 4.
Note that, as per Section 4, clients might send time zone definitions for time zones that are not advertised by any of the time zone services associated with the server. In that case, servers have various choices:
CalDAV defines a CALDAV:calendar-timezone WebDAV property that is used by clients to set a default time zone for the server to use when doing time-based queries on calendar data (see Section 5.3.2 of [RFC4791]). The content of that WebDAV property is an iCalendar "VTIMEZONE" component. This specification defines a new CALDAV:calendar-timezone-id WebDAV property that allows the default time zone to be set via its time zone identifier, rather than providing the full "VTIMEZONE" component (see Section 5.2). This WebDAV property MUST be present on all resources that also support the CALDAV:calendar-timezone WebDAV property. Its value MUST match the value of the "TZID" iCalendar property in the "VTIMEZONE" component in the CALDAV:calendar-timezone WebDAV property on the same resource. The server MUST accept clients setting either the CALDAV:calendar-timezone or the CALDAV:calendar-timezone-id, and it MUST adjust the value of the alternate property to reflect any changes. i.e., if a client sets the CALDAV:calendar-timezone-id WebDAV property value to "America/New_York", then the server will return the full "VTIMEZONE" data for that time zone in the CALDAV:calendar-timezone WebDAV property.
If a client attempts to update the CALDAV:calendar-timezone-id with a value that does not correspond to a time zone that is known to the server, the server MUST reject the property update using a CALDAV:valid-timezone pre-condition error. In such cases, clients MAY repeat the request using the CALDAV:calendar-timezone instead, and provide the full iCalendar data for the time zone being set.
CalDAV calendar query reports support a CALDAV:timezone XML element that is used by clients to set a specific time zone for the server to use when doing time-based queries on calendar data (see Sections 7.3 and 9.8 of [RFC4791]). The content of that XML element is an iCalendar "VTIMEZONE" component. This specification defines a new CALDAV:timezone-id XML element, that can be used as an alternative to the CALDAV:timezone XML element, that allows a specific time zone to be set via its time zone identifier, rather than providing the full "VTIMEZONE" component (see Section 6.2). Servers MUST support clients providing a time zone identifier for use in a calendar query REPORT using this new element.
If a client attempts use a CALDAV:timezone-id XML element with a value that does not correspond to a time zone that is known to the server, the server MUST reject the request with a CALDAV:valid-timezone pre-condition error. In such cases, clients MAY repeat the request using the CALDAV:timezone XML element instead, and provide the full iCalendar data for the time zone being used.
Clients MUST expect servers not to include standard time zone definitions in any iCalendar data they receive from the server. Clients MUST retrieve standard time zone definitions from the set of time zone 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 Section 3.1.3):
<!ELEMENT timezone-service-set (DAV:href+)> DAV:href value: URI of a time zone data distribution service as defined by this specification.
<C:timezone-service-set xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:href>https://timezones.example.com</D:href> </C:timezone-service-set>
<!ELEMENT calendar-timezone-id (#PCDATA)> PCDATA value: an time zone identifier.
<C:calendar-timezone-id xmlns:C="urn:ietf:params:xml:ns:caldav">US-Eastern< /C:calendar-timezone-id>
<!ELEMENT calendar-query ((DAV:allprop | DAV:propname | DAV:prop)?, filter, (timezone | timezone-id)?)>
The CALDAV:calendar-query XML element, defined in Section 9.5 of [RFC4791], is modified to allow use of the CALDAV:timezone-id XML element as follows:
<!ELEMENT timezone-id (#PCDATA)> PCDATA value: an time zone identifier.
This specification does not introduce any new security concerns beyond those addressed in CalDAV [RFC4791] and iCalendar [RFC5545].
No IANA actions are needed.
Thanks to Mike Douglass, Andrew McMillan, and Ken Murchison. This specification came about via discussions at the Calendaring and Scheduling Consortium.
[I-D.ietf-tzdist-service] | Douglass, M. and C. Daboo, "Time Zone Data Distribution Service", Internet-Draft draft-ietf-tzdist-service-00, August 2014. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC4791] | Daboo, C., Desruisseaux, B. and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007. |
[RFC4918] | Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. |
[RFC5545] | Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. |
[RFC6557] | Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, February 2012. |
[RFC6638] | Daboo, C. and B. Desruisseaux, "Scheduling Extensions to CalDAV", RFC 6638, June 2012. |
Changes in -00: