idnits 2.17.1 draft-ietf-calext-rscale-02.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 mention this, which it should. -- The draft header indicates that this document updates RFC5546, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7265, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4791, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4791, updated by this document, for RFC5378 checks: 2004-06-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 10, 2014) is 3425 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 (==), 8 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: 4791, 5545, 5546, 6321, 7265 G. Yakushev 5 (if approved) Google Inc. 6 Intended status: Standards Track December 10, 2014 7 Expires: June 13, 2015 9 Non-Gregorian Recurrence Rules in iCalendar 10 draft-ietf-calext-rscale-02 12 Abstract 14 This document defines how non-Gregorian recurrence rules can be 15 specified and used in iCalendar data, and with CalDAV servers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 13, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 5 55 4.1. Handling Leap Months . . . . . . . . . . . . . . . . . . 6 56 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Registering Calendar Systems . . . . . . . . . . . . . . . . 9 58 6. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 10 59 7. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . . 11 60 8. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 12 62 9.1. CALDAV:supported-rscale-set Property . . . . . . . . . . 13 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 68 13.2. Informative References . . . . . . . . . . . . . . . . . 15 69 Appendix A. Change History (To be removed by RFC Editor before 70 publication) . . . . . . . . . . . . . . . . . . . . 15 71 Appendix B. xCal RELAX NG schema update . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 The iCalendar [RFC5545] data format is in widespread use to represent 77 calendar data. iCalendar represents dates and times using the 78 Gregorian calendar system only. It does provide a way to use non- 79 Gregorian calendar systems via a "CALSCALE" property, but this has 80 never been used. However, there is a need to support at least non- 81 Gregorian recurrence patterns to cover anniversaries, and many local, 82 religious, or civil holidays based on non-Gregorian dates. 84 There are several disadvantages to using the existing "CALSCALE" 85 property in iCalendar for implementing non-Gregorian calendars: 87 1. The "CALSCALE" property exists in the top-level "VCALENDAR" 88 objects and thus applies to all components within that object. 89 In today's multi-cultural society, that restricts the ability to 90 mix events from different calendar systems within the same 91 iCalendar object. e.g., it would prevent having both the 92 Gregorian New Year and Chinese New Year in the same iCalendar 93 object. 95 2. Many countries observe daylight savings time, encoded in 96 iCalendar using the "VTIMEZONE" component. Time zone and 97 daylight saving time rules are always specified via Gregorian 98 calendar based recurrence rules (e.g., "the 3rd Sunday in 99 March"). This is problematic for non-Gregorian uses of 100 "CALSCALE" which would by default also apply to the dates and 101 rules used in the "VTIMEZONE" components in the corresponding 102 iCalendar object. 104 This specification solves these issues by allowing the "CALSCALE" to 105 remain set to Gregorian, but re-defining the recurrence rule property 106 "RRULE" to accept new items including one that allows non-Gregorian 107 calendar systems to be used. With this, all the date, time and 108 period values in the iCalendar object would remain specified using 109 the Gregorian calendar system, but repeating patterns in other 110 calendar systems could be defined. It is then up to calendar user 111 agents and servers to map between Gregorian and non-Gregorian 112 calendar systems in order to expand out recurrence instances. 114 This specification does not itself define calendar systems, rather it 115 utilizes the calendar system registry defined by the Unicode 116 Consortium in their CLDR (Common Locale Data Repository) project 117 [UNICODE.CLDR], as implemented in the Unicode (ICU) Library 118 [UNICODE.ICU]. 120 2. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 [RFC2119]. 127 The notation used in this memo is the ABNF notation of [RFC5234] as 128 used by iCalendar [RFC5545]. Any syntax elements shown below that 129 are not explicitly defined in this specification come from iCalendar 130 [RFC5545], iTIP [RFC5546], and CalDAV [RFC4791]. 132 When XML element types in the namespaces "DAV:" and 133 "urn:ietf:params:xml:ns:caldav" are referenced in this document 134 outside of the context of an XML fragment, the string "DAV:" and 135 "CALDAV:" will be prefixed to the element type names respectively. 137 When a Gregorian calendar date value is shown in text, it will use 138 the format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 139 2-digit month, and "DD" the 2-digit day (this is the same format used 140 in iCalendar [RFC5545]). The Chinese calendar will be used as an 141 example of a non-Gregorian calendar for illustrative purposes. When 142 a Chinese calendar date value is shown in text, it will use the 143 format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with 144 a "{C}" prefix, and an optional "L" character after the month element 145 to indicate a leap month. Similarly, {E} and {H} are used in other 146 examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates, 147 respectively. Note that the Chinese calendar years shown in the 148 examples are based on the Unicode (ICU) [UNICODE.ICU] library's 149 Chinese calendar epoch. Whilst there are several different Chinese 150 calendar epochs in common use, the choice of one over another does 151 not impact the actual calculation of the Gregorian equivalent dates, 152 provided conversion is always done using the same epoch. 154 3. Overview 156 In the Gregorian calendar system, each year is composed of a fixed 157 number of months (12), with each month having a fixed number of days 158 (between 30 and 31), except for the second month (February) which 159 contains either 28 days, or 29 days (in a leap year). Weeks are 160 composed of 7 days, with day names Monday, Tuesday, Wednesday, 161 Thursday, Friday, Saturday and Sunday. Years can have either 365 or 162 366 days (the latter in a leap year). The number of whole weeks in a 163 year is 52 (though the [ISO.8601.2004] week numbering scheme used by 164 iCalendar [RFC5545] can have a numeric count up to 53). 166 In iCalendar, the "RECUR" value type defines various fields used to 167 express a recurrence pattern, and those fields are given limits based 168 on those of the Gregorian calendar system. Since other calendar 169 systems can have different limits and other behaviors that need to be 170 accounted for, the maximum values for the elements in the "RECUR" 171 value are not covered by this specification. 173 To generate a set of recurring instances in a non-Gregorian calendar 174 system, the following principles are used: 176 1. iCalendar data continues to use the "GREGORIAN" calendar system, 177 so all "DATE", "DATE-TIME" and "PERIOD" values continue to use 178 the Gregorian format and limits. 180 2. The "RRULE" property is extended to include an "RSCALE" element 181 in its value that specifies the calendar system to use for the 182 recurrence pattern. The existing elements of the "RRULE" value 183 type are used, but modified to support different upper limits, 184 based on the "RSCALE" value, as well as a modification to month 185 numbers to allow a leap month to be specified. Existing 186 requirements for the use of "RRULE" all still apply (e.g., the 187 "RRULE" has to match the "DTSTART" value of the master instance). 188 Other recurrence properties such as "RECURRENCE-ID", "RDATE" and 189 "EXDATE" continue to use the Gregorian date format as "CALSCALE" 190 is unchanged. 192 When generating instances, the following procedure might be used: 194 1. Convert the "DTSTART" property value of the master recurring 195 component into the date and time components for the calendar 196 system specified by the "RSCALE" element in the "RRULE" value. 197 This provides the "seed" value for generating subsequent 198 recurrence instances. 200 2. Iteratively generate instances using the "RRULE" value applied to 201 the year, month, and day components of the date in the new 202 calendar system. 204 3. For each generated instance, convert the date values back from 205 the non-Gregorian form into Gregorian and use those values for 206 other properties such as "RECURRENCE-ID". 208 Consider the following example for an event representing the Chinese 209 New Year: 211 DTSTART;VALUE=DATE:20130210 212 RRULE:RSCALE=CHINESE;FREQ=YEARLY 213 SUMMARY:Chinese New Year 215 To generate instances, first the "DTSTART" value "20130210" is 216 converted into the Chinese calendar system giving "{C}46500101". 217 Next, the year component is incremented by one to give "{C}46510101", 218 and that is then converted back into Gregorian as "20140131". 219 Additional instances are generated by iteratively increasing the year 220 component in the Chinese date value and converting back to Gregorian. 222 4. Extended RRULE Property 224 This specification extends the existing "RRULE" iCalendar property 225 value to include a new "RSCALE" element that can be used to indicate 226 the calendar system used for generating the recurrence pattern. 228 When "RSCALE" is present, the other changes to "RRULE" are: 230 1. Elements that include numeric values (e.g., "BYYEARDAY") have 231 numeric ranges defined by the "RSCALE" value (i.e., in some 232 calendar systems there might be more than 366 days in a year). 234 2. Month numbers can include an "L" suffix to indicate that the 235 specified month is a leap month in the corresponding calendar 236 system. 238 3. A "SKIP" element is added to define how "missing" instances are 239 handled. e.g., if a yearly recurring event starts in a leap 240 month, the "SKIP" element determines whether instances in non- 241 leap years are ignored ("SKIP" set to "YES"), appear in the 242 preceding regular month ("SKIP" set to "BACKWARD" - the default 243 when "RSCALE" is present), or appear in the following regular 244 month ("SKIP" set to "FORWARD"). This applies for both leap days 245 and leap months. The "SKIP" processing is done after all rule 246 elements, other than "BYSETPOS", "COUNT" and "UNTIL", have been 247 processed. 249 The syntax for the "RECUR" value is modified in the following 250 fashion: 252 recur-rule-part /= ("RSCALE" "=" rscale) 253 / ("SKIP" "=" skip) 255 rscale = (iana-token ; A CLDR-registered calendar system 256 ; name. 257 / x-name) ; A non-standard, experimental 258 ; calendar system name. 259 ; Names are case-insensitive, 260 ; but uppercase values are preferred. 262 skip = ("YES" / "BACKWARD" / "FORWARD") 263 ; Optional, with default value "BACKWARD", 264 ; and MUST only be present if "RSCALE" is present. 266 monthnum = 1*2DIGIT ["L"] 267 ; Existing element modified to include a leap 268 ; month indicator suffix. 270 4.1. Handling Leap Months 272 Leap months can occur in different calendar systems. For such 273 calendar systems the following rules are applied for "identifying" 274 months: 276 1. Numeric values 1 through N are used to identify regular, non- 277 leap, months (where N is the number of months in a regular, non- 278 leap, year). 280 2. The suffix "L" is added to the regular month number to indicate a 281 leap month which follows the regular month. e.g., "5L" is a leap 282 month that follows the 5th regular month in the year. 284 Care has to be taken when mapping the month identifiers used here 285 with those of any underlying calendar system library being used. In 286 particular, the Hebrew calendar system used by Unicode (ICU) 287 [UNICODE.ICU] uses a month number scheme of 1 through 13, with month 288 6 being the leap month, and in non-leap years, month 6 is skipped. 290 In iCalendar, this would map to months 1 through 12 with "5L" as the 291 leap month. 293 4.2. Examples 295 4.2.1. Chinese New Year 297 Consider the following set of iCalendar properties: 299 DTSTART;VALUE=DATE:20130210 300 RRULE:RSCALE=CHINESE;FREQ=YEARLY 301 SUMMARY:Chinese New Year 303 These define a recurring event for the Chinese New Year, with the 304 first instance the one in Gregorian year 2013. 306 The Chinese date corresponding to the first instance is {C}46500101. 307 The table below shows the initial instance, and the next four, each 308 of which is determined by adding the appropriate amount to the year 309 component of the Chinese date. Also shown is the conversion back to 310 the Gregorian date: 312 +--------------+--------------------------+ 313 | Chinese Date | Gregorian Date | 314 +--------------+--------------------------+ 315 | {C}46500101 | 20130210 - DTSTART value | 316 | {C}46510101 | 20140131 | 317 | {C}46520101 | 20150219 | 318 | {C}46530101 | 20160208 | 319 | {C}46540101 | 20170128 | 320 +--------------+--------------------------+ 322 4.2.2. Ethiopic 13th Month 324 Consider the following set of iCalendar properties: 326 DTSTART;VALUE=DATE:201300906 327 RRULE:RSCALE=ETHIOPIC;FREQ=YEARLY;BYMONTH=13 328 SUMMARY:First day of 13th month 330 These define a recurring event for the first day of the 13th month, 331 with the first instance the one in Gregorian year 2013. 333 The Ethiopic date corresponding to the first instance is {E}20051301. 334 The table below shows the initial instance, and the next four, each 335 of which is determined by adding the appropriate amount to the year 336 component of the Ethiopic date. Also shown is the conversion back to 337 the Gregorian date: 339 +---------------+--------------------------+ 340 | Ethiopic Date | Gregorian Date | 341 +---------------+--------------------------+ 342 | {E}20051301 | 20130906 - DTSTART value | 343 | {E}20061301 | 20140906 | 344 | {E}20071301 | 20150906 | 345 | {E}20081301 | 20160906 | 346 | {E}20091301 | 20170906 | 347 +---------------+--------------------------+ 349 Note that in this example, the value of the "BYMONTH" component in 350 the "RRULE" matches the Ethiopic month value and not the Gregorian 351 month. 353 4.2.3. Hebrew anniversary starting in a leap month 355 Consider the following set of iCalendar properties: 357 DTSTART;VALUE=DATE:20140208 358 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD 359 SUMMARY:Anniversary 361 These define a recurring event for the 8th day of the Hebrew month of 362 Adar I (the leap month identified by "5L"), with the first instance 363 the one in Gregorian year 2014. 365 The Hebrew date corresponding to the first instance is {H}577405L08, 366 which is a leap month in year 5774. The table below shows the 367 initial instance, and the next four, each of which is determined by 368 adding the appropriate amount to the year component of the Hebrew 369 date, taking into account that only year 5776 is a leap year. Thus 370 in other years the Hebrew month component is adjusted forward to 371 month 6. Also shown is the conversion back to the Gregorian date: 373 +--------------+--------------------------+ 374 | Hebrew Date | Gregorian Date | 375 +--------------+--------------------------+ 376 | {H}577405L08 | 20140208 - DTSTART value | 377 | {H}57750608 | 20150227 | 378 | {H}577605L08 | 20160217 | 379 | {H}57770608 | 20170306 | 380 | {H}57780608 | 20180223 | 381 +--------------+--------------------------+ 383 4.2.4. Gregorian leap day with SKIP 385 Consider the following set of iCalendar properties: 387 DTSTART;VALUE=DATE:20120229 388 RRULE:FREQ=YEARLY 389 SUMMARY:Anniversary 391 These define a recurring event for the 29th February, 2012 in the 392 standard iCalendar calendar scale - Gregorian. The standard 393 iCalendar behavior is that non-existent dates in a recurrence set are 394 ignored. Thus the properties above would only generate instances in 395 leap years (2016, 2020, etc), which is likely not what users expect. 396 The new "RSCALE" option defined by this specification provides the 397 "SKIP" element which can be used to "fill in" the missing instances 398 in an appropriate fashion. The set of iCalendar properties below do 399 that: 401 DTSTART;VALUE=DATE:20120229 402 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 403 SUMMARY:Anniversary 405 With these properties, the "missing" instances in non-leap year now 406 appear on the 1st March in those years: 408 +-------------------------------+----------------------------+ 409 | Instances (with SKIP=FORWARD) | Instances (without RSCALE) | 410 +-------------------------------+----------------------------+ 411 | 20120229 | 20120229 - DTSTART value | 412 | 20130301 | | 413 | 20140301 | | 414 | 20150301 | | 415 | 20160229 | 20160229 | 416 | 20170301 | | 417 +-------------------------------+----------------------------+ 419 5. Registering Calendar Systems 421 This specification uses the Unicode Consortium's registry of calendar 422 systems [UNICODE.CLDR] to define valid values for the "RSCALE" 423 element of an "RRULE". Note that the underscore character "_" is 424 never used in CLDR-based calendar system names. New values can be 425 added to this registry following Unicode Consortium rules. It is 426 expected that many implementations of non-Gregorian calendars will 427 use software libraries provided by Unicode (ICU) [UNICODE.ICU], and 428 hence it makes sense to re-use their registry rather than creating a 429 new one. For consistency, when used, the "RSCALE" values SHOULD be 430 uppercased. 432 CLDR supports the use of "alias" values as alternative names for 433 specific calendar systems. These alias values MUST be treated as 434 valid "RSCALE" element values. 436 When using the CLDR data, calendar agents SHOULD take into account 437 the "deprecated" value and use the alternative "preferred" calendar 438 system. In particular, the "islamicc" calendar system is considered 439 deprecated in favor of the "islamic-civil" calendar system. 441 6. Use with iTIP 443 iTIP [RFC5546] defines how iCalendar data can be sent between 444 calendar user agents to schedule calendar components between calendar 445 users. It is often not possible to know the capabilities of a 446 calendar user agent to which an iTIP message is being sent, but iTIP 447 defines fallback behavior in such cases. 449 For calendar user agents that do not support the "RSCALE" element, 450 the following can occur when iTIP messages containing an "RSCALE" 451 element are received: 453 The receiving calendar user agent can reject the entire iTIP 454 message and return an iTIP reply with a "REQUEST-STATUS" property 455 set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]). 457 The receiving calendar user agent can fallback to a non-recurring 458 behavior for the calendar component (effectively ignoring the 459 "RRULE" property) and return an iTIP reply with a "REQUEST-STATUS" 460 property set to the "2.3", "2.5", "2.8", or "2.10" status codes 461 (as per Sections 3.6.3, 3.6.6, 3.6.9, or 3.6.11, respectively, of 462 [RFC5546]). 464 For calendar user agents that support the "RSCALE" element but do not 465 support the calendar system specified by the "RSCALE" element value, 466 the following can occur: 468 the iTIP message SHOULD be rejected, returning a "REQUEST-STATUS" 469 property set to the "3.1" status code (as per Section 3.6.14 of 470 [RFC5546]). 472 if the iTIP message is accepted and the calendar component treated 473 as non-recurring, an iTIP reply with a "REQUEST-STATUS" property 474 set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or 475 3.6.11, respectively, of [RFC5546]) SHOULD be returned. 477 7. Use with xCal 479 xCal [RFC6321] defines how iCalendar data is represented in XML. 480 This specification extends the XML element in Section 3.6.10 481 of [RFC6321] in the following manner: 483 1. A new XML element is defined as a child element of 484 . The content of this element MUST be a string whose 485 value is the "RSCALE" element value of the "RRULE", with case 486 preserved. 488 2. A new XML element is defined as a child element of 489 . The content of this element MUST be a string whose 490 value is the "SKIP" element value of the "RRULE", with case 491 preserved. 493 3. The "bymonth" XML element is redefined to support either numeric 494 or string values as its content (as per Section 4.1). 496 Extensions to the RELAX NG schema in Appendix A of [RFC6321] are 497 defined in Appendix B. 499 Example: the iCalendar "RRULE" property: 501 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 503 would be represented in XML as: 505 506 507 GREGORIAN 508 YEARLY 509 FORWARD 510 511 513 8. Use with jCal 515 jCal [RFC7265] defines how iCalendar data is represented in JSON. 516 This specification extends the "recur" JSON object defined in 517 Section 3.6.10 of [RFC7265] in the following manner: 519 1. A new "rscale" child member is defined. This MUST be a string 520 whose value is the "RSCALE" element value of the "RRULE", with 521 case preserved. 523 2. A new "skip" child member is defined. This MUST be a string 524 whose value is the "SKIP" element value of the "RRULE", with case 525 preserved. 527 3. The "bymonth" child member is redefined to support either numeric 528 or string values. If the "BYMONTH" element value is an integer, 529 then a numeric JSON value MUST be used. If the "BYMONTH" element 530 value is an integer with the "L" suffix (as per Section 4.1), 531 then a JSON string value MUST be used. 533 Example: the iCalendar "RRULE" property: 535 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD 537 would be represented in JSON as: 539 [ 540 "rrule", 541 {}, 542 "recur", 543 { 544 "rscale": "GREGORIAN", 545 "freq": "YEARLY", 546 "skip": "FORWARD" 547 } 548 ] 550 9. Use with CalDAV 552 The CalDAV [RFC4791] calendar access protocol allows clients and 553 servers to exchange iCalendar data. In addition, CalDAV clients are 554 able to query calendar data stored on the server, including time- 555 based queries. Since an "RSCALE" element value determines the time 556 ranges for recurring instances in a calendar component, CalDAV 557 servers need to support it to interoperate with clients also using 558 the "RSCALE" element. 560 A CalDAV server advertises a CALDAV:supported-rscale-set WebDAV 561 property on calendar home or calendar collections if it supports use 562 of "RSCALE" element as described in this specification. The server 563 can advertise a specific set of supported calendar systems by 564 including one or more CALDAV:supported-rscale XML elements within the 565 CALDAV:supported-rscale-set XML element. If no CALDAV:supported- 566 rscale XML elements are included in the WebDAV property, then clients 567 can try any calendar system value, but need to be prepared for a 568 failure when attempting to store the calendar data. 570 Clients MUST NOT attempt to store iCalendar data containing "RSCALE" 571 elements if the CALDAV:supported-rscale-set WebDAV property is not 572 advertised by the server. 574 The server SHOULD return an HTTP 403 response with a DAV:error 575 element containing a CALDAV:supported-rscale XML element, if a client 576 attempts to store iCalendar data with an "RSCALE" element value not 577 supported by the server. 579 It is possible for an "RSCALE" value to be present in calendar data 580 on the server being accessed by a client that does not support an 581 "RSCALE" element or its specified value. It is expected that 582 existing clients, unaware of "RSCALE", will fail gracefully by 583 ignoring the calendar component, whilst still processing other 584 calendar data on the server. 586 9.1. CALDAV:supported-rscale-set Property 588 Name: supported-rscale-set 590 Namespace: urn:ietf:params:xml:ns:caldav 592 Purpose: Enumerates the set of supported iCalendar "RSCALE" element 593 values supported by the server. 595 Protected: This property MUST be protected and SHOULD NOT be 596 returned by a PROPFIND allprop request (as defined in Section 14.2 597 of [RFC4918]). 599 Description: See above. 601 Definition: 603 604 605 608 Example: 610 612 GREGORIAN 613 CHINESE 614 ISLAMIC-CIVIL 615 HEBREW 616 ETHIOPIC 617 619 10. Security Considerations 621 This specification does not introduce any addition security concerns 622 beyond those described in [RFC5545], [RFC5546], and [RFC4791]. 624 11. IANA Considerations 626 This document requires no IANA actions. 628 12. Acknowledgments 630 Thanks to the following for feedback: Mark Davis, Mike Douglass, 631 Peter Edberg, Marten Gajda, Philipp Kewisch, Ken Murchison, Arnaud 632 Quillaud, Dave Thewlis, and Umaoka Yoshito. 634 This specification originated from work at the Calendaring and 635 Scheduling Consortium, which has helped with the development and 636 testing of implementations. 638 13. References 640 13.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 646 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 647 March 2007. 649 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 650 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 652 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 653 Specifications: ABNF", STD 68, RFC 5234, January 2008. 655 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 656 Core Object Specification (iCalendar)", RFC 5545, 657 September 2009. 659 [RFC5546] Daboo, C., "iCalendar Transport-Independent 660 Interoperability Protocol (iTIP)", RFC 5546, December 661 2009. 663 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 664 Format for iCalendar", RFC 6321, August 2011. 666 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 667 Format for iCalendar", RFC 7265, May 2014. 669 [UNICODE.CLDR] 670 "CLDR calendar.xml Data", Unicode Consortium CLDR, 671 . 674 13.2. Informative References 676 [ISO.8601.2004] 677 International Organization for Standardization, "Data 678 elements and interchange formats - Information interchange 679 - Representation of dates and times", ISO Standard 8601, 680 2004. 682 [UNICODE.ICU] 683 "International Components for Unicode", Unicode Consortium 684 ICU, April 2014, . 686 Appendix A. Change History (To be removed by RFC Editor before 687 publication) 689 Changes in draft-ietf-calext-rscale-02: 691 1. Added xCal and jCal changes sections and relax NG schema 692 appendix. 694 2. Added ICU reference at the end of Section 1. 696 Changes in draft-ietf-calext-rscale-01: 698 1. Editorial changes/fixes per document shepherd review. 700 2. Switched CLDR reference to "tags/latest". 702 Changes in draft-ietf-calext-rscale-00: 704 1. Updated some references. 706 2. Editorial changes/fixes. 708 Changes in draft-daboo-icalendar-rscale-04: 710 1. Always use "L" suffix for leap months, even for Hebrew calendar. 712 2. Remove negative month numbers to go back to base 5545 definition. 714 3. Added example for Gregorian leap day with skip. 716 4. Clarify that RSCALE names are case insensitive, but with upper 717 case preferred. 719 5. Clarify that BYSETPOS processing is done after SKIP. 721 6. Remove Islamic example in favor of Ethiopic example which shows a 722 13th month. 724 Changes in draft-daboo-icalendar-rscale-03: 726 1. Added details about handling RSCALE in iTIP. 728 2. Added details about handling RSCALE in CalDAV. 730 3. Fixed examples to use ICU Chinese epoch and added text describing 731 why that is not an issue for actual recurrence calculations. 733 Changes in draft-daboo-icalendar-rscale-02: 735 1. Fixed some incorrect dates in examples. 737 2. Clarified use of CLDR and alias, deprecated, preferred 738 attributes. 740 3. Clarified when SKIP processing occurs. 742 Changes in draft-daboo-icalendar-rscale-01: 744 1. Removed requirement that RSCALE be the first item in an RRULE. 746 2. Added BYLEAPMONTH element and removed BYMONTH "L" suffix. 748 3. Removed Open Issues. 750 Appendix B. xCal RELAX NG schema update 752 The following changes are made to the RELAX NG schema defined in 753 Appendix A of [RFC6321]. 755 # 3.3.10 RECUR 756 # This extension adds type-rscale and type-skip, 757 # and modifies type-bymonth 759 value-recur = element recur { 760 type-rscale?, 761 type-freq, 762 (type-until | type-count)?, 763 element interval { 764 xsd:positiveInteger 765 }?, 766 type-bysecond*, 767 type-byminute*, 768 type-byhour*, 769 type-byday*, 770 type-bymonthday*, 771 type-byyearday*, 772 type-byweekno*, 773 type-bymonth*, 774 type-bysetpos*, 775 element wkst { type-weekday }?, 776 type-skip? 777 } 779 type-rscale = element rscale { 780 xsd:string 781 } 783 type-bymonth = element bymonth { 784 xsd:positiveInteger | 785 xsd:string 786 } 788 type-skip = element skip { 789 "YES" | 790 "BACKWARD" | 791 "FORWARD" 792 } 794 Authors' Addresses 795 Cyrus Daboo 796 Apple Inc. 797 1 Infinite Loop 798 Cupertino, CA 95014 799 USA 801 Email: cyrus@daboo.name 802 URI: http://www.apple.com/ 804 Gregory Yakushev 805 Google Inc. 806 Brandschenkestrasse 100 807 8002 Zurich 808 Switzerland 810 Email: yakushev@google.com 811 URI: http://www.google.com/