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

From: Gregory Yakushev <[email-masked]>
Date: Mon, 17 Jun 2013 20:21:22 +0200

On the 'L' suffix versus BYLEAPMONTH parameter for leap months:

We had discussed this at the CalConnect round table, and consensus was to
keep the 'L' suffix. Below are some of our thoughts on it:

1. Failing the parsing when client cannot understand an RRULE is actually
the best it can do. Otherwise it risks producing incorrect set of instances
and cause data inconsistency. In fact, we issued a call to make sure most
libraries and calendar systems fail RRULE parsing when encountering unknown
parameters (a separate thread posted to [email-masked] for it).

2. Clients can receive a variety of broken data, and should treat
unexpected BYMONTH value in the same way as any other kind of garbage in
the input: fail the parsing in a controlled manner.

3. There are already parameters that are usually numeric, but occasionally
not. For example, it is currently possible to specify BYDAY=-2MO parameter,
and parsers are expected to handle it. So having a numeric value with a
suffix in a familiar concept in iCalendar.

4. Adding a new BYLEAPMONTH parameter is a major hassle for an extremely
rare edge case: we would have to define a new value type for it and include
it in FREQ compatibility table, bloating the spec. All the while leap
months are only possible in a handful of eastern calendars, and even in
them we do not have a practical example why people would need to specify
such a recurrence. Event birthdays happening in leap month can be easily
specified with just FREQ=YEARLY and proper DTSTART.

5. We are modifying iCalendar spec which is 15 years old (at least RFC2445
is). It is likely that the spec will be relevant long after our current
interoperability concerns will be history. So, while we do need to ensure
smooth transition, we'd prefer not to base design decisions primarily
around legacy client interoperability.

What do you think?
Grisha

On Tue, May 7, 2013 at 11:37 PM, Gregory Yakushev <[email-masked]>wrote:

> 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:
>>
>> > 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:
>> > 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 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.
>> >>
>> >>
>> >> On Mon, May 6, 2013 at 9:25 PM, Philipp Kewisch <[email-masked]>
>> wrote:
>> >> 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?
>> >>>
>> >>> [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY",
>> >>> "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" } ]
>> >>>>
>> >>>> A parser expecting a number would be pretty confused though.
>> >>>>
>> >>>> Philipp
>> >>>>
>> >>>>
>> >>>> On 5/6/13 4:27 PM, Gregory Yakushev wrote:
>> >>>>
>> >>>> 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
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> calsify mailing list
>> >>>>
>> >>>> [email-masked]
>> >>>> https://www.ietf.org/mailman/listinfo/calsify
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> jcardcal mailing list
>> >>>>
>> >>>> [email-masked]
>> >>>> https://www.ietf.org/mailman/listinfo/jcardcal
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >> _______________________________________________
>> >> calsify mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/calsify
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> calsify mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/calsify
>> >
>> > _______________________________________________
>> > jcardcal mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/jcardcal
>> >
>> >
>> >
>> > _______________________________________________
>> > jcardcal mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/jcardcal
>>
>>
>