Internet DRAFT - draft-ietf-tzdist-caldav-timezone-ref
draft-ietf-tzdist-caldav-timezone-ref
Network Working Group C. Daboo
Internet-Draft Apple
Updates: 4791 (if approved) October 13, 2015
Intended status: Standards Track
Expires: April 15, 2016
CalDAV: Time Zones by Reference
draft-ietf-tzdist-caldav-timezone-ref-05
Abstract
This document defines an update to the CalDAV calendar access
protocol (RFC 4791) to allow clients and servers to exchange
iCalendar data without the need to send full time zone data.
Status of This Memo
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 April 15, 2016.
Copyright Notice
Copyright (c) 2015 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.
Daboo Expires April 15, 2016 [Page 1]
Internet-Draft CalDAV Time Zone Extension October 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Time Zones by Reference . . . . . . . . . . . . . . . . . . . 3
3.1. New Server Behavior . . . . . . . . . . . . . . . . . . . 3
4. New Client Behavior . . . . . . . . . . . . . . . . . . . . . 7
5. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 8
5.1. CALDAV:timezone-service-set . . . . . . . . . . . . . . . 8
5.2. CALDAV:calendar-timezone-id . . . . . . . . . . . . . . . 8
6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 9
6.1. CALDAV:calendar-query XML Element . . . . . . . . . . . . 9
6.2. CALDAV:timezone-id XML Element . . . . . . . . . . . . . 9
7. Additional Message Header Fields . . . . . . . . . . . . . . 10
7.1. CalDAV-Timezones Request Header Field . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. CalDAV-Timezones . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
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.
Daboo Expires April 15, 2016 [Page 2]
Internet-Draft CalDAV Time Zone Extension October 2015
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.
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 document are to be interpreted as described in
[RFC2119].
Other notations used in this memo follow the notations of [RFC4791].
3. Time Zones by Reference
Note that this specification only defines changes to iCalendar data
sent or received via the CalDAV protocol (both [RFC4791] and
[RFC6638], and extensions). These changes do not apply to other
means of exchanging calendar data, such as iTIP [RFC5546] based
scheduling mechanisms (e.g., iMIP [RFC6047]), or other methods.
3.1. New Server Behavior
3.1.1. Server Advertised Capability
A server that supports this specification MUST include "calendar-no-
timezone" as a field in the DAV response header field from an OPTIONS
request on a calendar home collection (see Section 6.2.1 of
Daboo Expires April 15, 2016 [Page 3]
Internet-Draft CalDAV Time Zone Extension October 2015
[RFC4791]) or calendar collection (see Section 4.2 of [RFC4791]).
Clients MUST check for the presence of that field in the DAV response
header field before changing their behavior as per Section 4.
3.1.2. Associated Time Zone Data Distribution Service
A CalDAV server supporting this specification MUST have one or more
associated time zone distribution services [I-D.ietf-tzdist-service]
that provide data for the set of time zones known to the server and
expected to be used by clients. A CalDAV server advertises the set
of time zone distribution 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 current time
zone definitions for the 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, potentially allowing for savings on storage space by
eliminating the need to store time zone data that is not currently
being used.
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
[I-D.ietf-tzdist-service], taking care to refresh time zone data in a
timely fashion.
3.1.3. Time Zones in CalDAV 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 the ones 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 if the time zone identifier 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 not available on the advertised
time zone distribution servers. This behaviour applies to all HTTP
requests on CalDAV resources that return iCalendar data either
directly (such as 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.
Daboo Expires April 15, 2016 [Page 4]
Internet-Draft CalDAV Time Zone Extension October 2015
Observation and experiments have shown that, in the vast majority of
cases, CalDAV clients have typically ignored 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).
Thus, in the absence of a "CalDAV-Timezones" request header field,
servers advertizing the "calendar-no-timezone" capability MAY opt to
not send standard "VTIMEZONE" components. Servers that do that will
need to provide an administrator configuration setting to override
the new default behavior based on client "User-Agent" request header
field field values, or other suitable means of identifying the client
software in use.
3.1.4. Time Zones in CalDAV Requests
In addition to servers not sending time zone definitions to clients
in iCalendar data, this specification also allows clients to not
include time zone definitions when sending iCalendar data to the
server, as per Section 4. This behaviour applies to all HTTP
requests on CalDAV resources that include iCalendar data either
directly in the request body (such as a "PUT" request on a calendar
object resource), or embedded in a "structured" request body such as
a one used by "PROPPATCH" request.
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:
1. Servers can preserve the original time zone 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.
2. Servers can refuse to accept any unknown/non-standard time zones,
in which case they MUST reject the HTTP request containing such
data using a WebDAV precondition code of CALDAV:valid-timezone.
3. Servers can, with appropriate knowledge, map the unknown/non-
standard time zone to a standard time zone 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 time zone identifier chosen by the mapping
procedure. Any subsequent request to fetch the calendar data
would see the new time zone identifier in the calendar data.
Note there is one important situation where this re-mapping is
not appropriate: an attendee's copy of an event. In that case
Daboo Expires April 15, 2016 [Page 5]
Internet-Draft CalDAV Time Zone Extension October 2015
the original time zone definition needs to be preserved as the
organizer's calendar user agent will expect to see that in any
iTIP [RFC5546] replies sent by the attendee.
3.1.5. Support of Time Zone Identifiers in WebDAV Properties
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.
3.1.6. Support of Time Zone Identifiers in CALDAV:calendar-query REPORT
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.
Daboo Expires April 15, 2016 [Page 6]
Internet-Draft CalDAV Time Zone Extension October 2015
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.
4. New Client Behavior
When a server advertises the "calendar-no-timezone" field in a DAV
response header field (as per Section 3.1.1):
1. Clients SHOULD include an HTTP "CalDAV-Timezones" request header
field with a value of "F" to ensure that the CalDAV server does
not include "VTIMEZONE" components in any iCalendar data returned
in a response (see Section 3.1.3), for those time zones whose
identifier is one provided by any of the advertised time zone
distribution servers (see Section 3.1.2). In this case, clients
will have to retrieve the missing standard time zone definitions
either from their own cache of standard time zones, or from the
set of time zone distribution servers advertised by the CalDAV
server (see Section 3.1.2).
2. Clients can include an HTTP "CalDAV-Timezones" request header
field with a value of "T" to ensure that 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 receive from the server,
if there is no "CalDAV-Timezones" request header field in the
HTTP request. Clients MUST retrieve standard time zone
definitions either from its own cache of standard time zones, or
from the set of time zone distribution servers advertised by the
CalDAV server (see Section 3.1.2).
4. Clients SHOULD remove standard time zone definitions from
iCalendar data they send to the server, provided the
corresponding 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 be
prepared for the server to reject such data or 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).
Daboo Expires April 15, 2016 [Page 7]
Internet-Draft CalDAV Time Zone Extension October 2015
6. Clients SHOULD make use of the CALDAV:calendar-timezone-id WebDAV
property (see Section 3.1.5) and CalDAV:timezone-id XML element
(see Section 3.1.6) for specifying default and specific time
zones to use in calendar queries executed by the server.
5. New WebDAV Properties
5.1. CALDAV:timezone-service-set
Name: timezone-service-set
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies one or more time zone data distribution servers
being used by the CalDAV server to provide standard time zone
data.
Conformance: This property SHOULD be defined on CalDAV calendar home
collection resources. If 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 is
using to provide its set of time zone data. See Section 3.1.2 for
more details.
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: Specifies a time zone identifier for a calendar collection.
Daboo Expires April 15, 2016 [Page 8]
Internet-Draft CalDAV Time Zone Extension October 2015
Conformance: This property SHOULD be defined on all resources where
the CALDAV:calendar-timezone property is also defined. If
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 used as an
alternative to the CALDAV:calendar-timezone property (see
Section 5.3.2 of [RFC4791]). It allows clients to set the default
time zone using only a time zone identifier. It also indicates to
the client, the time zone identifier of the current default time
zone. See Section 3.1.5 for more details.
Definition:
<!ELEMENT calendar-timezone-id (#PCDATA)>
PCDATA value: an 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], is modified to allow use of the CALDAV:timezone-id XML
element as follows:
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: Specifies the time zone identifier for a time zone
component to use when determining the results of a report.
Daboo Expires April 15, 2016 [Page 9]
Internet-Draft CalDAV Time Zone Extension October 2015
Description: The CALDAV:timezone-id XML element is used as an
alternative to the CALDAV:timezone XML element (see Section 9.8 of
[RFC4791]) in calendar query reports, to allow a client to specify
a time zone using a time zone identifier rather than providing the
full iCalendar time zone data. See Section 3.1.6 for more
details.
Definition:
<!ELEMENT timezone-id (#PCDATA)>
PCDATA value: an time zone identifier.
7. Additional Message Header Fields
7.1. CalDAV-Timezones Request Header Field
The "CalDAV-Timezones" request header field provides a way for a
client to indicate to the server whether it wants "VTIMEZONE"
components returned in any iCalendar data that is part of the HTTP
response. The value "T" indicates that the client wants time zone
data returned, the value "F" indicates that it does not.
CalDAV-Timezones = "T" / "F"
Example:
CalDAV-Timezones: F
8. Security Considerations
This specifications adds Time Zone Data Distribution Service
[I-D.ietf-tzdist-service] servers into the overall calendaring and
scheduling client/server architecture, as a critical component, and
thus adds a new vector of attack against such systems. As such,
administrators of CalDAV servers SHOULD ensure that any advertised
time zone distribution servers are protected by a level of security
commensurate with all the other components in the system.
Beyond the above point, this specification does not introduce any new
security concerns beyond those addressed in CalDAV [RFC4791],
iCalendar [RFC5545], and the Time Zone Data Distribution Service
[I-D.ietf-tzdist-service].
9. Privacy Considerations
The privacy recommendations in Section 9 of the Time Zone Data
Distribution Service [I-D.ietf-tzdist-service] specification SHOULD
be used to ensure that details of clients' interactions with CalDAV
Daboo Expires April 15, 2016 [Page 10]
Internet-Draft CalDAV Time Zone Extension October 2015
servers are not exposed to potential network observers. Note that
since events can be delivered to a calendar user from an outside
source (e.g., using iTIP [RFC5546]), and an attacker could create a
calendar event with, e.g., a fake or lesser-used time zone identifier
that could be used to monitor the calendar user's activity and
interaction with others, this specification increases the importance
of using the mitigations of privacy issues discussed in
[I-D.ietf-tzdist-service].
10. IANA Considerations
The message header field below should be 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 specification (Section 7.1)
Related information: none
11. Acknowledgments
Thanks to Mike Douglass, Andrew McMillan, and Ken Murchison. This
specification came about via discussions at the Calendaring and
Scheduling Consortium.
12. References
12.1. Normative References
[I-D.ietf-tzdist-service]
Douglass, M. and C. Daboo, "Time Zone Data Distribution
Service", draft-ietf-tzdist-service-11 (work in progress),
July 2015.
[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>.
Daboo Expires April 15, 2016 [Page 11]
Internet-Draft CalDAV Time Zone Extension October 2015
[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>.
12.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>.
Appendix A. Change History (To be removed by RFC Editor before
publication)
Changes in -05:
1. IESG Review: abstract now says "updates" instead of "extends".
Daboo Expires April 15, 2016 [Page 12]
Internet-Draft CalDAV Time Zone Extension October 2015
2. IESG Review: 3.1.5, 3.1.6 section title tweaks.
3. IESG Review: add tzdist reference in Security Considerations.
4. IESG Review: fixed truncated sentence in bullet #3 in Section 4.
5. IESG Review: added privacy considerations section that references
the corresponding tzdist service section.
6. IESG Review: added text to security considerations section to
indicate tzdist servers need to be protected as well as the
caldav server.
Changes in -04:
1. AD Review: added Updates 4791
2. AD Review: reworded first bullet of Section 4 to indicate clients
have a choice of where to locate time zones
3. AD Review: added text about server providing an admin config
option to override new default behavior
4. AD Review: Replaced Prefer header with CalDAV-Timezones
Changes in -03:
1. Chair Review: minor editorial changes
2. Chair Review: expanded item #3 in Section 3.1.4 to clarify the
behavior and indicate when it would not be appropriate.
Changes in -02:
1. Ticket #27: added an HTTP Prefer header preference to allow
clients to explicitly state whether they want or do not want
VTIMEZONEs from the server.
Changes in -01:
1. Ticket #24: rewording intro to Section 3 to remove the MUST.
2. Ticket #26: rewording Section 3.1.1 to not provide advice about
how to handle limited devices.
Changes in -00:
Daboo Expires April 15, 2016 [Page 13]
Internet-Draft CalDAV Time Zone Extension October 2015
1. Initial WG draft derived from draft-daboo-caldav-timezone-ref-01,
with some terminology changes to match WG name.
2. "timezone" -> "time zone" (https://tools.ietf.org/wg/tzdist/trac/
ticket/6).
Author's Address
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino , CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
Daboo Expires April 15, 2016 [Page 14]
