7 May 2013 23:37
Re: [Jcardcal] Call for comments for draft-daboo-icalendar-rscale
Gregory Yakushev <yakushev <at> google.com>
2013-05-07 21:37:15 GMT
2013-05-07 21:37:15 GMT
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 <at> 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 <yakushev <at> 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 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 <james <at> lightsofapollo.com> 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 <kewisch <at> gmail.com> 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 <yakushev <at> google.com> 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 <yakushev <at> google.com> 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 <kewisch <at> gmail.com> 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
>>> <kewisch <at> gmail.com>
>>> 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 <at> 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 <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/calsify
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jcardcal mailing list
>>>>
>>>> jcardcal <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jcardcal
>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________
>> calsify mailing list
>> calsify <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify
>>
>>
>>
>> _______________________________________________
>> calsify mailing list
>> calsify <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify
>
> _______________________________________________
> jcardcal mailing list
> jcardcal <at> ietf.org
> https://www.ietf.org/mailman/listinfo/jcardcal
>
>
>
> _______________________________________________
> jcardcal mailing list
> jcardcal <at> ietf.org
> https://www.ietf.org/mailman/listinfo/jcardcal
_______________________________________________ calsify mailing list calsify <at> ietf.org https://www.ietf.org/mailman/listinfo/calsify
RSS Feed