7Internet Engineering Task Force (IETF) C. Daboo
8Request for Comments: 7809 Apple
9Updates: 4791 March 2016
10Category: Standards Track
14 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
18 This document defines an update to the Calendaring Extensions to
19 WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients
20 and servers to exchange iCalendar data without the need to send full
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 5741.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 http://www.rfc-editor.org/info/rfc7809.
39 Copyright (c) 2016 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
58Daboo Standards Track [Page 1]
60RFC 7809 CalDAV Time Zone Extension March 2016
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. Time Zones by Reference . . . . . . . . . . . . . . . . . . . 3
68 3.1. New Server Behavior . . . . . . . . . . . . . . . . . . . 4
69 4. New Client Behavior . . . . . . . . . . . . . . . . . . . . . 7
70 5. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 8
71 5.1. CALDAV:timezone-service-set . . . . . . . . . . . . . . . 8
72 5.2. CALDAV:calendar-timezone-id . . . . . . . . . . . . . . . 9
73 6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 9
74 6.1. CALDAV:calendar-query XML Element . . . . . . . . . . . . 9
75 6.2. CALDAV:timezone-id XML Element . . . . . . . . . . . . . 10
76 7. Additional Message Header Fields . . . . . . . . . . . . . . 10
77 7.1. CalDAV-Timezones Request Header Field . . . . . . . . . . 10
78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
79 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
81 10.1. CalDAV-Timezones . . . . . . . . . . . . . . . . . . . . 11
82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
83 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
84 11.2. Informative References . . . . . . . . . . . . . . . . . 12
85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
90 The CalDAV [RFC4791] calendar access protocol allows clients to
91 access calendar data stored on a server in the iCalendar [RFC5545]
92 data format. In iCalendar, calendar data that uses local time in any
93 of its date and/or time values is specified as a date-time value in
94 combination with a time zone identifier ("TZID" property parameter).
95 The time zone identifier refers to a time zone definition (a
96 "VTIMEZONE" component) that has all of the rules required to
97 determine local-time UTC offsets for the corresponding time zone. In
98 many cases, these "VTIMEZONE" components can be larger, octet-wise,
99 than the events or tasks that make use of them. However, iCalendar
100 currently requires all iCalendar objects ("VCALENDAR" components)
101 that refer to a time zone via its identifier to also include the
102 corresponding "VTIMEZONE" component. This leads to inefficiencies in
103 the CalDAV protocol because large amounts of "VTIMEZONE" data are
104 continuously being exchanged, and for the most part these time zone
105 definitions are unchanging. This is particularly problematic for
106 mobile or limited devices, with limited network bandwidth, CPU, and
114Daboo Standards Track [Page 2]
116RFC 7809 CalDAV Time Zone Extension March 2016
119 A set of standard time zone definitions are available at the IANA-
120 hosted time zone database [RFC6557]. That database provides the
121 "raw" data for time zone definitions, and those can be converted into
122 iCalendar "VTIMEZONE" components for use in iCalendar applications,
123 as well as converted into other formats for use by other applications
124 (e.g., "zoneinfo" files often found on Unix-based operating systems).
125 A new time zone data distribution service protocol [RFC7808] is
126 available that allows iCalendar applications to retrieve these
127 standard time zone definitions in a timely and accurate fashion,
128 instead of relying on possibly infrequent system updates of time zone
129 data that frequently result in mismatched calendar data and thus
130 missed meetings between calendar users. Another benefit of the time
131 zone data distribution service is that it provides a single
132 "reference" for standard time zone data that CalDAV clients and
133 servers can make use of to "agree" on standard time zone definitions,
134 and thus eliminate the need to exchange the data for those.
136 This specification defines a new mode of operation for CalDAV clients
137 and servers that allows them to exchange iCalendar data without the
138 need to send "VTIMEZONE" components for known, standard time zone
139 definitions. This can significantly reduce the amount of data that
140 needs to be sent between client and server, giving rise to
141 performance and efficiency improvements for each of them.
1432. Conventions Used in This Document
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
147 "OPTIONAL" in this document are to be interpreted as described in
150 Other notations used in this memo are as in [RFC4791].
1523. Time Zones by Reference
154 Note that this specification only defines changes to iCalendar data
155 sent or received via the CalDAV protocol (both [RFC4791] and
156 [RFC6638], and extensions). These changes do not apply to other
157 means of exchanging calendar data, such as scheduling mechanisms
158 based on the iCalendar Transport-Independent Interoperability
159 Protocol (iTIP) [RFC5546], e.g., the iCalendar Message-Based
160 Interoperability Protocol (iMIP) [RFC6047], or other methods.
170Daboo Standards Track [Page 3]
172RFC 7809 CalDAV Time Zone Extension March 2016
1753.1. New Server Behavior
1773.1.1. Server Advertised Capability
179 A server that supports this specification MUST include "calendar-no-
180 timezone" as a field in the DAV response header field from an
181 "OPTIONS" request on a calendar home collection (see Section 6.2.1 of
182 [RFC4791]) or calendar collection (see Section 4.2 of [RFC4791]).
183 Clients MUST check for the presence of that field in the DAV response
184 header field before changing their behavior as per Section 4.
1863.1.2. Associated Time Zone Data Distribution Service
188 A CalDAV server supporting this specification MUST have one or more
189 associated time zone distribution services [RFC7808] that provide
190 data for the set of time zones known to the server and expected to be
191 used by clients. A CalDAV server advertises the set of time zone
192 distribution services it makes use of via a CALDAV:timezone-service-
193 set WebDAV property (see Section 5.1) defined on calendar home
194 collections. Clients can use the time zone data distribution
195 services listed in this property to fetch current time zone
196 definitions for the time zone identifiers in iCalendar data retrieved
197 from the server. This allows clients to keep their "built-in" time
198 zone definitions up to date. It also allows clients to use an "on-
199 demand" model for populating their local time zone definition cache,
200 only fetching a time zone definition when it is first seen in
201 calendar data, potentially allowing for savings on storage space by
202 eliminating the need to store time zone data that is not currently
205 When making use of the time zone data distribution services
206 advertised by a CalDAV server, clients MUST follow all the
207 requirements of the time zone data distribution service protocol
208 [RFC7808], taking care to refresh time zone data in a timely fashion.
2103.1.3. Time Zones in CalDAV Responses
212 Servers MUST support the HTTP "CalDAV-Timezones" request header field
213 (see Section 7.1). If the "CalDAV-Timezones" request header field
214 has the value "T" on any HTTP request that returns iCalendar data,
215 then the server MUST include all the appropriate "VTIMEZONE"
216 components in the iCalendar data (all the ones that are referenced by
217 "TZID" property parameters). If the "CalDAV-Timezones" request
218 header field has the value "F" on any HTTP request that returns
219 iCalendar data, then the server MUST NOT return any "VTIMEZONE"
220 components if the time zone identifier matches one provided by any of
221 the advertised time zone distribution servers (see Section 3.1.2).
222 However, the server MUST return the appropriate "VTIMEZONE" component
226Daboo Standards Track [Page 4]
228RFC 7809 CalDAV Time Zone Extension March 2016
231 for each time zone with an identifier not available on the advertised
232 time zone distribution servers. This behavior applies to all HTTP
233 requests on CalDAV resources that return iCalendar data either
234 directly (such as a "GET" request on a calendar object resource), or
235 embedded in a "structured" response such as a DAV:multistatus
236 returned by a "REPORT" or "PROPFIND" request.
238 Observation and experiments have shown that, in the vast majority of
239 cases, CalDAV clients have typically ignored time zone definitions in
240 data received from servers, and instead make use of their own "built-
241 in" definitions for the corresponding time zone identifier. This
242 means that it is reasonable for CalDAV servers to unilaterally decide
243 not to send "VTIMEZONE" components for standard time zones that
244 clients are expected to have "built-in" (i.e., IANA time zones).
245 Thus, in the absence of a "CalDAV-Timezones" request header field,
246 servers advertising the "calendar-no-timezone" capability MAY opt to
247 not send standard "VTIMEZONE" components. Servers that do that will
248 need to provide an administrator configuration setting to override
249 the new default behavior based on client "User-Agent" request header
250 field values, or other suitable means of identifying the client
2533.1.4. Time Zones in CalDAV Requests
255 In addition to servers not sending time zone definitions to clients
256 in iCalendar data, this specification also allows clients to not
257 include time zone definitions when sending iCalendar data to the
258 server, as per Section 4. This behavior applies to all HTTP requests
259 on CalDAV resources that include iCalendar data either directly in
260 the request body (such as a "PUT" request on a calendar object
261 resource) or embedded in a "structured" request body such as a one
262 used by a "PROPPATCH" request.
264 Note that, as per Section 4, clients might send time zone definitions
265 for time zones that are not advertised by any of the time zone
266 services associated with the server. In that case, servers have
269 1. Servers can preserve the original time zone definitions in the
270 iCalendar data sent by the client, so that those can be returned
271 to that client or other clients who subsequently request
274 2. Servers can refuse to accept any unknown/nonstandard time zones
275 -- in which case, they MUST reject the HTTP request containing
276 such data using a WebDAV precondition code of
277 CALDAV:valid-timezone.
282Daboo Standards Track [Page 5]
284RFC 7809 CalDAV Time Zone Extension March 2016
287 3. Servers can, with appropriate knowledge, map the unknown/
288 nonstandard time zone to a standard time zone definition that
289 accurately matches the one supplied by the client. In doing so,
290 servers will need to rewrite the iCalendar data to make use of
291 the new standard time zone identifier chosen by the mapping
292 procedure. Any subsequent request to fetch the calendar data
293 would see the new time zone identifier in the calendar data.
294 Note there is one important situation where this remapping is not
295 appropriate: an attendee's copy of an event. In that case, the
296 original time zone definition needs to be preserved as the
297 organizer's calendar user agent will expect to see that in any
298 iTIP [RFC5546] replies sent by the attendee.
3003.1.5. Support of Time Zone Identifiers in WebDAV Properties
302 CalDAV defines a CALDAV:calendar-timezone WebDAV property that is
303 used by clients to set a default time zone for the server to use when
304 doing time-based queries on calendar data (see Section 5.3.2 of
305 [RFC4791]). The content of that WebDAV property is an iCalendar
306 "VTIMEZONE" component. This specification defines a new
307 CALDAV:calendar-timezone-id WebDAV property that allows the default
308 time zone to be set via its time zone identifier, rather than
309 providing the full "VTIMEZONE" component (see Section 5.2). This
310 WebDAV property MUST be present on all resources that also support
311 the CALDAV:calendar-timezone WebDAV property. Its value MUST match
312 the value of the "TZID" iCalendar property in the "VTIMEZONE"
313 component in the CALDAV:calendar-timezone WebDAV property on the same
314 resource. The server MUST accept clients that set either the
315 CALDAV:calendar-timezone or the CALDAV:calendar-timezone-id, and it
316 MUST adjust the value of the alternate property to reflect any
317 changes. That is, if a client sets the CALDAV:calendar-timezone-id
318 WebDAV property value to "America/New_York", then the server will
319 return the full "VTIMEZONE" data for that time zone in the
320 CALDAV:calendar-timezone WebDAV property.
322 If a client attempts to update the CALDAV:calendar-timezone-id with a
323 value that does not correspond to a time zone that is known to the
324 server, the server MUST reject the property update using a
325 CALDAV:valid-timezone pre-condition error. In such cases, clients
326 MAY repeat the request using the CALDAV:calendar-timezone instead,
327 and provide the full iCalendar data for the time zone being set.
3293.1.6. Support of Time Zone Identifiers in CALDAV:calendar-query REPORT
331 CalDAV calendar query reports support a CALDAV:timezone XML element
332 that is used by clients to set a specific time zone for the server to
333 use when doing time-based queries on calendar data (see Sections 7.3
334 and 9.8 of [RFC4791]). The content of that XML element is an
338Daboo Standards Track [Page 6]
340RFC 7809 CalDAV Time Zone Extension March 2016
343 iCalendar "VTIMEZONE" component. This specification defines a new
344 CALDAV:timezone-id XML element that can be used as an alternative to
345 the CALDAV:timezone XML element; it allows a specific time zone to be
346 set via its time zone identifier, rather than providing the full
347 "VTIMEZONE" component (see Section 6.2). Servers MUST support a
348 client's ability to provide a time zone identifier for use in a
349 calendar query "REPORT" using this new element.
351 If a client attempts use of a CALDAV:timezone-id XML element with a
352 value that does not correspond to a time zone that is known to the
353 server, the server MUST reject the request with a CALDAV:valid-
354 timezone precondition error. In such cases, clients MAY repeat the
355 request using the CALDAV:timezone XML element instead, and provide
356 the full iCalendar data for the time zone being used.
3584. New Client Behavior
360 When a server advertises the "calendar-no-timezone" field in a DAV
361 response header field (as per Section 3.1.1):
363 1. Clients SHOULD include an HTTP "CalDAV-Timezones" request header
364 field with a value of "F" to ensure that the CalDAV server does
365 not include "VTIMEZONE" components in any iCalendar data returned
366 in a response (see Section 3.1.3), for those time zones whose
367 identifier is one provided by any of the advertised time zone
368 distribution servers (see Section 3.1.2). In this case, clients
369 will have to retrieve the missing standard time zone definitions
370 either from their own cache of standard time zones or from the
371 set of time zone distribution servers advertised by the CalDAV
372 server (see Section 3.1.2).
374 2. Clients can include an HTTP "CalDAV-Timezones" request header
375 field with a value of "T" to ensure that the CalDAV server does
376 include all "VTIMEZONE" components in any iCalendar data returned
377 in a response (see Section 3.1.3).
379 3. Clients can expect servers not to include standard time zone
380 definitions in any iCalendar data they receive from the server,
381 if there is no "CalDAV-Timezones" request header field in the
382 HTTP request. Clients MUST retrieve standard time zone
383 definitions either from its own cache of standard time zones or
384 from the set of time zone distribution servers advertised by the
385 CalDAV server (see Section 3.1.2).
394Daboo Standards Track [Page 7]
396RFC 7809 CalDAV Time Zone Extension March 2016
399 4. Clients SHOULD remove standard time zone definitions from
400 iCalendar data they send to the server, provided the
401 corresponding time zone identifier is one available on any of the
402 server's advertised time zone distribution servers (see
405 5. Clients MUST send time zone definitions in iCalendar data for any
406 time zone identifiers not available via any of the server's
407 advertised time zone distribution servers. Clients MUST be
408 prepared for the server to reject such data or map the time zone
409 to one in the set of standard time zones provided by the server's
410 associated time zone services (as per Section 3.1.4).
412 6. Clients SHOULD make use of the CALDAV:calendar-timezone-id WebDAV
413 property (see Section 3.1.5) and CalDAV:timezone-id XML element
414 (see Section 3.1.6) for specifying default and specific time
415 zones to use in calendar queries executed by the server.
4175. New WebDAV Properties
4195.1. CALDAV:timezone-service-set
421 Name: timezone-service-set
423 Namespace: urn:ietf:params:xml:ns:caldav
425 Purpose: Specifies one or more time zone data distribution servers
426 being used by the CalDAV server to provide standard time zone
429 Conformance: This property SHOULD be defined on CalDAV calendar home
430 collection resources. If defined, it SHOULD NOT be returned by a
431 "PROPFIND" DAV:allprop request (as defined in Section 14.2 of
434 Description: The CALDAV:timezone-service-set property lists one or
435 more time zone data distribution servers that the CalDAV server is
436 using to provide its set of time zone data. See Section 3.1.2 for
441 <!ELEMENT timezone-service-set (DAV:href+)>
442 DAV:href value: URI of a time zone data distribution service
443 as defined by this specification.
450Daboo Standards Track [Page 8]
452RFC 7809 CalDAV Time Zone Extension March 2016
457 <C:timezone-service-set
459 xmlns:C="urn:ietf:params:xml:ns:caldav">
460 <D:href>https://timezones.example.com</D:href>
461 </C:timezone-service-set>
4635.2. CALDAV:calendar-timezone-id
465 Name: calendar-timezone-id
467 Namespace: urn:ietf:params:xml:ns:caldav
469 Purpose: Specifies a time zone identifier for a calendar collection.
471 Conformance: This property SHOULD be defined on all resources where
472 the CALDAV:calendar-timezone property is also defined. If
473 defined, it SHOULD NOT be returned by a "PROPFIND" DAV:allprop
474 request (as defined in Section 14.2 of [RFC4918]).
476 Description: The CALDAV:calendar-timezone-id property is used as an
477 alternative to the CALDAV:calendar-timezone property (see
478 Section 5.3.2 of [RFC4791]). It allows clients to set the default
479 time zone using only a time zone identifier. It also indicates to
480 the client the time zone identifier of the current default time
481 zone. See Section 3.1.5 for more details.
485 <!ELEMENT calendar-timezone-id (#PCDATA)>
486 PCDATA value: a time zone identifier.
490 <C:calendar-timezone-id
491 xmlns:C="urn:ietf:params:xml:ns:caldav">US-Eastern<
492 /C:calendar-timezone-id>
4946. XML Element Definitions
4966.1. CALDAV:calendar-query XML Element
498 The CALDAV:calendar-query XML element, defined in Section 9.5 of
499 [RFC4791], is modified to allow use of the CALDAV:timezone-id XML
506Daboo Standards Track [Page 9]
508RFC 7809 CalDAV Time Zone Extension March 2016
513 <!ELEMENT calendar-query ((DAV:allprop |
516 (timezone | timezone-id)?)>
5186.2. CALDAV:timezone-id XML Element
522 Namespace: urn:ietf:params:xml:ns:caldav
524 Purpose: Specifies the time zone identifier for a time zone
525 component to use when determining the results of a report.
527 Description: The CALDAV:timezone-id XML element is used as an
528 alternative to the CALDAV:timezone XML element (see Section 9.8 of
529 [RFC4791]) in calendar query reports, to allow a client to specify
530 a time zone using a time zone identifier rather than providing the
531 full iCalendar time zone data. See Section 3.1.6 for more
536 <!ELEMENT timezone-id (#PCDATA)>
537 PCDATA value: a time zone identifier.
5397. Additional Message Header Fields
5417.1. CalDAV-Timezones Request Header Field
543 The "CalDAV-Timezones" request header field provides a way for a
544 client to indicate to the server whether it wants "VTIMEZONE"
545 components returned in any iCalendar data that is part of the HTTP
546 response. The value "T" indicates that the client wants time zone
547 data returned; the value "F" indicates that it does not.
549 CalDAV-Timezones = "T" / "F"
562Daboo Standards Track [Page 10]
564RFC 7809 CalDAV Time Zone Extension March 2016
5678. Security Considerations
569 This specifications adds time zone data distribution service
570 [RFC7808] servers into the overall calendaring and scheduling client/
571 server architecture, as a critical component, and thus adds a new
572 vector of attack against such systems. As such, administrators of
573 CalDAV servers SHOULD ensure that any advertised time zone
574 distribution servers are protected by a level of security
575 commensurate with all the other components in the system.
577 Besides the above point, this specification does not introduce any
578 new security concerns beyond those addressed in CalDAV [RFC4791],
579 iCalendar [RFC5545], and the time zone data distribution service
5829. Privacy Considerations
584 The privacy recommendations in Section 9 of the time zone data
585 distribution service specification [RFC7808] SHOULD be used to ensure
586 that details of clients' interactions with CalDAV servers are not
587 exposed to potential network observers. Note that since events can
588 be delivered to a calendar user from an outside source (e.g., using
589 iTIP [RFC5546]), and an attacker could create a calendar event with,
590 e.g., a time zone identifier that is fake or rarely used and that
591 could be used to monitor the calendar user's activity and interaction
592 with others, this specification increases the importance of using the
593 mitigations of privacy issues discussed in [RFC7808].
59510. IANA Considerations
597 The message header field below has been added to the Permanent
598 Message Header Field Registry (see [RFC3864]).
60010.1. CalDAV-Timezones
602 Header field name: CalDAV-Timezones
604 Applicable protocol: http
608 Author/Change controller: IETF
610 Specification document(s): this document (Section 7.1)
612 Related information: none
618Daboo Standards Track [Page 11]
620RFC 7809 CalDAV Time Zone Extension March 2016
62511.1. Normative References
627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
628 Requirement Levels", BCP 14, RFC 2119,
629 DOI 10.17487/RFC2119, March 1997,
630 <http://www.rfc-editor.org/info/rfc2119>.
632 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
633 Procedures for Message Header Fields", BCP 90, RFC 3864,
634 DOI 10.17487/RFC3864, September 2004,
635 <http://www.rfc-editor.org/info/rfc3864>.
637 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
638 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
639 DOI 10.17487/RFC4791, March 2007,
640 <http://www.rfc-editor.org/info/rfc4791>.
642 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
643 Authoring and Versioning (WebDAV)", RFC 4918,
644 DOI 10.17487/RFC4918, June 2007,
645 <http://www.rfc-editor.org/info/rfc4918>.
647 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
648 Scheduling Core Object Specification (iCalendar)",
649 RFC 5545, DOI 10.17487/RFC5545, September 2009,
650 <http://www.rfc-editor.org/info/rfc5545>.
652 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
653 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
654 <http://www.rfc-editor.org/info/rfc6638>.
656 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution
657 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016,
658 <http://www.rfc-editor.org/info/rfc7808>.
66011.2. Informative References
662 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
663 Interoperability Protocol (iTIP)", RFC 5546,
664 DOI 10.17487/RFC5546, December 2009,
665 <http://www.rfc-editor.org/info/rfc5546>.
667 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based
668 Interoperability Protocol (iMIP)", RFC 6047,
669 DOI 10.17487/RFC6047, December 2010,
670 <http://www.rfc-editor.org/info/rfc6047>.
674Daboo Standards Track [Page 12]
676RFC 7809 CalDAV Time Zone Extension March 2016
679 [RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the
680 Time Zone Database", BCP 175, RFC 6557,
681 DOI 10.17487/RFC6557, February 2012,
682 <http://www.rfc-editor.org/info/rfc6557>.
686 Thanks to Mike Douglass, Andrew McMillan, and Ken Murchison. This
687 specification came about via discussions at the Calendaring and
688 Scheduling Consortium.
698 Email: cyrus@daboo.name
699 URI: http://www.apple.com/
730Daboo Standards Track [Page 13]