draft-ietf-calext-rscale-04.txt		rfc7529.txt
	Network Working Group C. Daboo		Internet Engineering Task Force (IETF) C. Daboo
	Internet-Draft Apple Inc.		Request for Comments: 7529 Apple Inc.
	Updates: 5545, 6321, 7265 (if approved) G. Yakushev		Updates: 5545, 6321, 7265 G. Yakushev
	Intended status: Standards Track Google Inc.		Category: Standards Track Google Inc.
	Expires: August 15, 2015 February 11, 2015		ISSN: 2070-1721 May 2015
	Non-Gregorian Recurrence Rules in iCalendar		Non-Gregorian Recurrence Rules in the Internet Calendaring and
	draft-ietf-calext-rscale-04		Scheduling Core Object Specification (iCalendar)
	Abstract		Abstract
	This document defines extensions to iCalendar (RFC 5545) to support		This document defines extensions to the Internet Calendaring and
	use of non-Gregorian recurrence rules. It also defines how CalDAV		Scheduling Core Object Specification (iCalendar) (RFC 5545) to
	(RFC 4791) servers and clients can be extended to support these new		support use of non-Gregorian recurrence rules. It also defines how
	recurrence rules.		Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and
			clients can be extended to support these new recurrence rules.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 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 at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on August 15, 2015.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7529.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 6		4. Extended RRULE Property . . . . . . . . . . . . . . . . . . . 6
	4.1. Skipping Invalid Dates . . . . . . . . . . . . . . . . . 6		4.1. Skipping Invalid Dates . . . . . . . . . . . . . . . . . 6
	4.2. Handling Leap Months . . . . . . . . . . . . . . . . . . 9		4.2. Handling Leap Months . . . . . . . . . . . . . . . . . . 9
	4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Registering Calendar Systems . . . . . . . . . . . . . . . . 12		5. Registering Calendar Systems . . . . . . . . . . . . . . . . 13
	6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Use with iTIP . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . . 14		8. Use with xCal . . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Use with jCal . . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 16		10. Use with CalDAV . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. CALDAV:supported-rscale-set Property . . . . . . . . . . 17		10.1. CALDAV:supported-rscale-set Property . . . . . . . . . . 17
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 17		11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		12.1. Normative References . . . . . . . . . . . . . . . . . . 18
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		12.2. Informative References . . . . . . . . . . . . . . . . . 19
	14.1. Normative References . . . . . . . . . . . . . . . . . . 18		Appendix A. xCal RELAX NG Schema Update . . . . . . . . . . . . 20
	14.2. Informative References . . . . . . . . . . . . . . . . . 18		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix A. Change History (To be removed by RFC Editor before		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	publication) . . . . . . . . . . . . . . . . . . . . 19
	Appendix B. xCal RELAX NG schema update . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The iCalendar [RFC5545] data format is in widespread use to represent		The iCalendar [RFC5545] data format is in widespread use to represent
	calendar data. iCalendar represents dates and times using the		calendar data. iCalendar represents dates and times using the
	Gregorian calendar system only. It does provide a way to use non-		Gregorian calendar system only. It does provide a way to use non-
	Gregorian calendar systems via a "CALSCALE" property, but this has		Gregorian calendar systems via a "CALSCALE" property, but this has
	never been used. However, there is a need to support at least non-		never been used. However, there is a need to support at least non-
	Gregorian recurrence patterns to cover anniversaries, and many local,		Gregorian recurrence patterns to cover anniversaries, and many local,
	religious, or civil holidays based on non-Gregorian dates.		religious, or civil holidays based on non-Gregorian dates.
	There are several disadvantages to using the existing "CALSCALE"		There are several disadvantages to using the existing "CALSCALE"
	property in iCalendar for implementing non-Gregorian calendars:		property in iCalendar for implementing non-Gregorian calendars:
	1. The "CALSCALE" property exists in the top-level "VCALENDAR"		1. The "CALSCALE" property exists in the top-level "VCALENDAR"
	objects and thus applies to all components within that object.		objects and thus applies to all components within that object.
	In today's multi-cultural society, that restricts the ability to		In today's multi-cultural society, that restricts the ability to
	mix events from different calendar systems within the same		mix events from different calendar systems within the same
	iCalendar object. e.g., it would prevent having both the		iCalendar object, e.g., it would prevent having both the
	Gregorian New Year and Chinese New Year in the same iCalendar		Gregorian New Year and Chinese New Year in the same iCalendar
	object.		object.
	2. Time zone and daylight saving time rules are typically published		2. Time zone and daylight saving time rules are typically published
	using Gregorian calendar dates and rules (e.g., "the 3rd Sunday		using Gregorian calendar dates and rules (e.g., "the 3rd Sunday
	in March"), and thus converted to iCalendar "VTIMEZONE"		in March") and are thus converted to iCalendar "VTIMEZONE"
	components using Gregorian date-time values and recurrence rules.		components using Gregorian dates and recurrence rules. This
	This results in the problem whereby one component (the		results in the problem whereby one component (the "VTIMEZONE") is
	"VTIMEZONE") is fixed to the Gregorian calendar system, and		fixed to the Gregorian calendar system, and another (a "VEVENT")
	another (a "VEVENT") wants to use a different non-Gregorian		wants to use a different non-Gregorian calendar scale; thus, the
	calendar scale, and thus the single top-level "CALSCALE" property		single top-level "CALSCALE" property is again inadequate.
	is again inadequate.
	This specification solves these issues by allowing the "CALSCALE" to		This specification solves these issues by allowing the "CALSCALE" to
	remain set to Gregorian, but re-defining the "RRULE" recurrence rule		remain set to Gregorian but redefining the "RRULE" recurrence rule
	property to accept new items including one that allows non-Gregorian		property to accept new items, including one that allows non-Gregorian
	calendar systems to be used. With this, all the date, time and		calendar systems to be used. With this, all the "DATE", "DATE-TIME",
	period values in the iCalendar object would remain specified using		and "PERIOD" values in the iCalendar object would remain specified
	the Gregorian calendar system, but repeating patterns in other		using the Gregorian calendar system, but repeating patterns in other
	calendar systems could be defined. It is then up to calendar user		calendar systems could be defined. It is then up to calendar user
	agents and servers to map between Gregorian and non-Gregorian		agents and servers to map between Gregorian and non-Gregorian
	calendar systems in order to expand out recurrence instances. The		calendar systems in order to expand out recurrence instances. The
	non-Gregorian recurrence rules can be used in any iCalendar component		non-Gregorian recurrence rules can be used in any iCalendar component
	that allows the "RRULE" property to be specified, including		that allows the "RRULE" property to be specified, including
	"VTIMEZONE" components (to allow for possible future use of non-		"VTIMEZONE" components (to allow for possible future use of non-
	Gregorian rules in published daylight saving time data).		Gregorian rules in published daylight saving time data).
	This specification does not itself define calendar systems, rather it		This specification does not itself define calendar systems; rather,
	utilizes the calendar system registry defined by the Unicode		it utilizes the calendar system registry defined by the Unicode
	Consortium in their CLDR (Common Locale Data Repository) project		Consortium in their Common Locale Data Repository (CLDR) project
	[UNICODE.CLDR], as implemented in the Unicode (ICU) Library		[UNICODE.CLDR], as implemented in the Unicode (International
	[UNICODE.ICU].		Components for Unicode (ICU)) Library [UNICODE.ICU].
	This specification makes the following updates:		This specification makes the following updates:
	It updates iCalendar [RFC5545], xCal [RFC6321], and jCal		It updates iCalendar [RFC5545], the XML format for iCalendar
			(xCal) [RFC6321], and the JSON format for iCalendar (jCal)
	[RFC7265], to extend the "RRULE" property definition.		[RFC7265], to extend the "RRULE" property definition.
	It updates iTIP [RFC5546] to specify how the extended "RRULE"		It clarifies use of the iCalendar Transport-Independent
	property should be handled in iTIP messages.		Interoperability Protocol (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"		It extends CalDAV [RFC4791] to specify how the extended "RRULE"
	property can be supported by CalDAV servers and clients.		property can be supported by CalDAV servers and clients.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	The notation used in this memo is the ABNF notation of [RFC5234] as		The notation used in this memo is the ABNF notation of [RFC5234] as
	used by iCalendar [RFC5545]. Any syntax elements shown below that		used by iCalendar [RFC5545]. Any syntax elements shown below that
	are not explicitly defined in this specification come from iCalendar		are not explicitly defined in this specification come from iCalendar
	[RFC5545], iTIP [RFC5546], and CalDAV [RFC4791].		[RFC5545], iTIP [RFC5546], and CalDAV [RFC4791].
	When XML element types in the namespaces "DAV:" and		When XML element types in the namespaces "DAV:" and
	"urn:ietf:params:xml:ns:caldav" are referenced in this document		"urn:ietf:params:xml:ns:caldav" are referenced in this document
	outside of the context of an XML fragment, the string "DAV:" and		outside of the context of an XML fragment, the string "DAV:" and
	"CALDAV:" will be prefixed to the element type names respectively.		"CALDAV:" will be prefixed to the element type names, respectively.
	When a Gregorian calendar date value is shown in text, it will use		When a Gregorian calendar date is shown in text, it will use the
	the format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the		format "YYYYMMDD", where "YYYY" is the 4-digit year, "MM" the 2-digit
	2-digit month, and "DD" the 2-digit day (this is the same format used		month, and "DD" the 2-digit day (this is the same format used in
	in iCalendar [RFC5545]). The Chinese calendar will be used as an		iCalendar [RFC5545]). The Chinese calendar will be used as an
	example of a non-Gregorian calendar for illustrative purposes. When		example of a non-Gregorian calendar for illustrative purposes. When
	a Chinese calendar date value is shown in text, it will use the		a Chinese calendar date is shown in text, it will use the format
	format "{C}YYYYMM[L]DD" - i.e., the same format as Gregorian but with		"{C}YYYYMM[L]DD" -- i.e., the same format as Gregorian but with a
	a "{C}" prefix, and an optional "L" character after the month element		"{C}" prefix, and an optional "L" character after the month element
	to indicate a leap month. Similarly, {E} and {H} are used in other		to indicate a leap month. Similarly, {E} and {H} are used in other
	examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates,		examples as prefixes for Ethiopic (Amete Mihret) and Hebrew dates,
	respectively. The "{}" prefix is used for purely illustrative		respectively. The "{}" prefix is used for purely illustrative
	purposes and never appears in actual date-time values used in		purposes and never appears in actual dates used in iCalendar or
	iCalendar or related specifications. Note that the Chinese calendar		related specifications. Note that the Chinese calendar years shown
	years shown in the examples are based on the Unicode (ICU)		in the examples are based on the Unicode (ICU) [UNICODE.ICU]
	[UNICODE.ICU] library's Chinese calendar epoch. Whilst there are		library's Chinese calendar epoch. While there are several different
	several different Chinese calendar epochs in common use, the choice		Chinese calendar epochs in common use, the choice of one over another
	of one over another does not impact the actual calculation of the		does not impact the actual calculation of the Gregorian equivalent
	Gregorian equivalent dates, provided conversion is always done using		dates, provided conversion is always done using the same epoch.
	the same epoch.
	3. Overview		3. Overview
	In the Gregorian calendar system, each year is composed of a fixed		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		number of months (12), with each month having a fixed number of days
	(between 30 and 31), except for the second month (February) which		(between 30 and 31), except for the second month (February), which
	contains either 28 days, or 29 days (in a leap year). Weeks are		contains either 28 or 29 days (the latter in a leap year). Weeks are
	composed of 7 days, with day names Monday, Tuesday, Wednesday,		composed of 7 days, with day names Monday, Tuesday, Wednesday,
	Thursday, Friday, Saturday and Sunday. Years can have either 365 or		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		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		year is 52 (though the [ISO.8601.2004] week numbering scheme used by
	iCalendar [RFC5545] can have a numeric count up to 53).		iCalendar [RFC5545] can have a numeric count up to 53).
	In iCalendar, the "RECUR" value type defines various fields used to		In iCalendar, the "RECUR" value type defines various fields used to
	express a recurrence pattern, and those fields are given limits based		express a recurrence pattern, and those fields are given limits based
	on those of the Gregorian calendar system. Since other calendar		on those of the Gregorian calendar system. Since other calendar
	systems can have different limits and other behaviors that need to be		systems can have different limits and other behaviors that need to be
	accounted for, the maximum values for the elements in the "RECUR"		accounted for, the maximum values for the elements in the "RECUR"
	value are not covered by this specification.		value are not covered by this specification.
	To generate a set of recurring instances in a non-Gregorian calendar		To generate a set of recurring instances in a non-Gregorian calendar
	system, the following principles are used:		system, the following principles are used:
	1. iCalendar data continues to use the "GREGORIAN" calendar system,		1. iCalendar data continues to use the "GREGORIAN" calendar system,
	so all "DATE", "DATE-TIME" and "PERIOD" values continue to use		so all "DATE", "DATE-TIME", and "PERIOD" values continue to use
	the Gregorian format and limits.		the Gregorian format and limits.
	2. The "RRULE" property is extended to include an "RSCALE" element		2. The "RRULE" property is extended to include an "RSCALE" element
	in its value that specifies the calendar system to use for the		in its value that specifies the calendar system to use for the
	recurrence pattern. The existing elements of the "RRULE" value		recurrence pattern. The existing elements of the "RRULE" value
	type are used, but modified to support different upper limits,		type are used, but modified to support different upper limits,
	based on the "RSCALE" value, as well as a modification to month		based on the "RSCALE" value, as well as a modification to month
	numbers to allow a leap month to be specified. Existing		numbers to allow a leap month to be specified. Existing
	requirements for the use of "RRULE" all still apply (e.g., the		requirements for the use of "RRULE" all still apply (e.g., the
	"RRULE" has to match the "DTSTART" value of the master instance).		"RRULE" has to match the "DTSTART" value of the master instance).
	Other recurrence properties such as "RECURRENCE-ID", "RDATE" and		Other recurrence properties such as "RECURRENCE-ID", "RDATE", and
	"EXDATE" continue to use the Gregorian date format as "CALSCALE"		"EXDATE" continue to use the Gregorian date format as "CALSCALE"
	is unchanged.		is unchanged.
	When generating instances, the following procedure might be used:		When generating instances, the following procedure might be used:
	1. Convert the "DTSTART" property value of the master recurring		1. Convert the "DTSTART" property value of the master recurring
	component into the date and time components for the calendar		component into the date and time components for the calendar
	system specified by the "RSCALE" element in the "RRULE" value.		system specified by the "RSCALE" element in the "RRULE" value.
	This provides the "seed" value for generating subsequent		This provides the "seed" value for generating subsequent
	recurrence instances.		recurrence instances.
	2. Iteratively generate instances using the "RRULE" value applied to		2. Iteratively generate instances using the "RRULE" value applied to
	the year, month, and day components of the date in the new		the year, month, and day components of the date in the new
	calendar system.		calendar system.
	3. For each generated instance, convert the date values back from		3. For each generated instance, convert the dates and times back
	the non-Gregorian form into Gregorian and use those values for		from the non-Gregorian form into Gregorian and use those values
	other properties such as "RECURRENCE-ID".		for other properties such as "RECURRENCE-ID".
	Consider the following example for an event representing the Chinese		Consider the following example for an event representing the Chinese
	New Year:		New Year:
	DTSTART;VALUE=DATE:20130210		DTSTART;VALUE=DATE:20130210
	RRULE:RSCALE=CHINESE;FREQ=YEARLY		RRULE:RSCALE=CHINESE;FREQ=YEARLY
	SUMMARY:Chinese New Year		SUMMARY:Chinese New Year
	To generate instances, first the "DTSTART" value "20130210" is		To generate instances, first the "DTSTART" value "20130210" is
	converted into the Chinese calendar system giving "{C}46500101".		converted into the Chinese calendar system giving "{C}46500101".
	Next, the year component is incremented by one to give "{C}46510101",		Next, the year component is incremented by one to give "{C}46510101",
	and that is then converted back into Gregorian as "20140131".		and that is then converted back into Gregorian as "20140131".
	Additional instances are generated by iteratively increasing the year		Additional instances are generated by iteratively increasing the year
	component in the Chinese date value and converting back to Gregorian.		component in the Chinese date and converting back to Gregorian.
	4. Extended RRULE Property		4. Extended RRULE Property
	This specification extends the existing "RRULE" iCalendar property		This specification extends the existing "RRULE" iCalendar property
	value to include a new "RSCALE" element that can be used to indicate		value to include a new "RSCALE" element that can be used to indicate
	the calendar system used for generating the recurrence pattern.		the calendar system used for generating the recurrence pattern.
	When "RSCALE" is present, the other changes to "RRULE" are:		When "RSCALE" is present, the other changes to "RRULE" are:
	1. Elements that include numeric values (e.g., "BYYEARDAY") have		1. Elements that include numeric values (e.g., "BYYEARDAY") have
	skipping to change at page 6, line 27		skipping to change at page 6, line 27
	2. Month numbers can include an "L" suffix to indicate that the		2. Month numbers can include an "L" suffix to indicate that the
	specified month is a leap month in the corresponding calendar		specified month is a leap month in the corresponding calendar
	system (see Section 4.2).		system (see Section 4.2).
	3. A "SKIP" element is added to define how "missing" instances are		3. A "SKIP" element is added to define how "missing" instances are
	handled (see Section 4.1).		handled (see Section 4.1).
	The syntax for the "RECUR" value is modified in the following		The syntax for the "RECUR" value is modified in the following
	fashion:		fashion:
	recur-rule-part /= ("RSCALE" "=" rscale)		; recur-rule-part is extended from RFC 5545
			recur-rule-part =/ ("RSCALE" "=" rscale)
	/ ("SKIP" "=" skip)		/ ("SKIP" "=" skip)
	rscale = (iana-token ; A CLDR-registered calendar system		rscale = (iana-token ; A CLDR-registered calendar system
	; name.		; name.
	/ x-name) ; A non-standard, experimental		/ x-name) ; A non-standard, experimental
	; calendar system name.		; calendar system name.
	; Names are case-insensitive,		; Names are case insensitive,
	; but uppercase values are preferred.		; but uppercase values are preferred.
	skip = ("OMIT" / "BACKWARD" / "FORWARD")		skip = ("OMIT" / "BACKWARD" / "FORWARD")
	; Optional, with default value "OMIT", and		; Optional, with default value "OMIT", and
	; MUST NOT be present unless "RSCALE" is present.		; MUST NOT be present unless "RSCALE" is present.
	monthnum = 1*2DIGIT ["L"]		monthnum = 1*2DIGIT ["L"]
	; Existing element modified to include a leap		; Existing element modified to include a leap
	; month indicator suffix.		; month indicator suffix.
	4.1. Skipping Invalid Dates		4.1. Skipping Invalid Dates
	In every calendar system only certain combinations of day-of-month		In every calendar system, only certain combinations of day-of-month
	and month values are valid for a given year. e.g., in the Gregorian		and month values are valid for a given year, e.g., in the Gregorian
	calendar system January 31st is valid, but February 31st is not.		calendar system, January 31st is valid but February 31st is not.
	Similarly, February 29th is valid in a leap year, but invalid in a		Similarly, February 29th is valid in a leap year but invalid in a
	non-leap year. Other calendar systems can also include leap months		non-leap year. Other calendar systems can also include leap months
	(see Section 4.2) which vary from year to year. This poses a problem		(see Section 4.2), which vary from year to year. This poses a
	for recurring events where the frequency of recurrence might give		problem for recurring events where the frequency of recurrence might
	rise to an invalid date. For example, a recurring event that starts		give rise to an invalid date. For example, a recurring event that
	on January 31st and is set to repeat monthly will generate invalid		starts on January 31st and is set to repeat monthly will generate
	dates for months with fewer than 31 days. The iCalendar [RFC5545]		invalid dates for months with fewer than 31 days. The iCalendar
	specification requires recurrence rule generators to ignore any		[RFC5545] specification requires recurrence rule generators to ignore
	invalid dates generated when iterating the rule. However, that		any invalid dates generated when iterating the rule. However, that
	behavior might be surprising to a calendar user born on a leap day		behavior might be surprising to a calendar user born on a leap day
	and whose birthday event only appears on their calendar every four		and whose birthday event only appears on their calendar every four
	years. There are common conventions used by humans to determine what		years. There are common conventions used by humans to determine what
	to do in such cases, but those conventions can differ from calendar		to do in such cases, but those conventions can differ from calendar
	system to calendar system, as well as within the same calendar		system to calendar system, as well as within the same calendar
	system, depending on the nature of the event. Typically, humans will		system, depending on the nature of the event. Typically, humans will
	expect the "missing" events to be moved to a earlier or later (valid)		expect the "missing" events to be moved to an earlier or later
	date.		(valid) date.
	This specification introduces a new "RRULE" element, "SKIP", for use		This specification introduces a new "RRULE" element, "SKIP", for use
	only when the "RSCALE" element is present. The "SKIP" element allows		only when the "RSCALE" element is present. The "SKIP" element allows
	the calendar user agent to specify new options for handling invalid		the calendar user agent to specify new options for handling invalid
	dates.		dates.
	"SKIP=OMIT": this is the default option and corresponds to the		"SKIP=OMIT": this is the default option and corresponds to the
	existing iCalendar behavior of simply ignoring the invalid date.		existing iCalendar behavior of simply ignoring the invalid date.
	"SKIP=BACKWARD": when this option is set, a date with an invalid		"SKIP=BACKWARD": when this option is set, a date with an invalid
	month is changed to the previous (valid) month. A date with an		month is changed to the previous (valid) month. A date with an
	invalid day-of-month is changed to the previous (valid) day-of-		invalid day-of-month is changed to the previous (valid)
	month.		day-of-month.
	"SKIP=FORWARD": when this option is set, a date with an invalid		"SKIP=FORWARD": when this option is set, a date with an invalid
	month is changed to the next (valid) month. A date with an		month is changed to the next (valid) month. A date with an
	invalid day-of-month is changed to the next (valid) day-of-month.		invalid day-of-month is changed to the next (valid) day-of-month.
	Note that for both "BACKWARD" and "FORWARD", if the month is changed		Note that for both "BACKWARD" and "FORWARD", if the month is changed
	and results in an invalid day-of-month, then the skip behavior will		and results in an invalid day-of-month, then the skip behavior will
	be re-applied as per the day-of-month rules, according to the		be reapplied as per the day-of-month rules, according to the
	processing order defined below.		processing order defined below.
	The month and day-of-month skip behavior is only applied at specific		The month and day-of-month skip behavior is only applied at specific
	points during the processing of an "RRULE" as determined by the order		points during the processing of an "RRULE" as determined by the order
	in which any "BYxxx" elements are processed. The order is as follows		in which any "BYxxx" elements are processed. The order is as follows
	(based on the "RRULE" element processing order defined in		(based on the "RRULE" element processing order defined in
	Section 3.3.10 of [RFC5545]):		Section 3.3.10 of [RFC5545]):
	o BYMONTH		o BYMONTH
	skipping to change at page 8, line 27		skipping to change at page 8, line 27
	o BYSECOND		o BYSECOND
	o BYSETPOS		o BYSETPOS
	o COUNT		o COUNT
	o UNTIL		o UNTIL
	It is often possible to avoid having to deal with invalid dates by		It is often possible to avoid having to deal with invalid dates by
	determining the real intent of a human user. e.g., a human creating a		determining the real intent of a human user, e.g., a human creating a
	monthly recurring event that starts on January 31st, likely intends		monthly recurring event that starts on January 31st likely intends
	the event to occur on the last day of every month, in which case that		the event to occur on the last day of every month, in which case that
	could be encoded into an "RRULE" by using the "BYMONTHDAY=-1"		could be encoded into an "RRULE" by using the "BYMONTHDAY=-1"
	element.		element.
	Only a few types of recurrence patterns are likely to need the use of		Only a few types of recurrence patterns are likely to need the use of
	"SKIP". The following is a list of some situations where it might be		"SKIP". The following is a list of some situations where it might be
	needed:		needed:
	1. The start date of the recurrence is a leap day in the specified		1. The start date of the recurrence is a leap day in the specified
	calendar system.		calendar system.
	skipping to change at page 9, line 8		skipping to change at page 9, line 8
	than the smallest day-of-month value for any month in any year in		than the smallest day-of-month value for any month in any year in
	the specified calendar system.		the specified calendar system.
	4. A "BYMONTHDAY" element in an "RRULE" has a day-of-month value		4. A "BYMONTHDAY" element in an "RRULE" has a day-of-month value
	greater than the smallest day-of-month value for any month in any		greater than the smallest day-of-month value for any month in any
	year in the specified calendar system.		year in the specified calendar system.
	5. A "BYMONTH" element in an "RRULE" has a value corresponding to a		5. A "BYMONTH" element in an "RRULE" has a value corresponding to a
	leap month in the specified calendar system.		leap month in the specified calendar system.
	6. A combination of "BYMONTHDAY" and "BYMONTH" elements in an		6. A combination of a "BYMONTHDAY" element and a "BYMONTH" element
	"RRULE" have a value corresponding to a leap day in the specified		in an "RRULE" has a value corresponding to a leap day in the
	calendar system.		specified calendar system.
	7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater		7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater
	than the smallest number of days in any year in the specified		than the smallest number of days in any year in the specified
	calendar system.		calendar system.
	8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater		8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater
	than the smallest number of weeks in any year in the specified		than the smallest number of weeks in any year in the specified
	calendar system.		calendar system.
	Examples of using "SKIP" for some common use cases appear in		Examples of using "SKIP" for some common use cases appear in
	Section 4.3.		Section 4.3.
	4.2. Handling Leap Months		4.2. Handling Leap Months
	Leap months can occur in different calendar systems. For such		Leap months can occur in different calendar systems. For such
	calendar systems the following rules are applied for "identifying"		calendar systems, the following rules are applied for "identifying"
	months:		months:
	1. Numeric values 1 through N are used to identify regular, non-		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, months (where N is the number of months in a regular, non-
	leap, year).		leap, year).
	2. The suffix "L" is added to the regular month number to indicate a		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		leap month that follows the regular month, e.g., "5L" is a leap
	month that follows the 5th regular month in the year.		month that follows the 5th regular month in the year.
	Care has to be taken when mapping the month identifiers used here		Care has to be taken when mapping the month identifiers used here
	with those of any underlying calendar system library being used. In		with those of any underlying calendar system library being used. In
	particular, the Hebrew calendar system used by Unicode (ICU)		particular, the Hebrew calendar system used by Unicode (ICU)
	[UNICODE.ICU] uses a month number scheme of 1 through 13, with month		[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.		6 being the leap month, and in non-leap years, month 6 is skipped.
	Thus ICU months 1 through 5 map to iCalendar months 1 through 5, ICU		Thus, ICU months 1 through 5 map to iCalendar months 1 through 5, ICU
	month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map		month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map
	to iCalendar months 6 through 12.		to iCalendar months 6 through 12.
	4.3. Examples		4.3. Examples
	4.3.1. Chinese New Year		4.3.1. Chinese New Year
	Consider the following set of iCalendar properties (from the example		Consider the following set of iCalendar properties (from the example
	above):		above):
	DTSTART;VALUE=DATE:20130210		DTSTART;VALUE=DATE:20130210
	RRULE:RSCALE=CHINESE;FREQ=YEARLY		RRULE:RSCALE=CHINESE;FREQ=YEARLY
	SUMMARY:Chinese New Year		SUMMARY:Chinese New Year
	These define a recurring event for the Chinese New Year, with the		These define a recurring event for the Chinese New Year, with the
	first instance the one in Gregorian year 2013.		first instance being the one in Gregorian year 2013.
	The Chinese date corresponding to the first instance is {C}46500101.		The Chinese date corresponding to the first instance is
	The table below shows the initial instance, and the next four, each		"{C}46500101". The table below shows the initial instance and the
	of which is determined by adding the appropriate amount to the year		next four, each of which is determined by adding the appropriate
	component of the Chinese date. Also shown is the conversion back to		amount to the year component of the Chinese date. Also shown is the
	the Gregorian date:		conversion back to the Gregorian date:
	+--------------+--------------------------+		+--------------+--------------------------+
	| Chinese Date | Gregorian Date |		| Chinese Date | Gregorian Date |
	+--------------+--------------------------+		+--------------+--------------------------+
	| {C}46500101 | 20130210 - DTSTART value |		| {C}46500101 | 20130210 - DTSTART value |
	| {C}46510101 | 20140131 |		| {C}46510101 | 20140131 |
	| {C}46520101 | 20150219 |		| {C}46520101 | 20150219 |
	| {C}46530101 | 20160208 |		| {C}46530101 | 20160208 |
	| {C}46540101 | 20170128 |		| {C}46540101 | 20170128 |
	+--------------+--------------------------+		+--------------+--------------------------+
	4.3.2. Ethiopic 13th Month		4.3.2. Ethiopic 13th Month
	Consider the following set of iCalendar properties:		Consider the following set of iCalendar properties:
	DTSTART;VALUE=DATE:20130906		DTSTART;VALUE=DATE:20130906
	RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13		RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13
	SUMMARY:First day of 13th month		SUMMARY:First day of 13th month
	These define a recurring event for the first day of the 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. Whilst there		with the first instance being the one in Gregorian year 2013. While
	are a number of alternative ways of writing the "RRULE" above to		there are a number of alternative ways of writing the "RRULE" above
	achieve the same pattern of recurring dates, the one above was chosen		to achieve the same pattern of recurring dates, the one above was
	to illustrate a "BYMONTH" value exceeding the limit of 12, previously		chosen to illustrate a "BYMONTH" value exceeding the limit of 12,
	described in iCalendar (Section 3.3.10 of [RFC5545]).		previously described in iCalendar (Section 3.3.10 of [RFC5545]).
	The Ethiopic date corresponding to the first instance is {E}20051301.		The Ethiopic date corresponding to the first instance is
	The table below shows the initial instance, and the next four, each		"{E}20051301". The table below shows the initial instance and the
	of which is determined by adding the appropriate amount to the year		next four, each of which is determined by adding the appropriate
	component of the Ethiopic date. Also shown is the conversion back to		amount to the year component of the Ethiopic date. Also shown is the
	the Gregorian date:		conversion back to the Gregorian date:
	+---------------+--------------------------+		+---------------+--------------------------+
	| Ethiopic Date | Gregorian Date |		| Ethiopic Date | Gregorian Date |
	+---------------+--------------------------+		+---------------+--------------------------+
	| {E}20051301 | 20130906 - DTSTART value |		| {E}20051301 | 20130906 - DTSTART value |
	| {E}20061301 | 20140906 |		| {E}20061301 | 20140906 |
	| {E}20071301 | 20150906 |		| {E}20071301 | 20150906 |
	| {E}20081301 | 20160906 |		| {E}20081301 | 20160906 |
	| {E}20091301 | 20170906 |		| {E}20091301 | 20170906 |
	+---------------+--------------------------+		+---------------+--------------------------+
	Note that in this example, the value of the "BYMONTH" component in		Note that in this example, the value of the "BYMONTH" component in
	the "RRULE" matches the Ethiopic month value and not the Gregorian		the "RRULE" matches the Ethiopic month value and not the Gregorian
	month.		month.
	4.3.3. Hebrew anniversary starting in a leap month		4.3.3. Hebrew Anniversary Starting in a Leap Month
	Consider the following set of iCalendar properties:		Consider the following set of iCalendar properties:
	DTSTART;VALUE=DATE:20140208		DTSTART;VALUE=DATE:20140208
	RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD		RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=5L;BYMONTHDAY=8;SKIP=FORWARD
	SUMMARY:Anniversary		SUMMARY:Anniversary
	These define a recurring event for the 8th day of the Hebrew month of		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		Adar I (the leap month identified by "5L"), with the first instance
	the one in Gregorian year 2014.		being the one in Gregorian year 2014.
	The Hebrew date corresponding to the first instance is {H}577405L08,		The Hebrew date corresponding to the first instance is
	which is a leap month in year 5774. The table below shows the		"{H}577405L08", which is a leap month in year 5774. The table below
	initial instance, and the next four, each of which is determined by		shows the initial instance and the next four, each of which is
	adding the appropriate amount to the year component of the Hebrew		determined by adding the appropriate amount to the year component of
	date, taking into account that only year 5776 is a leap year. Thus		the Hebrew date, taking into account that only year 5776 is a leap
	in other years the Hebrew month component is adjusted forward to		year. Thus, in other years the Hebrew month component is adjusted
	month 6. Also shown is the conversion back to the Gregorian date:		forward to month 6. Also shown is the conversion back to the
			Gregorian date:
	+--------------+--------------------------+		+--------------+--------------------------+
	| Hebrew Date | Gregorian Date |		| Hebrew Date | Gregorian Date |
	+--------------+--------------------------+		+--------------+--------------------------+
	| {H}577405L08 | 20140208 - DTSTART value |		| {H}577405L08 | 20140208 - DTSTART value |
	| {H}57750608 | 20150227 |		| {H}57750608 | 20150227 |
	| {H}577605L08 | 20160217 |		| {H}577605L08 | 20160217 |
	| {H}57770608 | 20170306 |		| {H}57770608 | 20170306 |
	| {H}57780608 | 20180223 |		| {H}57780608 | 20180223 |
	+--------------+--------------------------+		+--------------+--------------------------+
	4.3.4. Gregorian leap day with SKIP		4.3.4. Gregorian Leap Day with SKIP
	Consider the following set of iCalendar properties:		Consider the following set of iCalendar properties:
	DTSTART;VALUE=DATE:20120229		DTSTART;VALUE=DATE:20120229
	RRULE:FREQ=YEARLY		RRULE:FREQ=YEARLY
	SUMMARY:Anniversary		SUMMARY:Anniversary
	These define a recurring event for the 29th February, 2012 in the		These define a recurring event for the 29th of February, 2012, in the
	standard iCalendar calendar scale - Gregorian. The standard		standard iCalendar calendar scale -- Gregorian. The standard
	iCalendar behavior is that non-existent dates in a recurrence set are		iCalendar behavior is that non-existent dates in a recurrence set are
	ignored. Thus the properties above would only generate instances in		ignored. Thus, the properties above would only generate instances in
	leap years (2016, 2020, etc), which is likely not what users expect.		leap years (2016, 2020, etc.), which is likely not what users expect.
	The new "RSCALE" option defined by this specification provides the		The new "RSCALE" option defined by this specification provides the
	"SKIP" element which can be used to "fill in" the missing instances		"SKIP" element, which can be used to "fill in" the missing instances
	in an appropriate fashion. The set of iCalendar properties below do		in an appropriate fashion. The set of iCalendar properties below
	that:		does that:
	DTSTART;VALUE=DATE:20120229		DTSTART;VALUE=DATE:20120229
	RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD		RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD
	SUMMARY:Anniversary		SUMMARY:Anniversary
	With these properties, the "missing" instances in non-leap year now		With these properties, the "missing" instances in non-leap years now
	appear on the 1st March in those years:		appear on the 1st of March in those years:
	+-------------------------------+----------------------------+		+-------------------------------+----------------------------+
	| Instances (with SKIP=FORWARD) | Instances (without RSCALE) |		| Instances (with SKIP=FORWARD) | Instances (without RSCALE) |
	+-------------------------------+----------------------------+		+-------------------------------+----------------------------+
	| 20120229 | 20120229 - DTSTART value |		| 20120229 | 20120229 - DTSTART value |
	| 20130301 | |		| 20130301 | |
	| 20140301 | |		| 20140301 | |
	| 20150301 | |		| 20150301 | |
	| 20160229 | 20160229 |		| 20160229 | 20160229 |
	| 20170301 | |		| 20170301 | |
	skipping to change at page 12, line 50		skipping to change at page 13, line 14
	5. Registering Calendar Systems		5. Registering Calendar Systems
	This specification uses the Unicode Consortium's registry of calendar		This specification uses the Unicode Consortium's registry of calendar
	systems [UNICODE.CLDR] to define valid values for the "RSCALE"		systems [UNICODE.CLDR] to define valid values for the "RSCALE"
	element of an "RRULE". Note that the underscore character "_" is		element of an "RRULE". Note that the underscore character "_" is
	never used in CLDR-based calendar system names. New values can be		never used in CLDR-based calendar system names. New values can be
	added to this registry following Unicode Consortium rules. It is		added to this registry following Unicode Consortium rules. It is
	expected that many implementations of non-Gregorian calendars will		expected that many implementations of non-Gregorian calendars will
	use software libraries provided by Unicode (ICU) [UNICODE.ICU], and		use software libraries provided by Unicode (ICU) [UNICODE.ICU], and
	hence it makes sense to re-use their registry rather than creating a		hence it makes sense to reuse their registry rather than creating a
	new one. "RSCALE" values are case-insensitive, but upper case is		new one. "RSCALE" values are case insensitive, but uppercase is
	preferred.		preferred.
	CLDR supports the use of "alias" values as alternative names for		CLDR supports the use of "alias" values as alternative names for
	specific calendar systems. These alias values can be used as		specific calendar systems. These alias values can be used as
	"RSCALE" values and are treated the same as the equivalent CLDR		"RSCALE" values and are treated the same as the equivalent CLDR
	calendar system they are an alias for.		calendar system they are an alias for.
	When using the CLDR data, calendar agents SHOULD take into account		When using the CLDR data, calendar agents SHOULD take into account
	the "deprecated" value and use the alternative "preferred" calendar		the "deprecated" value and use the alternative "preferred" calendar
	system. In particular, the "islamicc" calendar system is considered		system. In particular, the "islamicc" calendar system is considered
	skipping to change at page 13, line 33		skipping to change at page 13, line 46
	within which at least one iCalendar component uses the		within which at least one iCalendar component uses the
	unrecognized "RSCALE" element or element value.		unrecognized "RSCALE" element or element value.
	2. The calendar user agent can reject just the iCalendar components		2. The calendar user agent can reject just the iCalendar components
	containing an unrecognized "RSCALE" element or element value.		containing an unrecognized "RSCALE" element or element value.
	Note that any overridden components associated with those		Note that any overridden components associated with those
	rejected components MUST also be rejected (i.e., any other		rejected components MUST also be rejected (i.e., any other
	components with the same "UID" property value as the one with the		components with the same "UID" property value as the one with the
	unrecognized "RSCALE" element or element value).		unrecognized "RSCALE" element or element value).
	3. The calendar user agent can fallback to a non-recurring behavior		3. The calendar user agent can fall back to a non-recurring behavior
	for the iCalendar component containing the unrecognized "RSCALE"		for the iCalendar component containing the unrecognized "RSCALE"
	element or element value (effectively ignoring the "RRULE"		element or element value (effectively ignoring the "RRULE"
	property). However, any overridden components SHOULD be rejected		property). However, any overridden components SHOULD be rejected
	as they would represent "orphaned" instances that would seem to		as they would represent "orphaned" instances that would seem to
	be out of place.		be out of place.
	In general, the best choice for a calendar user agent would be option		In general, the best choice for a calendar user agent would be option
	(2) above, as it would be the least disruptive choice. Note that		(2) above, as it would be the least disruptive choice. Note that
	when processing iTIP [RFC5546] messages, the manner of the rejection		when processing iTIP [RFC5546] messages, the manner of the rejection
	is covered in the next section.		is covered as discussed in the next section.
	7. Use with iTIP		7. Use with iTIP
	iTIP [RFC5546] defines how iCalendar data can be sent between		iTIP [RFC5546] defines how iCalendar data can be sent between
	calendar user agents to schedule calendar components between calendar		calendar user agents to schedule calendar components between calendar
	users. It is often not possible to know the capabilities of a		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		calendar user agent to which an iTIP message is being sent, but iTIP
	defines fallback behavior in such cases.		defines fallback behavior in such cases.
	For calendar user agents that do not support the "RSCALE" element,		For calendar user agents that do not support the "RSCALE" element,
	the following can occur when iTIP messages containing an "RSCALE"		the following can occur when iTIP messages containing an "RSCALE"
	element are received:		element are received:
	The receiving calendar user agent can reject the entire iTIP		The receiving calendar user agent can reject the entire iTIP
	message and return an iTIP reply with a "REQUEST-STATUS" property		message and return an iTIP reply with a "REQUEST-STATUS" property
	set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]).		set to the "3.1" status code (as per Section 3.6.14 of [RFC5546]).
	The receiving calendar user agent can fallback to a non-recurring		The receiving calendar user agent can fall back to a non-recurring
	behavior for the calendar component (effectively ignoring the		behavior for the calendar component (effectively ignoring the
	"RRULE" property) and return an iTIP reply with a "REQUEST-STATUS"		"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		property set to the "2.3", "2.5", "2.8", or "2.10" status codes
	(as per Sections 3.6.3, 3.6.6, 3.6.9, or 3.6.11, respectively, of		(as per Sections 3.6.4, 3.6.6, 3.6.9, or 3.6.11, respectively, of
	[RFC5546]).		[RFC5546]).
	For calendar user agents that support the "RSCALE" element but do not		For calendar user agents that support the "RSCALE" element but do not
	support the calendar system specified by the "RSCALE" element value,		support the calendar system specified by the "RSCALE" element value,
	the following can occur:		the following can occur:
	the iTIP message SHOULD be rejected, returning a "REQUEST-STATUS"		The iTIP message SHOULD be rejected, returning a "REQUEST-STATUS"
	property set to the "3.1" status code (as per Section 3.6.14 of		property set to the "3.1" status code (as per Section 3.6.14 of
	[RFC5546]).		[RFC5546]).
	if the iTIP message is accepted and the calendar component treated		If the iTIP message is accepted and the calendar component treated
	as non-recurring, an iTIP reply with a "REQUEST-STATUS" property		as non-recurring, an iTIP reply with a "REQUEST-STATUS" property
	set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or		set to the "2.8" or "2.10" status codes (as per Sections 3.6.9 or
	3.6.11, respectively, of [RFC5546]) SHOULD be returned.		3.6.11, respectively, of [RFC5546]) SHOULD be returned.
	As noted in Section 6, the best choice is to reject the entire iTIP		As noted in Section 6, the best choice is to reject the entire iTIP
	message.		message.
	8. Use with xCal		8. Use with xCal
	xCal [RFC6321] defines how iCalendar data is represented in XML.		xCal [RFC6321] defines how iCalendar data is represented in XML.
	skipping to change at page 15, line 5		skipping to change at page 15, line 21
	1. A new <rscale> XML element is defined as a child element of		1. A new <rscale> XML element is defined as a child element of
	<recur>. The content of this element MUST be a string whose		<recur>. The content of this element MUST be a string whose
	value is the "RSCALE" element value of the "RRULE", with case		value is the "RSCALE" element value of the "RRULE", with case
	preserved.		preserved.
	2. A new <skip> XML element is defined as a child element of		2. A new <skip> XML element is defined as a child element of
	<recur>. The content of this element MUST be a string whose		<recur>. The content of this element MUST be a string whose
	value is the "SKIP" element value of the "RRULE", with case		value is the "SKIP" element value of the "RRULE", with case
	preserved.		preserved.
	3. The "bymonth" XML element is redefined to support either numeric		3. The <bymonth> XML element is redefined to support either numeric
	or string values as its content (as per Section 4.2).		or string values as its content (as per Section 4.2).
	Extensions to the RELAX NG schema in Appendix A of [RFC6321] are		Extensions to the RELAX NG schema in Appendix A of [RFC6321] are
	defined in Appendix B.		defined in Appendix A of this document.
	Example: the iCalendar "RRULE" property:		Example: the iCalendar "RRULE" property:
	RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD		RRULE:RSCALE=GREGORIAN;FREQ=YEARLY;SKIP=FORWARD
	would be represented in XML as:		would be represented in XML as:
	<rrule>		<rrule>
	<recur>		<recur>
	<rscale>GREGORIAN</rscale>		<rscale>GREGORIAN</rscale>
	skipping to change at page 16, line 26		skipping to change at page 16, line 42
	10. Use with CalDAV		10. Use with CalDAV
	The CalDAV [RFC4791] calendar access protocol allows clients and		The CalDAV [RFC4791] calendar access protocol allows clients and
	servers to exchange iCalendar data. In addition, CalDAV clients are		servers to exchange iCalendar data. In addition, CalDAV clients are
	able to query calendar data stored on the server, including time-		able to query calendar data stored on the server, including time-
	based queries. Since an "RSCALE" element value determines the time		based queries. Since an "RSCALE" element value determines the time
	ranges for recurring instances in a calendar component, CalDAV		ranges for recurring instances in a calendar component, CalDAV
	servers need to support it to interoperate with clients also using		servers need to support it to interoperate with clients also using
	the "RSCALE" element.		the "RSCALE" element.
	A CalDAV server advertises a CALDAV:supported-rscale-set WebDAV		A CalDAV server advertises a CALDAV:supported-rscale-set Web
	property on calendar home or calendar collections if it supports use		Distributed Authoring and Versioning (WebDAV) property on calendar
	of "RSCALE" element as described in this specification. The server		home or calendar collections if it supports use of the "RSCALE"
	can advertise a specific set of supported calendar systems by		element as described in this specification. The server can advertise
	including one or more CALDAV:supported-rscale XML elements within the		a specific set of supported calendar systems by including one or more
	CALDAV:supported-rscale-set XML element. If no CALDAV:supported-		CALDAV:supported-rscale XML elements within the
	rscale XML elements are included in the WebDAV property, then clients		CALDAV:supported-rscale-set XML element. If no
	can try any calendar system value, but need to be prepared for a		CALDAV:supported-rscale XML elements are included in the WebDAV
	failure when attempting to store the calendar data.		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"		Clients MUST NOT attempt to store iCalendar data containing "RSCALE"
	elements if the CALDAV:supported-rscale-set WebDAV property is not		elements if the CALDAV:supported-rscale-set WebDAV property is not
	advertised by the server.		advertised by the server.
	The server SHOULD return an HTTP 403 response with a DAV:error		The server SHOULD return an HTTP 403 response with a DAV:error
	element containing a CALDAV:supported-rscale XML element, if a client		element containing a CALDAV:supported-rscale XML element, if a client
	attempts to store iCalendar data with an "RSCALE" element value not		attempts to store iCalendar data with an "RSCALE" element value not
	supported by the server.		supported by the server.
	It is possible for an "RSCALE" value to be present in calendar data		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		on the server being accessed by a client that does not support an
	"RSCALE" element or its specified value. It is expected that		"RSCALE" element or its specified value. It is expected that
	existing clients, unaware of "RSCALE", will fail gracefully by		existing clients, unaware of "RSCALE", will fail gracefully by
	ignoring the calendar component, whilst still processing other		ignoring the calendar component, while still processing other
	calendar data on the server (as per option (2) in Section 6).		calendar data on the server (as per option (2) in Section 6).
	10.1. CALDAV:supported-rscale-set Property		10.1. CALDAV:supported-rscale-set Property
	Name: supported-rscale-set		Name: supported-rscale-set
	Namespace: urn:ietf:params:xml:ns:caldav		Namespace: urn:ietf:params:xml:ns:caldav
	Purpose: Enumerates the set of supported iCalendar "RSCALE" element		Purpose: Enumerates the set of supported iCalendar "RSCALE" element
	values supported by the server.		values supported by the server.
	Protected: This property MUST be protected and SHOULD NOT be		Protected: This property MUST be protected and SHOULD NOT be
	returned by a PROPFIND allprop request (as defined in Section 14.2		returned by a PROPFIND allprop request (as defined in Section 14.2
	of [RFC4918]).		of [RFC4918]).
	Description: See above.		Description: See above.
	Definition:		Definition:
	<!ELEMENT supported-rscale-set (supported-rscale*) >		<!ELEMENT supported-rscale-set (supported-rscale*)>
	<!ELEMENT supported-rscale (#PCDATA)>		<!ELEMENT supported-rscale (#PCDATA)>
	<!-- PCDATA value: string - case-insensitive but		<!-- PCDATA value: string - case insensitive but
	uppercase preferred -->		uppercase preferred -->
	Example:		Example:
	<C:supported-rscale-set		<C:supported-rscale-set
	xmlns:C="urn:ietf:params:xml:ns:caldav">		xmlns:C="urn:ietf:params:xml:ns:caldav">
	<C:supported-rscale>GREGORIAN</C:supported-rscale>		<C:supported-rscale>GREGORIAN</C:supported-rscale>
	<C:supported-rscale>CHINESE</C:supported-rscale>		<C:supported-rscale>CHINESE</C:supported-rscale>
	<C:supported-rscale>ISLAMIC-CIVIL</C:supported-rscale>		<C:supported-rscale>ISLAMIC-CIVIL</C:supported-rscale>
	<C:supported-rscale>HEBREW</C:supported-rscale>		<C:supported-rscale>HEBREW</C:supported-rscale>
	<C:supported-rscale>ETHIOPIC</C:supported-rscale>		<C:supported-rscale>ETHIOPIC</C:supported-rscale>
	</C:supported-rscale-set>		</C:supported-rscale-set>
	11. Security Considerations		11. Security Considerations
	This specification does not introduce any addition security concerns		This specification does not introduce any additional security
	beyond those described in [RFC5545], [RFC5546], and [RFC4791].		concerns beyond those described in [RFC5545], [RFC5546], and
			[RFC4791].
	12. IANA Considerations
	This document requires no IANA actions.
	13. Acknowledgments
	Thanks to the following for feedback: Mark Davis, Mike Douglass,
	Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, Barry
	Leiba, 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.
	14. References		12. References
	14.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,		[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
	"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,		"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
	March 2007.		March 2007, <http://www.rfc-editor.org/info/rfc4791>.
	[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918, June 2007.		Authoring and Versioning (WebDAV)", RFC 4918, June 2007,
			<http://www.rfc-editor.org/info/rfc4918>.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008,
			<http://www.rfc-editor.org/info/rfc5234>.
	[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling		[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
	Core Object Specification (iCalendar)", RFC 5545,		Scheduling Core Object Specification (iCalendar)", RFC
	September 2009.		5545, September 2009,
			<http://www.rfc-editor.org/info/rfc5545>.
	[RFC5546] Daboo, C., "iCalendar Transport-Independent		[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
	Interoperability Protocol (iTIP)", RFC 5546, December		Interoperability Protocol (iTIP)", RFC 5546, December
	2009.		2009, <http://www.rfc-editor.org/info/rfc5546>.
	[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML		[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
	Format for iCalendar", RFC 6321, August 2011.		Format for iCalendar", RFC 6321, August 2011,
			<http://www.rfc-editor.org/info/rfc6321>.
	[RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON		[RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
	Format for iCalendar", RFC 7265, May 2014.		Format for iCalendar", RFC 7265, May 2014,
			<http://www.rfc-editor.org/info/rfc7265>.
	[UNICODE.CLDR]		[UNICODE.CLDR]
	"CLDR calendar.xml Data", Unicode Consortium CLDR,		The Unicode Consortium, "CLDR calendar.xml Data", Unicode
			Consortium CLDR,
	<http://www.unicode.org/repos/cldr/tags/latest/common/		<http://www.unicode.org/repos/cldr/tags/latest/common/
	bcp47/calendar.xml>.		bcp47/calendar.xml>.
	14.2. Informative References		12.2. Informative References
	[ISO.8601.2004]		[ISO.8601.2004]
	International Organization for Standardization, "Data		International Organization for Standardization, "Data
	elements and interchange formats - Information interchange		elements and interchange formats - Information interchange
	- Representation of dates and times", ISO Standard 8601,		- Representation of dates and times", ISO Standard 8601,
	2004.		December 2004.
	[UNICODE.ICU]		[UNICODE.ICU]
	"International Components for Unicode", Unicode Consortium		"International Components for Unicode", April 2014,
	ICU, April 2014, <http://site.icu-project.org>.		<http://site.icu-project.org>.
	Appendix A. Change History (To be removed by RFC Editor before
	publication)
	Changes in draft-ietf-calext-rscale-04:
	1. AD review: Clarified that {} prefix is purely illustrative.
	2. AD review: reworded SKIP formal syntax comment.
	3. AD review: clarified mapping of ICU to iCalendar months for
	Hebrew calendar.
	4. AD review: tweaked introductory text of Chinese example.
	5. AD review: changed Ethiopic example to use MONTHLY and explained
	why that rule was chosen.
	6. AD review: removed "SHOULD" for RSCALE upper case.
	7. AD review: "SKIP" - added new section, changed the default value.
	8. OPSDIR review: fixed Ethiopic example.
	Changes in draft-ietf-calext-rscale-03:
	1. Reworded abstract.
	2. Added list of changes to other specs in Section 1.
	3. Clarified behavior wrt VTIMEZONE in Section 1.
	Changes in draft-ietf-calext-rscale-02:
	1. Added xCal and jCal changes sections and relax NG schema
	appendix.
	2. Added ICU reference at the end of Section 1.
	Changes in draft-ietf-calext-rscale-01:
	1. Editorial changes/fixes per document shepherd review.
	2. Switched CLDR reference to "tags/latest".
	Changes in draft-ietf-calext-rscale-00:
	1. Updated some references.
	2. Editorial changes/fixes.
	Changes in draft-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 in draft-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.
	Changes in draft-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 in draft-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		Appendix A. xCal RELAX NG Schema Update
	The following changes are made to the RELAX NG schema defined in		The following changes are made to the RELAX NG schema defined in
	Appendix A of [RFC6321].		Appendix A of [RFC6321].
	# 3.3.10 RECUR		# 3.3.10 RECUR
	# This extension adds type-rscale and type-skip,		# This extension adds type-rscale and type-skip,
	# and modifies type-bymonth		# and modifies type-bymonth
	value-recur = element recur {		value-recur = element recur {
	type-rscale?,		type-rscale?,
	skipping to change at page 22, line 5		skipping to change at page 21, line 5
	xsd:positiveInteger |		xsd:positiveInteger |
	xsd:string		xsd:string
	}		}
	type-skip = element skip {		type-skip = element skip {
	"OMIT" |		"OMIT" |
	"BACKWARD" |		"BACKWARD" |
	"FORWARD"		"FORWARD"
	}		}
			Acknowledgments
			Thanks to the following for feedback: Mark Davis, Mike Douglass,
			Donald Eastlake, Peter Edberg, Marten Gajda, Philipp Kewisch, Barry
			Leiba, 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.
	Authors' Addresses		Authors' Addresses
	Cyrus Daboo		Cyrus Daboo
	Apple Inc.		Apple Inc.
	1 Infinite Loop		1 Infinite Loop
	Cupertino, CA 95014		Cupertino, CA 95014
	USA		United States
	Email: cyrus@daboo.name		EMail: cyrus@daboo.name
	URI: http://www.apple.com/		URI: http://www.apple.com/
	Gregory Yakushev		Gregory Yakushev
	Google Inc.		Google Inc.
	Brandschenkestrasse 100		Brandschenkestrasse 100
	8002 Zurich		8002 Zurich
	Switzerland		Switzerland
	Email: yakushev@google.com		EMail: gyakushev@yahoo.com
	URI: http://www.google.com/		URI: http://www.google.com/
End of changes. 85 change blocks.
	301 lines changed or deleted		211 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/