idnits 2.17.1 draft-ietf-calext-rscale-03.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 (January 7, 2015) is 3368 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: July 11, 2015 January 7, 2015 8 Non-Gregorian Recurrence Rules in iCalendar 9 draft-ietf-calext-rscale-03 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 July 11, 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. Handling Leap Months . . . . . . . . . . . . . . . . . . 7 57 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Registering Calendar Systems . . . . . . . . . . . . . . . . 10 59 6. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . . 11 61 8. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . . 12 62 9. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 13 63 9.1. CALDAV:supported-rscale-set Property . . . . . . . . . . 13 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 69 13.2. Informative References . . . . . . . . . . . . . . . . . 15 70 Appendix A. Change History (To be removed by RFC Editor before 71 publication) . . . . . . . . . . . . . . . . . . . . 15 72 Appendix B. xCal RELAX NG schema update . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 The iCalendar [RFC5545] data format is in widespread use to represent 78 calendar data. iCalendar represents dates and times using the 79 Gregorian calendar system only. It does provide a way to use non- 80 Gregorian calendar systems via a "CALSCALE" property, but this has 81 never been used. However, there is a need to support at least non- 82 Gregorian recurrence patterns to cover anniversaries, and many local, 83 religious, or civil holidays based on non-Gregorian dates. 85 There are several disadvantages to using the existing "CALSCALE" 86 property in iCalendar for implementing non-Gregorian calendars: 88 1. The "CALSCALE" property exists in the top-level "VCALENDAR" 89 objects and thus applies to all components within that object. 90 In today's multi-cultural society, that restricts the ability to 91 mix events from different calendar systems within the same 92 iCalendar object. e.g., it would prevent having both the 93 Gregorian New Year and Chinese New Year in the same iCalendar 94 object. 96 2. Time zone and daylight saving time rules are typically published 97 using Gregorian calendar dates and rules (e.g., "the 3rd Sunday 98 in March"), and thus converted to iCalendar "VTIMEZONE" 99 components using Gregorian date-time values and recurrence rules. 100 This results in the problem whereby one component (the 101 "VTIMEZONE") is fixed to the Gregorian calendar system, and 102 another (a "VEVENT") wants to use a different non-Gregorian 103 calendar scale, and thus the single top-level "CALSCALE" property 104 is again inadequate. 106 This specification solves these issues by allowing the "CALSCALE" to 107 remain set to Gregorian, but re-defining the "RRULE" recurrence rule 108 property to accept new items including one that allows non-Gregorian 109 calendar systems to be used. With this, all the date, time and 110 period values in the iCalendar object would remain specified using 111 the Gregorian calendar system, but repeating patterns in other 112 calendar systems could be defined. It is then up to calendar user 113 agents and servers to map between Gregorian and non-Gregorian 114 calendar systems in order to expand out recurrence instances. The 115 non-Gregorian recurrence rules can be used in any iCalendar component 116 that allows the "RRULE" property to be specified, including 117 "VTIMEZONE" components (to allow for possible future use of non- 118 Gregorian rules in published daylight saving time data). 120 This specification does not itself define calendar systems, rather it 121 utilizes the calendar system registry defined by the Unicode 122 Consortium in their CLDR (Common Locale Data Repository) project 123 [UNICODE.CLDR], as implemented in the Unicode (ICU) Library 124 [UNICODE.ICU]. 126 This specification makes the following updates: 128 It updates iCalendar [RFC5545], xCal [RFC6321], and jCal 129 [RFC7265], to extend the "RRULE" property definition. 131 It updates iTIP [RFC5546] to specify how the extended "RRULE" 132 property should be handled in iTIP messages. 134 It updates CalDAV [RFC4791] to specify how the extended "RRULE" 135 property can be supported by CalDAV servers and clients. 137 2. Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 [RFC2119]. 144 The notation used in this memo is the ABNF notation of [RFC5234] as 145 used by iCalendar [RFC5545]. Any syntax elements shown below that 146 are not explicitly defined in this specification come from iCalendar 147 [RFC5545], iTIP [RFC5546], and CalDAV [RFC4791]. 149 When XML element types in the namespaces "DAV:" and 150 "urn:ietf:params:xml:ns:caldav" are referenced in this document 151 outside of the context of an XML fragment, the string "DAV:" and 152 "CALDAV:" will be prefixed to the element type names respectively. 154 When a Gregorian calendar date value is shown in text, it will use 155 the format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 156 2-digit month, and "DD" the 2-digit day (this is the same format used 157 in iCalendar [RFC5545]). The Chinese calendar will be used as an 158 example of a non-Gregorian calendar for illustrative purposes. When 159 a Chinese calendar date value is shown in text, it will use the 160 format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with 161 a "{C}" prefix, and an optional "L" character after the month element 162 to indicate a leap month. Similarly, {E} and {H} are used in other 163 examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates, 164 respectively. Note that the Chinese calendar years shown in the 165 examples are based on the Unicode (ICU) [UNICODE.ICU] library's 166 Chinese calendar epoch. Whilst there are several different Chinese 167 calendar epochs in common use, the choice of one over another does 168 not impact the actual calculation of the Gregorian equivalent dates, 169 provided conversion is always done using the same epoch. 171 3. Overview 173 In the Gregorian calendar system, each year is composed of a fixed 174 number of months (12), with each month having a fixed number of days 175 (between 30 and 31), except for the second month (February) which 176 contains either 28 days, or 29 days (in a leap year). Weeks are 177 composed of 7 days, with day names Monday, Tuesday, Wednesday, 178 Thursday, Friday, Saturday and Sunday. Years can have either 365 or 179 366 days (the latter in a leap year). The number of whole weeks in a 180 year is 52 (though the [ISO.8601.2004] week numbering scheme used by 181 iCalendar [RFC5545] can have a numeric count up to 53). 183 In iCalendar, the "RECUR" value type defines various fields used to 184 express a recurrence pattern, and those fields are given limits based 185 on those of the Gregorian calendar system. Since other calendar 186 systems can have different limits and other behaviors that need to be 187 accounted for, the maximum values for the elements in the "RECUR" 188 value are not covered by this specification. 190 To generate a set of recurring instances in a non-Gregorian calendar 191 system, the following principles are used: 193 1. iCalendar data continues to use the "GREGORIAN" calendar system, 194 so all "DATE", "DATE-TIME" and "PERIOD" values continue to use 195 the Gregorian format and limits. 197 2. The "RRULE" property is extended to include an "RSCALE" element 198 in its value that specifies the calendar system to use for the 199 recurrence pattern. The existing elements of the "RRULE" value 200 type are used, but modified to support different upper limits, 201 based on the "RSCALE" value, as well as a modification to month 202 numbers to allow a leap month to be specified. Existing 203 requirements for the use of "RRULE" all still apply (e.g., the 204 "RRULE" has to match the "DTSTART" value of the master instance). 205 Other recurrence properties such as "RECURRENCE-ID", "RDATE" and 206 "EXDATE" continue to use the Gregorian date format as "CALSCALE" 207 is unchanged. 209 When generating instances, the following procedure might be used: 211 1. Convert the "DTSTART" property value of the master recurring 212 component into the date and time components for the calendar 213 system specified by the "RSCALE" element in the "RRULE" value. 214 This provides the "seed" value for generating subsequent 215 recurrence instances. 217 2. Iteratively generate instances using the "RRULE" value applied to 218 the year, month, and day components of the date in the new 219 calendar system. 221 3. For each generated instance, convert the date values back from 222 the non-Gregorian form into Gregorian and use those values for 223 other properties such as "RECURRENCE-ID". 225 Consider the following example for an event representing the Chinese 226 New Year: 228 DTSTART;VALUE=DATE:20130210 229 RRULE:RSCALE=CHINESE;FREQ=YEARLY 230 SUMMARY:Chinese New Year 232 To generate instances, first the "DTSTART" value "20130210" is 233 converted into the Chinese calendar system giving "{C}46500101". 234 Next, the year component is incremented by one to give "{C}46510101", 235 and that is then converted back into Gregorian as "20140131". 236 Additional instances are generated by iteratively increasing the year 237 component in the Chinese date value and converting back to Gregorian. 239 4. Extended RRULE Property 241 This specification extends the existing "RRULE" iCalendar property 242 value to include a new "RSCALE" element that can be used to indicate 243 the calendar system used for generating the recurrence pattern. 245 When "RSCALE" is present, the other changes to "RRULE" are: 247 1. Elements that include numeric values (e.g., "BYYEARDAY") have 248 numeric ranges defined by the "RSCALE" value (i.e., in some 249 calendar systems there might be more than 366 days in a year). 251 2. Month numbers can include an "L" suffix to indicate that the 252 specified month is a leap month in the corresponding calendar 253 system. 255 3. A "SKIP" element is added to define how "missing" instances are 256 handled. e.g., if a yearly recurring event starts in a leap 257 month, the "SKIP" element determines whether instances in non- 258 leap years are ignored ("SKIP" set to "YES"), appear in the 259 preceding regular month ("SKIP" set to "BACKWARD" - the default 260 when "RSCALE" is present), or appear in the following regular 261 month ("SKIP" set to "FORWARD"). This applies for both leap days 262 and leap months. The "SKIP" processing is done after all rule 263 elements, other than "BYSETPOS", "COUNT" and "UNTIL", have been 264 processed. 266 The syntax for the "RECUR" value is modified in the following 267 fashion: 269 recur-rule-part /= ("RSCALE" "=" rscale) 270 / ("SKIP" "=" skip) 272 rscale = (iana-token ; A CLDR-registered calendar system 273 ; name. 274 / x-name) ; A non-standard, experimental 275 ; calendar system name. 276 ; Names are case-insensitive, 277 ; but uppercase values are preferred. 279 skip = ("YES" / "BACKWARD" / "FORWARD") 280 ; Optional, with default value "BACKWARD", 281 ; and MUST only be present if "RSCALE" is present. 283 monthnum = 1*2DIGIT ["L"] 284 ; Existing element modified to include a leap 285 ; month indicator suffix. 287 4.1. Handling Leap Months 289 Leap months can occur in different calendar systems. For such 290 calendar systems the following rules are applied for "identifying" 291 months: 293 1. Numeric values 1 through N are used to identify regular, non- 294 leap, months (where N is the number of months in a regular, non- 295 leap, year). 297 2. The suffix "L" is added to the regular month number to indicate a 298 leap month which follows the regular month. e.g., "5L" is a leap 299 month that follows the 5th regular month in the year. 301 Care has to be taken when mapping the month identifiers used here 302 with those of any underlying calendar system library being used. In 303 particular, the Hebrew calendar system used by Unicode (ICU) 304 [UNICODE.ICU] uses a month number scheme of 1 through 13, with month 305 6 being the leap month, and in non-leap years, month 6 is skipped. 306 In iCalendar, this would map to months 1 through 12 with "5L" as the 307 leap month. 309 4.2. Examples 311 4.2.1. Chinese New Year 313 Consider the following set of iCalendar properties: 315 DTSTART;VALUE=DATE:20130210 316 RRULE:RSCALE=CHINESE;FREQ=YEARLY 317 SUMMARY:Chinese New Year 319 These define a recurring event for the Chinese New Year, with the 320 first instance the one in Gregorian year 2013. 322 The Chinese date corresponding to the first instance is {C}46500101. 323 The table below shows the initial instance, and the next four, each 324 of which is determined by adding the appropriate amount to the year 325 component of the Chinese date. Also shown is the conversion back to 326 the Gregorian date: 328 +--------------+--------------------------+ 329 | Chinese Date | Gregorian Date | 330 +--------------+--------------------------+ 331 | {C}46500101 | 20130210 - DTSTART value | 332 | {C}46510101 | 20140131 | 333 | {C}46520101 | 20150219 | 334 | {C}46530101 | 20160208 | 335 | {C}46540101 | 20170128 | 336 +--------------+--------------------------+ 338 4.2.2. Ethiopic 13th Month 340 Consider the following set of iCalendar properties: 342 DTSTART;VALUE=DATE:201300906 343 RRULE:RSCALE=ETHIOPIC;FREQ=YEARLY;BYMONTH=13 344 SUMMARY:First day of 13th month 346 These define a recurring event for the first day of the 13th month, 347 with the first instance the one in Gregorian year 2013. 349 The Ethiopic date corresponding to the first instance is {E}20051301. 350 The table below shows the initial instance, and the next four, each 351 of which is determined by adding the appropriate amount to the year 352 component of the Ethiopic date. Also shown is the conversion back to 353 the Gregorian date: 355 +---------------+--------------------------+ 356 | Ethiopic Date | Gregorian Date | 357 +---------------+--------------------------+ 358 | {E}20051301 | 20130906 - DTSTART value | 359 | {E}20061301 | 20140906 | 360 | {E}20071301 | 20150906 | 361 | {E}20081301 | 20160906 | 362 | {E}20091301 | 20170906 | 363 +---------------+--------------------------+ 365 Note that in this example, the value of the "BYMONTH" component in 366 the "RRULE" matches the Ethiopic month value and not the Gregorian 367 month. 369 4.2.3. Hebrew anniversary starting in a leap month 371 Consider the following set of iCalendar properties: 373 DTSTART;VALUE=DATE:20140208 374 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD 375 SUMMARY:Anniversary 376 These define a recurring event for the 8th day of the Hebrew month of 377 Adar I (the leap month identified by "5L"), with the first instance 378 the one in Gregorian year 2014. 380 The Hebrew date corresponding to the first instance is {H}577405L08, 381 which is a leap month in year 5774. The table below shows the 382 initial instance, and the next four, each of which is determined by 383 adding the appropriate amount to the year component of the Hebrew 384 date, taking into account that only year 5776 is a leap year. Thus 385 in other years the Hebrew month component is adjusted forward to 386 month 6. Also shown is the conversion back to the Gregorian date: 388 +--------------+--------------------------+ 389 | Hebrew Date | Gregorian Date | 390 +--------------+--------------------------+ 391 | {H}577405L08 | 20140208 - DTSTART value | 392 | {H}57750608 | 20150227 | 393 | {H}577605L08 | 20160217 | 394 | {H}57770608 | 20170306 | 395 | {H}57780608 | 20180223 | 396 +--------------+--------------------------+ 398 4.2.4. Gregorian leap day with SKIP 400 Consider the following set of iCalendar properties: 402 DTSTART;VALUE=DATE:20120229 403 RRULE:FREQ=YEARLY 404 SUMMARY:Anniversary 406 These define a recurring event for the 29th February, 2012 in the 407 standard iCalendar calendar scale - Gregorian. The standard 408 iCalendar behavior is that non-existent dates in a recurrence set are 409 ignored. Thus the properties above would only generate instances in 410 leap years (2016, 2020, etc), which is likely not what users expect. 411 The new "RSCALE" option defined by this specification provides the 412 "SKIP" element which can be used to "fill in" the missing instances 413 in an appropriate fashion. The set of iCalendar properties below do 414 that: 416 DTSTART;VALUE=DATE:20120229 417 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 418 SUMMARY:Anniversary 420 With these properties, the "missing" instances in non-leap year now 421 appear on the 1st March in those years: 423 +-------------------------------+----------------------------+ 424 | Instances (with SKIP=FORWARD) | Instances (without RSCALE) | 425 +-------------------------------+----------------------------+ 426 | 20120229 | 20120229 - DTSTART value | 427 | 20130301 | | 428 | 20140301 | | 429 | 20150301 | | 430 | 20160229 | 20160229 | 431 | 20170301 | | 432 +-------------------------------+----------------------------+ 434 5. Registering Calendar Systems 436 This specification uses the Unicode Consortium's registry of calendar 437 systems [UNICODE.CLDR] to define valid values for the "RSCALE" 438 element of an "RRULE". Note that the underscore character "_" is 439 never used in CLDR-based calendar system names. New values can be 440 added to this registry following Unicode Consortium rules. It is 441 expected that many implementations of non-Gregorian calendars will 442 use software libraries provided by Unicode (ICU) [UNICODE.ICU], and 443 hence it makes sense to re-use their registry rather than creating a 444 new one. For consistency, when used, the "RSCALE" values SHOULD be 445 uppercased. 447 CLDR supports the use of "alias" values as alternative names for 448 specific calendar systems. These alias values MUST be treated as 449 valid "RSCALE" element values. 451 When using the CLDR data, calendar agents SHOULD take into account 452 the "deprecated" value and use the alternative "preferred" calendar 453 system. In particular, the "islamicc" calendar system is considered 454 deprecated in favor of the "islamic-civil" calendar system. 456 6. Use with iTIP 458 iTIP [RFC5546] defines how iCalendar data can be sent between 459 calendar user agents to schedule calendar components between calendar 460 users. It is often not possible to know the capabilities of a 461 calendar user agent to which an iTIP message is being sent, but iTIP 462 defines fallback behavior in such cases. 464 For calendar user agents that do not support the "RSCALE" element, 465 the following can occur when iTIP messages containing an "RSCALE" 466 element are received: 468 The receiving calendar user agent can reject the entire iTIP 469 message and return an iTIP reply with a "REQUEST-STATUS" property 470 set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]). 472 The receiving calendar user agent can fallback to a non-recurring 473 behavior for the calendar component (effectively ignoring the 474 "RRULE" property) and return an iTIP reply with a "REQUEST-STATUS" 475 property set to the "2.3", "2.5", "2.8", or "2.10" status codes 476 (as per Sections 3.6.3, 3.6.6, 3.6.9, or 3.6.11, respectively, of 477 [RFC5546]). 479 For calendar user agents that support the "RSCALE" element but do not 480 support the calendar system specified by the "RSCALE" element value, 481 the following can occur: 483 the iTIP message SHOULD be rejected, returning a "REQUEST-STATUS" 484 property set to the "3.1" status code (as per Section 3.6.14 of 485 [RFC5546]). 487 if the iTIP message is accepted and the calendar component treated 488 as non-recurring, an iTIP reply with a "REQUEST-STATUS" property 489 set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or 490 3.6.11, respectively, of [RFC5546]) SHOULD be returned. 492 7. Use with xCal 494 xCal [RFC6321] defines how iCalendar data is represented in XML. 495 This specification extends the XML element in Section 3.6.10 496 of [RFC6321] in the following manner: 498 1. A new XML element is defined as a child element of 499 . The content of this element MUST be a string whose 500 value is the "RSCALE" element value of the "RRULE", with case 501 preserved. 503 2. A new XML element is defined as a child element of 504 . The content of this element MUST be a string whose 505 value is the "SKIP" element value of the "RRULE", with case 506 preserved. 508 3. The "bymonth" XML element is redefined to support either numeric 509 or string values as its content (as per Section 4.1). 511 Extensions to the RELAX NG schema in Appendix A of [RFC6321] are 512 defined in Appendix B. 514 Example: the iCalendar "RRULE" property: 516 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 518 would be represented in XML as: 520 521 522 GREGORIAN 523 YEARLY 524 FORWARD 525 526 528 8. Use with jCal 530 jCal [RFC7265] defines how iCalendar data is represented in JSON. 531 This specification extends the "recur" JSON object defined in 532 Section 3.6.10 of [RFC7265] in the following manner: 534 1. A new "rscale" child member is defined. This MUST be a string 535 whose value is the "RSCALE" element value of the "RRULE", with 536 case preserved. 538 2. A new "skip" child member is defined. This MUST be a string 539 whose value is the "SKIP" element value of the "RRULE", with case 540 preserved. 542 3. The "bymonth" child member is redefined to support either numeric 543 or string values. If the "BYMONTH" element value is an integer, 544 then a numeric JSON value MUST be used. If the "BYMONTH" element 545 value is an integer with the "L" suffix (as per Section 4.1), 546 then a JSON string value MUST be used. 548 Example: the iCalendar "RRULE" property: 550 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 552 would be represented in JSON as: 554 [ 555 "rrule", 556 {}, 557 "recur", 558 { 559 "rscale": "GREGORIAN", 560 "freq": "YEARLY", 561 "skip": "FORWARD" 562 } 563 ] 565 9. Use with CalDAV 567 The CalDAV [RFC4791] calendar access protocol allows clients and 568 servers to exchange iCalendar data. In addition, CalDAV clients are 569 able to query calendar data stored on the server, including time- 570 based queries. Since an "RSCALE" element value determines the time 571 ranges for recurring instances in a calendar component, CalDAV 572 servers need to support it to interoperate with clients also using 573 the "RSCALE" element. 575 A CalDAV server advertises a CALDAV:supported-rscale-set WebDAV 576 property on calendar home or calendar collections if it supports use 577 of "RSCALE" element as described in this specification. The server 578 can advertise a specific set of supported calendar systems by 579 including one or more CALDAV:supported-rscale XML elements within the 580 CALDAV:supported-rscale-set XML element. If no CALDAV:supported- 581 rscale XML elements are included in the WebDAV property, then clients 582 can try any calendar system value, but need to be prepared for a 583 failure when attempting to store the calendar data. 585 Clients MUST NOT attempt to store iCalendar data containing "RSCALE" 586 elements if the CALDAV:supported-rscale-set WebDAV property is not 587 advertised by the server. 589 The server SHOULD return an HTTP 403 response with a DAV:error 590 element containing a CALDAV:supported-rscale XML element, if a client 591 attempts to store iCalendar data with an "RSCALE" element value not 592 supported by the server. 594 It is possible for an "RSCALE" value to be present in calendar data 595 on the server being accessed by a client that does not support an 596 "RSCALE" element or its specified value. It is expected that 597 existing clients, unaware of "RSCALE", will fail gracefully by 598 ignoring the calendar component, whilst still processing other 599 calendar data on the server. 601 9.1. CALDAV:supported-rscale-set Property 603 Name: supported-rscale-set 605 Namespace: urn:ietf:params:xml:ns:caldav 607 Purpose: Enumerates the set of supported iCalendar "RSCALE" element 608 values supported by the server. 610 Protected: This property MUST be protected and SHOULD NOT be 611 returned by a PROPFIND allprop request (as defined in Section 14.2 612 of [RFC4918]). 614 Description: See above. 616 Definition: 618 619 620 623 Example: 625 627 GREGORIAN 628 CHINESE 629 ISLAMIC-CIVIL 630 HEBREW 631 ETHIOPIC 632 634 10. Security Considerations 636 This specification does not introduce any addition security concerns 637 beyond those described in [RFC5545], [RFC5546], and [RFC4791]. 639 11. IANA Considerations 641 This document requires no IANA actions. 643 12. Acknowledgments 645 Thanks to the following for feedback: Mark Davis, Mike Douglass, 646 Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, 647 Jonathan Lennox, Ken Murchison, Arnaud Quillaud, Dave Thewlis, and 648 Umaoka Yoshito. 650 This specification originated from work at the Calendaring and 651 Scheduling Consortium, which has helped with the development and 652 testing of implementations. 654 13. References 656 13.1. Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 662 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 663 March 2007. 665 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 666 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 668 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 669 Specifications: ABNF", STD 68, RFC 5234, January 2008. 671 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 672 Core Object Specification (iCalendar)", RFC 5545, 673 September 2009. 675 [RFC5546] Daboo, C., "iCalendar Transport-Independent 676 Interoperability Protocol (iTIP)", RFC 5546, December 677 2009. 679 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 680 Format for iCalendar", RFC 6321, August 2011. 682 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 683 Format for iCalendar", RFC 7265, May 2014. 685 [UNICODE.CLDR] 686 "CLDR calendar.xml Data", Unicode Consortium CLDR, 687 . 690 13.2. Informative References 692 [ISO.8601.2004] 693 International Organization for Standardization, "Data 694 elements and interchange formats - Information interchange 695 - Representation of dates and times", ISO Standard 8601, 696 2004. 698 [UNICODE.ICU] 699 "International Components for Unicode", Unicode Consortium 700 ICU, April 2014, . 702 Appendix A. Change History (To be removed by RFC Editor before 703 publication) 705 Changes in draft-ietf-calext-rscale-03: 707 1. Reworded abstract. 709 2. Added list of changes to other specs in Section 1. 711 3. Clarified behavior wrt VTIMEZONE in Section 1. 713 Changes in draft-ietf-calext-rscale-02: 715 1. Added xCal and jCal changes sections and relax NG schema 716 appendix. 718 2. Added ICU reference at the end of Section 1. 720 Changes in draft-ietf-calext-rscale-01: 722 1. Editorial changes/fixes per document shepherd review. 724 2. Switched CLDR reference to "tags/latest". 726 Changes in draft-ietf-calext-rscale-00: 728 1. Updated some references. 730 2. Editorial changes/fixes. 732 Changes in draft-daboo-icalendar-rscale-04: 734 1. Always use "L" suffix for leap months, even for Hebrew calendar. 736 2. Remove negative month numbers to go back to base 5545 definition. 738 3. Added example for Gregorian leap day with skip. 740 4. Clarify that RSCALE names are case insensitive, but with upper 741 case preferred. 743 5. Clarify that BYSETPOS processing is done after SKIP. 745 6. Remove Islamic example in favor of Ethiopic example which shows a 746 13th month. 748 Changes in draft-daboo-icalendar-rscale-03: 750 1. Added details about handling RSCALE in iTIP. 752 2. Added details about handling RSCALE in CalDAV. 754 3. Fixed examples to use ICU Chinese epoch and added text describing 755 why that is not an issue for actual recurrence calculations. 757 Changes in draft-daboo-icalendar-rscale-02: 759 1. Fixed some incorrect dates in examples. 761 2. Clarified use of CLDR and alias, deprecated, preferred 762 attributes. 764 3. Clarified when SKIP processing occurs. 766 Changes in draft-daboo-icalendar-rscale-01: 768 1. Removed requirement that RSCALE be the first item in an RRULE. 770 2. Added BYLEAPMONTH element and removed BYMONTH "L" suffix. 772 3. Removed Open Issues. 774 Appendix B. xCal RELAX NG schema update 776 The following changes are made to the RELAX NG schema defined in 777 Appendix A of [RFC6321]. 779 # 3.3.10 RECUR 780 # This extension adds type-rscale and type-skip, 781 # and modifies type-bymonth 783 value-recur = element recur { 784 type-rscale?, 785 type-freq, 786 (type-until | type-count)?, 787 element interval { 788 xsd:positiveInteger 789 }?, 790 type-bysecond*, 791 type-byminute*, 792 type-byhour*, 793 type-byday*, 794 type-bymonthday*, 795 type-byyearday*, 796 type-byweekno*, 797 type-bymonth*, 798 type-bysetpos*, 799 element wkst { type-weekday }?, 800 type-skip? 801 } 803 type-rscale = element rscale { 804 xsd:string 805 } 807 type-bymonth = element bymonth { 808 xsd:positiveInteger | 809 xsd:string 810 } 812 type-skip = element skip { 813 "YES" | 814 "BACKWARD" | 815 "FORWARD" 816 } 818 Authors' Addresses 819 Cyrus Daboo 820 Apple Inc. 821 1 Infinite Loop 822 Cupertino, CA 95014 823 USA 825 Email: cyrus@daboo.name 826 URI: http://www.apple.com/ 828 Gregory Yakushev 829 Google Inc. 830 Brandschenkestrasse 100 831 8002 Zurich 832 Switzerland 834 Email: yakushev@google.com 835 URI: http://www.google.com/