Subject: [calsify] Call for comments for draft-daboo-icalendar-rscale

From: Gregory Yakushev <[email-masked]>
Date: Mon, 6 May 2013 16:27:54 +0200

A draft RFC to support non-Gregorian recurrence rules in iCalendar is
available for discussion. It will allow us to specify events like Chinese
New Year, Ramadan or Korean birthdays. Please see the links below. Comments
are welcome on the [email-masked] mailing list.

If adopted, we are likely to start using it at Google, and recurrences with
RSCALE parameter will appear in iCalendar data provided by us.

Grigory Yakushev
Google Inc.

Title:           Non-Gregorian Recurrence Rules in iCalendar
URL:
http://www.ietf.org/internet-drafts/draft-daboo-icalendar-rscale-00.txt
Status:
http://datatracker.ietf.org/doc/draft-daboo-icalendar-rscale
Htmlized:        http://tools.ietf.org/html/draft-daboo-icalendar-rscale-00

---

From: Philipp Kewisch <[email-masked]>
Date: Mon, 06 May 2013 20:19:55 +0200

I wonder how we should handle this for jCal. the rscale draft says that 
for "leap months", it should be suffixed with an "L". This turns the 
number value into a string value. I don't know if this is correct in the 
calendar system, but in theory we could do this:

[ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", 
"bymonth": "11L" } ]

A parser expecting a number would be pretty confused though.

Philipp

On 5/6/13 4:27 PM, Gregory Yakushev wrote:
> available for discussion. It will allow us to specify events like 
> Chinese New Year, Ramadan or Korean birthdays. Please see the links 
> below. Comments are welcome on the [email-masked] 
> <mailto:[email-masked]> mailing list.
>
> If adopted, we are likely to start using it at Google, and recurrences 
> with RSCALE parameter will appear in iCalendar data provided by us.
>
> Grigory Yakushev
> Google Inc.
>
> Status: http://datatracker.ietf.org/doc/draft-daboo-icalendar-rscale
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Philipp Kewisch <[email-masked]>
Date: Mon, 06 May 2013 21:25:56 +0200

That won't work for multiple months where only one of them is leapmonth:

[ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth": [8, "11L"] } ]

Philipp

On 5/6/13 9:09 PM, Michael Angstadt wrote:
> What if you added a "leapMonth" boolean field?
>
> "bymonth": 11, "leapMonth": true } ]
>
> -Mike
>
> On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch <[email-masked]> wrote:
>> I wonder how we should handle this for jCal. the rscale draft says that for
>> "leap months", it should be suffixed with an "L". This turns the number
>> value into a string value. I don't know if this is correct in the calendar
>> system, but in theory we could do this:
>>
>> [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth":
>> "11L" } ]
>>
>> jcardcal mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jcardcal
>>

---

From: Gregory Yakushev <[email-masked]>
Date: Mon, 6 May 2013 22:31:40 +0200

Our primary motivation to use 'L' suffix over LEAPMONTH=TRUE was that RRULE
is a string anyway, and 'L' is shorter. But if you have a structured
representation of RRULE, using a separate boolean makes total sense. To
expand the RRULE you will need some library (such as icu-project.org),
which probably accepts leap months as a boolean and not an 'L' suffix.

For clients not supporting RSCALE parameter it is actually better to fail
on recurrence rules that have it, because otherwise they will produce
incorrect expansion and cause a date inconsistency.

On Mon, May 6, 2013 at 9:25 PM, Philipp Kewisch <[email-masked]> wrote:

> On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch <[email-masked]> <[email-masked]> wrote:
>
> URL:http://www.ietf.org/internet-drafts/draft-daboo-icalendar-rscale-00.txt
> Status:http://datatracker.ietf.org/doc/draft-daboo-icalendar-rscale
> calsify mailing [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
>
>
>
> jcardcal mailing [email-masked]://www.ietf.org/mailman/listinfo/jcardcal
>
>
>

---

From: Gregory Yakushev <[email-masked]>
Date: Mon, 6 May 2013 22:37:20 +0200

I see your point about the {8, "11L"} case. As an option, you can do this: [
"rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth":
[8], "byleapmonth": [11] } ]

On Mon, May 6, 2013 at 10:31 PM, Gregory Yakushev <[email-masked]>wrote:

> Our primary motivation to use 'L' suffix over LEAPMONTH=TRUE was that
> RRULE is a string anyway, and 'L' is shorter. But if you have a structured

---

From: Philipp Kewisch <[email-masked]>
Date: Mon, 6 May 2013 23:16:14 +0200

In that case the RSCALE draft should also be changed to add BYLEAPMONTH. I would be fine with this implementation, parsers that don't know rscale won't totally freak out.

Philipp

On May 6, 2013, at 22:37, Gregory Yakushev <[email-masked]> wrote:

> I see your point about the {8, "11L"} case. As an option, you can do this: [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymonth": [8], "byleapmonth": [11] } ]
> 
> 
> On Mon, May 6, 2013 at 10:31 PM, Gregory Yakushev <[email-masked]> wrote:
>> Our primary motivation to use 'L' suffix over LEAPMONTH=TRUE was that RRULE is a string anyway, and 'L' is shorter. But if you have a structured representation of RRULE, using a separate boolean makes total sense. To expand the RRULE you will need some library (such as icu-project.org), which probably accepts leap months as a boolean and not an 'L' suffix.
>> 
>> For clients not supporting RSCALE parameter it is actually better to fail on recurrence rules that have it, because otherwise they will produce incorrect expansion and cause a date inconsistency.
>> 
>>

---

From: James Lal <[email-masked]>
Date: Mon, 6 May 2013 16:04:16 -0700

BYLEAPMONTH+1 gives us a clear(er) way to opt-into new features and
optimize specifically for them..

On Mon, May 6, 2013 at 2:16 PM, Philipp Kewisch <[email-masked]> wrote:

> In that case the RSCALE draft should also be changed to add BYLEAPMONTH. I
> would be fine with this implementation, parsers that don't know rscale
> won't totally freak out.
>
> Philipp
>
>
>
>> On Mon, May 6, 2013 at 9:25 PM, Philipp Kewisch <[email-masked]>wrote:
>>

---

From: Gregory Yakushev <[email-masked]>
Date: Tue, 7 May 2013 22:20:23 +0200

Thanks for the comments! We will consider replacing 'L' suffix with
BYLEAPMONTH parameter in the next draft. There will be slight delay because
my coauthor (Cyrus Daboo) is on vacation.

Is there anything else that sticks out in the proposal?

On Tue, May 7, 2013 at 1:04 AM, James Lal <[email-masked]> wrote:

>> In that case the RSCALE draft should also be changed to add BYLEAPMONTH.
>> I would be fine with this implementation, parsers that don't know rscale
>> won't totally freak out.
>>
>> Philipp
>>
>>
>>
>> I see your point about the {8, "11L"} case. As an option, you can do
>> this: [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY",
>> "bymonth": [8], "byleapmonth": [11] } ]
>>
>>
>>> For clients not supporting RSCALE parameter it is actually better to
>>> fail on recurrence rules that have it, because otherwise they will produce

---

From: Gregory Yakushev <[email-masked]>
Date: Tue, 7 May 2013 23:37:15 +0200

Yes, I think there's no strong reason for that requirement, we can remove
it. The motivation was that RSCALE parameter influences valid ranges of
other parameters, so needs to be parsed first. But it is probably not
strong enough argument for this requirement.

On Tue, May 7, 2013 at 10:47 PM, Caleb Richardson <[email-masked]
> wrote:

> Is there any reason for the following text in section 5? If not, I
> recommend removing it.
>
> The "RSCALE" element MUST be included as the first element in the "RRULE"
> value if present.
>
> This doesn't seem consistent with other iCalendar parameters, for example
> RFC 5545 specifically states that RRULE parts are not ordered in any
> particular sequence. It adds a small amount of complexity when outputting
> an iCalendar stream, especially if parameters are simply stored as a map.
>
> Caleb
>
> On May 7, 2013, at 1:20 PM, Gregory Yakushev <[email-masked]> wrote:
>
> "bymonth": [8, "11L"] } ]
> >>
> >> Philipp
> >>
> >>> On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch
> >>> <[email-masked]>
> >>>  wrote:
> >>>
> "bymonth":
> Chinese
> >>>> are welcome on the
> >>>>  mailing list.
> >>>> Htmlized:
> >>>> http://tools.ietf.org/html/draft-daboo-icalendar-rscale-00
> >>>>
> >>>>
> >>>>