From yakushev@google.com Mon Jun 17 02:55:16 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64D621F96D9 for ; Mon, 17 Jun 2013 02:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4GMw1QjsZ+L for ; Mon, 17 Jun 2013 02:55:15 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6E01321F9811 for ; Mon, 17 Jun 2013 02:55:15 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id p12so1762575vbe.40 for ; Mon, 17 Jun 2013 02:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EhF7/2xJge/AGvm1EUYtZJE7Vzudc0hbM2EAVckRQxU=; b=ipfowqwyR9+z2PdSfKhztORywaAbQLLJiqTCW0qHHGqp2McXWNjS5m6kmek3NoW0uK YZYz1VUmjBJ8tAN6Ls70eGYgkXyxfX5NfIaiP5nNb6w/Otm4qDaasPK69QPkS71RJWaE 2KuojTT5ahaXUgy3i6okhsRfXdTIOudZg0FKzc6pqc1ANtpmwLy1msaX/TCgaHXslSZa 7gFHvEbFq1Hx4/lP7sZmJkjq2Fpk1XjF2un3ugWkFRciUqu4OxHtb0ZW8sNN5MzS+NWd dTDl+lOnMRH+KmFth8A836HVeg5wuUgxTxEWgziEzOuSW4rW+tXLeZzlvlmPZ6jaNsPp 2sjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=EhF7/2xJge/AGvm1EUYtZJE7Vzudc0hbM2EAVckRQxU=; b=BMkYEc0RNlxT6kM2bzIIpD7pyIj1VvGhc0egFoDkihtqDu/+uivsM7ygefI7W6wNWT JSYB4/ZTMYlqm7tKAaWKv43JFZG2r3j1lqP+l0tDGGSZiBj7rN1+0Lp6ds+uzVDvOSHw ReRuqlmKtgmwUDqvzb2tLeDB28Qrz2qV8ZcN9NcS4y6JSvkDLWg3mopfCIQjb4K4w1ox 3vYNJGZJFRhQhpb4IDdYU/xhs6plPnjcVdLyg31R3P6VxKriItrj6NvBGxQ3JAXm+Iza pa5bdexGTQYqtWXynP/vD04koWUsOfaGwzastQIfElgC7jnmtyXXSRFWcBdvD7B/1f/A 2kPg== MIME-Version: 1.0 X-Received: by 10.52.76.36 with SMTP id h4mr18893vdw.113.1371462914311; Mon, 17 Jun 2013 02:55:14 -0700 (PDT) Received: by 10.58.208.81 with HTTP; Mon, 17 Jun 2013 02:55:14 -0700 (PDT) Date: Mon, 17 Jun 2013 11:55:14 +0200 Message-ID: From: Gregory Yakushev To: Calsify , caldeveloper-l@lists.calconnect.org, "jcardcal@ietf.org" , Cyrus Daboo , Arnaud Quillaud Content-Type: multipart/alternative; boundary=20cf3071c8c2d4d0e804df5697d0 X-Gm-Message-State: ALoCoQkJ/EMq6sk2CngtEe5acziTFlMHliqrp9MqtChYEx6xCqhiz4n+HMKOR9OPUU2yR5PplsJRsHNPhAvI3eeCPeuhkCq+wibPjs6phPvpxyVK2OHcR8Cq/BMs7R95B4eVn1Bb5fFCvm+JS0gXIGopS+T0Z4d0k8kaUmqkeVjgHv0XkSUKW+5W/pEwQBazJmxzYawq7pqR Subject: [calsify] Call for action: fail RRULE parsing on unknown parameters X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 09:55:16 -0000 --20cf3071c8c2d4d0e804df5697d0 Content-Type: text/plain; charset=ISO-8859-1 This letter is an outcome of CalConnect round table discussion. Currently some calendaring libraries and services silently ignore RRULE parameters they don't understand. Such behavior contradicts the spec ( http://tools.ietf.org/html/rfc5545#section-3.3.10), and prevents any extension to the RRULE behavior. We want to add a new parameter to the RRULE, which modifies set of instances produced by it. If a client or service silently ignores the new parameter, it will produce incorrect set of instances causing data inconsistency. The best such a client can do is to reject RRULE it doesn't understand, and do not produce any set of instances for it. Bug will be filed shortly for ical4j, fixing which should also fix all dependent services (including our Google Calendar). If you are aware of other implementations of iCalendar parsing, please post here so we can cover them too. Best Regards Grisha Google Inc. --20cf3071c8c2d4d0e804df5697d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This letter is an outcome of CalConnect round t= able discussion.

Currently some calendaring libraries a= nd services silently ignore RRULE parameters they don't understand. Suc= h behavior contradicts the spec (http://tools.ietf.org/html/rfc5545#section-3.3.10),= and prevents any extension to the RRULE behavior.

We want to add a new parameter to the RRULE, which mod= ifies set of instances produced by it. If a client or service silently igno= res the new parameter, it will produce incorrect set of instances causing d= ata inconsistency. The best such a client can do is to reject RRULE it does= n't understand, and do not produce any set of instances for it.

Bug will be filed shortly for ical4j, fixin= g which should also fix all dependent services (including our Google Calend= ar). If you are aware of other implementations of iCalendar parsing, please= post here so we can cover them too.

Best Regards
Grisha
Google Inc.
--20cf3071c8c2d4d0e804df5697d0-- From yakushev@google.com Mon Jun 17 11:21:25 2013 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E921F9C62 for ; Mon, 17 Jun 2013 11:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcXK5pJUvPar for ; Mon, 17 Jun 2013 11:21:24 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A65B821F9C23 for ; Mon, 17 Jun 2013 11:21:23 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id da11so2368049veb.20 for ; Mon, 17 Jun 2013 11:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ocRSwZoo4VaqG++/gc/k/SUFaGNJdVdvkwY7iLorMwQ=; b=VQim/aTzvnF7dMMgDzbx8peHwIFVLnmhfJ55JD3I7Dr8ETQHjCfgBEaI6EYkQzvfTH Eq4/nIoA1uhs+qjxLlwz/CSyGWGbwtF8JxE9FX+2p5O6swNCeRDU4F+cT/9OlFPPjTej qoPiiZhENo2Rl5rEJyBnTjXxh14bJYSEFb6bmysejlzVExEH7FYZcAO6kYeY344Zlq9V LzQTcyQ7LfX4uPcziyFHWyEfIiWqk4zvIjyevgF4V14RAehgx2H7NWRH6d7zlE1q5eKv JOP4CtXVku9KpW650jQ9w4TJbcSDJCDnUPEhXH0x0IHTseypiKGS19kQShCFioMnZubZ 5Ltg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ocRSwZoo4VaqG++/gc/k/SUFaGNJdVdvkwY7iLorMwQ=; b=bKCPcDHt+Gqxc5bBMLFhneN5l76XpiwS9+c0UlgxliAa+1Hl2cAi1jyg9TrtfJI+O4 0xpu6k53WX6EY9WpAwFwHBitiAZ9E3YBK61zBEcBu5dfOxGpjNMCaUdnME62VwhwlH1M zDBibm36zDJCAngFGIbj8P6nZ3JjnwDO7X7dsPwbEzUUz2xhFltj0nXyKhgIBSV4Iuzy q59vFdQpAjP6c6vXE21X+64G4q/V17Ow5XzNiHJAARDzYjCbciugUja4WtOzPLGX4eRE 5zPmDQt1yta4sJ8OnLtxODB2tTeDJKxBbtUNpHhScYvUxLZ3FR29IdJvJJJafH4yWrng 7gbA== MIME-Version: 1.0 X-Received: by 10.221.24.75 with SMTP id rd11mr3949854vcb.81.1371493282839; Mon, 17 Jun 2013 11:21:22 -0700 (PDT) Received: by 10.58.208.81 with HTTP; Mon, 17 Jun 2013 11:21:22 -0700 (PDT) In-Reply-To: References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> <0F9E6C44-6D96-45A0-ADCD-A69D9561996C@gmail.com> Date: Mon, 17 Jun 2013 20:21:22 +0200 Message-ID: From: Gregory Yakushev To: Caleb Richardson Content-Type: multipart/alternative; boundary=001a11335dfeef9e6804df5da9c7 X-Gm-Message-State: ALoCoQnQaTr3/DcgFbgwS1auuNg5RzI4nDXpsSbGhoysMjATj+xkfr1EsvlolAmvkrJ6ZoR3rpnCSLkEWK18KFryhyFoMGEWSlmtzOHMkFPwhg9SIMSTvZQqZ49AojZdLMxMiYMgW+gd4WngYyWSV0tO012XLd1q7D1DrGTGSCjb5vJGuHkA5XsLHdni0WPw56YjvMbEWjGO Cc: Calsify , "jcardcal@ietf.org" Subject: Re: [calsify] [Jcardcal] Call for comments for draft-daboo-icalendar-rscale X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 18:21:25 -0000 --001a11335dfeef9e6804df5da9c7 Content-Type: text/plain; charset=ISO-8859-1 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 calsify@ietf.org 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 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 < > calebrichardson@gmail.com> 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 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 >> 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 >> 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 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 >> 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 >> 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 >> >>> >> >>> 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 >> >>>> calsify@ietf.org >> >>>> 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 >> >>>> >> >>>> calsify@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/calsify >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> jcardcal mailing list >> >>>> >> >>>> jcardcal@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/jcardcal >> >>>> >> >>>> >> >>>> >> >> >> >> >> >> _______________________________________________ >> >> calsify mailing list >> >> calsify@ietf.org >> >> https://www.ietf.org/mailman/listinfo/calsify >> >> >> >> >> >> >> >> _______________________________________________ >> >> calsify mailing list >> >> calsify@ietf.org >> >> https://www.ietf.org/mailman/listinfo/calsify >> > >> > _______________________________________________ >> > jcardcal mailing list >> > jcardcal@ietf.org >> > https://www.ietf.org/mailman/listinfo/jcardcal >> > >> > >> > >> > _______________________________________________ >> > jcardcal mailing list >> > jcardcal@ietf.org >> > https://www.ietf.org/mailman/listinfo/jcardcal >> >> > --001a11335dfeef9e6804df5da9c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On the 'L' suffix versus BYLEAPMONTH parameter for= leap months:

We had discussed this at the CalConnect ro= und 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 incorre= ct 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 e= ncountering unknown parameters (a separate thread posted to calsify@ietf.org for it).

2. Clients can receive a variet= y 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 controlle= d manner.

3. There are already parameters that are us= ually numeric, but occasionally not. For example, it is currently possible = to specify BYDAY=3D-2MO parameter, and parsers are expected to handle it. S= o having a numeric value with a suffix in a familiar concept in iCalendar.<= /div>

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 w= ould need to specify such a recurrence. Event birthdays happening in leap m= onth can be easily specified with just FREQ=3DYEARLY 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 rel= evant 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, Gre= gory Yakushev <yakushev@google.com> wrote:
Yes, I think there's no= strong reason for that requirement, we can remove it. The motivation was t= hat 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 <calebrichardson@gmail.com> wrote:
Is there any reason for the following text i= n 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 examp= le RFC 5545 specifically states that RRULE parts are not ordered in any par= ticular sequence. It adds a small amount of complexity when outputting an i= Calendar stream, especially if parameters are simply stored as a map.

Caleb

On May 7, 2013, at 1:20 PM, Gregory Yakushev <yakushev@google.com> wrote:

> Thanks for the comments! We will consider replacing 'L' suffix= with BYLEAPMONTH parameter in the next draft. There will be slight delay b= ecause 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 <james@lightsofapollo.com> wrot= e:
> BYLEAPMONTH+1 gives us a clear(er) way to opt-into new features and op= timize specifically for them..
>
>
> On Mon, May 6, 2013 at 2:16 PM, Philipp Kewisch <kewisch@gmail.com> wrote:
> In that case the RSCALE draft should also be changed to add BYLEAPMONT= H. I would be fine with this implementation, parsers that don't know rs= cale won't totally freak out.
>
> Philipp
>
>
>
> On May 6, 2013, at 22:37, Gregory Yakushev <yakushev@google.com> wrote:
>
>> I see your point about the {8, "11L"} case. As an option= , you can do this: [ "rrule", {}, "recur", { "rsca= le": " CHINESE", "freq": "YEARLY", "= ;bymonth": [8], "byleapmonth": [11] } ]
>>
>>
>> On Mon, May 6, 2013 at 10:31 PM, Gregory Yakushev <yakushev@google.com> wr= ote:
>> Our primary motivation to use 'L' suffix over LEAPMONTH=3D= 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 mak= es total sense. To expand the RRULE you will need some library (such as icu-project.org), whi= ch 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 produ= ce incorrect expansion and cause a date inconsistency.
>>
>>
>> On Mon, May 6, 2013 at 9:25 PM, Philipp Kewisch <kewisch@gmail.com> wrote: >> That won't work for multiple months where only one of them is = leapmonth:
>>
>> [ "rrule", {}, "recur", { "rscale": = " CHINESE", "freq": "YEARLY", "bymonth&q= uot;: [8, "11L"] } ]
>>
>> Philipp
>>
>> On 5/6/13 9:09 PM, Michael Angstadt wrote:
>>> What if you added a "leapMonth" boolean field?
>>>
>>> [ "rrule", {}, "recur", { "rscale&quo= t;: " CHINESE", "freq": "YEARLY",
>>> "bymonth": 11, "leapMonth": true } ]
>>>
>>> -Mike
>>>
>>> On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch
>>> <kew= isch@gmail.com>
>>> =A0wrote:
>>>
>>>> I wonder how we should handle this for jCal. the rscale dr= aft says that for
>>>> "leap months", it should be suffixed with an &qu= ot;L". This turns the number
>>>> value into a string value. I don't know if this is cor= rect in the calendar
>>>> system, but in theory we could do this:
>>>>
>>>> [ "rrule", {}, "recur", { "rscale= ": " CHINESE", "freq": "YEARLY", "b= ymonth":
>>>> "11L" } ]
>>>>
>>>> A parser expecting a number would be pretty confused thoug= h.
>>>>
>>>> Philipp
>>>>
>>>>
>>>> On 5/6/13 4:27 PM, Gregory Yakushev wrote:
>>>>
>>>> A draft RFC to support non-Gregorian recurrence rules in i= Calendar is
>>>> available for discussion. It will allow us to specify even= ts like Chinese
>>>> New Year, Ramadan or Korean birthdays. Please see the link= s below. Comments
>>>> are welcome on the
>>>> cals= ify@ietf.org
>>>> =A0mailing 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: =A0 =A0 =A0 =A0 =A0 Non-Gregorian Recurrence Rules = in iCalendar
>>>> URL:
>>>>
>>>> http://www.ietf.org/internet-dr= afts/draft-daboo-icalendar-rscale-00.txt
>>>>
>>>> Status:
>>>>
>>>> http://datatracker.ietf.org/doc/draft-dabo= o-icalendar-rscale
>>>>
>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-daboo-icale= ndar-rscale-00
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> calsify mailing list
>>>>
>>>> cals= ify@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/calsify
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jcardcal mailing list
>>>>
>>>> jca= rdcal@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jcardcal
>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________
>> calsify mailing list
>> calsify@ietf= .org
>> https://www.ietf.org/mailman/listinfo/calsify
>>
>>
>>
>> _______________________________________________
>> calsify mailing list
>> calsify@ietf= .org
>> https://www.ietf.org/mailman/listinfo/calsify
>
> _______________________________________________
> jcardcal mailing list
> jcardcal@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/jcardcal
>
>
>
> _______________________________________________
> jcardcal mailing list
> jcardcal@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/jcardcal



--001a11335dfeef9e6804df5da9c7--