RFC 7809

Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference

📅 published March 2016, from ietf

RFC 7809 🎀 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference

okay so this is RFC 7809 and it's giving Standards Track realness 💅 C. Daboo from Apple wrote it, and it was published in March 2016 (ISSN 2070-1721 if you're into the paperwork 🙈). The title block says it updates RFC 4791, which is the base CalDAV spec, so think of this as a glow-up patch for CalDAV 🦋 It doesn't list anything it obsoletes.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Time Zones by Reference . . . . . . . . . . . . . . . . . . .   3
  3.1.  New Server Behavior . . . . . . . . . . . . . . . . . . .   4
4.  New Client Behavior . . . . . . . . . . . . . . . . . . . . .   7
5.  New WebDAV Properties . . . . . . . . . . . . . . . . . . . .   8
  5.1.  CALDAV:timezone-service-set . . . . . . . . . . . . . . .   8
  5.2.  CALDAV:calendar-timezone-id . . . . . . . . . . . . . . .   9
6.  XML Element Definitions . . . . . . . . . . . . . . . . . . .   9
  6.1.  CALDAV:calendar-query XML Element . . . . . . . . . . . .   9
  6.2.  CALDAV:timezone-id XML Element  . . . . . . . . . . . . .  10
7.  Additional Message Header Fields  . . . . . . . . . . . . . .  10
  7.1.  CalDAV-Timezones Request Header Field . . . . . . . . . .  10
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
  10.1.  CalDAV-Timezones . . . . . . . . . . . . . . . . . . . .  11
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
  11.2.  Informative References . . . . . . . . . . . . . . . . .  12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

Abstract ✨

this doc defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) so that clients and servers can swap iCalendar data without having to send full time zone data 🫶

Status of This Memo 📜

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 5741.

info about the current status of this doc, any errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc7809 💜

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. please actually read these, bestie, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

1. Introduction ✨

okay so the CalDAV [RFC4791] calendar access protocol lets clients reach calendar data stored on a server in the iCalendar [RFC5545] data format 📅 In iCalendar, any calendar data that uses local time in its date and/or time values is written as a date-time value paired with a time zone identifier (the TZID property parameter). That identifier points at a time zone definition (a VTIMEZONE component) that has every rule needed to figure out local-time UTC offsets for that zone.

here's the tea ☕ a VTIMEZONE component can be way bigger, octet-wise, than the events or tasks that use it. still, iCalendar currently says every iCalendar object (VCALENDAR component) that references a time zone by its identifier also has to include the matching VTIMEZONE component. this is inefficient for CalDAV because huge amounts of VTIMEZONE data keep getting exchanged, and mostly those definitions don't change at all 😭 It's especially rough for mobile or limited devices with limited network bandwidth, CPU, and energy 🔋

a set of standard time zone definitions lives in the IANA-hosted time zone database [RFC6557]. that database has the "raw" data, which can be converted into VTIMEZONE components for iCalendar apps, and into other formats for other apps (like the zoneinfo files you often find on Unix-based operating systems) 🐧 There's also a new time zone data distribution service protocol [RFC7808] that lets iCalendar apps grab these standard definitions quickly and accurately. This matters because the alternative is relying on system updates that might be rare, and those can leave calendar data mismatched and cause missed meetings between calendar users 💀 Another perk is that the distribution service acts as a single "reference" for standard time zone data. CalDAV clients and servers can use it to "agree" on standard definitions, so they don't have to exchange that data at all 🫶

this spec defines a new mode of operation for CalDAV clients and servers. In that mode, they can exchange iCalendar data without sending VTIMEZONE components for known, standard time zone definitions. This can cut down the amount of data sent between client and server a lot, which means performance and efficiency gains for both of them 🚀

2. Conventions Used in This Document ✨

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 🧚

other notations used in this memo are the same as in [RFC4791] 💅

3. Time Zones by Reference 🧚

note that this spec only changes iCalendar data that gets sent or received over the CalDAV protocol (that's [RFC4791] and [RFC6638], plus extensions). These changes don't apply to other ways of swapping calendar data, like scheduling based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], e.g., the iCalendar Message-Based Interoperability Protocol (iMIP) [RFC6047], or other methods 🙅‍♀️

3.1. New Server Behavior 💖

3.1.1. Server Advertised Capability 🌸

okay this is the main server flex 💪 A server that supports this spec MUST include "calendar-no-timezone" as a field in the DAV response header field, coming back from an "OPTIONS" request on a calendar home collection (see Section 6.2.1 of [RFC4791]) or a calendar collection (see Section 4.2 of [RFC4791]). Clients MUST check that the field is actually there in the DAV response header field before they change their behavior as per Section 4 🔍 no checking, no changing, periodt 💅

3.1.2. Associated Time Zone Data Distribution Service 🦋

a CalDAV server supporting this spec MUST have one or more associated time zone distribution services [RFC7808] that provide data for the set of time zones the server knows about and expects clients to use 🌍 The server advertises which distribution services it uses through the CALDAV:timezone-service-set WebDAV property (see Section 5.1), which is defined on calendar home collections. Clients can use the distribution services listed in this property to fetch current time zone definitions for the time zone identifiers in iCalendar data they got from the server 🙌 This helps clients keep their "built-in" time zone definitions up to date. It also lets them go "on-demand," only fetching a time zone definition when it first shows up in calendar data. That can save storage space, since they don't have to keep time zone data nobody's currently using 💾

when clients use the time zone data distribution services a CalDAV server advertises, they MUST follow all the requirements of the time zone data distribution service protocol [RFC7808], and they have to be careful to refresh time zone data in a timely fashion ⏰

3.1.3. Time Zones in CalDAV Responses 💜

okay the big rules for responses 👑 Servers MUST support the HTTP "CalDAV-Timezones" request header field (see Section 7.1). If the "CalDAV-Timezones" request header field has the value "T" on any HTTP request that returns iCalendar data, then the server MUST include all the appropriate VTIMEZONE components in the iCalendar data (all of them that are referenced by TZID property parameters) ✨ If the "CalDAV-Timezones" request header field has the value "F" on any HTTP request that returns iCalendar data, then the server MUST NOT return any VTIMEZONE components for a time zone identifier that matches one provided by any of the advertised time zone distribution servers (see Section 3.1.2). However, the server MUST return the appropriate VTIMEZONE component for each time zone with an identifier that isn't available on the advertised time zone distribution servers 🫶 This applies to every HTTP request on CalDAV resources that returns iCalendar data, whether it's returned directly (like a "GET" request on a calendar object resource) or embedded in a "structured" response such as a DAV:multistatus returned by a "REPORT" or "PROPFIND" request 🎀

here's the vibe check 🔍 Observation and experiments have shown that, in the vast majority of cases, CalDAV clients have usually ignored time zone definitions in data they got from servers. They use their own "built-in" definitions for the matching time zone identifier instead 🙈 So it's reasonable for CalDAV servers to decide on their own not to send VTIMEZONE components for standard time zones that clients are expected to have "built-in" (i.e., IANA time zones) 🌏 That means that, when there's no "CalDAV-Timezones" request header field, servers advertising the "calendar-no-timezone" capability MAY opt to not send standard VTIMEZONE components. Servers that do this will need to provide an administrator configuration setting to override the new default behavior based on client "User-Agent" request header field values, or other suitable means of identifying the client software in use 🛠️

3.1.4. Time Zones in CalDAV Requests ✨

okay so we already talked about servers not sending time zone definitions to clients in iCalendar data 💅 well, this spec also lets clients NOT include time zone definitions when they send iCalendar data to the server, as per Section 4 🎀 this works for every HTTP request on CalDAV resources that carries iCalendar data, whether it's right in the request body (like a "PUT" on a calendar object resource) or tucked inside a "structured" request body, like the one a "PROPPATCH" request uses 🦋

ngl this is where it gets spicy 🌶️ as per Section 4, clients might send time zone definitions for time zones that none of the time zone services linked to the server advertise. so what do servers do? they have a few options:

  1. Servers can preserve the original time zone definitions in the iCalendar data sent by the client, so they can be sent back to that client or to other clients who ask for the iCalendar data later 🧚
  2. Servers can refuse to accept any unknown or nonstandard time zones. in that case they MUST reject the HTTP request containing such data using a WebDAV precondition code of CALDAV:valid-timezone 🙅‍♀️
  3. Servers can, with the right knowledge, map the unknown or nonstandard time zone to a standard time zone definition that accurately matches the one the client supplied. the server will need to rewrite the iCalendar data so it uses the new standard time zone identifier picked by the mapping. any later request to fetch that calendar data will see the new identifier 💜 BUT there's one big exception where remapping is NOT appropriate: an attendee's copy of an event. the original time zone definition has to be kept there, because the organizer's calendar user agent will expect to see it in any iTIP [RFC5546] replies the attendee sends 🫶

3.1.5. Support of Time Zone Identifiers in WebDAV Properties 🌸

so CalDAV has this CALDAV:calendar-timezone WebDAV property that clients use to set a default time zone for the server to use when it does time-based queries on calendar data (see Section 5.3.2 of [RFC4791]) 🕰️ its value is a full iCalendar "VTIMEZONE" component. this spec adds a new CALDAV:calendar-timezone-id WebDAV property, which lets clients set that default time zone using just the time zone identifier instead of the whole "VTIMEZONE" component (see Section 5.2) ✨

here's the lowkey strict part 🔒 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 inside the CALDAV:calendar-timezone WebDAV property on that same resource. the server MUST accept clients that set either CALDAV:calendar-timezone or CALDAV:calendar-timezone-id, and it MUST update the value of the other property to reflect any changes. so if a client sets CALDAV:calendar-timezone-id to "America/New_York", the server will return the full "VTIMEZONE" data for that time zone in the CALDAV:calendar-timezone WebDAV property 🗽

if a client tries to update CALDAV:calendar-timezone-id with a value that doesn't match a time zone the server knows about, the server MUST reject the property update with a CALDAV:valid-timezone pre-condition error 🙅‍♀️ in that case, clients MAY repeat the request using CALDAV:calendar-timezone instead, and send the full iCalendar data for the time zone being set 🔁

3.1.6. Support of Time Zone Identifiers in CALDAV:calendar-query REPORT 🦋

CalDAV calendar query reports have a CALDAV:timezone XML element that clients use to pick a specific time zone for the server to use when it does time-based queries on calendar data (see Sections 7.3 and 9.8 of [RFC4791]). its content is an iCalendar "VTIMEZONE" component. this spec adds a CALDAV:timezone-id XML element as an alternative, so a specific time zone can be set with just its identifier instead of the full "VTIMEZONE" component (see Section 6.2) 💅

Servers MUST support a client's ability to provide a time zone identifier for use in a calendar query "REPORT" using this new element. no skipping this one bestie 👑

if a client tries to use a CALDAV:timezone-id XML element with a value that doesn't match a time zone the server knows, the server MUST reject the request with a CALDAV:valid-timezone precondition error 💀 in that case, clients MAY repeat the request using the CALDAV:timezone XML element instead, and send the full iCalendar data for the time zone being used 🌈

4. New Client Behavior 🎀

okay so when a server advertises the "calendar-no-timezone" field in a DAV response header field (as per Section 3.1.1), clients get a whole checklist 📋✨

  1. Clients SHOULD include an HTTP "CalDAV-Timezones" request header field with a value of "F" so the CalDAV server does NOT include "VTIMEZONE" components in any iCalendar data returned in a response (see Section 3.1.3). this is for time zones whose identifier is one provided by any of the advertised time zone distribution servers (see Section 3.1.2). in that case, clients will have to get the missing standard time zone definitions either from their own cache of standard time zones or from the set of time zone distribution servers the CalDAV server advertises (see Section 3.1.2) 🧠
  2. Clients can include an HTTP "CalDAV-Timezones" request header field with a value of "T" to make sure the CalDAV server DOES include all "VTIMEZONE" components in any iCalendar data returned in a response (see Section 3.1.3) 🌟
  3. Clients can expect servers not to include standard time zone definitions in any iCalendar data they get from the server, if there's no "CalDAV-Timezones" request header field in the HTTP request. BUT clients MUST retrieve standard time zone definitions either from their own cache of standard time zones or from the set of time zone distribution servers the CalDAV server advertises (see Section 3.1.2) 📚
  4. Clients SHOULD remove standard time zone definitions from the iCalendar data they send to the server, as long as the matching time zone identifier is one available on any of the server's advertised time zone distribution servers (see Section 3.1.2) ✂️
  5. Clients MUST send time zone definitions in iCalendar data for any time zone identifiers NOT available via any of the server's advertised time zone distribution servers. clients MUST also be prepared for the server to reject that data, or to map the time zone to one in the set of standard time zones provided by the server's associated time zone services (as per Section 3.1.4) 🫣
  6. Clients SHOULD use the CALDAV:calendar-timezone-id WebDAV property (see Section 3.1.5) and the CalDAV:timezone-id XML element (see Section 3.1.6) to specify default and specific time zones for calendar queries the server runs 🔍

5. New WebDAV Properties 🌷

5.1. CALDAV:timezone-service-set 🏷️

  • Name: timezone-service-set
  • Namespace: urn:ietf:params:xml:ns:caldav

Purpose: this one tells you which time zone data distribution servers the CalDAV server is using to give out its standard time zone data 🗺️

Conformance: this property SHOULD be defined on CalDAV calendar home collection resources. if it IS defined, it SHOULD NOT be returned by a "PROPFIND" DAV:allprop request (as defined in Section 14.2 of [RFC4918]) 🙈

Description: the CALDAV:timezone-service-set property lists one or more time zone data distribution servers that the CalDAV server uses to provide its set of time zone data. see Section 3.1.2 for more deets 🍓

Definition:

<!ELEMENT timezone-service-set (DAV:href+)>
DAV:href value: URI of a time zone data distribution service
as defined by this specification.

Example:

<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>

5.2. CALDAV:calendar-timezone-id 🪄

  • Name: calendar-timezone-id
  • Namespace: urn:ietf:params:xml:ns:caldav

Purpose: this one specifies a time zone identifier for a calendar collection 📅

Conformance: this property SHOULD be defined on all resources where the CALDAV:calendar-timezone property is also defined. if it IS defined, it SHOULD NOT be returned by a "PROPFIND" DAV:allprop request (as defined in Section 14.2 of [RFC4918]) 🙈

Description: the CALDAV:calendar-timezone-id property is an alternative to the CALDAV:calendar-timezone property (see Section 5.3.2 of [RFC4791]) 💫 it lets clients set the default time zone using only a time zone identifier, and it also tells the client the identifier of the current default time zone. see Section 3.1.5 for more details 💖

Definition:

<!ELEMENT calendar-timezone-id (#PCDATA)>
PCDATA value: a time zone identifier.

Example:

<C:calendar-timezone-id
    xmlns:C="urn:ietf:params:xml:ns:caldav">US-Eastern<
/C:calendar-timezone-id>

6. XML Element Definitions 🧁

6.1. CALDAV:calendar-query XML Element 🧾

The CALDAV:calendar-query XML element, defined in Section 9.5 of [RFC4791], gets a glow-up so it can use the CALDAV:timezone-id XML element like this 💅

Definition:

<!ELEMENT calendar-query ((DAV:allprop |
                           DAV:propname |
                           DAV:prop)?, filter,
                           (timezone | timezone-id)?)>

6.2. CALDAV:timezone-id XML Element 🌍

  • Name: timezone-id
  • Namespace: urn:ietf:params:xml:ns:caldav

Purpose: this one specifies the time zone identifier for a time zone component to use when figuring out the results of a report 🎯

Description: the CALDAV:timezone-id XML element is an alternative to the CALDAV:timezone XML element (see Section 9.8 of [RFC4791]) in calendar query reports. it lets a client name a time zone with an identifier instead of sending the full iCalendar time zone data. see Section 3.1.6 for more details 🌟

Definition:

<!ELEMENT timezone-id (#PCDATA)>
PCDATA value: a time zone identifier.

7. Additional Message Header Fields 💌

7.1. CalDAV-Timezones Request Header Field 💜

the "CalDAV-Timezones" request header field is how a client tells the server whether it wants "VTIMEZONE" components returned in any iCalendar data that's part of the HTTP response 🎁 the value "T" means yes, send the time zone data back; the value "F" means no, don't 🙅‍♀️

CalDAV-Timezones = "T" / "F"

Example:

CalDAV-Timezones: F

8. Security Considerations 🔐

Okay bestie, this one is serious 😭 This spec brings time zone data distribution service [RFC7808] servers into the calendaring and scheduling client/server setup as a critical piece, so it opens up a brand new attack vector against these systems. CalDAV server admins SHOULD make sure any advertised time zone distribution servers are protected at a level that matches all the other components in the system 🛡️.

Besides that, this spec doesn't add any new security concerns beyond the ones already covered in CalDAV [RFC4791], iCalendar [RFC5545], and the time zone data distribution service [RFC7808] 💅.

9. Privacy Considerations 🫣

The privacy recommendations in Section 9 of the time zone data distribution service spec [RFC7808] SHOULD be used so that clients' interactions with CalDAV servers aren't exposed to nosy network observers 👀.

Also, events can be delivered to a calendar user from an outside source (e.g., through iTIP [RFC5546]) 📨. An attacker could create a calendar event with a time zone identifier that is fake or rarely used, and use it to monitor the calendar user's activity and who they interact with 💀. So this spec makes the privacy mitigations discussed in [RFC7808] even more important 🔒.

10. IANA Considerations 📋

The message header field below has been added to the Permanent Message Header Field Registry (see [RFC3864]) ✨.

10.1. CalDAV-Timezones

Header field name: CalDAV-Timezones

Applicable protocol: http

Status: standard

Author/Change controller: IETF

Specification document(s): this document (Section 7.1)

Related information: none

11. References 📚

Here's the full reference list, every entry included 🧚

11.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
           Procedures for Message Header Fields", BCP 90, RFC 3864,
           DOI 10.17487/RFC3864, September 2004,
           <http://www.rfc-editor.org/info/rfc3864>.

[RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
           "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
           DOI 10.17487/RFC4791, March 2007,
           <http://www.rfc-editor.org/info/rfc4791>.

[RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
           Authoring and Versioning (WebDAV)", RFC 4918,
           DOI 10.17487/RFC4918, June 2007,
           <http://www.rfc-editor.org/info/rfc4918>.

[RFC5545]  Desruisseaux, B., Ed., "Internet Calendaring and
           Scheduling Core Object Specification (iCalendar)",
           RFC 5545, DOI 10.17487/RFC5545, September 2009,
           <http://www.rfc-editor.org/info/rfc5545>.

[RFC6638]  Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
           CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
           <http://www.rfc-editor.org/info/rfc6638>.

[RFC7808]  Douglass, M. and C. Daboo, "Time Zone Data Distribution
           Service", RFC 7808, DOI 10.17487/RFC7808, March 2016,
           <http://www.rfc-editor.org/info/rfc7808>.

11.2. Informative References

[RFC5546]  Daboo, C., Ed., "iCalendar Transport-Independent
           Interoperability Protocol (iTIP)", RFC 5546,
           DOI 10.17487/RFC5546, December 2009,
           <http://www.rfc-editor.org/info/rfc5546>.

[RFC6047]  Melnikov, A., Ed., "iCalendar Message-Based
           Interoperability Protocol (iMIP)", RFC 6047,
           DOI 10.17487/RFC6047, December 2010,
           <http://www.rfc-editor.org/info/rfc6047>.

[RFC6557]  Lear, E. and P. Eggert, "Procedures for Maintaining the
           Time Zone Database", BCP 175, RFC 6557,
           DOI 10.17487/RFC6557, February 2012,
           <http://www.rfc-editor.org/info/rfc6557>.

Acknowledgments 💖

Huge thanks to Mike Douglass, Andrew McMillan, and Ken Murchison 🫶 This specification came about via discussions at the Calendaring and Scheduling Consortium 🌈.

Author's Address 🦋

Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA   95014
United States

Email: cyrus@daboo.name
URI:   http://www.apple.com/
📦 where this page comes from