Network Working Group C. DabooInternet-Draft Apple Inc.Updates:5545,6321,7265 (if approved) G. YakushevIntended status: Standards Track Google Inc.Expires: July 11, 2015 January 7, 2015Non-Gregorian Recurrence Rules in iCalendardraft-ietf-calext-rscale-03Abstract This document defines extensions to iCalendar (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how CalDAV (RFC 4791) servers and clients can be extended to support these new recurrence rules.Status of This Memo This Internet-Draft is submitted in full conformance with the provisions ofBCP 78 andBCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is athttp://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 11, 2015.Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Daboo & Yakushev Expires July 11, 2015 [Page 1]
Internet-Draft iCalendar Property Extensions January 2015Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .22. Conventions Used in This Document . . . . . . . . . . . . . .33. Overview . . . . . . . . . . . . . . . . . . . . . . . . . .44. Extended RRULE Property . . . . . . . . . . . . . . . . . . .64.1. Handling Leap Months . . . . . . . . . . . . . . . . . .74.2. Examples . . . . . . . . . . . . . . . . . . . . . . . .75. Registering Calendar Systems . . . . . . . . . . . . . . . .106. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . .107. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . .118. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . .129. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . .139.1. CALDAV:supported-rscale-set Property . . . . . . . . . .1310. Security Considerations . . . . . . . . . . . . . . . . . . .1411. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1412. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .1413. References . . . . . . . . . . . . . . . . . . . . . . . . .1413.1. Normative References . . . . . . . . . . . . . . . . . .1413.2. Informative References . . . . . . . . . . . . . . . . .15Appendix A. Change History (To be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . .15Appendix B. xCal RELAX NG schema update . . . . . . . . . . . .17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .181. Introduction The iCalendar [RFC5545] data format is in widespread use to represent calendar data. iCalendar represents dates and times using the Gregorian calendar system only. It does provide a way to use non- Gregorian calendar systems via a "CALSCALE" property, but this has never been used. However, there is a need to support at least non- Gregorian recurrence patterns to cover anniversaries, and many local, religious, or civil holidays based on non-Gregorian dates. There are several disadvantages to using the existing "CALSCALE" property in iCalendar for implementing non-Gregorian calendars: 1. The "CALSCALE" property exists in the top-level "VCALENDAR" objects and thus applies to all components within that object. In today's multi-cultural society, that restricts the ability to mix events from different calendar systems within the same iCalendar object. e.g., it would prevent having both the Gregorian New Year and Chinese New Year in the same iCalendar object. 2. Time zone and daylight saving time rules are typically published using Gregorian calendar dates and rules (e.g., "the 3rd SundayDaboo & Yakushev Expires July 11, 2015 [Page 2]
Internet-Draft iCalendar Property Extensions January 2015 in March"), and thus converted to iCalendar "VTIMEZONE" components using Gregorian date-time values and recurrence rules. This results in the problem whereby one component (the "VTIMEZONE") is fixed to the Gregorian calendar system, and another (a "VEVENT") wants to use a different non-Gregorian calendar scale, and thus the single top-level "CALSCALE" property is again inadequate. This specification solves these issues by allowing the "CALSCALE" to remain set to Gregorian, but re-defining the "RRULE" recurrence rule property to accept new items including one that allows non-Gregorian calendar systems to be used. With this, all the date, time and period values in the iCalendar object would remain specified using the Gregorian calendar system, but repeating patterns in other calendar systems could be defined. It is then up to calendar user agents and servers to map between Gregorian and non-Gregorian calendar systems in order to expand out recurrence instances. The non-Gregorian recurrence rules can be used in any iCalendar component that allows the "RRULE" property to be specified, including "VTIMEZONE" components (to allow for possible future use of non- Gregorian rules in published daylight saving time data). This specification does not itself define calendar systems, rather it utilizes the calendar system registry defined by the Unicode Consortium in their CLDR (Common Locale Data Repository) project [UNICODE.CLDR], as implemented in the Unicode (ICU) Library [UNICODE.ICU]. This specification makes the following updates: It updates iCalendar [RFC5545], xCal [RFC6321], and jCal [RFC7265], to extend the "RRULE" property definition. It updates iTIP [RFC5546] to specify how the extended "RRULE" property should be handled in iTIP messages. It updates CalDAV [RFC4791] to specify how the extended "RRULE" property can be supported by CalDAV servers and clients.2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The notation used in this memo is the ABNF notation of [RFC5234] as used by iCalendar [RFC5545]. Any syntax elements shown below thatDaboo & Yakushev Expires July 11, 2015 [Page 3]
Internet-Draft iCalendar Property Extensions January 2015 are not explicitly defined in this specification come from iCalendar [RFC5545], iTIP [RFC5546], and CalDAV [RFC4791]. When XML element types in the namespaces "DAV:" and "urn:ietf:params:xml:ns:caldav" are referenced in this document outside of the context of an XML fragment, the string "DAV:" and "CALDAV:" will be prefixed to the element type names respectively. When a Gregorian calendar date value is shown in text, it will use the format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 2-digit month, and "DD" the 2-digit day (this is the same format used in iCalendar [RFC5545]). The Chinese calendar will be used as an example of a non-Gregorian calendar for illustrative purposes. When a Chinese calendar date value is shown in text, it will use the format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with a "{C}" prefix, and an optional "L" character after the month element to indicate a leap month. Similarly, {E} and {H} are used in other examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates, respectively. Note that the Chinese calendar years shown in the examples are based on the Unicode (ICU) [UNICODE.ICU] library's Chinese calendar epoch. Whilst there are several different Chinese calendar epochs in common use, the choice of one over another does not impact the actual calculation of the Gregorian equivalent dates, provided conversion is always done using the same epoch.3. Overview In the Gregorian calendar system, each year is composed of a fixed number of months (12), with each month having a fixed number of days (between 30 and 31), except for the second month (February) which contains either 28 days, or 29 days (in a leap year). Weeks are composed of 7 days, with day names Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday. Years can have either 365 or 366 days (the latter in a leap year). The number of whole weeks in a year is 52 (though the [ISO.8601.2004] week numbering scheme used by iCalendar [RFC5545] can have a numeric count up to 53). In iCalendar, the "RECUR" value type defines various fields used to express a recurrence pattern, and those fields are given limits based on those of the Gregorian calendar system. Since other calendar systems can have different limits and other behaviors that need to be accounted for, the maximum values for the elements in the "RECUR" value are not covered by this specification. To generate a set of recurring instances in a non-Gregorian calendar system, the following principles are used:Daboo & Yakushev Expires July 11, 2015 [Page 4]
Internet-Draft iCalendar Property Extensions January 2015 1. iCalendar data continues to use the "GREGORIAN" calendar system, so all "DATE", "DATE-TIME" and "PERIOD" values continue to use the Gregorian format and limits. 2. The "RRULE" property is extended to include an "RSCALE" element in its value that specifies the calendar system to use for the recurrence pattern. The existing elements of the "RRULE" value type are used, but modified to support different upper limits, based on the "RSCALE" value, as well as a modification to month numbers to allow a leap month to be specified. Existing requirements for the use of "RRULE" all still apply (e.g., the "RRULE" has to match the "DTSTART" value of the master instance). Other recurrence properties such as "RECURRENCE-ID", "RDATE" and "EXDATE" continue to use the Gregorian date format as "CALSCALE" is unchanged. When generating instances, the following procedure might be used: 1. Convert the "DTSTART" property value of the master recurring component into the date and time components for the calendar system specified by the "RSCALE" element in the "RRULE" value. This provides the "seed" value for generating subsequent recurrence instances. 2. Iteratively generate instances using the "RRULE" value applied to the year, month, and day components of the date in the new calendar system. 3. For each generated instance, convert the date values back from the non-Gregorian form into Gregorian and use those values for other properties such as "RECURRENCE-ID". Consider the following example for an event representing the Chinese New Year: DTSTART;VALUE=DATE:20130210 RRULE:RSCALE=CHINESE;FREQ=YEARLY SUMMARY:Chinese New Year To generate instances, first the "DTSTART" value "20130210" is converted into the Chinese calendar system giving "{C}46500101". Next, the year component is incremented by one to give "{C}46510101", and that is then converted back into Gregorian as "20140131". Additional instances are generated by iteratively increasing the year component in the Chinese date value and converting back to Gregorian.Daboo & Yakushev Expires July 11, 2015 [Page 5]
Internet-Draft iCalendar Property Extensions January 20154. Extended RRULE Property This specification extends the existing "RRULE" iCalendar property value to include a new "RSCALE" element that can be used to indicate the calendar system used for generating the recurrence pattern. When "RSCALE" is present, the other changes to "RRULE" are: 1. Elements that include numeric values (e.g., "BYYEARDAY") have numeric ranges defined by the "RSCALE" value (i.e., in some calendar systems there might be more than 366 days in a year). 2. Month numbers can include an "L" suffix to indicate that the specified month is a leap month in the corresponding calendar system. 3. A "SKIP" element is added to define how "missing" instances are handled. e.g., if a yearly recurring event starts in a leap month, the "SKIP" element determines whether instances in non- leap years are ignored ("SKIP" set to "YES"), appear in the preceding regular month ("SKIP" set to "BACKWARD" - the default when "RSCALE" is present), or appear in the following regular month ("SKIP" set to "FORWARD"). This applies for both leap days and leap months. The "SKIP" processing is done after all rule elements, other than "BYSETPOS", "COUNT" and "UNTIL", have been processed. The syntax for the "RECUR" value is modified in the following fashion: recur-rule-part /= ("RSCALE" "=" rscale) / ("SKIP" "=" skip) rscale = (iana-token ; A CLDR-registered calendar system ; name. / x-name) ; A non-standard, experimental ; calendar system name. ; Names are case-insensitive, ; but uppercase values are preferred. skip = ("YES" / "BACKWARD" / "FORWARD") ; Optional, with default value "BACKWARD", ; and MUST only be present if "RSCALE" is present. monthnum = 1*2DIGIT ["L"] ; Existing element modified to include a leap ; month indicator suffix.Daboo & Yakushev Expires July 11, 2015 [Page 6]
Internet-Draft iCalendar Property Extensions January 20154.1. Handling Leap Months Leap months can occur in different calendar systems. For such calendar systems the following rules are applied for "identifying" months: 1. Numeric values 1 through N are used to identify regular, non- leap, months (where N is the number of months in a regular, non- leap, year). 2. The suffix "L" is added to the regular month number to indicate a leap month which follows the regular month. e.g., "5L" is a leap month that follows the 5th regular month in the year. Care has to be taken when mapping the month identifiers used here with those of any underlying calendar system library being used. In particular, the Hebrew calendar system used by Unicode (ICU) [UNICODE.ICU] uses a month number scheme of 1 through 13, with month 6 being the leap month, and in non-leap years, month 6 is skipped. In iCalendar, this would map to months 1 through 12 with "5L" as the leap month.4.2. Examples4.2.1. Chinese New Year Consider the following set of iCalendar properties: DTSTART;VALUE=DATE:20130210 RRULE:RSCALE=CHINESE;FREQ=YEARLY SUMMARY:Chinese New Year These define a recurring event for the Chinese New Year, with the first instance the one in Gregorian year 2013. The Chinese date corresponding to the first instance is {C}46500101. The table below shows the initial instance, and the next four, each of which is determined by adding the appropriate amount to the year component of the Chinese date. Also shown is the conversion back to the Gregorian date:Daboo & Yakushev Expires July 11, 2015 [Page 7]
Internet-Draft iCalendar Property Extensions January 2015 +--------------+--------------------------+ | Chinese Date | Gregorian Date | +--------------+--------------------------+ | {C}46500101 | 20130210 - DTSTART value | | {C}46510101 | 20140131 | | {C}46520101 | 20150219 | | {C}46530101 | 20160208 | | {C}46540101 | 20170128 | +--------------+--------------------------+4.2.2. Ethiopic 13th Month Consider the following set of iCalendar properties: DTSTART;VALUE=DATE:201300906 RRULE:RSCALE=ETHIOPIC;FREQ=YEARLY;BYMONTH=13 SUMMARY:First day of 13th month These define a recurring event for the first day of the 13th month, with the first instance the one in Gregorian year 2013. The Ethiopic date corresponding to the first instance is {E}20051301. The table below shows the initial instance, and the next four, each of which is determined by adding the appropriate amount to the year component of the Ethiopic date. Also shown is the conversion back to the Gregorian date: +---------------+--------------------------+ | Ethiopic Date | Gregorian Date | +---------------+--------------------------+ | {E}20051301 | 20130906 - DTSTART value | | {E}20061301 | 20140906 | | {E}20071301 | 20150906 | | {E}20081301 | 20160906 | | {E}20091301 | 20170906 | +---------------+--------------------------+ Note that in this example, the value of the "BYMONTH" component in the "RRULE" matches the Ethiopic month value and not the Gregorian month.4.2.3. Hebrew anniversary starting in a leap month Consider the following set of iCalendar properties: DTSTART;VALUE=DATE:20140208 RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD SUMMARY:AnniversaryDaboo & Yakushev Expires July 11, 2015 [Page 8]
Internet-Draft iCalendar Property Extensions January 2015 These define a recurring event for the 8th day of the Hebrew month of Adar I (the leap month identified by "5L"), with the first instance the one in Gregorian year 2014. The Hebrew date corresponding to the first instance is {H}577405L08, which is a leap month in year 5774. The table below shows the initial instance, and the next four, each of which is determined by adding the appropriate amount to the year component of the Hebrew date, taking into account that only year 5776 is a leap year. Thus in other years the Hebrew month component is adjusted forward to month 6. Also shown is the conversion back to the Gregorian date: +--------------+--------------------------+ | Hebrew Date | Gregorian Date | +--------------+--------------------------+ | {H}577405L08 | 20140208 - DTSTART value | | {H}57750608 | 20150227 | | {H}577605L08 | 20160217 | | {H}57770608 | 20170306 | | {H}57780608 | 20180223 | +--------------+--------------------------+4.2.4. Gregorian leap day with SKIP Consider the following set of iCalendar properties: DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY SUMMARY:Anniversary These define a recurring event for the 29th February, 2012 in the standard iCalendar calendar scale - Gregorian. The standard iCalendar behavior is that non-existent dates in a recurrence set are ignored. Thus the properties above would only generate instances in leap years (2016, 2020, etc), which is likely not what users expect. The new "RSCALE" option defined by this specification provides the "SKIP" element which can be used to "fill in" the missing instances in an appropriate fashion. The set of iCalendar properties below do that: DTSTART;VALUE=DATE:20120229 RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD SUMMARY:Anniversary With these properties, the "missing" instances in non-leap year now appear on the 1st March in those years:Daboo & Yakushev Expires July 11, 2015 [Page 9]
Internet-Draft iCalendar Property Extensions January 2015 +-------------------------------+----------------------------+ | Instances (with SKIP=FORWARD) | Instances (without RSCALE) | +-------------------------------+----------------------------+ | 20120229 | 20120229 - DTSTART value | | 20130301 | | | 20140301 | | | 20150301 | | | 20160229 | 20160229 | | 20170301 | | +-------------------------------+----------------------------+5. Registering Calendar Systems This specification uses the Unicode Consortium's registry of calendar systems [UNICODE.CLDR] to define valid values for the "RSCALE" element of an "RRULE". Note that the underscore character "_" is never used in CLDR-based calendar system names. New values can be added to this registry following Unicode Consortium rules. It is expected that many implementations of non-Gregorian calendars will use software libraries provided by Unicode (ICU) [UNICODE.ICU], and hence it makes sense to re-use their registry rather than creating a new one. For consistency, when used, the "RSCALE" values SHOULD be uppercased. CLDR supports the use of "alias" values as alternative names for specific calendar systems. These alias values MUST be treated as valid "RSCALE" element values. When using the CLDR data, calendar agents SHOULD take into account the "deprecated" value and use the alternative "preferred" calendar system. In particular, the "islamicc" calendar system is considered deprecated in favor of the "islamic-civil" calendar system.6. Use with iTIP iTIP [RFC5546] defines how iCalendar data can be sent between calendar user agents to schedule calendar components between calendar users. It is often not possible to know the capabilities of a calendar user agent to which an iTIP message is being sent, but iTIP defines fallback behavior in such cases. For calendar user agents that do not support the "RSCALE" element, the following can occur when iTIP messages containing an "RSCALE" element are received: The receiving calendar user agent can reject the entire iTIP message and return an iTIP reply with a "REQUEST-STATUS" property set to the "3.1" status code (as perSection 3.6.14 of [RFC5546]).Daboo & Yakushev Expires July 11, 2015 [Page 10]
Internet-Draft iCalendar Property Extensions January 2015 The receiving calendar user agent can fallback to a non-recurring behavior for the calendar component (effectively ignoring the "RRULE" property) and return an iTIP reply with a "REQUEST-STATUS" property set to the "2.3", "2.5", "2.8", or "2.10" status codes (as per Sections3.6.3,3.6.6,3.6.9, or 3.6.11, respectively, of [RFC5546]). For calendar user agents that support the "RSCALE" element but do not support the calendar system specified by the "RSCALE" element value, the following can occur: the iTIP message SHOULD be rejected, returning a "REQUEST-STATUS" property set to the "3.1" status code (as perSection 3.6.14 of [RFC5546]). if the iTIP message is accepted and the calendar component treated as non-recurring, an iTIP reply with a "REQUEST-STATUS" property set to the "2.8" or "2.10" status codes (as per Sections3.6.9 or 3.6.11, respectively, of [RFC5546]) SHOULD be returned.7. Use with xCal xCal [RFC6321] defines how iCalendar data is represented in XML. This specification extends the <recur> XML element inSection 3.6.10 of [RFC6321] in the following manner: 1. A new <rscale> XML element is defined as a child element of <recur>. The content of this element MUST be a string whose value is the "RSCALE" element value of the "RRULE", with case preserved. 2. A new <skip> XML element is defined as a child element of <recur>. The content of this element MUST be a string whose value is the "SKIP" element value of the "RRULE", with case preserved. 3. The "bymonth" XML element is redefined to support either numeric or string values as its content (as perSection 4.1). Extensions to the RELAX NG schema inAppendix A of [RFC6321] are defined inAppendix B. Example: the iCalendar "RRULE" property: RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD would be represented in XML as:Daboo & Yakushev Expires July 11, 2015 [Page 11]
Internet-Draft iCalendar Property Extensions January 2015 <rrule> <recur> <rscale>GREGORIAN</rscale> <freq>YEARLY</freq> <skip>FORWARD</skip> </recur> </rrule>8. Use with jCal jCal [RFC7265] defines how iCalendar data is represented in JSON. This specification extends the "recur" JSON object defined inSection 3.6.10 of [RFC7265] in the following manner: 1. A new "rscale" child member is defined. This MUST be a string whose value is the "RSCALE" element value of the "RRULE", with case preserved. 2. A new "skip" child member is defined. This MUST be a string whose value is the "SKIP" element value of the "RRULE", with case preserved. 3. The "bymonth" child member is redefined to support either numeric or string values. If the "BYMONTH" element value is an integer, then a numeric JSON value MUST be used. If the "BYMONTH" element value is an integer with the "L" suffix (as perSection 4.1), then a JSON string value MUST be used. Example: the iCalendar "RRULE" property: RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD would be represented in JSON as: [ "rrule", {}, "recur", { "rscale": "GREGORIAN", "freq": "YEARLY", "skip": "FORWARD" } ]Daboo & Yakushev Expires July 11, 2015 [Page 12]
Internet-Draft iCalendar Property Extensions January 20159. Use with CalDAV The CalDAV [RFC4791] calendar access protocol allows clients and servers to exchange iCalendar data. In addition, CalDAV clients are able to query calendar data stored on the server, including time- based queries. Since an "RSCALE" element value determines the time ranges for recurring instances in a calendar component, CalDAV servers need to support it to interoperate with clients also using the "RSCALE" element. A CalDAV server advertises a CALDAV:supported-rscale-set WebDAV property on calendar home or calendar collections if it supports use of "RSCALE" element as described in this specification. The server can advertise a specific set of supported calendar systems by including one or more CALDAV:supported-rscale XML elements within the CALDAV:supported-rscale-set XML element. If no CALDAV:supported- rscale XML elements are included in the WebDAV property, then clients can try any calendar system value, but need to be prepared for a failure when attempting to store the calendar data. Clients MUST NOT attempt to store iCalendar data containing "RSCALE" elements if the CALDAV:supported-rscale-set WebDAV property is not advertised by the server. The server SHOULD return an HTTP 403 response with a DAV:error element containing a CALDAV:supported-rscale XML element, if a client attempts to store iCalendar data with an "RSCALE" element value not supported by the server. It is possible for an "RSCALE" value to be present in calendar data on the server being accessed by a client that does not support an "RSCALE" element or its specified value. It is expected that existing clients, unaware of "RSCALE", will fail gracefully by ignoring the calendar component, whilst still processing other calendar data on the server.9.1. CALDAV:supported-rscale-set Property Name: supported-rscale-set Namespace: urn:ietf:params:xml:ns:caldav Purpose: Enumerates the set of supported iCalendar "RSCALE" element values supported by the server. Protected: This property MUST be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined inSection 14.2 of [RFC4918]).Daboo & Yakushev Expires July 11, 2015 [Page 13]
Internet-Draft iCalendar Property Extensions January 2015 Description: See above. Definition: <!ELEMENT supported-rscale-set (supported-rscale*) > <!ELEMENT supported-rscale (#PCDATA)> <!-- PCDATA value: string - case-insensitive but uppercase preferred --> Example: <C:supported-rscale-set xmlns:C="urn:ietf:params:xml:ns:caldav"> <C:supported-rscale>GREGORIAN</C:supported-rscale> <C:supported-rscale>CHINESE</C:supported-rscale> <C:supported-rscale>ISLAMIC-CIVIL</C:supported-rscale> <C:supported-rscale>HEBREW</C:supported-rscale> <C:supported-rscale>ETHIOPIC</C:supported-rscale> </C:supported-rscale-set>10. Security Considerations This specification does not introduce any addition security concerns beyond those described in [RFC5545], [RFC5546], and [RFC4791].11. IANA Considerations This document requires no IANA actions.12. Acknowledgments Thanks to the following for feedback: Mark Davis, Mike Douglass, Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, Jonathan Lennox, Ken Murchison, Arnaud Quillaud, Dave Thewlis, and Umaoka Yoshito. This specification originated from work at the Calendaring and Scheduling Consortium, which has helped with the development and testing of implementations.13. References13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119, March 1997.Daboo & Yakushev Expires July 11, 2015 [Page 14]
Internet-Draft iCalendar Property Extensions January 2015 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)",RFC 4791, March 2007. [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)",RFC 4918, June 2007. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68,RFC 5234, January 2008. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)",RFC 5545, September 2009. [RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)",RFC 5546, December 2009. [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML Format for iCalendar",RFC 6321, August 2011. [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON Format for iCalendar",RFC 7265, May 2014. [UNICODE.CLDR] "CLDR calendar.xml Data", Unicode Consortium CLDR, <http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml>.13.2. Informative References [ISO.8601.2004] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, 2004. [UNICODE.ICU] "International Components for Unicode", Unicode Consortium ICU, April 2014, <http://site.icu-project.org>.Appendix A. Change History (To be removed by RFC Editor before publication) Changes indraft-ietf-calext-rscale-03: 1. Reworded abstract.Daboo & Yakushev Expires July 11, 2015 [Page 15]
Internet-Draft iCalendar Property Extensions January 2015 2. Added list of changes to other specs inSection 1. 3. Clarified behavior wrt VTIMEZONE inSection 1. Changes indraft-ietf-calext-rscale-02: 1. Added xCal and jCal changes sections and relax NG schema appendix. 2. Added ICU reference at the end ofSection 1. Changes indraft-ietf-calext-rscale-01: 1. Editorial changes/fixes per document shepherd review. 2. Switched CLDR reference to "tags/latest". Changes indraft-ietf-calext-rscale-00: 1. Updated some references. 2. Editorial changes/fixes. Changes indraft-daboo-icalendar-rscale-04: 1. Always use "L" suffix for leap months, even for Hebrew calendar. 2. Remove negative month numbers to go back to base 5545 definition. 3. Added example for Gregorian leap day with skip. 4. Clarify that RSCALE names are case insensitive, but with upper case preferred. 5. Clarify that BYSETPOS processing is done after SKIP. 6. Remove Islamic example in favor of Ethiopic example which shows a 13th month. Changes indraft-daboo-icalendar-rscale-03: 1. Added details about handling RSCALE in iTIP. 2. Added details about handling RSCALE in CalDAV. 3. Fixed examples to use ICU Chinese epoch and added text describing why that is not an issue for actual recurrence calculations.Daboo & Yakushev Expires July 11, 2015 [Page 16]
Internet-Draft iCalendar Property Extensions January 2015 Changes indraft-daboo-icalendar-rscale-02: 1. Fixed some incorrect dates in examples. 2. Clarified use of CLDR and alias, deprecated, preferred attributes. 3. Clarified when SKIP processing occurs. Changes indraft-daboo-icalendar-rscale-01: 1. Removed requirement that RSCALE be the first item in an RRULE. 2. Added BYLEAPMONTH element and removed BYMONTH "L" suffix. 3. Removed Open Issues.Appendix B. xCal RELAX NG schema update The following changes are made to the RELAX NG schema defined inAppendix A of [RFC6321].Daboo & Yakushev Expires July 11, 2015 [Page 17]
Internet-Draft iCalendar Property Extensions January 2015 # 3.3.10 RECUR # This extension adds type-rscale and type-skip, # and modifies type-bymonth value-recur = element recur { type-rscale?, type-freq, (type-until | type-count)?, element interval { xsd:positiveInteger }?, type-bysecond*, type-byminute*, type-byhour*, type-byday*, type-bymonthday*, type-byyearday*, type-byweekno*, type-bymonth*, type-bysetpos*, element wkst { type-weekday }?, type-skip? } type-rscale = element rscale { xsd:string } type-bymonth = element bymonth { xsd:positiveInteger | xsd:string } type-skip = element skip { "YES" | "BACKWARD" | "FORWARD" }Authors' AddressesDaboo & Yakushev Expires July 11, 2015 [Page 18]
Internet-Draft iCalendar Property Extensions January 2015 Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Email: cyrus@daboo.name URI:http://www.apple.com/ Gregory Yakushev Google Inc. Brandschenkestrasse 100 8002 Zurich Switzerland Email: yakushev@google.com URI:http://www.google.com/Daboo & Yakushev Expires July 11, 2015 [Page 19]
Datatracker
draft-ietf-calext-rscale-03
This is an older version of an Internet-Draft that was ultimately published asRFC 7529.
| Document | Document type | This is an older version of an Internet-Draft that was ultimately published asRFC 7529. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors | Cyrus Daboo,Gregory Yakushev | ||
| Replaces | draft-daboo-icalendar-rscale | ||
| RFC stream |   | ||
| Other formats | |||
| Additional resources | Mailing list discussion |