7Internet Engineering Task Force (IETF) C. Daboo
8Request for Comments: 7529 Apple Inc.
9Updates: 5545, 6321, 7265 G. Yakushev
10Category: Standards Track Google Inc.
11ISSN: 2070-1721 May 2015
14 Non-Gregorian Recurrence Rules in the Internet Calendaring and
15 Scheduling Core Object Specification (iCalendar)
19 This document defines extensions to the Internet Calendaring and
20 Scheduling Core Object Specification (iCalendar) (RFC 5545) to
21 support use of non-Gregorian recurrence rules. It also defines how
22 Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and
23 clients can be extended to support these new recurrence rules.
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc7529.
41 Copyright (c) 2015 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Daboo & Yakushev Standards Track [Page 1]
60RFC 7529 iCalendar RSCALE Extension May 2015
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 4. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 6
69 4.1. Skipping Invalid Dates . . . . . . . . . . . . . . . . . 6
70 4.2. Handling Leap Months . . . . . . . . . . . . . . . . . . 9
71 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
72 5. Registering Calendar Systems . . . . . . . . . . . . . . . . 13
73 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
74 7. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 14
75 8. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . . 15
76 9. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . . 15
77 10. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 16
78 10.1. CALDAV:supported-rscale-set Property . . . . . . . . . . 17
79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
81 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
82 12.2. Informative References . . . . . . . . . . . . . . . . . 19
83 Appendix A. xCal RELAX NG Schema Update . . . . . . . . . . . . 20
84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
89 The iCalendar [RFC5545] data format is in widespread use to represent
90 calendar data. iCalendar represents dates and times using the
91 Gregorian calendar system only. It does provide a way to use non-
92 Gregorian calendar systems via a "CALSCALE" property, but this has
93 never been used. However, there is a need to support at least non-
94 Gregorian recurrence patterns to cover anniversaries, and many local,
95 religious, or civil holidays based on non-Gregorian dates.
97 There are several disadvantages to using the existing "CALSCALE"
98 property in iCalendar for implementing non-Gregorian calendars:
100 1. The "CALSCALE" property exists in the top-level "VCALENDAR"
101 objects and thus applies to all components within that object.
102 In today's multi-cultural society, that restricts the ability to
103 mix events from different calendar systems within the same
104 iCalendar object, e.g., it would prevent having both the
105 Gregorian New Year and Chinese New Year in the same iCalendar
108 2. Time zone and daylight saving time rules are typically published
109 using Gregorian calendar dates and rules (e.g., "the 3rd Sunday
110 in March") and are thus converted to iCalendar "VTIMEZONE"
114Daboo & Yakushev Standards Track [Page 2]
116RFC 7529 iCalendar RSCALE Extension May 2015
119 components using Gregorian dates and recurrence rules. This
120 results in the problem whereby one component (the "VTIMEZONE") is
121 fixed to the Gregorian calendar system, and another (a "VEVENT")
122 wants to use a different non-Gregorian calendar scale; thus, the
123 single top-level "CALSCALE" property is again inadequate.
125 This specification solves these issues by allowing the "CALSCALE" to
126 remain set to Gregorian but redefining the "RRULE" recurrence rule
127 property to accept new items, including one that allows non-Gregorian
128 calendar systems to be used. With this, all the "DATE", "DATE-TIME",
129 and "PERIOD" values in the iCalendar object would remain specified
130 using the Gregorian calendar system, but repeating patterns in other
131 calendar systems could be defined. It is then up to calendar user
132 agents and servers to map between Gregorian and non-Gregorian
133 calendar systems in order to expand out recurrence instances. The
134 non-Gregorian recurrence rules can be used in any iCalendar component
135 that allows the "RRULE" property to be specified, including
136 "VTIMEZONE" components (to allow for possible future use of non-
137 Gregorian rules in published daylight saving time data).
139 This specification does not itself define calendar systems; rather,
140 it utilizes the calendar system registry defined by the Unicode
141 Consortium in their Common Locale Data Repository (CLDR) project
142 [UNICODE.CLDR], as implemented in the Unicode (International
143 Components for Unicode (ICU)) Library [UNICODE.ICU].
145 This specification makes the following updates:
147 It updates iCalendar [RFC5545], the XML format for iCalendar
148 (xCal) [RFC6321], and the JSON format for iCalendar (jCal)
149 [RFC7265], to extend the "RRULE" property definition.
151 It clarifies use of the iCalendar Transport-Independent
152 Interoperability Protocol (iTIP) [RFC5546] to specify how the
153 extended "RRULE" property should be handled in iTIP messages.
155 It extends CalDAV [RFC4791] to specify how the extended "RRULE"
156 property can be supported by CalDAV servers and clients.
1582. Conventions Used in This Document
160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
162 "OPTIONAL" in this document are to be interpreted as described in
170Daboo & Yakushev Standards Track [Page 3]
172RFC 7529 iCalendar RSCALE Extension May 2015
175 The notation used in this memo is the ABNF notation of [RFC5234] as
176 used by iCalendar [RFC5545]. Any syntax elements shown below that
177 are not explicitly defined in this specification come from iCalendar
178 [RFC5545], iTIP [RFC5546], and CalDAV [RFC4791].
180 When XML element types in the namespaces "DAV:" and
181 "urn:ietf:params:xml:ns:caldav" are referenced in this document
182 outside of the context of an XML fragment, the string "DAV:" and
183 "CALDAV:" will be prefixed to the element type names, respectively.
185 When a Gregorian calendar date is shown in text, it will use the
186 format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 2-digit
187 month, and "DD" the 2-digit day (this is the same format used in
188 iCalendar [RFC5545]). The Chinese calendar will be used as an
189 example of a non-Gregorian calendar for illustrative purposes. When
190 a Chinese calendar date is shown in text, it will use the format
191 "{C}YYYYMM[L]DD" -- i.e., the same format as Gregorian but with a
192 "{C}" prefix, and an optional "L" character after the month element
193 to indicate a leap month. Similarly, {E} and {H} are used in other
194 examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates,
195 respectively. The "{}" prefix is used for purely illustrative
196 purposes and never appears in actual dates used in iCalendar or
197 related specifications. Note that the Chinese calendar years shown
198 in the examples are based on the Unicode (ICU) [UNICODE.ICU]
199 library's Chinese calendar epoch. While there are several different
200 Chinese calendar epochs in common use, the choice of one over another
201 does not impact the actual calculation of the Gregorian equivalent
202 dates, provided conversion is always done using the same epoch.
206 In the Gregorian calendar system, each year is composed of a fixed
207 number of months (12), with each month having a fixed number of days
208 (between 30 and 31), except for the second month (February), which
209 contains either 28 or 29 days (the latter in a leap year). Weeks are
210 composed of 7 days, with day names Monday, Tuesday, Wednesday,
211 Thursday, Friday, Saturday, and Sunday. Years can have either 365 or
212 366 days (the latter in a leap year). The number of whole weeks in a
213 year is 52 (though the [ISO.8601.2004] week numbering scheme used by
214 iCalendar [RFC5545] can have a numeric count up to 53).
216 In iCalendar, the "RECUR" value type defines various fields used to
217 express a recurrence pattern, and those fields are given limits based
218 on those of the Gregorian calendar system. Since other calendar
219 systems can have different limits and other behaviors that need to be
220 accounted for, the maximum values for the elements in the "RECUR"
221 value are not covered by this specification.
226Daboo & Yakushev Standards Track [Page 4]
228RFC 7529 iCalendar RSCALE Extension May 2015
231 To generate a set of recurring instances in a non-Gregorian calendar
232 system, the following principles are used:
234 1. iCalendar data continues to use the "GREGORIAN" calendar system,
235 so all "DATE", "DATE-TIME", and "PERIOD" values continue to use
236 the Gregorian format and limits.
238 2. The "RRULE" property is extended to include an "RSCALE" element
239 in its value that specifies the calendar system to use for the
240 recurrence pattern. The existing elements of the "RRULE" value
241 type are used, but modified to support different upper limits,
242 based on the "RSCALE" value, as well as a modification to month
243 numbers to allow a leap month to be specified. Existing
244 requirements for the use of "RRULE" all still apply (e.g., the
245 "RRULE" has to match the "DTSTART" value of the master instance).
246 Other recurrence properties such as "RECURRENCE-ID", "RDATE", and
247 "EXDATE" continue to use the Gregorian date format as "CALSCALE"
250 When generating instances, the following procedure might be used:
252 1. Convert the "DTSTART" property value of the master recurring
253 component into the date and time components for the calendar
254 system specified by the "RSCALE" element in the "RRULE" value.
255 This provides the "seed" value for generating subsequent
256 recurrence instances.
258 2. Iteratively generate instances using the "RRULE" value applied to
259 the year, month, and day components of the date in the new
262 3. For each generated instance, convert the dates and times back
263 from the non-Gregorian form into Gregorian and use those values
264 for other properties such as "RECURRENCE-ID".
266 Consider the following example for an event representing the Chinese
269 DTSTART;VALUE=DATE:20130210
270 RRULE:RSCALE=CHINESE;FREQ=YEARLY
271 SUMMARY:Chinese New Year
273 To generate instances, first the "DTSTART" value "20130210" is
274 converted into the Chinese calendar system giving "{C}46500101".
275 Next, the year component is incremented by one to give "{C}46510101",
276 and that is then converted back into Gregorian as "20140131".
277 Additional instances are generated by iteratively increasing the year
278 component in the Chinese date and converting back to Gregorian.
282Daboo & Yakushev Standards Track [Page 5]
284RFC 7529 iCalendar RSCALE Extension May 2015
2874. Extended RRULE Property
289 This specification extends the existing "RRULE" iCalendar property
290 value to include a new "RSCALE" element that can be used to indicate
291 the calendar system used for generating the recurrence pattern.
293 When "RSCALE" is present, the other changes to "RRULE" are:
295 1. Elements that include numeric values (e.g., "BYYEARDAY") have
296 numeric ranges defined by the "RSCALE" value (i.e., in some
297 calendar systems there might be more than 366 days in a year).
299 2. Month numbers can include an "L" suffix to indicate that the
300 specified month is a leap month in the corresponding calendar
301 system (see Section 4.2).
303 3. A "SKIP" element is added to define how "missing" instances are
304 handled (see Section 4.1).
306 The syntax for the "RECUR" value is modified in the following
309 ; recur-rule-part is extended from RFC 5545
310 recur-rule-part =/ ("RSCALE" "=" rscale)
313 rscale = (iana-token ; A CLDR-registered calendar system
315 / x-name) ; A non-standard, experimental
316 ; calendar system name.
317 ; Names are case insensitive,
318 ; but uppercase values are preferred.
320 skip = ("OMIT" / "BACKWARD" / "FORWARD")
321 ; Optional, with default value "OMIT", and
322 ; MUST NOT be present unless "RSCALE" is present.
324 monthnum = 1*2DIGIT ["L"]
325 ; Existing element modified to include a leap
326 ; month indicator suffix.
3284.1. Skipping Invalid Dates
330 In every calendar system, only certain combinations of day-of-month
331 and month values are valid for a given year, e.g., in the Gregorian
332 calendar system, January 31st is valid but February 31st is not.
333 Similarly, February 29th is valid in a leap year but invalid in a
334 non-leap year. Other calendar systems can also include leap months
338Daboo & Yakushev Standards Track [Page 6]
340RFC 7529 iCalendar RSCALE Extension May 2015
343 (see Section 4.2), which vary from year to year. This poses a
344 problem for recurring events where the frequency of recurrence might
345 give rise to an invalid date. For example, a recurring event that
346 starts on January 31st and is set to repeat monthly will generate
347 invalid dates for months with fewer than 31 days. The iCalendar
348 [RFC5545] specification requires recurrence rule generators to ignore
349 any invalid dates generated when iterating the rule. However, that
350 behavior might be surprising to a calendar user born on a leap day
351 and whose birthday event only appears on their calendar every four
352 years. There are common conventions used by humans to determine what
353 to do in such cases, but those conventions can differ from calendar
354 system to calendar system, as well as within the same calendar
355 system, depending on the nature of the event. Typically, humans will
356 expect the "missing" events to be moved to an earlier or later
359 This specification introduces a new "RRULE" element, "SKIP", for use
360 only when the "RSCALE" element is present. The "SKIP" element allows
361 the calendar user agent to specify new options for handling invalid
364 "SKIP=OMIT": this is the default option and corresponds to the
365 existing iCalendar behavior of simply ignoring the invalid date.
367 "SKIP=BACKWARD": when this option is set, a date with an invalid
368 month is changed to the previous (valid) month. A date with an
369 invalid day-of-month is changed to the previous (valid)
372 "SKIP=FORWARD": when this option is set, a date with an invalid
373 month is changed to the next (valid) month. A date with an
374 invalid day-of-month is changed to the next (valid) day-of-month.
376 Note that for both "BACKWARD" and "FORWARD", if the month is changed
377 and results in an invalid day-of-month, then the skip behavior will
378 be reapplied as per the day-of-month rules, according to the
379 processing order defined below.
381 The month and day-of-month skip behavior is only applied at specific
382 points during the processing of an "RRULE" as determined by the order
383 in which any "BYxxx" elements are processed. The order is as follows
384 (based on the "RRULE" element processing order defined in
385 Section 3.3.10 of [RFC5545]):
389 o SKIP (for invalid month only)
394Daboo & Yakushev Standards Track [Page 7]
396RFC 7529 iCalendar RSCALE Extension May 2015
405 o SKIP (for invalid day)
421 It is often possible to avoid having to deal with invalid dates by
422 determining the real intent of a human user, e.g., a human creating a
423 monthly recurring event that starts on January 31st likely intends
424 the event to occur on the last day of every month, in which case that
425 could be encoded into an "RRULE" by using the "BYMONTHDAY=-1"
428 Only a few types of recurrence patterns are likely to need the use of
429 "SKIP". The following is a list of some situations where it might be
432 1. The start date of the recurrence is a leap day in the specified
435 2. The start date of the recurrence is in a leap month in the
436 specified calendar system.
438 3. The start date of the recurrence has a day-of-month value greater
439 than the smallest day-of-month value for any month in any year in
440 the specified calendar system.
442 4. A "BYMONTHDAY" element in an "RRULE" has a day-of-month value
443 greater than the smallest day-of-month value for any month in any
444 year in the specified calendar system.
450Daboo & Yakushev Standards Track [Page 8]
452RFC 7529 iCalendar RSCALE Extension May 2015
455 5. A "BYMONTH" element in an "RRULE" has a value corresponding to a
456 leap month in the specified calendar system.
458 6. A combination of a "BYMONTHDAY" element and a "BYMONTH" element
459 in an "RRULE" has a value corresponding to a leap day in the
460 specified calendar system.
462 7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater
463 than the smallest number of days in any year in the specified
466 8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater
467 than the smallest number of weeks in any year in the specified
470 Examples of using "SKIP" for some common use cases appear in
4734.2. Handling Leap Months
475 Leap months can occur in different calendar systems. For such
476 calendar systems, the following rules are applied for "identifying"
479 1. Numeric values 1 through N are used to identify regular, non-
480 leap, months (where N is the number of months in a regular, non-
483 2. The suffix "L" is added to the regular month number to indicate a
484 leap month that follows the regular month, e.g., "5L" is a leap
485 month that follows the 5th regular month in the year.
487 Care has to be taken when mapping the month identifiers used here
488 with those of any underlying calendar system library being used. In
489 particular, the Hebrew calendar system used by Unicode (ICU)
490 [UNICODE.ICU] uses a month number scheme of 1 through 13, with month
491 6 being the leap month, and in non-leap years, month 6 is skipped.
492 Thus, ICU months 1 through 5 map to iCalendar months 1 through 5, ICU
493 month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map
494 to iCalendar months 6 through 12.
506Daboo & Yakushev Standards Track [Page 9]
508RFC 7529 iCalendar RSCALE Extension May 2015
5134.3.1. Chinese New Year
515 Consider the following set of iCalendar properties (from the example
518 DTSTART;VALUE=DATE:20130210
519 RRULE:RSCALE=CHINESE;FREQ=YEARLY
520 SUMMARY:Chinese New Year
522 These define a recurring event for the Chinese New Year, with the
523 first instance being the one in Gregorian year 2013.
525 The Chinese date corresponding to the first instance is
526 "{C}46500101". The table below shows the initial instance and the
527 next four, each of which is determined by adding the appropriate
528 amount to the year component of the Chinese date. Also shown is the
529 conversion back to the Gregorian date:
531 +--------------+--------------------------+
532 | Chinese Date | Gregorian Date |
533 +--------------+--------------------------+
534 | {C}46500101 | 20130210 - DTSTART value |
535 | {C}46510101 | 20140131 |
536 | {C}46520101 | 20150219 |
537 | {C}46530101 | 20160208 |
538 | {C}46540101 | 20170128 |
539 +--------------+--------------------------+
5414.3.2. Ethiopic 13th Month
543 Consider the following set of iCalendar properties:
545 DTSTART;VALUE=DATE:20130906
546 RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13
547 SUMMARY:First day of 13th month
549 These define a recurring event for the first day of the 13th month,
550 with the first instance being the one in Gregorian year 2013. While
551 there are a number of alternative ways of writing the "RRULE" above
552 to achieve the same pattern of recurring dates, the one above was
553 chosen to illustrate a "BYMONTH" value exceeding the limit of 12,
554 previously described in iCalendar (Section 3.3.10 of [RFC5545]).
562Daboo & Yakushev Standards Track [Page 10]
564RFC 7529 iCalendar RSCALE Extension May 2015
567 The Ethiopic date corresponding to the first instance is
568 "{E}20051301". The table below shows the initial instance and the
569 next four, each of which is determined by adding the appropriate
570 amount to the year component of the Ethiopic date. Also shown is the
571 conversion back to the Gregorian date:
573 +---------------+--------------------------+
574 | Ethiopic Date | Gregorian Date |
575 +---------------+--------------------------+
576 | {E}20051301 | 20130906 - DTSTART value |
577 | {E}20061301 | 20140906 |
578 | {E}20071301 | 20150906 |
579 | {E}20081301 | 20160906 |
580 | {E}20091301 | 20170906 |
581 +---------------+--------------------------+
583 Note that in this example, the value of the "BYMONTH" component in
584 the "RRULE" matches the Ethiopic month value and not the Gregorian
5874.3.3. Hebrew Anniversary Starting in a Leap Month
589 Consider the following set of iCalendar properties:
591 DTSTART;VALUE=DATE:20140208
592 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD
595 These define a recurring event for the 8th day of the Hebrew month of
596 Adar I (the leap month identified by "5L"), with the first instance
597 being the one in Gregorian year 2014.
599 The Hebrew date corresponding to the first instance is
600 "{H}577405L08", which is a leap month in year 5774. The table below
601 shows the initial instance and the next four, each of which is
602 determined by adding the appropriate amount to the year component of
603 the Hebrew date, taking into account that only year 5776 is a leap
604 year. Thus, in other years the Hebrew month component is adjusted
605 forward to month 6. Also shown is the conversion back to the
618Daboo & Yakushev Standards Track [Page 11]
620RFC 7529 iCalendar RSCALE Extension May 2015
623 +--------------+--------------------------+
624 | Hebrew Date | Gregorian Date |
625 +--------------+--------------------------+
626 | {H}577405L08 | 20140208 - DTSTART value |
627 | {H}57750608 | 20150227 |
628 | {H}577605L08 | 20160217 |
629 | {H}57770608 | 20170306 |
630 | {H}57780608 | 20180223 |
631 +--------------+--------------------------+
6334.3.4. Gregorian Leap Day with SKIP
635 Consider the following set of iCalendar properties:
637 DTSTART;VALUE=DATE:20120229
641 These define a recurring event for the 29th of February, 2012, in the
642 standard iCalendar calendar scale -- Gregorian. The standard
643 iCalendar behavior is that non-existent dates in a recurrence set are
644 ignored. Thus, the properties above would only generate instances in
645 leap years (2016, 2020, etc.), which is likely not what users expect.
646 The new "RSCALE" option defined by this specification provides the
647 "SKIP" element, which can be used to "fill in" the missing instances
648 in an appropriate fashion. The set of iCalendar properties below
651 DTSTART;VALUE=DATE:20120229
652 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD
655 With these properties, the "missing" instances in non-leap years now
656 appear on the 1st of March in those years:
658 +-------------------------------+----------------------------+
659 | Instances (with SKIP=FORWARD) | Instances (without RSCALE) |
660 +-------------------------------+----------------------------+
661 | 20120229 | 20120229 - DTSTART value |
665 | 20160229 | 20160229 |
667 +-------------------------------+----------------------------+
674Daboo & Yakushev Standards Track [Page 12]
676RFC 7529 iCalendar RSCALE Extension May 2015
6795. Registering Calendar Systems
681 This specification uses the Unicode Consortium's registry of calendar
682 systems [UNICODE.CLDR] to define valid values for the "RSCALE"
683 element of an "RRULE". Note that the underscore character "_" is
684 never used in CLDR-based calendar system names. New values can be
685 added to this registry following Unicode Consortium rules. It is
686 expected that many implementations of non-Gregorian calendars will
687 use software libraries provided by Unicode (ICU) [UNICODE.ICU], and
688 hence it makes sense to reuse their registry rather than creating a
689 new one. "RSCALE" values are case insensitive, but uppercase is
692 CLDR supports the use of "alias" values as alternative names for
693 specific calendar systems. These alias values can be used as
694 "RSCALE" values and are treated the same as the equivalent CLDR
695 calendar system they are an alias for.
697 When using the CLDR data, calendar agents SHOULD take into account
698 the "deprecated" value and use the alternative "preferred" calendar
699 system. In particular, the "islamicc" calendar system is considered
700 deprecated in favor of the "islamic-civil" calendar system.
704 For calendar user agents that do not support the "RSCALE" element, or
705 do not support the calendar system specified by the "RSCALE" element
706 value, the following behaviors are possible when processing iCalendar
709 1. The calendar user agent can reject the entire iCalendar object
710 within which at least one iCalendar component uses the
711 unrecognized "RSCALE" element or element value.
713 2. The calendar user agent can reject just the iCalendar components
714 containing an unrecognized "RSCALE" element or element value.
715 Note that any overridden components associated with those
716 rejected components MUST also be rejected (i.e., any other
717 components with the same "UID" property value as the one with the
718 unrecognized "RSCALE" element or element value).
720 3. The calendar user agent can fall back to a non-recurring behavior
721 for the iCalendar component containing the unrecognized "RSCALE"
722 element or element value (effectively ignoring the "RRULE"
723 property). However, any overridden components SHOULD be rejected
724 as they would represent "orphaned" instances that would seem to
730Daboo & Yakushev Standards Track [Page 13]
732RFC 7529 iCalendar RSCALE Extension May 2015
735 In general, the best choice for a calendar user agent would be option
736 (2) above, as it would be the least disruptive choice. Note that
737 when processing iTIP [RFC5546] messages, the manner of the rejection
738 is covered as discussed in the next section.
742 iTIP [RFC5546] defines how iCalendar data can be sent between
743 calendar user agents to schedule calendar components between calendar
744 users. It is often not possible to know the capabilities of a
745 calendar user agent to which an iTIP message is being sent, but iTIP
746 defines fallback behavior in such cases.
748 For calendar user agents that do not support the "RSCALE" element,
749 the following can occur when iTIP messages containing an "RSCALE"
750 element are received:
752 The receiving calendar user agent can reject the entire iTIP
753 message and return an iTIP reply with a "REQUEST-STATUS" property
754 set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]).
756 The receiving calendar user agent can fall back to a non-recurring
757 behavior for the calendar component (effectively ignoring the
758 "RRULE" property) and return an iTIP reply with a "REQUEST-STATUS"
759 property set to the "2.3", "2.5", "2.8", or "2.10" status codes
760 (as per Sections 3.6.4, 3.6.6, 3.6.9, or 3.6.11, respectively, of
763 For calendar user agents that support the "RSCALE" element but do not
764 support the calendar system specified by the "RSCALE" element value,
765 the following can occur:
767 The iTIP message SHOULD be rejected, returning a "REQUEST-STATUS"
768 property set to the "3.1" status code (as per Section 3.6.14 of
771 If the iTIP message is accepted and the calendar component treated
772 as non-recurring, an iTIP reply with a "REQUEST-STATUS" property
773 set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or
774 3.6.11, respectively, of [RFC5546]) SHOULD be returned.
776 As noted in Section 6, the best choice is to reject the entire iTIP
786Daboo & Yakushev Standards Track [Page 14]
788RFC 7529 iCalendar RSCALE Extension May 2015
793 xCal [RFC6321] defines how iCalendar data is represented in XML.
794 This specification extends the <recur> XML element in Section 3.6.10
795 of [RFC6321] in the following manner:
797 1. A new <rscale> XML element is defined as a child element of
798 <recur>. The content of this element MUST be a string whose
799 value is the "RSCALE" element value of the "RRULE", with case
802 2. A new <skip> XML element is defined as a child element of
803 <recur>. The content of this element MUST be a string whose
804 value is the "SKIP" element value of the "RRULE", with case
807 3. The <bymonth> XML element is redefined to support either numeric
808 or string values as its content (as per Section 4.2).
810 Extensions to the RELAX NG schema in Appendix A of [RFC6321] are
811 defined in Appendix A of this document.
813 Example: the iCalendar "RRULE" property:
815 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD
817 would be represented in XML as:
821 <rscale>GREGORIAN</rscale>
829 jCal [RFC7265] defines how iCalendar data is represented in JSON.
830 This specification extends the "recur" JSON object defined in
831 Section 3.6.10 of [RFC7265] in the following manner:
833 1. A new "rscale" child member is defined. This MUST be a string
834 whose value is the "RSCALE" element value of the "RRULE", with
842Daboo & Yakushev Standards Track [Page 15]
844RFC 7529 iCalendar RSCALE Extension May 2015
847 2. A new "skip" child member is defined. This MUST be a string
848 whose value is the "SKIP" element value of the "RRULE", with case
851 3. The "bymonth" child member is redefined to support either numeric
852 or string values. If the "BYMONTH" element value is an integer,
853 then a numeric JSON value MUST be used. If the "BYMONTH" element
854 value is an integer with the "L" suffix (as per Section 4.2),
855 then a JSON string value MUST be used.
857 Example: the iCalendar "RRULE" property:
859 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD
861 would be represented in JSON as:
868 "rscale": "GREGORIAN",
876 The CalDAV [RFC4791] calendar access protocol allows clients and
877 servers to exchange iCalendar data. In addition, CalDAV clients are
878 able to query calendar data stored on the server, including time-
879 based queries. Since an "RSCALE" element value determines the time
880 ranges for recurring instances in a calendar component, CalDAV
881 servers need to support it to interoperate with clients also using
882 the "RSCALE" element.
884 A CalDAV server advertises a CALDAV:supported-rscale-set Web
885 Distributed Authoring and Versioning (WebDAV) property on calendar
886 home or calendar collections if it supports use of the "RSCALE"
887 element as described in this specification. The server can advertise
888 a specific set of supported calendar systems by including one or more
889 CALDAV:supported-rscale XML elements within the
890 CALDAV:supported-rscale-set XML element. If no
891 CALDAV:supported-rscale XML elements are included in the WebDAV
892 property, then clients can try any calendar system value but need to
893 be prepared for a failure when attempting to store the calendar data.
898Daboo & Yakushev Standards Track [Page 16]
900RFC 7529 iCalendar RSCALE Extension May 2015
903 Clients MUST NOT attempt to store iCalendar data containing "RSCALE"
904 elements if the CALDAV:supported-rscale-set WebDAV property is not
905 advertised by the server.
907 The server SHOULD return an HTTP 403 response with a DAV:error
908 element containing a CALDAV:supported-rscale XML element, if a client
909 attempts to store iCalendar data with an "RSCALE" element value not
910 supported by the server.
912 It is possible for an "RSCALE" value to be present in calendar data
913 on the server being accessed by a client that does not support an
914 "RSCALE" element or its specified value. It is expected that
915 existing clients, unaware of "RSCALE", will fail gracefully by
916 ignoring the calendar component, while still processing other
917 calendar data on the server (as per option (2) in Section 6).
91910.1. CALDAV:supported-rscale-set Property
921 Name: supported-rscale-set
923 Namespace: urn:ietf:params:xml:ns:caldav
925 Purpose: Enumerates the set of supported iCalendar "RSCALE" element
926 values supported by the server.
928 Protected: This property MUST be protected and SHOULD NOT be
929 returned by a PROPFIND allprop request (as defined in Section 14.2
932 Description: See above.
936 <!ELEMENT supported-rscale-set (supported-rscale*)>
937 <!ELEMENT supported-rscale (#PCDATA)>
938 <!-- PCDATA value: string - case insensitive but
939 uppercase preferred -->
943 <C:supported-rscale-set
944 xmlns:C="urn:ietf:params:xml:ns:caldav">
945 <C:supported-rscale>GREGORIAN</C:supported-rscale>
946 <C:supported-rscale>CHINESE</C:supported-rscale>
947 <C:supported-rscale>ISLAMIC-CIVIL</C:supported-rscale>
948 <C:supported-rscale>HEBREW</C:supported-rscale>
949 <C:supported-rscale>ETHIOPIC</C:supported-rscale>
950 </C:supported-rscale-set>
954Daboo & Yakushev Standards Track [Page 17]
956RFC 7529 iCalendar RSCALE Extension May 2015
95911. Security Considerations
961 This specification does not introduce any additional security
962 concerns beyond those described in [RFC5545], [RFC5546], and
96712.1. Normative References
969 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
970 Requirement Levels", BCP 14, RFC 2119, March 1997,
971 <http://www.rfc-editor.org/info/rfc2119>.
973 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
974 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
975 March 2007, <http://www.rfc-editor.org/info/rfc4791>.
977 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
978 Authoring and Versioning (WebDAV)", RFC 4918, June 2007,
979 <http://www.rfc-editor.org/info/rfc4918>.
981 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
982 Specifications: ABNF", STD 68, RFC 5234, January 2008,
983 <http://www.rfc-editor.org/info/rfc5234>.
985 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
986 Scheduling Core Object Specification (iCalendar)", RFC
987 5545, September 2009,
988 <http://www.rfc-editor.org/info/rfc5545>.
990 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
991 Interoperability Protocol (iTIP)", RFC 5546, December
992 2009, <http://www.rfc-editor.org/info/rfc5546>.
994 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
995 Format for iCalendar", RFC 6321, August 2011,
996 <http://www.rfc-editor.org/info/rfc6321>.
998 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
999 Format for iCalendar", RFC 7265, May 2014,
1000 <http://www.rfc-editor.org/info/rfc7265>.
1003 The Unicode Consortium, "CLDR calendar.xml Data", Unicode
1005 <http://www.unicode.org/repos/cldr/tags/latest/common/
1006 bcp47/calendar.xml>.
1010Daboo & Yakushev Standards Track [Page 18]
1012RFC 7529 iCalendar RSCALE Extension May 2015
101512.2. Informative References
1018 International Organization for Standardization, "Data
1019 elements and interchange formats - Information interchange
1020 - Representation of dates and times", ISO Standard 8601,
1024 "International Components for Unicode", April 2014,
1025 <http://site.icu-project.org>.
1066Daboo & Yakushev Standards Track [Page 19]
1068RFC 7529 iCalendar RSCALE Extension May 2015
1071Appendix A. xCal RELAX NG Schema Update
1073 The following changes are made to the RELAX NG schema defined in
1074 Appendix A of [RFC6321].
1077 # This extension adds type-rscale and type-skip,
1078 # and modifies type-bymonth
1080 value-recur = element recur {
1083 (type-until | type-count)?,
1096 element wkst { type-weekday }?,
1101 type-rscale = element rscale {
1105 type-bymonth = element bymonth {
1106 xsd:positiveInteger |
1110 type-skip = element skip {
1122Daboo & Yakushev Standards Track [Page 20]
1124RFC 7529 iCalendar RSCALE Extension May 2015
1129 Thanks to the following for feedback: Mark Davis, Mike Douglass,
1130 Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, Barry
1131 Leiba, Jonathan Lennox, Ken Murchison, Arnaud Quillaud, Dave Thewlis,
1134 This specification originated from work at the Calendaring and
1135 Scheduling Consortium, which has helped with the development and
1136 testing of implementations.
1146 EMail: cyrus@daboo.name
1147 URI: http://www.apple.com/
1152 Brandschenkestrasse 100
1156 EMail: gyakushev@yahoo.com
1157 URI: http://www.google.com/
1178Daboo & Yakushev Standards Track [Page 21]