idnits 2.17.1
draft-ietf-tzdist-caldav-timezone-ref-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC4791, but the
abstract doesn't seem to directly say this. It does mention RFC4791
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC4791, updated by this document, for
RFC5378 checks: 2004-06-24)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 13, 2015) is 3112 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Daboo
3 Internet-Draft Apple
4 Updates: 4791 (if approved) October 13, 2015
5 Intended status: Standards Track
6 Expires: April 15, 2016
8 CalDAV: Time Zones by Reference
9 draft-ietf-tzdist-caldav-timezone-ref-05
11 Abstract
13 This document defines an update to the CalDAV calendar access
14 protocol (RFC 4791) to allow clients and servers to exchange
15 iCalendar data without the need to send full time zone data.
17 Status of This Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on April 15, 2016.
34 Copyright Notice
36 Copyright (c) 2015 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
53 3. Time Zones by Reference . . . . . . . . . . . . . . . . . . . 3
54 3.1. New Server Behavior . . . . . . . . . . . . . . . . . . . 3
55 4. New Client Behavior . . . . . . . . . . . . . . . . . . . . . 7
56 5. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 8
57 5.1. CALDAV:timezone-service-set . . . . . . . . . . . . . . . 8
58 5.2. CALDAV:calendar-timezone-id . . . . . . . . . . . . . . . 8
59 6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 9
60 6.1. CALDAV:calendar-query XML Element . . . . . . . . . . . . 9
61 6.2. CALDAV:timezone-id XML Element . . . . . . . . . . . . . 9
62 7. Additional Message Header Fields . . . . . . . . . . . . . . 10
63 7.1. CalDAV-Timezones Request Header Field . . . . . . . . . . 10
64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
65 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
67 10.1. CalDAV-Timezones . . . . . . . . . . . . . . . . . . . . 11
68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
70 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
71 12.2. Informative References . . . . . . . . . . . . . . . . . 12
72 Appendix A. Change History (To be removed by RFC Editor before
73 publication) . . . . . . . . . . . . . . . . . . . . 12
74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
76 1. Introduction
78 The CalDAV [RFC4791] Calendar Access protocol allows clients to
79 access calendar data stored on a server in the iCalendar [RFC5545]
80 data format. In iCalendar, calendar data that uses local time in any
81 of its date and/or time values is specified as a date-time value in
82 combination with a time zone identifier ("TZID" property parameter).
83 The time zone identifier refers to a time zone definition (a
84 "VTIMEZONE" component) that has all of the rules required to
85 determine local time UTC offsets for the corresponding time zone. In
86 many cases, these "VTIMEZONE" components can be larger, octet-wise,
87 than the events or tasks which make use of them. However, iCalendar
88 currently requires all iCalendar objects ("VCALENDAR" components)
89 that refer to a time zone via its identifier to also include the
90 corresponding "VTIMEZONE" component. This leads to inefficiencies in
91 the CalDAV protocol because large amounts of "VTIMEZONE" data are
92 continuously being exchanged, and for the most part these time zone
93 definitions are unchanging. This is of particular problem to mobile
94 or limited devices, with limited network bandwidth, cpu processing,
95 and power constraints.
97 A set of standard time zone definitions are available at the IANA
98 hosted time zone database [RFC6557]. That database provides the
99 "raw" data for time zone definitions, and those can be converted into
100 iCalendar "VTIMEZONE" components for use in iCalendar applications,
101 as well as converted into other formats for use by other applications
102 (e.g., "zoneinfo" files often found on Unix-based operating systems).
103 A new Time Zone Data Distribution Service [I-D.ietf-tzdist-service]
104 protocol is available that allows iCalendar applications to retrieve
105 these standard time zone definitions in a timely and accurate
106 fashion, instead of relying on possibly infrequent system updates of
107 time zone data that frequently result in mismatched calendar data and
108 resulting missed meetings between calendar users. Another benefit of
109 the Time Zone Data Distribution Service is that it provides a single
110 "reference" for standard time zone data that CalDAV clients and
111 servers can make use of to "agree" on standard time zone definitions,
112 and thus eliminate the need to exchange the data for those.
114 This specification defines a new mode of operation for CalDAV clients
115 and servers which allow them to exchange iCalendar data without the
116 need to send "VTIMEZONE" components for known, standard time zone
117 definitions. This can significantly reduce the amount of data that
118 needs to be sent between client and server, giving rise to
119 performance and efficiency improvements for each of them.
121 2. Conventions Used in This Document
123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
125 "OPTIONAL" in this document are to be interpreted as described in
126 [RFC2119].
128 Other notations used in this memo follow the notations of [RFC4791].
130 3. Time Zones by Reference
132 Note that this specification only defines changes to iCalendar data
133 sent or received via the CalDAV protocol (both [RFC4791] and
134 [RFC6638], and extensions). These changes do not apply to other
135 means of exchanging calendar data, such as iTIP [RFC5546] based
136 scheduling mechanisms (e.g., iMIP [RFC6047]), or other methods.
138 3.1. New Server Behavior
140 3.1.1. Server Advertised Capability
142 A server that supports this specification MUST include "calendar-no-
143 timezone" as a field in the DAV response header field from an OPTIONS
144 request on a calendar home collection (see Section 6.2.1 of
146 [RFC4791]) or calendar collection (see Section 4.2 of [RFC4791]).
147 Clients MUST check for the presence of that field in the DAV response
148 header field before changing their behavior as per Section 4.
150 3.1.2. Associated Time Zone Data Distribution Service
152 A CalDAV server supporting this specification MUST have one or more
153 associated time zone distribution services [I-D.ietf-tzdist-service]
154 that provide data for the set of time zones known to the server and
155 expected to be used by clients. A CalDAV server advertises the set
156 of time zone distribution services it makes use of via a
157 CALDAV:timezone-service-set WebDAV property (see Section 5.1) defined
158 on calendar home collections. Clients can use the time zone data
159 distribution services listed in this property to fetch current time
160 zone definitions for the time zone identifiers in iCalendar data
161 retrieved from the server. This allows clients to keep their "built-
162 in" time zone definitions up to date. It also allows clients to use
163 an "on-demand" model for populating their local time zone definition
164 cache, only fetching a time zone definition when it is first seen in
165 calendar data, potentially allowing for savings on storage space by
166 eliminating the need to store time zone data that is not currently
167 being used.
169 When making use of the time zone data distribution services
170 advertised by a CalDAV server, clients MUST follow all the
171 requirements of the time zone data distribution service protocol
172 [I-D.ietf-tzdist-service], taking care to refresh time zone data in a
173 timely fashion.
175 3.1.3. Time Zones in CalDAV Responses
177 Servers MUST support the HTTP "CalDAV-Timezones" request header field
178 (see Section 7.1). If the "CalDAV-Timezones" request header field
179 has the value "T" on any HTTP request that returns iCalendar data,
180 then the server MUST include all the appropriate "VTIMEZONE"
181 components in the iCalendar data (all the ones that are referenced by
182 "TZID" property parameters). If the "CalDAV-Timezones" request
183 header field has the value "F" on any HTTP request that returns
184 iCalendar data, then the server MUST NOT return any "VTIMEZONE"
185 components if the time zone identifier matches one provided by any of
186 the advertised time zone distribution servers (see Section 3.1.2).
187 However, the server MUST return the appropriate "VTIMEZONE" component
188 for each time zone with an identifier not available on the advertised
189 time zone distribution servers. This behaviour applies to all HTTP
190 requests on CalDAV resources that return iCalendar data either
191 directly (such as a "GET" request on a calendar object resource), or
192 embedded in a "structured" response such as a DAV:multistatus
193 returned by a "REPORT" or "PROPFIND" request.
195 Observation and experiments have shown that, in the vast majority of
196 cases, CalDAV clients have typically ignored time zone definitions in
197 data received from servers, and instead make use of their own "built-
198 in" definitions for the corresponding time zone identifier. This
199 means that it is reasonable for CalDAV servers to unilaterally decide
200 not to send "VTIMEZONE" components for standard time zones that
201 clients are expected to have "built-in" (i.e., IANA time zones).
202 Thus, in the absence of a "CalDAV-Timezones" request header field,
203 servers advertizing the "calendar-no-timezone" capability MAY opt to
204 not send standard "VTIMEZONE" components. Servers that do that will
205 need to provide an administrator configuration setting to override
206 the new default behavior based on client "User-Agent" request header
207 field field values, or other suitable means of identifying the client
208 software in use.
210 3.1.4. Time Zones in CalDAV Requests
212 In addition to servers not sending time zone definitions to clients
213 in iCalendar data, this specification also allows clients to not
214 include time zone definitions when sending iCalendar data to the
215 server, as per Section 4. This behaviour applies to all HTTP
216 requests on CalDAV resources that include iCalendar data either
217 directly in the request body (such as a "PUT" request on a calendar
218 object resource), or embedded in a "structured" request body such as
219 a one used by "PROPPATCH" request.
221 Note that, as per Section 4, clients might send time zone definitions
222 for time zones that are not advertised by any of the time zone
223 services associated with the server. In that case, servers have
224 various choices:
226 1. Servers can preserve the original time zone definitions in the
227 iCalendar data sent by the client, so that those can be returned
228 to that or other clients who subsequently request iCalendar data.
230 2. Servers can refuse to accept any unknown/non-standard time zones,
231 in which case they MUST reject the HTTP request containing such
232 data using a WebDAV precondition code of CALDAV:valid-timezone.
234 3. Servers can, with appropriate knowledge, map the unknown/non-
235 standard time zone to a standard time zone definition that
236 accurately matches the one supplied by the client. In doing so,
237 servers will need to re-write the iCalendar data to make use of
238 the new standard time zone identifier chosen by the mapping
239 procedure. Any subsequent request to fetch the calendar data
240 would see the new time zone identifier in the calendar data.
241 Note there is one important situation where this re-mapping is
242 not appropriate: an attendee's copy of an event. In that case
243 the original time zone definition needs to be preserved as the
244 organizer's calendar user agent will expect to see that in any
245 iTIP [RFC5546] replies sent by the attendee.
247 3.1.5. Support of Time Zone Identifiers in WebDAV Properties
249 CalDAV defines a CALDAV:calendar-timezone WebDAV property that is
250 used by clients to set a default time zone for the server to use when
251 doing time-based queries on calendar data (see Section 5.3.2 of
252 [RFC4791]). The content of that WebDAV property is an iCalendar
253 "VTIMEZONE" component. This specification defines a new
254 CALDAV:calendar-timezone-id WebDAV property that allows the default
255 time zone to be set via its time zone identifier, rather than
256 providing the full "VTIMEZONE" component (see Section 5.2). This
257 WebDAV property MUST be present on all resources that also support
258 the CALDAV:calendar-timezone WebDAV property. Its value MUST match
259 the value of the "TZID" iCalendar property in the "VTIMEZONE"
260 component in the CALDAV:calendar-timezone WebDAV property on the same
261 resource. The server MUST accept clients setting either the
262 CALDAV:calendar-timezone or the CALDAV:calendar-timezone-id, and it
263 MUST adjust the value of the alternate property to reflect any
264 changes. i.e., if a client sets the CALDAV:calendar-timezone-id
265 WebDAV property value to "America/New_York", then the server will
266 return the full "VTIMEZONE" data for that time zone in the
267 CALDAV:calendar-timezone WebDAV property.
269 If a client attempts to update the CALDAV:calendar-timezone-id with a
270 value that does not correspond to a time zone that is known to the
271 server, the server MUST reject the property update using a
272 CALDAV:valid-timezone pre-condition error. In such cases, clients
273 MAY repeat the request using the CALDAV:calendar-timezone instead,
274 and provide the full iCalendar data for the time zone being set.
276 3.1.6. Support of Time Zone Identifiers in CALDAV:calendar-query REPORT
278 CalDAV calendar query reports support a CALDAV:timezone XML element
279 that is used by clients to set a specific time zone for the server to
280 use when doing time-based queries on calendar data (see Sections 7.3
281 and 9.8 of [RFC4791]). The content of that XML element is an
282 iCalendar "VTIMEZONE" component. This specification defines a new
283 CALDAV:timezone-id XML element, that can be used as an alternative to
284 the CALDAV:timezone XML element, that allows a specific time zone to
285 be set via its time zone identifier, rather than providing the full
286 "VTIMEZONE" component (see Section 6.2). Servers MUST support
287 clients providing a time zone identifier for use in a calendar query
288 REPORT using this new element.
290 If a client attempts use a CALDAV:timezone-id XML element with a
291 value that does not correspond to a time zone that is known to the
292 server, the server MUST reject the request with a CALDAV:valid-
293 timezone pre-condition error. In such cases, clients MAY repeat the
294 request using the CALDAV:timezone XML element instead, and provide
295 the full iCalendar data for the time zone being used.
297 4. New Client Behavior
299 When a server advertises the "calendar-no-timezone" field in a DAV
300 response header field (as per Section 3.1.1):
302 1. Clients SHOULD include an HTTP "CalDAV-Timezones" request header
303 field with a value of "F" to ensure that the CalDAV server does
304 not include "VTIMEZONE" components in any iCalendar data returned
305 in a response (see Section 3.1.3), for those time zones whose
306 identifier is one provided by any of the advertised time zone
307 distribution servers (see Section 3.1.2). In this case, clients
308 will have to retrieve the missing standard time zone definitions
309 either from their own cache of standard time zones, or from the
310 set of time zone distribution servers advertised by the CalDAV
311 server (see Section 3.1.2).
313 2. Clients can include an HTTP "CalDAV-Timezones" request header
314 field with a value of "T" to ensure that the CalDAV server does
315 include all "VTIMEZONE" components in any iCalendar data returned
316 in a response (see Section 3.1.3).
318 3. Clients can expect servers not to include standard time zone
319 definitions in any iCalendar data they receive from the server,
320 if there is no "CalDAV-Timezones" request header field in the
321 HTTP request. Clients MUST retrieve standard time zone
322 definitions either from its own cache of standard time zones, or
323 from the set of time zone distribution servers advertised by the
324 CalDAV server (see Section 3.1.2).
326 4. Clients SHOULD remove standard time zone definitions from
327 iCalendar data they send to the server, provided the
328 corresponding time zone identifier is one available on any of the
329 server's advertised time zone distribution servers (see
330 Section 3.1.2).
332 5. Clients MUST send time zone definitions in iCalendar data for any
333 time zone identifiers not available via any of the server's
334 advertised time zone distribution servers. Clients MUST be
335 prepared for the server to reject such data or map the time zone
336 to one in the set of standard time zones provided by the server's
337 associated time zone services (as per Section 3.1.4).
339 6. Clients SHOULD make use of the CALDAV:calendar-timezone-id WebDAV
340 property (see Section 3.1.5) and CalDAV:timezone-id XML element
341 (see Section 3.1.6) for specifying default and specific time
342 zones to use in calendar queries executed by the server.
344 5. New WebDAV Properties
346 5.1. CALDAV:timezone-service-set
348 Name: timezone-service-set
350 Namespace: urn:ietf:params:xml:ns:caldav
352 Purpose: Specifies one or more time zone data distribution servers
353 being used by the CalDAV server to provide standard time zone
354 data.
356 Conformance: This property SHOULD be defined on CalDAV calendar home
357 collection resources. If defined, it SHOULD NOT be returned by a
358 PROPFIND DAV:allprop request (as defined in Section 14.2 of
359 [RFC4918]).
361 Description: The CALDAV:timezone-service-set property lists one or
362 more time zone data distribution servers that the CalDAV server is
363 using to provide its set of time zone data. See Section 3.1.2 for
364 more details.
366 Definition:
368
369 DAV:href value: URI of a time zone data distribution service
370 as defined by this specification.
372 Example:
374
377 https://timezones.example.com
378
380 5.2. CALDAV:calendar-timezone-id
382 Name: calendar-timezone-id
384 Namespace: urn:ietf:params:xml:ns:caldav
386 Purpose: Specifies a time zone identifier for a calendar collection.
388 Conformance: This property SHOULD be defined on all resources where
389 the CALDAV:calendar-timezone property is also defined. If
390 defined, it SHOULD NOT be returned by a PROPFIND DAV:allprop
391 request (as defined in Section 14.2 of [RFC4918]).
393 Description: The CALDAV:calendar-timezone-id property is used as an
394 alternative to the CALDAV:calendar-timezone property (see
395 Section 5.3.2 of [RFC4791]). It allows clients to set the default
396 time zone using only a time zone identifier. It also indicates to
397 the client, the time zone identifier of the current default time
398 zone. See Section 3.1.5 for more details.
400 Definition:
402
403 PCDATA value: an time zone identifier.
405 Example:
407 US-Eastern<
409 /C:calendar-timezone-id>
411 6. XML Element Definitions
413 6.1. CALDAV:calendar-query XML Element
415 The CALDAV:calendar-query XML element, defined in Section 9.5 of
416 [RFC4791], is modified to allow use of the CALDAV:timezone-id XML
417 element as follows:
419 Definition:
421
426 6.2. CALDAV:timezone-id XML Element
428 Name: timezone-id
430 Namespace: urn:ietf:params:xml:ns:caldav
432 Purpose: Specifies the time zone identifier for a time zone
433 component to use when determining the results of a report.
435 Description: The CALDAV:timezone-id XML element is used as an
436 alternative to the CALDAV:timezone XML element (see Section 9.8 of
437 [RFC4791]) in calendar query reports, to allow a client to specify
438 a time zone using a time zone identifier rather than providing the
439 full iCalendar time zone data. See Section 3.1.6 for more
440 details.
442 Definition:
444
445 PCDATA value: an time zone identifier.
447 7. Additional Message Header Fields
449 7.1. CalDAV-Timezones Request Header Field
451 The "CalDAV-Timezones" request header field provides a way for a
452 client to indicate to the server whether it wants "VTIMEZONE"
453 components returned in any iCalendar data that is part of the HTTP
454 response. The value "T" indicates that the client wants time zone
455 data returned, the value "F" indicates that it does not.
457 CalDAV-Timezones = "T" / "F"
459 Example:
461 CalDAV-Timezones: F
463 8. Security Considerations
465 This specifications adds Time Zone Data Distribution Service
466 [I-D.ietf-tzdist-service] servers into the overall calendaring and
467 scheduling client/server architecture, as a critical component, and
468 thus adds a new vector of attack against such systems. As such,
469 administrators of CalDAV servers SHOULD ensure that any advertised
470 time zone distribution servers are protected by a level of security
471 commensurate with all the other components in the system.
473 Beyond the above point, this specification does not introduce any new
474 security concerns beyond those addressed in CalDAV [RFC4791],
475 iCalendar [RFC5545], and the Time Zone Data Distribution Service
476 [I-D.ietf-tzdist-service].
478 9. Privacy Considerations
480 The privacy recommendations in Section 9 of the Time Zone Data
481 Distribution Service [I-D.ietf-tzdist-service] specification SHOULD
482 be used to ensure that details of clients' interactions with CalDAV
483 servers are not exposed to potential network observers. Note that
484 since events can be delivered to a calendar user from an outside
485 source (e.g., using iTIP [RFC5546]), and an attacker could create a
486 calendar event with, e.g., a fake or lesser-used time zone identifier
487 that could be used to monitor the calendar user's activity and
488 interaction with others, this specification increases the importance
489 of using the mitigations of privacy issues discussed in
490 [I-D.ietf-tzdist-service].
492 10. IANA Considerations
494 The message header field below should be added to the Permanent
495 Message Header Field Registry (see [RFC3864]).
497 10.1. CalDAV-Timezones
499 Header field name: CalDAV-Timezones
501 Applicable protocol: http
503 Status: standard
505 Author/Change controller: IETF
507 Specification document(s): this specification (Section 7.1)
509 Related information: none
511 11. Acknowledgments
513 Thanks to Mike Douglass, Andrew McMillan, and Ken Murchison. This
514 specification came about via discussions at the Calendaring and
515 Scheduling Consortium.
517 12. References
519 12.1. Normative References
521 [I-D.ietf-tzdist-service]
522 Douglass, M. and C. Daboo, "Time Zone Data Distribution
523 Service", draft-ietf-tzdist-service-11 (work in progress),
524 July 2015.
526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
527 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
528 RFC2119, March 1997,
529 .
531 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
532 Procedures for Message Header Fields", BCP 90, RFC 3864,
533 DOI 10.17487/RFC3864, September 2004,
534 .
536 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
537 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI
538 10.17487/RFC4791, March 2007,
539 .
541 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
542 Authoring and Versioning (WebDAV)", RFC 4918, DOI
543 10.17487/RFC4918, June 2007,
544 .
546 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
547 Scheduling Core Object Specification (iCalendar)", RFC
548 5545, DOI 10.17487/RFC5545, September 2009,
549 .
551 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
552 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
553 .
555 12.2. Informative References
557 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
558 Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/
559 RFC5546, December 2009,
560 .
562 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based
563 Interoperability Protocol (iMIP)", RFC 6047, DOI 10.17487/
564 RFC6047, December 2010,
565 .
567 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
568 Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/
569 RFC6557, February 2012,
570 .
572 Appendix A. Change History (To be removed by RFC Editor before
573 publication)
575 Changes in -05:
577 1. IESG Review: abstract now says "updates" instead of "extends".
579 2. IESG Review: 3.1.5, 3.1.6 section title tweaks.
581 3. IESG Review: add tzdist reference in Security Considerations.
583 4. IESG Review: fixed truncated sentence in bullet #3 in Section 4.
585 5. IESG Review: added privacy considerations section that references
586 the corresponding tzdist service section.
588 6. IESG Review: added text to security considerations section to
589 indicate tzdist servers need to be protected as well as the
590 caldav server.
592 Changes in -04:
594 1. AD Review: added Updates 4791
596 2. AD Review: reworded first bullet of Section 4 to indicate clients
597 have a choice of where to locate time zones
599 3. AD Review: added text about server providing an admin config
600 option to override new default behavior
602 4. AD Review: Replaced Prefer header with CalDAV-Timezones
604 Changes in -03:
606 1. Chair Review: minor editorial changes
608 2. Chair Review: expanded item #3 in Section 3.1.4 to clarify the
609 behavior and indicate when it would not be appropriate.
611 Changes in -02:
613 1. Ticket #27: added an HTTP Prefer header preference to allow
614 clients to explicitly state whether they want or do not want
615 VTIMEZONEs from the server.
617 Changes in -01:
619 1. Ticket #24: rewording intro to Section 3 to remove the MUST.
621 2. Ticket #26: rewording Section 3.1.1 to not provide advice about
622 how to handle limited devices.
624 Changes in -00:
626 1. Initial WG draft derived from draft-daboo-caldav-timezone-ref-01,
627 with some terminology changes to match WG name.
629 2. "timezone" -> "time zone" (https://tools.ietf.org/wg/tzdist/trac/
630 ticket/6).
632 Author's Address
634 Cyrus Daboo
635 Apple Inc.
636 1 Infinite Loop
637 Cupertino , CA 95014
638 USA
640 Email: cyrus@daboo.name
641 URI: http://www.apple.com/