idnits 2.17.1
draft-daboo-icalendar-rscale-04.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 RFC5545, but the
abstract doesn't seem to mention this, which it should.
-- The draft header indicates that this document updates RFC4791, but the
abstract doesn't seem to mention this, which it should.
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 (June 11, 2014) is 3606 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 (==), 4 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 Inc.
4 Updates: 5545, 4791 (if approved) G. Yakushev
5 Intended status: Standards Track Google Inc.
6 Expires: December 13, 2014 June 11, 2014
8 Non-Gregorian Recurrence Rules in iCalendar
9 draft-daboo-icalendar-rscale-04
11 Abstract
13 This document defines how non-Gregorian recurrence rules can be
14 specified in iCalendar data.
16 Status of this Memo
18 This Internet-Draft is submitted in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF). Note that other groups may also distribute
23 working documents as Internet-Drafts. The list of current Internet-
24 Drafts is at http://datatracker.ietf.org/drafts/current/.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 This Internet-Draft will expire on December 13, 2014.
33 Copyright Notice
35 Copyright (c) 2014 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
51 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
53 4. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 6
54 4.1. Handling Leap Months . . . . . . . . . . . . . . . . . . . 7
55 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
56 5. Registering Calendar Systems . . . . . . . . . . . . . . . . . 10
57 6. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 11
58 7. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 11
59 7.1. CALDAV:supported-rscale-set Property . . . . . . . . . . . 12
60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
62 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
65 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
66 Appendix A. Change History (To be removed by RFC Editor
67 before publication) . . . . . . . . . . . . . . . . . 14
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
70 1. Introduction
72 The iCalendar [RFC5545] data format is in widespread use to represent
73 calendar data. iCalendar represents dates and times using the
74 Gregorian calendar system only. It does provide a way to use non-
75 Gregorian calendar systems via a "CALSCALE" property, however this
76 has never been formally used. However, there is a need to support at
77 least non-Gregorian recurrence patterns to cover anniversaries, and
78 many local, religious, or civil holidays based on non-Gregorian
79 dates.
81 There are several disadvantages to using the existing "CALSCALE"
82 property in iCalendar for implementing non-Gregorian calendars:
84 1. The "CALSCALE" property exists in the top-level "VCALENDAR"
85 objects and thus applies to all components within that object.
86 In today's multi-cultural society, that restricts the ability to
87 mix events from different calendar systems within the same
88 iCalendar object. e.g., it would prevent having both the
89 Gregorian New Year and Chinese New Year in the same iCalendar
90 object.
92 2. Many countries observe daylight savings time, encoded in
93 iCalendar using the "VTIMEZONE" component. Timezone and daylight
94 saving time rules are always specified via Gregorian calendar
95 based recurrence rules (e.g., "the 3rd Sunday in March"). This
96 is problematic for non-Gregorian uses of "CALSCALE" which would
97 by default also apply to the dates and rules used in the
98 "VTIMEZONE" components in the corresponding iCalendar object.
100 This specification solves these issues by allowing the "CALSCALE" to
101 remain set to Gregorian, but re-defining the recurrence rule property
102 "RRULE" to accept new items including one that allows non-Gregorian
103 calendar systems to be used. With this, all the date, time and
104 period values in the iCalendar object would remain specified using
105 the Gregorian calendar system, but repeating patterns in other
106 calendar systems could be defined. It is then up to calendar user
107 agents and servers to map between Gregorian and non-Gregorian
108 calendar systems in order to expand out recurrence instances.
110 This specification does not itself define calendar systems, rather it
111 utilizes the calendar system registry defined by the Unicode
112 Consortium in their CLDR (Common Locale Data Repository) project
113 [UNICODE.CLDR].
115 2. Conventions Used in This Document
117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
119 "OPTIONAL" in this document are to be interpreted as described in
120 [RFC2119].
122 The notation used in this memo is the ABNF notation of [RFC5234] as
123 used by iCalendar [RFC5545]. Any syntax elements shown below that
124 are not explicitly defined in this specification come from iCalendar
125 [RFC5545], iTIP [RFC5546], and CalDAV [RFC4791].
127 When XML element types in the namespaces "DAV:" and
128 "urn:ietf:params:xml:ns:caldav" are referenced in this document
129 outside of the context of an XML fragment, the string "DAV:" and
130 "CALDAV:" will be prefixed to the element type names respectively.
132 When a Gregorian calendar date value is shown in text, it will use
133 the format "YYYYMMHH", where "YYYY" is the 4-digit year, "MM" the
134 2-digit month, and "DD" the 2-digit day (this is the same format used
135 in iCalendar [RFC5545]). The Chinese calendar will be used as an
136 example of a non-Gregorian calendar for illustrative purposes. When
137 a Chinese calendar date value is shown in text, it will use the
138 format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with
139 a "{C}" prefix, and an optional "L" character after the month element
140 to indicate a leap month. Similarly, {E} and {H} are used in other
141 examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates,
142 respectively. Note that the Chinese calendar years shown in the
143 examples are based on the Unicode (ICU) [UNICODE.ICU] library's
144 Chinese calendar epoch. Whilst there are several different Chinese
145 calendar epochs in common use, the choice of one over another does
146 not impact the actual calculation of the Gregorian equivalent dates,
147 provided conversion is always done using the same epoch.
149 3. Overview
151 In the Gregorian calendar system, each year is composed of a fixed
152 number of months (12), with each month having a fixed number of days
153 (between 30 and 31), except for the second month (February) which
154 contains either 28 days, or 29 days (in a leap year). Weeks are
155 composed of 7 days, with day names Monday, Tuesday, Wednesday,
156 Thursday, Friday, Saturday and Sunday. Years can have either 365 or
157 366 days (the later in a leap year). The number of whole weeks in a
158 year is 52.
160 In iCalendar, the "RECUR" value type defines various fields used to
161 express a recurrence pattern, and those fields are given limits based
162 on those of the Gregorian calendar system. Since other calendar
163 systems can have different limits and other behaviors that need to be
164 accounted for, the maximum values for the elements in the "RECUR"
165 value are not covered by this specification.
167 To generate a set of recurring instances in a non-Gregorian calendar
168 system, the following procedure is used:
170 1. iCalendar data continues to use the "GREGORIAN" calendar system,
171 so all "DATE", "DATE-TIME" and "PERIOD" values continue to use
172 the Gregorian format and limits.
174 2. The "RRULE" property is extended to include an "RSCALE" element
175 in its value that specifies the calendar system to use for the
176 recurrence pattern. The existing elements of the "RRULE" value
177 type are used, but modified to support different upper limits,
178 based on the "RSCALE" value, as well as a modification to month
179 numbers to allow a leap month to be specified. Existing
180 requirements for the use of "RRULE" all still apply (e.g., the
181 "RRULE" has to match the "DTSTART" value of the master instance).
182 Other recurrence properties such as "RECURRENCE-ID", "RDATE" and
183 "EXDATE" continue to use the Gregorian date format as "CALSCALE"
184 is unchanged.
186 When generating instances, the following procedure might be used:
188 1. Convert the "DTSTART" property value of the master recurring
189 component into the date and time components for the calendar
190 system specified by the "RSCALE" element in the "RRULE" value.
191 This provides the "seed" value for generating subsequent
192 recurrence instances.
194 2. Iteratively generate instances using the "RRULE" value applied to
195 the year, month, and day components of the date in the new
196 calendar system.
198 3. For each generated instance, convert the date values back from
199 the non-Gregorian form into Gregorian and use those values for
200 other properties such as "RECURRENCE-ID".
202 Consider the following example for an event representing the Chinese
203 New Year:
205 DTSTART;VALUE=DATE:20130210
206 RRULE:RSCALE=CHINESE;FREQ=YEARLY
207 SUMMARY:Chinese New Year
209 To generate instances, first the "DTSTART" value "20130210" is
210 converted into the Chinese calendar system giving "{C}46500101".
211 Next, the year component is incremented by one to give "{C}46510101",
212 and that is then converted back into Gregorian as "20140131".
213 Additional instances are generated by iteratively increasing the year
214 component in the Chinese date value and converting back to Gregorian.
216 4. Extended RRULE Property
218 This specification extends the existing "RRULE" iCalendar property
219 value to include a new "RSCALE" element that can be used to indicate
220 the calendar system used for generating the recurrence pattern.
222 When "RSCALE" is present, the other changes to "RRULE" are:
224 1. Elements that include numeric values (e.g., "BYYEARDAY") have
225 numeric ranges defined by the "RSCALE" value (i.e., in some
226 calendar systems there might be more than 366 days in a year).
228 2. Month numbers can include an "L" suffix to indicate that the
229 specified month is a leap month in the corresponding calendar
230 system.
232 3. A "SKIP" element is added to define how "missing" instances are
233 handled. e.g., if a yearly recurring event starts in a leap
234 month, the "SKIP" element determines whether instances in non-
235 leap years are ignored ("SKIP" set to "YES"), appear in the
236 preceding regular month ("SKIP" set to "BACKWARD" - the default
237 when "RSCALE" is present), or appear in the following regular
238 month ("SKIP" set to "FORWARD"). This applies for both leap days
239 and leap months. The "SKIP" processing is done after all rule
240 elements, other than "BYSETPOS", "COUNT" and "UNTIL", have been
241 processed.
243 The syntax for the "RECUR" value is modified in the following
244 fashion:
246 recur-rule-part /= ("RSCALE" "=" rscale)
247 / ("SKIP" "=" skip)
249 rscale = (iana-token ; A CLDR-registered calendar system
250 ; name.
251 / x-name) ; A non-standard, experimental
252 ; calendar system name.
253 ; Names are case-insensitive,
254 ; but uppercase values are preferred.
256 skip = ("YES" / "BACKWARD" / "FORWARD")
257 ; Optional, with default value "BACKWARD",
258 ; and MUST only be present if "RSCALE" is present.
260 monthnum = 1*2DIGIT ["L"]
261 ; Existing element modified to include a leap
262 ; month indicator suffix.
264 4.1. Handling Leap Months
266 Leap months can occur in different calendar systems. For such
267 calendar systems the following rules are applied for "identifying"
268 months:
270 1. Numeric values 1 through N are used to identify regular, non-
271 leap, months (where N is the number of months in a regular, non-
272 leap, year).
274 2. The suffix "L" is added to the regular month number to indicate a
275 leap month which follows the regular month. e.g., "5L" is a leap
276 month that follows the 5th regular month in the year.
278 Care has to be taken when mapping the month identifiers used here
279 with those of any underlying calendar system library being used. In
280 particular, the Hebrew calendar system used by Unicode (ICU)
281 [UNICODE.ICU] uses a month number scheme of 1 through 13, with month
282 6 being the leap month, and in non-leap years, month 6 is skipped.
283 In iCalendar, this would map to months 1 through 12 with "5L" as the
284 leap month.
286 4.2. Examples
288 4.2.1. Chinese New Year
290 Consider the following set of iCalendar properties:
292 DTSTART;VALUE=DATE:20130210
293 RRULE:RSCALE=CHINESE;FREQ=YEARLY
294 SUMMARY:Chinese New Year
296 These define a recurring event for the Chinese New Year, with the
297 first instance the one in Gregorian year 2013.
299 The Chinese date corresponding to the first instance is {C}46500101.
300 The table below shows the initial instance, and the next four, each
301 of which is determined by adding the appropriate amount to the year
302 component of the Chinese date. Also shown is the conversion back to
303 the Gregorian date:
305 +--------------+--------------------------+
306 | Chinese Date | Gregorian Date |
307 +--------------+--------------------------+
308 | {C}46500101 | 20130210 - DTSTART value |
309 | {C}46510101 | 20140131 |
310 | {C}46520101 | 20150219 |
311 | {C}46530101 | 20160208 |
312 | {C}46540101 | 20170128 |
313 +--------------+--------------------------+
315 4.2.2. Ethiopic 13th Month
317 Consider the following set of iCalendar properties:
319 DTSTART;VALUE=DATE:201300906
320 RRULE:RSCALE=ETHIOPIC;FREQ=YEARLY;BYMONTH=13
321 SUMMARY:First day of 13th month
323 These define a recurring event for the first day of the 13th month,
324 with the first instance the one in Gregorian year 2013.
326 The Ethiopic date corresponding to the first instance is {E}20051301.
327 The table below shows the initial instance, and the next four, each
328 of which is determined by adding the appropriate amount to the year
329 component of the Ethiopic date. Also shown is the conversion back to
330 the Gregorian date:
332 +---------------+--------------------------+
333 | Ethiopic Date | Gregorian Date |
334 +---------------+--------------------------+
335 | {E}20051301 | 20130906 - DTSTART value |
336 | {E}20061301 | 20140906 |
337 | {E}20071301 | 20150906 |
338 | {E}20081301 | 20160906 |
339 | {E}20091301 | 20170906 |
340 +---------------+--------------------------+
342 Note that in this example, the value of the "BYMONTH" component in
343 the "RRULE" matches the Ethiopic month value and not the Gregorian
344 month.
346 4.2.3. Hebrew anniversary starting in a leap month
348 Consider the following set of iCalendar properties:
350 DTSTART;VALUE=DATE:20140208
351 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD
352 SUMMARY:Anniversary
354 These define a recurring event for the 8th day of the Hebrew month of
355 Adar I (the leap month identified by "5L"), with the first instance
356 the one in Gregorian year 2014.
358 The Hebrew date corresponding to the first instance is {H}577405L08,
359 which is a leap month in year 5774. The table below shows the
360 initial instance, and the next four, each of which is determined by
361 adding the appropriate amount to the year component of the Hebrew
362 date, taking into account that only year 5776 is a leap year. Thus
363 in other years the Hebrew month component is adjusted forward to
364 month 6. Also shown is the conversion back to the Gregorian date:
366 +--------------+--------------------------+
367 | Hebrew Date | Gregorian Date |
368 +--------------+--------------------------+
369 | {H}577405L08 | 20140208 - DTSTART value |
370 | {H}57750608 | 20150227 |
371 | {H}577605L08 | 20160217 |
372 | {H}57770608 | 20170306 |
373 | {H}57780608 | 20180223 |
374 +--------------+--------------------------+
376 4.2.4. Gregorian leap day with SKIP
378 Consider the following set of iCalendar properties:
380 DTSTART;VALUE=DATE:20120229
381 RRULE:FREQ=YEARLY
382 SUMMARY:Anniversary
384 These define a recurring event for the 29th February, 2012 in the
385 standard iCalendar calendar scale - Gregorian. The standard
386 iCalendar behavior is that non-existent dates in a recurrence set are
387 ignored. Thus the properties above would only generate instances in
388 leap years (2016, 2020, etc), which is likely not what users expect.
389 The new "RSCALE" option defined by this specification provides the
390 "SKIP" element which can be used to "fill in" the missing instances
391 in an appropriate fashion. The set of iCalendar properties below do
392 that:
394 DTSTART;VALUE=DATE:20120229
395 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD
396 SUMMARY:Anniversary
398 With these properties, the "missing" instances in non-leap year now
399 appear on the 1st March in those years:
401 +-------------------------------+----------------------------+
402 | Instances (with SKIP=FORWARD) | Instances (without RSCALE) |
403 +-------------------------------+----------------------------+
404 | 20120229 | 20120229 - DTSTART value |
405 | 20130301 | |
406 | 20140301 | |
407 | 20150301 | |
408 | 20160229 | 20160229 |
409 | 20170301 | |
410 +-------------------------------+----------------------------+
412 5. Registering Calendar Systems
414 This specification uses the Unicode Consortium's registry of calendar
415 systems [UNICODE.CLDR] to define valid values for the "RSCALE"
416 element of an "RRULE". Note that the underscore character "_" is
417 never used in CLDR-based calendar system names. New values can be
418 added to this registry following Unicode Consortium rules. It is
419 expected that many implementations of non-Gregorian calendars will
420 use software libraries provided by Unicode (ICU) [UNICODE.ICU], and
421 hence it makes sense to re-use their registry rather than creating a
422 new one. For consistency, when used, the "RSCALE" values SHOULD be
423 uppercased.
425 CLDR supports the use of "alias" values as alternative names for
426 specific calendar systems. These alias values MUST be treated as
427 valid "RSCALE" element values.
429 When using the CLDR data, calendar agents SHOULD take into account
430 the "deprecated" value and use the alternative "preferred" calendar
431 system. In particular, the "islamicc" calendar system is considered
432 deprecated in favor of the "islamic-civil" calendar system.
434 6. Use with iTIP
436 iTIP [RFC5546] defines how iCalendar data can be sent between
437 calendar user agents to schedule calendar components between calendar
438 users. It is often not possible to know the capabilities of a
439 calendar user agent to which an iTIP message is being sent, but iTIP
440 defines fallback behavior in such cases.
442 For calendar user agents that do not support the "RSCALE" element,
443 the following can occur when iTIP messages containing an "RSCALE"
444 element are received:
446 The receiving calendar user agent can reject the entire iTIP
447 message and return an iTIP reply with a "REQUEST-STATUS" property
448 set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]).
450 The receiving calendar user agent can fallback to a non-recurring
451 behavior for the calendar component (effectively ignoring the
452 "RRULE" property) and return an iTIP reply with a "REQUEST-STATUS"
453 property set to the "2.3", "2.5", "2.8", or "2.10" status codes
454 (as per Sections 3.6.3, 3.6.6, 3.6.9, or 3.6.11, respectively, of
455 [RFC5546]).
457 For calendar user agents that support the "RSCALE" element but do not
458 support the calendar system specified by the "RSCALE" element value,
459 the following can occur:
461 the iTIP message SHOULD be rejected, returning a "REQUEST-STATUS"
462 property set to the "3.1" status code (as per Section 3.6.14 of
463 [RFC5546]).
465 if the iTIP message is accepted and the calendar component treated
466 as non-recurring, an iTIP reply with a "REQUEST-STATUS" property
467 set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or
468 3.6.11, respectively, of [RFC5546]) SHOULD be returned.
470 7. Use with CalDAV
472 The CalDAV [RFC4791] calendar access protocol allows clients and
473 server to exchange iCalendar data. In addition, CalDAV clients are
474 able to query calendar data stored on the server, including time-
475 based queries. Since an "RSCALE" element value determines the time
476 ranges for recurring instances in a calendar component, CalDAV
477 servers need to support it to interoperate with clients also using
478 the "RSCALE" element.
480 A CalDAV server advertises a CALDAV:supported-rscale-set WebDAV
481 property on calendar home or calendar collections if it supports use
482 of "RSCALE" element as described in this specification. The server
483 can advertise a specific set of supported calendar systems by
484 including one or more CALDAV:supported-rscale XML elements within the
485 CALDAV:supported-rscale-set XML element. If no CALDAV:supported-
486 rscale XML elements are included in the WebDAV property, then clients
487 can try any calendar system value, but need to be prepared for a
488 failure when attempting to store the calendar data.
490 Clients MUST NOT attempt to store iCalendar data containing "RSCALE"
491 elements if the CALDAV:supported-rscale-set WebDAV property is not
492 advertised by the server.
494 The server SHOULD return an HTTP 403 response with a DAV:error
495 element containing a CALDAV:supported-rscale XML element, if a client
496 attempts to store iCalendar data with an "RSCALE" element value not
497 supported by the server.
499 It is possible for a "RSCALE" value to be present in calendar data on
500 the server being accessed by a client that does not support an
501 "RSCALE" element or its specified value. It is expected that
502 existing clients, unaware of "RSCALE", will fail gracefully by
503 ignoring the calendar component, whilst still processing other
504 calendar data on the server.
506 7.1. CALDAV:supported-rscale-set Property
508 Name: supported-rscale-set
510 Namespace: urn:ietf:params:xml:ns:caldav
512 Purpose: Enumerates the set of supported iCalendar "RSCALE" element
513 values supported by the server.
515 Protected: This property MUST be protected and SHOULD NOT be
516 returned by a PROPFIND allprop request (as defined in Section 14.2
517 of [RFC4918]).
519 Description: See above.
521 Definition:
523
524
525
528 Example:
530
532 GREGORIAN
533 CHINESE
534 ISLAMIC-CIVIL
535 HEBREW
536 ETHIOPIC
537
539 8. Security Considerations
541 This specification does not introduce any addition security concerns
542 beyond those described in [RFC5545], [RFC5546], and [RFC4791].
544 9. IANA Considerations
546 This specification does not define any new IANA registries or values.
548 10. Acknowledgments
550 Thanks to the following for feedback: Mark Davis, Mike Douglass,
551 Peter Edberg, Marten Gajda, Arnaud Quillaud, Dave Thewlis, and Umaoka
552 Yoshito. This specification came about via discussions at the
553 Calendaring and Scheduling Consortium.
555 11. References
557 11.1. Normative References
559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
560 Requirement Levels", BCP 14, RFC 2119, March 1997.
562 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
563 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
564 March 2007.
566 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
567 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
569 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
570 Specifications: ABNF", STD 68, RFC 5234, January 2008.
572 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
573 Core Object Specification (iCalendar)", RFC 5545,
574 September 2009.
576 [RFC5546] Daboo, C., "iCalendar Transport-Independent
577 Interoperability Protocol (iTIP)", RFC 5546,
578 December 2009.
580 [UNICODE.CLDR]
581 "CLDR calendar.xml Data", Unicode Consortium CLDR,
582 August 2013, .
585 11.2. Informative References
587 [UNICODE.ICU]
588 "International Components for Unicode", Unicode
589 Consortium ICU, April 2014, .
591 Appendix A. Change History (To be removed by RFC Editor before
592 publication)
594 Changes in -04:
596 1. Always use "L" suffix for leap months, even for Hebrew calendar.
598 2. Remove negative month numbers to go back to base 5545 definition.
600 3. Added example for Gregorian leap day with skip.
602 4. Clarify that RSCALE names are case insensitive, but with upper
603 case preferred.
605 5. Clarify that BYSETPOS processing is done after SKIP.
607 6. Remove Islamic example in favor of Ethiopic example which shows a
608 13th month.
610 Changes in -03:
612 1. Added details about handling RSCALE in iTIP.
614 2. Added details about handling RSCALE in CalDAV.
616 3. Fixed examples to use ICU Chinese epoch and added text describing
617 why that is not an issue for actual recurrence calculations.
619 Changes in -02:
621 1. Fixed some incorrect dates in examples.
623 2. Clarified use of CLDR and alias, deprecated, preferred
624 attributes.
626 3. Clarified when SKIP processing occurs.
628 Changes in -01:
630 1. Removed requirement that RSCALE be the first item in an RRULE.
632 2. Added BYLEAPMONTH element and removed BYMONTH "L" suffix.
634 3. Removed Open Issues.
636 Authors' Addresses
638 Cyrus Daboo
639 Apple Inc.
640 1 Infinite Loop
641 Cupertino, CA 95014
642 USA
644 Email: cyrus@daboo.name
645 URI: http://www.apple.com/
647 Gregory Yakushev
648 Google Inc.
649 Brandschenkestrasse 100
650 8002 Zurich,
651 Switzerland
653 Email: yakushev@google.com
654 URI: http://www.google.com/