idnits 2.17.1 draft-daboo-icalendar-rscale-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to mention this, which it should. 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 (April 26, 2013) is 3989 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 (if approved) G. Yakushev 5 Intended status: Standards Track Google Inc. 6 Expires: October 28, 2013 April 26, 2013 8 Non-Gregorian Recurrence Rules in iCalendar 9 draft-daboo-icalendar-rscale-00 11 Abstract 13 This document defines how non-Gregorian recurrence rules can be 14 specified in iCalendar data. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 28, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 53 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 6 55 5.1. Handling Leap Months . . . . . . . . . . . . . . . . . . . 7 56 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Registering Calendar Systems . . . . . . . . . . . . . . . . . 9 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 61 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 The iCalendar [RFC5545] data format is in widespread use to represent 67 calendar data. iCalendar represents dates and times using the 68 Gregorian calendar system only. It does provide a way to use non- 69 Gregorian calendar systems via a "CALSCALE" property, however this 70 has never been formally used. However, there is a need to support at 71 least non-Gregorian recurrence patterns to cover anniversaries, and 72 many local, religious, or civil holidays based on non-Gregorian 73 dates. 75 There are several disadvantages to using the existing "CALSCALE" 76 property in iCalendar for implementing non-Gregorian calendars: 78 1. The "CALSCALE" property exists in the top-level "VCALENDAR" 79 objects and thus applies to all components within that object. 80 In today's multi-cultural society, that restricts the ability to 81 mix events from different calendar systems within the same 82 iCalendar object. e.g., it would prevent having both the 83 Gregorian New Year and Chinese New Year in the same iCalendar 84 object. 86 2. Many countries observe daylight savings time, encoded in 87 iCalendar using the "VTIMEZONE" component. Timezone and daylight 88 saving time rules are always specified via Gregorian calendar 89 based recurrence rules (e.g., "the 3rd Sunday in March"). This 90 is problematic for non-Gregorian uses of "CALSCALE" which would 91 by default also apply to the dates and rules used in the 92 "VTIMEZONE" components in the corresponding iCalendar object. 94 This specification solves these issues by allowing the "CALSCALE" to 95 remain set to Gregorian, but re-defining the recurrence rule property 96 "RRULE" to accept new items including one that allows non-Gregorian 97 calendar systems to be used. With this, all the date, time and 98 period values in the iCalendar object would remain specified using 99 the Gregorian calendar system, but repeating patterns in other 100 calendar systems could be defined. It is then up to calendar user 101 agents and servers to map between Gregorian and non-Gregorian 102 calendar systems in order to expand out recurrence instances. 104 This specification does not itself define calendar systems, rather it 105 utilizes the registry defined by the Unicode Consortium 106 (http://unicode.org) in their CLDR (Common Locale Data Repository) 107 project. 109 2. Open Issues 111 Use "RRULE" or a new property (e.g., "RPATTERN") - depends on how 112 well existing clients cope with the extended "RRULE" behavior 113 currently defined here. 115 3. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 [RFC2119]. 122 The notation used in this memo is the ABNF notation of [RFC5234] as 123 used by iCalendar [RFC5545]. Any syntax elements shown below that 124 are not explicitly defined in this specification come from iCalendar 125 [RFC5545]. 127 When a Gregorian calendar date value is shown in text, it will use 128 the format "YYYYMMHH", where "YYYY" is the 4-digit year, "MM" the 129 2-digit month, and "DD" the 2-digit day (this is the same format used 130 in iCalendar [RFC5545]). The Chinese calendar will be used as an 131 example of a non-Gregorian calendar for illustrative purposes. When 132 a Chinese calendar date value is shown in text, it will use the 133 format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with 134 a "{C}" prefix, and an optional "L" character after the month element 135 to indicate a leap month. Similarly, {I} and {H} are used in other 136 examples as prefixes for Islamic and Hebrew dates, respectively. 138 4. Overview 140 In the Gregorian calendar system, each year is composed of a fixed 141 number of months (12), with each month having a fixed number of days 142 (between 30 and 31), except for the second month (February) which 143 contains either 28 days, or 29 days (in a leap year). Weeks are 144 composed of 7 days, with day names Monday, Tuesday, Wednesday, 145 Thursday, Friday, Saturday and Sunday. Years can have either 365 or 146 366 days (the later in a leap year). The number of whole weeks in a 147 year is 52. 149 In iCalendar, the "RECUR" value type defines various fields used to 150 express a recurrence pattern, and those fields are given limits based 151 on those of the Gregorian calendar system. Since other calendar 152 systems can have different limits and other behaviors that need to be 153 accounted for, the maximum values for the elements in the "RECUR" 154 value are not covered by this specification. 156 To generate a set of recurring instances in a non-Gregorian calendar 157 system, the following procedure is used: 159 1. iCalendar data continues to use the "GREGORIAN" calendar system, 160 so all "DATE", "DATE-TIME" and "PERIOD" values continue to use 161 the Gregorian format and limits. 163 2. The "RRULE" property is extended to include an "RSCALE" element 164 in its value that specifies the calendar system to use for the 165 recurrence pattern. The existing elements of the "RRULE" value 166 type are used, but modified to support different upper limits, 167 based on the "RSCALE" value, as well as a modification to month 168 numbers to allow a leap month to be specified. Existing 169 requirements for the use of "RRULE" all still apply (e.g., the 170 "RRULE" has to match the "DTSTART" value of the master instance). 171 Other recurrence properties such as "RECURRENCE-ID", "RDATE" and 172 "EXDATE" continue to use the Gregorian date format as "CALSCALE" 173 is unchanged. 175 When generating instances, the following procedure might be used: 177 1. Convert the "DTSTART" property value of the master recurring 178 component into the date and time components for the calendar 179 system specified by the "RSCALE" element in the "RRULE" value. 180 This provides the "seed" value for generating subsequent 181 recurrence instances. 183 2. Iteratively generate instances using the "RRULE" value applied to 184 the year, month, and day components of the date in the new 185 calendar system. 187 3. For each generated instance, convert the date values back from 188 the non-Gregorian form into Gregorian and use those values for 189 other properties such as "RECURRENCE-ID". 191 Consider the following example for an event representing the Chinese 192 New Year: 194 DTSTART;VALUE=DATE:20130210 195 RRULE:RSCALE=CHINESE;FREQ=YEARLY 196 SUMMARY:Chinese New Year 198 To generate instances, first the "DTSTART" value "20130210" is 199 converted into the Chinese calendar system giving "{C}47110101". 200 Next, the year component is incremented by one to give "{C}47120101", 201 and that is then converted back into Gregorian as "20140131". 202 Additional instances are generated by iteratively increasing the year 203 component in the Chinese date value and converting back to Gregorian. 205 This specification makes use of calendar algorithms defined by the 206 Unicode Consortium [TBD - reference]. The definition of different 207 calendar scales is defined by Unicode, as per Section 6. 209 5. Extended RRULE Property 211 This specification extends the existing "RRULE" iCalendar property 212 value to include a new "RSCALE" element that can be used to indicate 213 the calendar system used for generating the recurrence pattern. The 214 "RSCALE" element MUST be included as the first element in the "RRULE" 215 value if present. 217 When "RSCALE" is present, the other changes to "RRULE" are: 219 1. Elements that include numeric values (e.g., "BYYEARDAY") have 220 numeric ranges defined by the "RSCALE" value (i.e., in some 221 calendar systems there might be more than 366 days in a year). 223 2. Month numbers can include an "L" suffix to indicate that the 224 specified month is a leap month in the corresponding calendar 225 system. 227 3. Month numbers can be specified using a negative offset (i.e., 228 "-1" represents the last month of the year). 230 4. A "SKIP" element is added to define how "missing" instances are 231 handled. e.g., if a yearly recurring event starts in a leap 232 month, the "SKIP" element determines whether instances in non- 233 leap years are ignored ("SKIP" set to "YES"), appear in the 234 preceding regular month ("SKIP" set to "BACKWARD" - the default 235 when "RSCALE" is present), or appear in the following regular 236 month ("SKIP" set to "FORWARD"). 238 The syntax for the "RECUR" value is modified in the following 239 fashion: 241 recur-rule-part /= ("RSCALE" "=" rscale) 242 / ("SKIP" "=" skip) 243 ; 244 ; RSCALE MUST be specified before all other 245 ; elements in the "RECUR" value. 247 rscale = (iana-token ; A CLDR-registered calendar system 248 ; name (see Section 6). 249 / x-name) ; A non-standard, experimental 250 ; calendar system name. 252 skip = ("YES" / "BACKWARD" / "FORWARD") 253 ; When "RSCALE" is not present the default 254 ; is "YES". When "RSCALE" is present the default 255 ; is "BACKWARD". 257 monthnum = [plus / minus] 1*2DIGIT ["L"] 258 ; Existing element modified to include a positive 259 ; or negative offset capability, as well as a leap 260 ; month indicator suffix. 262 5.1. Handling Leap Months 264 Leap months can occur in different calendar systems. For most of 265 those, the suffix "L" is added to the "RRULE" month number component 266 to indicate a leap month. In some cases the month precedes the 267 regular month with the same number, in other cases it follows. The 268 one exception to this rule is the Hebrew calendar, where we follow 269 the definition from Unicode [TBD - REF]. In that case months are 270 number 1 through 13, with month 6 being the leap month. Thus in non- 271 leap years, month 6 is skipped. 273 5.2. Examples 275 5.2.1. Chinese New Year 277 Consider the following set of iCalendar properties: 279 DTSTART;VALUE=DATE:20130210 280 RRULE:RSCALE=CHINESE;FREQ=YEARLY 281 SUMMARY:Chinese New Year 283 These define a recurring event for the Chinese New Year, with the 284 first instance the one in Gregorian year 2013. 286 The Chinese date corresponding to the first instance is {C}47110101. 287 The table below shows the initial instance, and the next four, each 288 of which is determined by adding the appropriate amount to the year 289 component of the Chinese date. Also shown is the conversion back to 290 the Gregorian date: 292 +--------------+------------------------------------------------+ 293 | Chinese Date | Gregorian Date | 294 +--------------+------------------------------------------------+ 295 | {C}47110101 | 20130210 - DTSTART specified in iCalendar data | 296 | {C}47120101 | 20140131 | 297 | {C}47130101 | 20150120 | 298 | {C}47140101 | 20160208 | 299 | {C}47150101 | 20170128 | 300 +--------------+------------------------------------------------+ 302 5.2.2. Islamic Start of Ramadan 304 Consider the following set of iCalendar properties: 306 DTSTART;VALUE=DATE:20130709 307 RRULE:RSCALE=ISLAMIC;FREQ=YEARLY;BYMONTH=9 308 SUMMARY:Start of Ramadan 310 These define a recurring event for the start of the Islamic month of 311 Ramadan, with the first instance the one in Gregorian year 2013. 313 The Islamic date corresponding to the first instance is {I}14340901. 314 The table below shows the initial instance, and the next four, each 315 of which is determined by adding the appropriate amount to the year 316 component of the Islamic date. Also shown is the conversion back to 317 the Gregorian date: 319 +--------------+------------------------------------------------+ 320 | Islamic Date | Gregorian Date | 321 +--------------+------------------------------------------------+ 322 | {I}14340901 | 20130709 - DTSTART specified in iCalendar data | 323 | {I}14350901 | 20140628 | 324 | {I}14360901 | 20150618 | 325 | {I}14370901 | 20160606 | 326 | {I}14380901 | 20170527 | 327 +--------------+------------------------------------------------+ 329 Note that in this example, the value of the "BYMONTH" component in 330 the "RRULE" matches the Islamic month value and not the Gregorian 331 month. 333 5.2.3. Hebrew anniversary starting in a leap month 335 Consider the following set of iCalendar properties: 337 DTSTART;VALUE=DATE:20140208 338 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6;BYMONTHDAY=8;SKIP=FORWARD 339 SUMMARY:Anniversary 341 These define a recurring event for the 8th day of the Hebrew month of 342 Adar I, with the first instance the one in Gregorian year 2014. 344 The Hebrew date corresponding to the first instance is {H}57740608, 345 note that month 6 is a leap month in year 5774. The table below 346 shows the initial instance, and the next four, each of which is 347 determined by adding the appropriate amount to the year component of 348 the Hebrew date, taking into account that only year 5776 is a leap 349 year. Thus in other years the Hebrew month component is adjusted 350 forward to month 7. Also shown is the conversion back to the 351 Gregorian date: 353 +-------------+------------------------------------------------+ 354 | Hebrew Date | Gregorian Date | 355 +-------------+------------------------------------------------+ 356 | {H}57740608 | 20140208 - DTSTART specified in iCalendar data | 357 | {H}57750708 | 20150227 | 358 | {H}57760608 | 20160217 | 359 | {H}57770708 | 20170306 | 360 | {H}57780708 | 20180223 | 361 +-------------+------------------------------------------------+ 363 6. Registering Calendar Systems 365 This specification uses the Unicode Consortium's registry of calendar 366 systems to define valid values for the "RSCALE" element of an "RRULE" 367 [TBD - Unicode BCP47 - 368 http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml]. Note 369 that the underscore character "_" is never used in CLDR-based 370 calendar system names. New values can be added to this registry 371 following Unicode Consortium rules. It is expected that many 372 implementations of non-Gregorian calendars will use software 373 libraries provided by Unicode (ICU), and hence it makes sense to re- 374 use their registry rather than creating a new one. For consistency, 375 when used, the "RSCALE" values SHOULD be uppercased. 377 7. Security Considerations 379 This specification does not introduce any addition security concerns 380 beyond those described in [RFC5545]. 382 8. IANA Considerations 384 This specification does not define any new IANA registries or values. 386 9. Acknowledgments 388 Thanks to the following for feedback: Mark Davis, Mike Douglass, 389 Peter Edberg, Arnaud Quillaud, and Dave Thewlis. This specification 390 came about via discussions at the Calendaring and Scheduling 391 Consortium. 393 10. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 399 Specifications: ABNF", STD 68, RFC 5234, January 2008. 401 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 402 Core Object Specification (iCalendar)", RFC 5545, 403 September 2009. 405 Authors' Addresses 407 Cyrus Daboo 408 Apple Inc. 409 1 Infinite Loop 410 Cupertino, CA 95014 411 USA 413 Email: cyrus@daboo.name 414 URI: http://www.apple.com/ 415 Gregory Yakushev 416 Google Inc. 417 Brandschenkestrasse 100 418 8002 Zurich, 419 Switzerland 421 Email: yakushev@google.com 422 URI: http://www.google.com/