idnits 2.17.1 draft-ietf-calext-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 RFC6321, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to directly say this. It does mention RFC5545 though, so this could be OK. -- The draft header indicates that this document updates RFC7265, 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 RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- 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 (February 11, 2015) is 3362 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (==), 6 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, 6321, 7265 (if approved) G. Yakushev 5 Intended status: Standards Track Google Inc. 6 Expires: August 15, 2015 February 11, 2015 8 Non-Gregorian Recurrence Rules in iCalendar 9 draft-ietf-calext-rscale-04 11 Abstract 13 This document defines extensions to iCalendar (RFC 5545) to support 14 use of non-Gregorian recurrence rules. It also defines how CalDAV 15 (RFC 4791) servers and clients can be extended to support these new 16 recurrence rules. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 15, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 6 56 4.1. Skipping Invalid Dates . . . . . . . . . . . . . . . . . 6 57 4.2. Handling Leap Months . . . . . . . . . . . . . . . . . . 9 58 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Registering Calendar Systems . . . . . . . . . . . . . . . . 12 60 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 61 7. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 13 62 8. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . . 14 63 9. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . . 15 64 10. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 16 65 10.1. CALDAV:supported-rscale-set Property . . . . . . . . . . 17 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 68 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 71 14.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Appendix A. Change History (To be removed by RFC Editor before 73 publication) . . . . . . . . . . . . . . . . . . . . 19 74 Appendix B. xCal RELAX NG schema update . . . . . . . . . . . . 21 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 77 1. Introduction 79 The iCalendar [RFC5545] data format is in widespread use to represent 80 calendar data. iCalendar represents dates and times using the 81 Gregorian calendar system only. It does provide a way to use non- 82 Gregorian calendar systems via a "CALSCALE" property, but this has 83 never been used. However, there is a need to support at least non- 84 Gregorian recurrence patterns to cover anniversaries, and many local, 85 religious, or civil holidays based on non-Gregorian dates. 87 There are several disadvantages to using the existing "CALSCALE" 88 property in iCalendar for implementing non-Gregorian calendars: 90 1. The "CALSCALE" property exists in the top-level "VCALENDAR" 91 objects and thus applies to all components within that object. 92 In today's multi-cultural society, that restricts the ability to 93 mix events from different calendar systems within the same 94 iCalendar object. e.g., it would prevent having both the 95 Gregorian New Year and Chinese New Year in the same iCalendar 96 object. 98 2. Time zone and daylight saving time rules are typically published 99 using Gregorian calendar dates and rules (e.g., "the 3rd Sunday 100 in March"), and thus converted to iCalendar "VTIMEZONE" 101 components using Gregorian date-time values and recurrence rules. 102 This results in the problem whereby one component (the 103 "VTIMEZONE") is fixed to the Gregorian calendar system, and 104 another (a "VEVENT") wants to use a different non-Gregorian 105 calendar scale, and thus the single top-level "CALSCALE" property 106 is again inadequate. 108 This specification solves these issues by allowing the "CALSCALE" to 109 remain set to Gregorian, but re-defining the "RRULE" recurrence rule 110 property to accept new items including one that allows non-Gregorian 111 calendar systems to be used. With this, all the date, time and 112 period values in the iCalendar object would remain specified using 113 the Gregorian calendar system, but repeating patterns in other 114 calendar systems could be defined. It is then up to calendar user 115 agents and servers to map between Gregorian and non-Gregorian 116 calendar systems in order to expand out recurrence instances. The 117 non-Gregorian recurrence rules can be used in any iCalendar component 118 that allows the "RRULE" property to be specified, including 119 "VTIMEZONE" components (to allow for possible future use of non- 120 Gregorian rules in published daylight saving time data). 122 This specification does not itself define calendar systems, rather it 123 utilizes the calendar system registry defined by the Unicode 124 Consortium in their CLDR (Common Locale Data Repository) project 125 [UNICODE.CLDR], as implemented in the Unicode (ICU) Library 126 [UNICODE.ICU]. 128 This specification makes the following updates: 130 It updates iCalendar [RFC5545], xCal [RFC6321], and jCal 131 [RFC7265], to extend the "RRULE" property definition. 133 It updates iTIP [RFC5546] to specify how the extended "RRULE" 134 property should be handled in iTIP messages. 136 It updates CalDAV [RFC4791] to specify how the extended "RRULE" 137 property can be supported by CalDAV servers and clients. 139 2. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 [RFC2119]. 146 The notation used in this memo is the ABNF notation of [RFC5234] as 147 used by iCalendar [RFC5545]. Any syntax elements shown below that 148 are not explicitly defined in this specification come from iCalendar 149 [RFC5545], iTIP [RFC5546], and CalDAV [RFC4791]. 151 When XML element types in the namespaces "DAV:" and 152 "urn:ietf:params:xml:ns:caldav" are referenced in this document 153 outside of the context of an XML fragment, the string "DAV:" and 154 "CALDAV:" will be prefixed to the element type names respectively. 156 When a Gregorian calendar date value is shown in text, it will use 157 the format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 158 2-digit month, and "DD" the 2-digit day (this is the same format used 159 in iCalendar [RFC5545]). The Chinese calendar will be used as an 160 example of a non-Gregorian calendar for illustrative purposes. When 161 a Chinese calendar date value is shown in text, it will use the 162 format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with 163 a "{C}" prefix, and an optional "L" character after the month element 164 to indicate a leap month. Similarly, {E} and {H} are used in other 165 examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates, 166 respectively. The "{}" prefix is used for purely illustrative 167 purposes and never appears in actual date-time values used in 168 iCalendar or related specifications. Note that the Chinese calendar 169 years shown in the examples are based on the Unicode (ICU) 170 [UNICODE.ICU] library's Chinese calendar epoch. Whilst there are 171 several different Chinese calendar epochs in common use, the choice 172 of one over another does not impact the actual calculation of the 173 Gregorian equivalent dates, provided conversion is always done using 174 the same epoch. 176 3. Overview 178 In the Gregorian calendar system, each year is composed of a fixed 179 number of months (12), with each month having a fixed number of days 180 (between 30 and 31), except for the second month (February) which 181 contains either 28 days, or 29 days (in a leap year). Weeks are 182 composed of 7 days, with day names Monday, Tuesday, Wednesday, 183 Thursday, Friday, Saturday and Sunday. Years can have either 365 or 184 366 days (the latter in a leap year). The number of whole weeks in a 185 year is 52 (though the [ISO.8601.2004] week numbering scheme used by 186 iCalendar [RFC5545] can have a numeric count up to 53). 188 In iCalendar, the "RECUR" value type defines various fields used to 189 express a recurrence pattern, and those fields are given limits based 190 on those of the Gregorian calendar system. Since other calendar 191 systems can have different limits and other behaviors that need to be 192 accounted for, the maximum values for the elements in the "RECUR" 193 value are not covered by this specification. 195 To generate a set of recurring instances in a non-Gregorian calendar 196 system, the following principles are used: 198 1. iCalendar data continues to use the "GREGORIAN" calendar system, 199 so all "DATE", "DATE-TIME" and "PERIOD" values continue to use 200 the Gregorian format and limits. 202 2. The "RRULE" property is extended to include an "RSCALE" element 203 in its value that specifies the calendar system to use for the 204 recurrence pattern. The existing elements of the "RRULE" value 205 type are used, but modified to support different upper limits, 206 based on the "RSCALE" value, as well as a modification to month 207 numbers to allow a leap month to be specified. Existing 208 requirements for the use of "RRULE" all still apply (e.g., the 209 "RRULE" has to match the "DTSTART" value of the master instance). 210 Other recurrence properties such as "RECURRENCE-ID", "RDATE" and 211 "EXDATE" continue to use the Gregorian date format as "CALSCALE" 212 is unchanged. 214 When generating instances, the following procedure might be used: 216 1. Convert the "DTSTART" property value of the master recurring 217 component into the date and time components for the calendar 218 system specified by the "RSCALE" element in the "RRULE" value. 219 This provides the "seed" value for generating subsequent 220 recurrence instances. 222 2. Iteratively generate instances using the "RRULE" value applied to 223 the year, month, and day components of the date in the new 224 calendar system. 226 3. For each generated instance, convert the date values back from 227 the non-Gregorian form into Gregorian and use those values for 228 other properties such as "RECURRENCE-ID". 230 Consider the following example for an event representing the Chinese 231 New Year: 233 DTSTART;VALUE=DATE:20130210 234 RRULE:RSCALE=CHINESE;FREQ=YEARLY 235 SUMMARY:Chinese New Year 237 To generate instances, first the "DTSTART" value "20130210" is 238 converted into the Chinese calendar system giving "{C}46500101". 239 Next, the year component is incremented by one to give "{C}46510101", 240 and that is then converted back into Gregorian as "20140131". 241 Additional instances are generated by iteratively increasing the year 242 component in the Chinese date value and converting back to Gregorian. 244 4. Extended RRULE Property 246 This specification extends the existing "RRULE" iCalendar property 247 value to include a new "RSCALE" element that can be used to indicate 248 the calendar system used for generating the recurrence pattern. 250 When "RSCALE" is present, the other changes to "RRULE" are: 252 1. Elements that include numeric values (e.g., "BYYEARDAY") have 253 numeric ranges defined by the "RSCALE" value (i.e., in some 254 calendar systems there might be more than 366 days in a year). 256 2. Month numbers can include an "L" suffix to indicate that the 257 specified month is a leap month in the corresponding calendar 258 system (see Section 4.2). 260 3. A "SKIP" element is added to define how "missing" instances are 261 handled (see Section 4.1). 263 The syntax for the "RECUR" value is modified in the following 264 fashion: 266 recur-rule-part /= ("RSCALE" "=" rscale) 267 / ("SKIP" "=" skip) 269 rscale = (iana-token ; A CLDR-registered calendar system 270 ; name. 271 / x-name) ; A non-standard, experimental 272 ; calendar system name. 273 ; Names are case-insensitive, 274 ; but uppercase values are preferred. 276 skip = ("OMIT" / "BACKWARD" / "FORWARD") 277 ; Optional, with default value "OMIT", and 278 ; MUST NOT be present unless "RSCALE" is present. 280 monthnum = 1*2DIGIT ["L"] 281 ; Existing element modified to include a leap 282 ; month indicator suffix. 284 4.1. Skipping Invalid Dates 286 In every calendar system only certain combinations of day-of-month 287 and month values are valid for a given year. e.g., in the Gregorian 288 calendar system January 31st is valid, but February 31st is not. 289 Similarly, February 29th is valid in a leap year, but invalid in a 290 non-leap year. Other calendar systems can also include leap months 291 (see Section 4.2) which vary from year to year. This poses a problem 292 for recurring events where the frequency of recurrence might give 293 rise to an invalid date. For example, a recurring event that starts 294 on January 31st and is set to repeat monthly will generate invalid 295 dates for months with fewer than 31 days. The iCalendar [RFC5545] 296 specification requires recurrence rule generators to ignore any 297 invalid dates generated when iterating the rule. However, that 298 behavior might be surprising to a calendar user born on a leap day 299 and whose birthday event only appears on their calendar every four 300 years. There are common conventions used by humans to determine what 301 to do in such cases, but those conventions can differ from calendar 302 system to calendar system, as well as within the same calendar 303 system, depending on the nature of the event. Typically, humans will 304 expect the "missing" events to be moved to a earlier or later (valid) 305 date. 307 This specification introduces a new "RRULE" element, "SKIP", for use 308 only when the "RSCALE" element is present. The "SKIP" element allows 309 the calendar user agent to specify new options for handling invalid 310 dates. 312 "SKIP=OMIT": this is the default option and corresponds to the 313 existing iCalendar behavior of simply ignoring the invalid date. 315 "SKIP=BACKWARD": when this option is set, a date with an invalid 316 month is changed to the previous (valid) month. A date with an 317 invalid day-of-month is changed to the previous (valid) day-of- 318 month. 320 "SKIP=FORWARD": when this option is set, a date with an invalid 321 month is changed to the next (valid) month. A date with an 322 invalid day-of-month is changed to the next (valid) day-of-month. 324 Note that for both "BACKWARD" and "FORWARD", if the month is changed 325 and results in an invalid day-of-month, then the skip behavior will 326 be re-applied as per the day-of-month rules, according to the 327 processing order defined below. 329 The month and day-of-month skip behavior is only applied at specific 330 points during the processing of an "RRULE" as determined by the order 331 in which any "BYxxx" elements are processed. The order is as follows 332 (based on the "RRULE" element processing order defined in 333 Section 3.3.10 of [RFC5545]): 335 o BYMONTH 337 o SKIP (for invalid month only) 338 o BYWEEKNO 340 o BYYEARDAY 342 o BYMONTHDAY 344 o SKIP (for invalid day) 346 o BYDAY 348 o BYHOUR 350 o BYMINUTE 352 o BYSECOND 354 o BYSETPOS 356 o COUNT 358 o UNTIL 360 It is often possible to avoid having to deal with invalid dates by 361 determining the real intent of a human user. e.g., a human creating a 362 monthly recurring event that starts on January 31st, likely intends 363 the event to occur on the last day of every month, in which case that 364 could be encoded into an "RRULE" by using the "BYMONTHDAY=-1" 365 element. 367 Only a few types of recurrence patterns are likely to need the use of 368 "SKIP". The following is a list of some situations where it might be 369 needed: 371 1. The start date of the recurrence is a leap day in the specified 372 calendar system. 374 2. The start date of the recurrence is in a leap month in the 375 specified calendar system. 377 3. The start date of the recurrence has a day-of-month value greater 378 than the smallest day-of-month value for any month in any year in 379 the specified calendar system. 381 4. A "BYMONTHDAY" element in an "RRULE" has a day-of-month value 382 greater than the smallest day-of-month value for any month in any 383 year in the specified calendar system. 385 5. A "BYMONTH" element in an "RRULE" has a value corresponding to a 386 leap month in the specified calendar system. 388 6. A combination of "BYMONTHDAY" and "BYMONTH" elements in an 389 "RRULE" have a value corresponding to a leap day in the specified 390 calendar system. 392 7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater 393 than the smallest number of days in any year in the specified 394 calendar system. 396 8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater 397 than the smallest number of weeks in any year in the specified 398 calendar system. 400 Examples of using "SKIP" for some common use cases appear in 401 Section 4.3. 403 4.2. Handling Leap Months 405 Leap months can occur in different calendar systems. For such 406 calendar systems the following rules are applied for "identifying" 407 months: 409 1. Numeric values 1 through N are used to identify regular, non- 410 leap, months (where N is the number of months in a regular, non- 411 leap, year). 413 2. The suffix "L" is added to the regular month number to indicate a 414 leap month which follows the regular month. e.g., "5L" is a leap 415 month that follows the 5th regular month in the year. 417 Care has to be taken when mapping the month identifiers used here 418 with those of any underlying calendar system library being used. In 419 particular, the Hebrew calendar system used by Unicode (ICU) 420 [UNICODE.ICU] uses a month number scheme of 1 through 13, with month 421 6 being the leap month, and in non-leap years, month 6 is skipped. 422 Thus ICU months 1 through 5 map to iCalendar months 1 through 5, ICU 423 month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map 424 to iCalendar months 6 through 12. 426 4.3. Examples 428 4.3.1. Chinese New Year 430 Consider the following set of iCalendar properties (from the example 431 above): 433 DTSTART;VALUE=DATE:20130210 434 RRULE:RSCALE=CHINESE;FREQ=YEARLY 435 SUMMARY:Chinese New Year 437 These define a recurring event for the Chinese New Year, with the 438 first instance the one in Gregorian year 2013. 440 The Chinese date corresponding to the first instance is {C}46500101. 441 The table below shows the initial instance, and the next four, each 442 of which is determined by adding the appropriate amount to the year 443 component of the Chinese date. Also shown is the conversion back to 444 the Gregorian date: 446 +--------------+--------------------------+ 447 | Chinese Date | Gregorian Date | 448 +--------------+--------------------------+ 449 | {C}46500101 | 20130210 - DTSTART value | 450 | {C}46510101 | 20140131 | 451 | {C}46520101 | 20150219 | 452 | {C}46530101 | 20160208 | 453 | {C}46540101 | 20170128 | 454 +--------------+--------------------------+ 456 4.3.2. Ethiopic 13th Month 458 Consider the following set of iCalendar properties: 460 DTSTART;VALUE=DATE:20130906 461 RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13 462 SUMMARY:First day of 13th month 464 These define a recurring event for the first day of the 13th month, 465 with the first instance the one in Gregorian year 2013. Whilst there 466 are a number of alternative ways of writing the "RRULE" above to 467 achieve the same pattern of recurring dates, the one above was chosen 468 to illustrate a "BYMONTH" value exceeding the limit of 12, previously 469 described in iCalendar (Section 3.3.10 of [RFC5545]). 471 The Ethiopic date corresponding to the first instance is {E}20051301. 472 The table below shows the initial instance, and the next four, each 473 of which is determined by adding the appropriate amount to the year 474 component of the Ethiopic date. Also shown is the conversion back to 475 the Gregorian date: 477 +---------------+--------------------------+ 478 | Ethiopic Date | Gregorian Date | 479 +---------------+--------------------------+ 480 | {E}20051301 | 20130906 - DTSTART value | 481 | {E}20061301 | 20140906 | 482 | {E}20071301 | 20150906 | 483 | {E}20081301 | 20160906 | 484 | {E}20091301 | 20170906 | 485 +---------------+--------------------------+ 487 Note that in this example, the value of the "BYMONTH" component in 488 the "RRULE" matches the Ethiopic month value and not the Gregorian 489 month. 491 4.3.3. Hebrew anniversary starting in a leap month 493 Consider the following set of iCalendar properties: 495 DTSTART;VALUE=DATE:20140208 496 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD 497 SUMMARY:Anniversary 499 These define a recurring event for the 8th day of the Hebrew month of 500 Adar I (the leap month identified by "5L"), with the first instance 501 the one in Gregorian year 2014. 503 The Hebrew date corresponding to the first instance is {H}577405L08, 504 which is a leap month in year 5774. The table below shows the 505 initial instance, and the next four, each of which is determined by 506 adding the appropriate amount to the year component of the Hebrew 507 date, taking into account that only year 5776 is a leap year. Thus 508 in other years the Hebrew month component is adjusted forward to 509 month 6. Also shown is the conversion back to the Gregorian date: 511 +--------------+--------------------------+ 512 | Hebrew Date | Gregorian Date | 513 +--------------+--------------------------+ 514 | {H}577405L08 | 20140208 - DTSTART value | 515 | {H}57750608 | 20150227 | 516 | {H}577605L08 | 20160217 | 517 | {H}57770608 | 20170306 | 518 | {H}57780608 | 20180223 | 519 +--------------+--------------------------+ 521 4.3.4. Gregorian leap day with SKIP 523 Consider the following set of iCalendar properties: 525 DTSTART;VALUE=DATE:20120229 526 RRULE:FREQ=YEARLY 527 SUMMARY:Anniversary 529 These define a recurring event for the 29th February, 2012 in the 530 standard iCalendar calendar scale - Gregorian. The standard 531 iCalendar behavior is that non-existent dates in a recurrence set are 532 ignored. Thus the properties above would only generate instances in 533 leap years (2016, 2020, etc), which is likely not what users expect. 534 The new "RSCALE" option defined by this specification provides the 535 "SKIP" element which can be used to "fill in" the missing instances 536 in an appropriate fashion. The set of iCalendar properties below do 537 that: 539 DTSTART;VALUE=DATE:20120229 540 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 541 SUMMARY:Anniversary 543 With these properties, the "missing" instances in non-leap year now 544 appear on the 1st March in those years: 546 +-------------------------------+----------------------------+ 547 | Instances (with SKIP=FORWARD) | Instances (without RSCALE) | 548 +-------------------------------+----------------------------+ 549 | 20120229 | 20120229 - DTSTART value | 550 | 20130301 | | 551 | 20140301 | | 552 | 20150301 | | 553 | 20160229 | 20160229 | 554 | 20170301 | | 555 +-------------------------------+----------------------------+ 557 5. Registering Calendar Systems 559 This specification uses the Unicode Consortium's registry of calendar 560 systems [UNICODE.CLDR] to define valid values for the "RSCALE" 561 element of an "RRULE". Note that the underscore character "_" is 562 never used in CLDR-based calendar system names. New values can be 563 added to this registry following Unicode Consortium rules. It is 564 expected that many implementations of non-Gregorian calendars will 565 use software libraries provided by Unicode (ICU) [UNICODE.ICU], and 566 hence it makes sense to re-use their registry rather than creating a 567 new one. "RSCALE" values are case-insensitive, but upper case is 568 preferred. 570 CLDR supports the use of "alias" values as alternative names for 571 specific calendar systems. These alias values can be used as 572 "RSCALE" values and are treated the same as the equivalent CLDR 573 calendar system they are an alias for. 575 When using the CLDR data, calendar agents SHOULD take into account 576 the "deprecated" value and use the alternative "preferred" calendar 577 system. In particular, the "islamicc" calendar system is considered 578 deprecated in favor of the "islamic-civil" calendar system. 580 6. Compatibility 582 For calendar user agents that do not support the "RSCALE" element, or 583 do not support the calendar system specified by the "RSCALE" element 584 value, the following behaviors are possible when processing iCalendar 585 data: 587 1. The calendar user agent can reject the entire iCalendar object 588 within which at least one iCalendar component uses the 589 unrecognized "RSCALE" element or element value. 591 2. The calendar user agent can reject just the iCalendar components 592 containing an unrecognized "RSCALE" element or element value. 593 Note that any overridden components associated with those 594 rejected components MUST also be rejected (i.e., any other 595 components with the same "UID" property value as the one with the 596 unrecognized "RSCALE" element or element value). 598 3. The calendar user agent can fallback to a non-recurring behavior 599 for the iCalendar component containing the unrecognized "RSCALE" 600 element or element value (effectively ignoring the "RRULE" 601 property). However, any overridden components SHOULD be rejected 602 as they would represent "orphaned" instances that would seem to 603 be out of place. 605 In general, the best choice for a calendar user agent would be option 606 (2) above, as it would be the least disruptive choice. Note that 607 when processing iTIP [RFC5546] messages, the manner of the rejection 608 is covered in the next section. 610 7. Use with iTIP 612 iTIP [RFC5546] defines how iCalendar data can be sent between 613 calendar user agents to schedule calendar components between calendar 614 users. It is often not possible to know the capabilities of a 615 calendar user agent to which an iTIP message is being sent, but iTIP 616 defines fallback behavior in such cases. 618 For calendar user agents that do not support the "RSCALE" element, 619 the following can occur when iTIP messages containing an "RSCALE" 620 element are received: 622 The receiving calendar user agent can reject the entire iTIP 623 message and return an iTIP reply with a "REQUEST-STATUS" property 624 set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]). 626 The receiving calendar user agent can fallback to a non-recurring 627 behavior for the calendar component (effectively ignoring the 628 "RRULE" property) and return an iTIP reply with a "REQUEST-STATUS" 629 property set to the "2.3", "2.5", "2.8", or "2.10" status codes 630 (as per Sections 3.6.3, 3.6.6, 3.6.9, or 3.6.11, respectively, of 631 [RFC5546]). 633 For calendar user agents that support the "RSCALE" element but do not 634 support the calendar system specified by the "RSCALE" element value, 635 the following can occur: 637 the iTIP message SHOULD be rejected, returning a "REQUEST-STATUS" 638 property set to the "3.1" status code (as per Section 3.6.14 of 639 [RFC5546]). 641 if the iTIP message is accepted and the calendar component treated 642 as non-recurring, an iTIP reply with a "REQUEST-STATUS" property 643 set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or 644 3.6.11, respectively, of [RFC5546]) SHOULD be returned. 646 As noted in Section 6, the best choice is to reject the entire iTIP 647 message. 649 8. Use with xCal 651 xCal [RFC6321] defines how iCalendar data is represented in XML. 652 This specification extends the XML element in Section 3.6.10 653 of [RFC6321] in the following manner: 655 1. A new XML element is defined as a child element of 656 . The content of this element MUST be a string whose 657 value is the "RSCALE" element value of the "RRULE", with case 658 preserved. 660 2. A new XML element is defined as a child element of 661 . The content of this element MUST be a string whose 662 value is the "SKIP" element value of the "RRULE", with case 663 preserved. 665 3. The "bymonth" XML element is redefined to support either numeric 666 or string values as its content (as per Section 4.2). 668 Extensions to the RELAX NG schema in Appendix A of [RFC6321] are 669 defined in Appendix B. 671 Example: the iCalendar "RRULE" property: 673 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 675 would be represented in XML as: 677 678 679 GREGORIAN 680 YEARLY 681 FORWARD 682 683 685 9. Use with jCal 687 jCal [RFC7265] defines how iCalendar data is represented in JSON. 688 This specification extends the "recur" JSON object defined in 689 Section 3.6.10 of [RFC7265] in the following manner: 691 1. A new "rscale" child member is defined. This MUST be a string 692 whose value is the "RSCALE" element value of the "RRULE", with 693 case preserved. 695 2. A new "skip" child member is defined. This MUST be a string 696 whose value is the "SKIP" element value of the "RRULE", with case 697 preserved. 699 3. The "bymonth" child member is redefined to support either numeric 700 or string values. If the "BYMONTH" element value is an integer, 701 then a numeric JSON value MUST be used. If the "BYMONTH" element 702 value is an integer with the "L" suffix (as per Section 4.2), 703 then a JSON string value MUST be used. 705 Example: the iCalendar "RRULE" property: 707 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 709 would be represented in JSON as: 711 [ 712 "rrule", 713 {}, 714 "recur", 715 { 716 "rscale": "GREGORIAN", 717 "freq": "YEARLY", 718 "skip": "FORWARD" 719 } 720 ] 722 10. Use with CalDAV 724 The CalDAV [RFC4791] calendar access protocol allows clients and 725 servers to exchange iCalendar data. In addition, CalDAV clients are 726 able to query calendar data stored on the server, including time- 727 based queries. Since an "RSCALE" element value determines the time 728 ranges for recurring instances in a calendar component, CalDAV 729 servers need to support it to interoperate with clients also using 730 the "RSCALE" element. 732 A CalDAV server advertises a CALDAV:supported-rscale-set WebDAV 733 property on calendar home or calendar collections if it supports use 734 of "RSCALE" element as described in this specification. The server 735 can advertise a specific set of supported calendar systems by 736 including one or more CALDAV:supported-rscale XML elements within the 737 CALDAV:supported-rscale-set XML element. If no CALDAV:supported- 738 rscale XML elements are included in the WebDAV property, then clients 739 can try any calendar system value, but need to be prepared for a 740 failure when attempting to store the calendar data. 742 Clients MUST NOT attempt to store iCalendar data containing "RSCALE" 743 elements if the CALDAV:supported-rscale-set WebDAV property is not 744 advertised by the server. 746 The server SHOULD return an HTTP 403 response with a DAV:error 747 element containing a CALDAV:supported-rscale XML element, if a client 748 attempts to store iCalendar data with an "RSCALE" element value not 749 supported by the server. 751 It is possible for an "RSCALE" value to be present in calendar data 752 on the server being accessed by a client that does not support an 753 "RSCALE" element or its specified value. It is expected that 754 existing clients, unaware of "RSCALE", will fail gracefully by 755 ignoring the calendar component, whilst still processing other 756 calendar data on the server (as per option (2) in Section 6). 758 10.1. CALDAV:supported-rscale-set Property 760 Name: supported-rscale-set 762 Namespace: urn:ietf:params:xml:ns:caldav 764 Purpose: Enumerates the set of supported iCalendar "RSCALE" element 765 values supported by the server. 767 Protected: This property MUST be protected and SHOULD NOT be 768 returned by a PROPFIND allprop request (as defined in Section 14.2 769 of [RFC4918]). 771 Description: See above. 773 Definition: 775 776 777 780 Example: 782 784 GREGORIAN 785 CHINESE 786 ISLAMIC-CIVIL 787 HEBREW 788 ETHIOPIC 789 791 11. Security Considerations 793 This specification does not introduce any addition security concerns 794 beyond those described in [RFC5545], [RFC5546], and [RFC4791]. 796 12. IANA Considerations 798 This document requires no IANA actions. 800 13. Acknowledgments 802 Thanks to the following for feedback: Mark Davis, Mike Douglass, 803 Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, Barry 804 Leiba, Jonathan Lennox, Ken Murchison, Arnaud Quillaud, Dave Thewlis, 805 and Umaoka Yoshito. 807 This specification originated from work at the Calendaring and 808 Scheduling Consortium, which has helped with the development and 809 testing of implementations. 811 14. References 813 14.1. Normative References 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 819 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 820 March 2007. 822 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 823 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 825 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 826 Specifications: ABNF", STD 68, RFC 5234, January 2008. 828 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 829 Core Object Specification (iCalendar)", RFC 5545, 830 September 2009. 832 [RFC5546] Daboo, C., "iCalendar Transport-Independent 833 Interoperability Protocol (iTIP)", RFC 5546, December 834 2009. 836 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 837 Format for iCalendar", RFC 6321, August 2011. 839 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 840 Format for iCalendar", RFC 7265, May 2014. 842 [UNICODE.CLDR] 843 "CLDR calendar.xml Data", Unicode Consortium CLDR, 844 . 847 14.2. Informative References 849 [ISO.8601.2004] 850 International Organization for Standardization, "Data 851 elements and interchange formats - Information interchange 852 - Representation of dates and times", ISO Standard 8601, 853 2004. 855 [UNICODE.ICU] 856 "International Components for Unicode", Unicode Consortium 857 ICU, April 2014, . 859 Appendix A. Change History (To be removed by RFC Editor before 860 publication) 862 Changes in draft-ietf-calext-rscale-04: 864 1. AD review: Clarified that {} prefix is purely illustrative. 866 2. AD review: reworded SKIP formal syntax comment. 868 3. AD review: clarified mapping of ICU to iCalendar months for 869 Hebrew calendar. 871 4. AD review: tweaked introductory text of Chinese example. 873 5. AD review: changed Ethiopic example to use MONTHLY and explained 874 why that rule was chosen. 876 6. AD review: removed "SHOULD" for RSCALE upper case. 878 7. AD review: "SKIP" - added new section, changed the default value. 880 8. OPSDIR review: fixed Ethiopic example. 882 Changes in draft-ietf-calext-rscale-03: 884 1. Reworded abstract. 886 2. Added list of changes to other specs in Section 1. 888 3. Clarified behavior wrt VTIMEZONE in Section 1. 890 Changes in draft-ietf-calext-rscale-02: 892 1. Added xCal and jCal changes sections and relax NG schema 893 appendix. 895 2. Added ICU reference at the end of Section 1. 897 Changes in draft-ietf-calext-rscale-01: 899 1. Editorial changes/fixes per document shepherd review. 901 2. Switched CLDR reference to "tags/latest". 903 Changes in draft-ietf-calext-rscale-00: 905 1. Updated some references. 907 2. Editorial changes/fixes. 909 Changes in draft-daboo-icalendar-rscale-04: 911 1. Always use "L" suffix for leap months, even for Hebrew calendar. 913 2. Remove negative month numbers to go back to base 5545 definition. 915 3. Added example for Gregorian leap day with skip. 917 4. Clarify that RSCALE names are case insensitive, but with upper 918 case preferred. 920 5. Clarify that BYSETPOS processing is done after SKIP. 922 6. Remove Islamic example in favor of Ethiopic example which shows a 923 13th month. 925 Changes in draft-daboo-icalendar-rscale-03: 927 1. Added details about handling RSCALE in iTIP. 929 2. Added details about handling RSCALE in CalDAV. 931 3. Fixed examples to use ICU Chinese epoch and added text describing 932 why that is not an issue for actual recurrence calculations. 934 Changes in draft-daboo-icalendar-rscale-02: 936 1. Fixed some incorrect dates in examples. 938 2. Clarified use of CLDR and alias, deprecated, preferred 939 attributes. 941 3. Clarified when SKIP processing occurs. 943 Changes in draft-daboo-icalendar-rscale-01: 945 1. Removed requirement that RSCALE be the first item in an RRULE. 947 2. Added BYLEAPMONTH element and removed BYMONTH "L" suffix. 949 3. Removed Open Issues. 951 Appendix B. xCal RELAX NG schema update 953 The following changes are made to the RELAX NG schema defined in 954 Appendix A of [RFC6321]. 956 # 3.3.10 RECUR 957 # This extension adds type-rscale and type-skip, 958 # and modifies type-bymonth 960 value-recur = element recur { 961 type-rscale?, 962 type-freq, 963 (type-until | type-count)?, 964 element interval { 965 xsd:positiveInteger 966 }?, 967 type-bysecond*, 968 type-byminute*, 969 type-byhour*, 970 type-byday*, 971 type-bymonthday*, 972 type-byyearday*, 973 type-byweekno*, 974 type-bymonth*, 975 type-bysetpos*, 976 element wkst { type-weekday }?, 977 type-skip? 978 } 980 type-rscale = element rscale { 981 xsd:string 982 } 984 type-bymonth = element bymonth { 985 xsd:positiveInteger | 986 xsd:string 987 } 989 type-skip = element skip { 990 "OMIT" | 991 "BACKWARD" | 992 "FORWARD" 993 } 995 Authors' Addresses 997 Cyrus Daboo 998 Apple Inc. 999 1 Infinite Loop 1000 Cupertino, CA 95014 1001 USA 1003 Email: cyrus@daboo.name 1004 URI: http://www.apple.com/ 1006 Gregory Yakushev 1007 Google Inc. 1008 Brandschenkestrasse 100 1009 8002 Zurich 1010 Switzerland 1012 Email: yakushev@google.com 1013 URI: http://www.google.com/