From yakushev@google.com Mon May 6 07:28:02 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 DCA8821F92BC for ; Mon, 6 May 2013 07:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 63zpAxmnZq3b for ; Mon, 6 May 2013 07:28:02 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEC521F91AB for ; Mon, 6 May 2013 07:27:59 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x14so2934179vbb.6 for ; Mon, 06 May 2013 07:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=qlvi43CVRDSkyZ6BuMCi17q+uciz7gFoNX3RrjQ1lbc=; b=GPuABBgEEYb0nka6oZDiHd64V4hhhWMQd9N88Bg1p8luN+a68vXwfiIH3ZzYjB2Nlq d1GbKqX1Acs8xFIJN+rO2kcXgI1O5Shancw6ZOeW8vMoBmyBelaAiSSXw3iY1uHiehEF 4G4nzp1sK9+eClhZ0Sj5j6y6g7GZxAqX2NfBYu24FoWtoCYEXZYb5CZE6V2FM42MMIdO mtP0peOb/mCDninuqIuC/bZoQSt+OGL6VWHQgke+b7IceH2pMsMxFMNZL9VucXyd/wF7 i2/jbD+zJ3k5s7tIx+izaFeLhdHjL5KcGlzUR+ctoMUXyLAKFEPCiXDAvbQ2TyjSWkw0 9Jxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=qlvi43CVRDSkyZ6BuMCi17q+uciz7gFoNX3RrjQ1lbc=; b=mSD1dBsabYlnguHlW+wYhTWTkhlcpfDuaoC95wERyrANxFuhDV7t0jviLAq5rO7fG7 V+dPwyr1Gcw7h7ahxLp5IDPQ9jOh4xdob2TkwovuYi0JwZG5LUQzFHOKkdrUsGOQpi6G Mz7oVNqgpz7hsAoed7scrK2r3LFvYEojSGQF+tcrHkojI39VWyc0B4GDls9n5I8c+6Yo Betdo8m2f1y3WZJTAKNLjMiMkX1+QSgAvaWQbECteizDryCJd79BzwV10MVnhTWPCUoh m+RuJvkIP3ALJVfZUuEkf/AMPteS68R/c8jdn/0fSTNPFuC8TUab8Tu39SOHKI71CRc2 GzlA== MIME-Version: 1.0 X-Received: by 10.58.15.193 with SMTP id z1mr6873839vec.40.1367850474862; Mon, 06 May 2013 07:27:54 -0700 (PDT) Received: by 10.59.5.165 with HTTP; Mon, 6 May 2013 07:27:54 -0700 (PDT) Date: Mon, 6 May 2013 16:27:54 +0200 Message-ID: From: Gregory Yakushev To: calsify@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d9589a9152b04dc0d8150 X-Gm-Message-State: ALoCoQkhX20IqMZQ36XnBvAIin9aD0c1CdEyFSd9eqxWAeii89s7IUsvbwuzsPUhXVehiH+TUcwqhso8x8W5EFApyG+/ft3rh31SVBLMyEXmBH37MOOhyeu8IAknyG1Z0CyTyLj0F8340PKyGjZaBfnvQ4rLd0I2SAqOTne0MO4TpuF/GzrX0HJuD/8z1FajPGlylwT6wyqi Subject: [calsify] 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, 06 May 2013 14:28:03 -0000 --047d7b5d9589a9152b04dc0d8150 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7b5d9589a9152b04dc0d8150 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A draft RFC to support non-Gregorian recurrence= rules in=A0iCalendar=A0is available for discussion. It will allow us to sp= ecify 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<= br>
Google Inc.

Title: =A0 =A0 =A0 = =A0 =A0 Non-Gregorian Recurrence Rules in iCalendar
URL: =A0 =A0 = =A0 =A0 =A0 =A0=A0http://www.ietf.org/internet-d= rafts/draft-daboo-icalendar-rscale-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/= draft-daboo-icalendar-rscale
Htmlized: =A0 =A0 =A0 =A0= http://tools.ietf.org/html/draft-daboo-icalendar-rscale-00
--047d7b5d9589a9152b04dc0d8150-- From kewisch@gmail.com Mon May 6 11:19:54 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 2725D21F912C; Mon, 6 May 2013 11:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 2Yf5KQHQa5Ws; Mon, 6 May 2013 11:19:53 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1E21F911E; Mon, 6 May 2013 11:19:52 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id w5so1744785bku.33 for ; Mon, 06 May 2013 11:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=pVFOem/cEQhesyNzc2QLznShGjk2WQajEftfnBZWvMk=; b=QOJFrDAeVi8DIjAMn1E768NOXOWwXJRgGcZW23hNUNq6y3A3zfC/Dyrr+tsj3YFpUn 2xbaJfWr784MKNdvEYakZQBMoy/0XlTH3hcSQ48L07Fe6/KpMB5wnHf/YMUs2ZyEVrqF 9zZ8YjICbRIBDe/66c86OEImttNDRIr/oFvxCbN0aTXaGx7IChFSMKa6vP8TCTUxCEhy pJeyH7hlEhO1anUe4uBnoS3rTl4S2GUfXRa31BWXiD92l7nOqNKDnL5aMNm1idqzcYCB mMAmOfInrihgbC7FN6kFrp3ZyvzptV9NOnAkABFM6fKbHKgQZX72lNLTI1uW054x+d54 F3zg== X-Received: by 10.204.185.70 with SMTP id cn6mr8954233bkb.100.1367864391730; Mon, 06 May 2013 11:19:51 -0700 (PDT) Received: from oskar.local (e177194200.adsl.alicedsl.de. [85.177.194.200]) by mx.google.com with ESMTPSA id da16sm5711338bkb.2.2013.05.06.11.19.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 11:19:51 -0700 (PDT) Message-ID: <5187F44B.5030502@gmail.com> Date: Mon, 06 May 2013 20:19:55 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040008060500050207020801" Cc: "jcardcal@ietf.org" Subject: Re: [calsify] 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, 06 May 2013 18:19:54 -0000 This is a multi-part message in MIME format. --------------040008060500050207020801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------040008060500050207020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------040008060500050207020801-- From kewisch@gmail.com Mon May 6 12:25:55 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 5635C21F854D; Mon, 6 May 2013 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 vftZdVNzGAp2; Mon, 6 May 2013 12:25:54 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 01E2F21F8FDF; Mon, 6 May 2013 12:25:53 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id y8so1768099bkt.13 for ; Mon, 06 May 2013 12:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=Ezc2fwBniTARhZercQbw3wsdoV1yJvk1JWZcBQQdFGw=; b=vxldJekCaCq52i/o/OTpBNdr0tnDKY+KLonKZCtxCXhGbrWKoJ0PhdwuAIyTiEPKY4 DMn1cXlhW3ArYkU+yWa4HV1BkOx2PqHcm8q/VTKhQG5Eu7bpzXmjGz9hRSiA2ii7JqSP tIRde59YQe2ML7l/8xqeFQoRtS/NY7EmKIONdCEQadBSwaphwVynyWteZev/puhLghyi wzx6ufB9gV8uqqMdGGyrdSgIFxDgQzYIGy9ozq49UHi6kWEgIvXa+M/nWHIjvDNk6uV2 gzTU5qXhUvXgdit9omNbExKY6XCIljbQ+Fwax8QH4udjmti6U5qiorElXm9340BoMfzJ ubqQ== X-Received: by 10.205.104.138 with SMTP id dm10mr9248807bkc.51.1367868353052; Mon, 06 May 2013 12:25:53 -0700 (PDT) Received: from oskar.local (e177211140.adsl.alicedsl.de. [85.177.211.140]) by mx.google.com with ESMTPSA id x5sm5765364bkh.15.2013.05.06.12.25.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 12:25:52 -0700 (PDT) Message-ID: <518803C4.6070609@gmail.com> Date: Mon, 06 May 2013 21:25:56 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Michael Angstadt References: <5187F44B.5030502@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020509000000010205070503" 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, 06 May 2013 19:25:55 -0000 This is a multi-part message in MIME format. --------------020509000000010205070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 >> --------------020509000000010205070503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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@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@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

--------------020509000000010205070503-- From yakushev@google.com Mon May 6 13:31:42 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 99ABA21F8F5C for ; Mon, 6 May 2013 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.378 X-Spam-Level: X-Spam-Status: No, score=-99.378 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 rcr7WAPVdryi for ; Mon, 6 May 2013 13:31:41 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6E21F8F20 for ; Mon, 6 May 2013 13:31:41 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jz10so3720181veb.0 for ; Mon, 06 May 2013 13:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aDxf92GP7HRn8kUWFj+joAH0TyLLpuLldTY8qel2e/Y=; b=ZwvWeoCL03zTHXSCzsqLlWtJOh+y3Z0grpPjUHsBVtId9n2TNvszLfRW+xrOcvPTtH CTL1/B/HiHVaT4RONCdJZ7wGbLe8uYGk6iQ7kn29w9ajF3dCSKTuGmg7knvIZFsqrEEz T7Nhg3/MlgJxI9wJGIyFencO78ZD6+uTK6pMElcta4yYby7BJ/jbfYgGjO3HajmDL8ob Fm7hW/DEgxbAAM8FI0nNFf95Qjqa7wBp0bqrn4fHBC/tCSl7+410rsqH43Jhga8s8QeM OK2D+wLll6NxjDfJjkzOwNiuXTyXv1zVc+mU8Tu/bk+OzBNH0T7qpePwUIFvEZOa0hZa lukA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=aDxf92GP7HRn8kUWFj+joAH0TyLLpuLldTY8qel2e/Y=; b=ZY/MW7Oa97307OlheQgRLrh+RKQ8CPHDvD8lXcVuyIk3a9RdGlRdLn9Jbd7CwZNvQh Ane0CDZf/xUm9LJkGVQE2D+1sIDlQC/uMnjWUi7MiV0VecQq7wMdvGLk7zWDZb5TCS6U amiubaQMHUeY0Wrf0mD8WH4yskQllJzsQXcijVRyp/ZApGqp1YUYDe7+wODIdvdYmJOM ULjiDIgkKx8/NnsvEZJp4rW+Ge7aPi6ofb9ML/xA9IpgbzTb0eYXq3dpBP+hZnA+gJNw Yy16ev+wVJOog+jNeNiXA4rSjDHRACDr8sgI+jPRbyIU+Roy16MUx0Z/DD4/OOAeZ8Wp p1FQ== MIME-Version: 1.0 X-Received: by 10.52.120.8 with SMTP id ky8mr6286040vdb.128.1367872300930; Mon, 06 May 2013 13:31:40 -0700 (PDT) Received: by 10.59.5.165 with HTTP; Mon, 6 May 2013 13:31:40 -0700 (PDT) In-Reply-To: <518803C4.6070609@gmail.com> References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> Date: Mon, 6 May 2013 22:31:40 +0200 Message-ID: From: Gregory Yakushev To: Philipp Kewisch Content-Type: multipart/alternative; boundary=089e013a1ba8987cee04dc12961e X-Gm-Message-State: ALoCoQmexjqDZrzUsnOEERnERmQrY07j6Ufe5bjaqMJ9VqtkI6g9OJRSMj17AaDeuLoB8KCGx3SWRZPju06CPQz8dH8GNJh7qdZTWejSUhCQnvXjUCSjNftlw20DNZpT4ZY1MbRhVjO3rjDEF3HGjyMcpTiYxWl8+NmTb55BbSXLLoDZdZhCZV9KHCzxKLCiCQ9C2DpQ9FBA Cc: Calsify , Michael Angstadt , "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, 06 May 2013 20:31:42 -0000 --089e013a1ba8987cee04dc12961e Content-Type: text/plain; charset=ISO-8859-1 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 listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > > > > _______________________________________________ > jcardcal mailing listjcardcal@ietf.orghttps://www.ietf.org/mailman/listinfo/jcardcal > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > --089e013a1ba8987cee04dc12961e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Our primary motivation to use 'L' suffix over LEAP= MONTH=3DTRUE was that RRULE is a string anyway, and 'L' is shorter.= But if you have a structured representation of RRULE, using a separate boo= lean makes total sense. To expand the RRULE you will need some library (suc= h as=A0icu-project.org), which proba= bly accepts leap months as a boolean and not an 'L' suffix.

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


On Mon,= May 6, 2013 at 9:25 PM, Philipp Kewisch <kewisch@gmail.com>= wrote:
=20 =20 =20 =20
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": " CH=
INESE", "freq": "YEARLY",
"bymonth": 11, "leapMonth": true } ]

-Mike

On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch <kewisch@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 calen=
dar
system, but in theory we could do this:

[ "rrule", {}, "recur", { "rscale": " CH=
INESE", "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 ca=
lsify@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-rscal=
e
Htmlized:        http://tools.ietf.org/html/draft-daboo-icale=
ndar-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


--089e013a1ba8987cee04dc12961e-- From yakushev@google.com Mon May 6 13:37:24 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 EF1D821F8E49 for ; Mon, 6 May 2013 13:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.877 X-Spam-Level: X-Spam-Status: No, score=-99.877 tagged_above=-999 required=5 tests=[AWL=0.499, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 jWxzBvIkfevk for ; Mon, 6 May 2013 13:37:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D128B21F8BDE for ; Mon, 6 May 2013 13:37:20 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id m17so997351vca.31 for ; Mon, 06 May 2013 13:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=akrY+a9etJd6pkVQYLmKcDvSMXUPOaamv3RFpv8vTFY=; b=aaiVoluY/bLixMn8Q+BemZSK7NyIaYkYDt/hnDmaAHIv2eQbZk3hwOSePNcZPuXjM5 Xd+ezDEbNaOSt1tdgJWGWJxgwC/rs5vjBplQTAIw1fupJ4lIbj7RdHXhetGgTPP9ulK2 A7k9B5vbgKUAoGCBjeiEZ5oaCCb8uuquWm3F4ICzz04rMksnbYznzDI8m/T4TppRoa/Z Ix36vAzQUpbv61rKln+6PLqcnuMF9nbB+mWOSE4Wbc7NXr7dtDhA7qeUG5RwTc9QnGJt 8V3QpKPzq0WOK+IUHw0Q3JlmMJvwaQmU78Lbvv2OXNJSWtiqdzMpZ/BApZaGXfM2QqKy oUgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=akrY+a9etJd6pkVQYLmKcDvSMXUPOaamv3RFpv8vTFY=; b=LeKytpOxxDsRrLDuVwsLtWUuVvGNT/yfJstIziCSrQSIDH/q2wBypwEBxm+rjT7o/l ImA15CbVpxM0pnS+BSFK4oXAeNuVqKczD6I+ZXmmBQzQAg7sYhyyau3nTC1kzkWkV2Td GyLF4imDfVehwCo9OB0xcKK3bTiJbcZTeIE3s/NOPiJHXuHF/At1F88nUbPjw9ITy+6Q g/O7eQZJv0qgEfhm/lFjIs/+D0PhOvo+8rjO6+DwDlWHPCMVRaUq3ums8Fnhd5frXYJP 8lTBAN9Tzi8D75usS1au0VuaBOP8nu3HCBBUfTXozSiiowMvNqV8o98ZhWpGzcbQHlrz pa0A== MIME-Version: 1.0 X-Received: by 10.52.16.114 with SMTP id f18mr6031475vdd.89.1367872640272; Mon, 06 May 2013 13:37:20 -0700 (PDT) Received: by 10.59.5.165 with HTTP; Mon, 6 May 2013 13:37:20 -0700 (PDT) In-Reply-To: References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> Date: Mon, 6 May 2013 22:37:20 +0200 Message-ID: From: Gregory Yakushev To: Philipp Kewisch Content-Type: multipart/alternative; boundary=bcaec502d5f0d26d7f04dc12aad0 X-Gm-Message-State: ALoCoQkZXmcuj93lkvrILIMd1Kd2BziG6fRcIadAndAqjdDjdAKw/yx3vvMFroaUeM3Er1zfNlYgTip+iOj0DggfES9t4HKg549supJuGkwcqQYfG3r+4ZEc6cknM16Cb7WV7VXVzkunsMQoyM+tsx6/oCYa53PxL2Wi3uAOIomFEcOUgS2Ukimeftdi++efLlvAA1NNOLAd Cc: Calsify , Michael Angstadt , "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, 06 May 2013 20:37:25 -0000 --bcaec502d5f0d26d7f04dc12aad0 Content-Type: text/plain; charset=ISO-8859-1 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 listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify >> >> >> >> >> _______________________________________________ >> jcardcal mailing listjcardcal@ietf.orghttps://www.ietf.org/mailman/listinfo/jcardcal >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> >> > --bcaec502d5f0d26d7f04dc12aad0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I see your point about the {8, "11L"} case. As a= n option, you can do this:=A0[ "rru= le", {}, "recur", { "rscale": " CHINESE"= , "freq": "YEARLY", "bymonth": [8], "byl= eapmonth": [11] } ]


On Mon, May 6, 2013 at 10:31 PM, Gregory= Yakushev <yakushev@google.com> wrote:
Our primary motivation to use 'L' suffix over LEAP= MONTH=3DTRUE was that RRULE is a string anyway, and 'L' is shorter.= But if you have a structured representation of RRULE, using a separate boo= lean makes total sense. To expand the RRULE you will need some library (suc= h as=A0icu-project.org= ), which probably accepts leap months as a boolean and not an 'L= 9; suffix.

For clients not supporting RSCALE parameter it is actually b= etter 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@gmail.com> wrote:
=20 =20 =20 =20
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": " CH=
INESE", "freq": "YEARLY",
"bymonth": 11, "leapMonth": true } ]

-Mike

On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch <kewisch@gmail.com> wrote:

I wonder how we should handle this for jCal. the rsc=
ale 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 calen=
dar
system, but in theory we could do this:

[ "rrule", {}, "recur", { "rscale": " CH=
INESE", "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 ca=
lsify@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-rscal=
e
Htmlized:        http://tools.ietf.org/html/draft-daboo-icale=
ndar-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<= br> https://www.ietf.org/mailman/listinfo/calsify



--bcaec502d5f0d26d7f04dc12aad0-- From kewisch@gmail.com Mon May 6 14:16:22 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 53C8421F8651; Mon, 6 May 2013 14:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 fPpZbMePIt9T; Mon, 6 May 2013 14:16:21 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8F21F8644; Mon, 6 May 2013 14:16:20 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id ik5so1809997bkc.37 for ; Mon, 06 May 2013 14:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=rK9FGMIVNaYwSsFH9y2MmRLSiHtjl7fWIGaCgZBao7Y=; b=0KUj0UBANDcJBYLkG4hllUPER0MYsYo4mf8Vo2IRHTb1YCTsJKurZH7pC+rkY+PKDS 18iW9YxtelASQdNP5uNHGTwhKl1bBJlZQNqScGUAbuavmdCFOWuJpYmumln/ytVOPIsL 4w2wurmLW2wmbSLTbf534KX2MGVXBWojGuCRxGPoer6xD0poUTk/6KeQnMt2vCsgdJst 9ixbEq0H5oMb5bV6ib9AU+/jYrxzCSuRi39k+0DbCypm+EoS79zlKQySwGbIAV5LVRlB xEKBxw4jn5nGIVbXePcbyKtdqpKNTKIwLI55oeW00ZoSRPLrRXbrEBoOB1EIt1ZTN8UU YEfg== X-Received: by 10.205.115.196 with SMTP id ff4mr9294106bkc.111.1367874979809; Mon, 06 May 2013 14:16:19 -0700 (PDT) Received: from ?IPv6:2002:55b1:d38c::e04c:c156:b3e2:f8d3? ([2002:55b1:d38c:0:e04c:c156:b3e2:f8d3]) by mx.google.com with ESMTPSA id f14sm5850643bky.16.2013.05.06.14.16.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 May 2013 14:16:19 -0700 (PDT) References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-0F4AD0BA-DAF5-4FAB-8F1C-24A3E04A46EB Content-Transfer-Encoding: 7bit Message-Id: <0F9E6C44-6D96-45A0-ADCD-A69D9561996C@gmail.com> X-Mailer: iPhone Mail (10A523) From: Philipp Kewisch Date: Mon, 6 May 2013 23:16:14 +0200 To: Gregory Yakushev 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, 06 May 2013 21:16:22 -0000 --Apple-Mail-0F4AD0BA-DAF5-4FAB-8F1C-24A3E04A46EB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In that case the RSCALE draft should also be changed to add BYLEAPMONTH. I w= ould be fine with this implementation, parsers that don't know rscale won't t= otally 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] } ] >=20 >=20 > On Mon, May 6, 2013 at 10:31 PM, Gregory Yakushev wr= ote: >> Our primary motivation to use 'L' suffix over LEAPMONTH=3DTRUE was that R= RULE is a string anyway, and 'L' is shorter. But if you have a structured re= presentation of RRULE, using a separate boolean makes total sense. To expand= the RRULE you will need some library (such as icu-project.org), which proba= bly accepts leap months as a boolean and not an 'L' suffix. >>=20 >> For clients not supporting RSCALE parameter it is actually better to fail= on recurrence rules that have it, because otherwise they will produce incor= rect expansion and cause a date inconsistency. >>=20 >>=20 >> 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:= >>>=20 >>> [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bymon= th": [8, "11L"] } ] >>> Philipp >>>=20 >>> On 5/6/13 9:09 PM, Michael Angstadt wrote: >>>> What if you added a "leapMonth" boolean field? >>>>=20 >>>> [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", >>>> "bymonth": 11, "leapMonth": true } ] >>>>=20 >>>> -Mike >>>>=20 >>>> On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch wro= te: >>>>> I wonder how we should handle this for jCal. the rscale draft says tha= t for >>>>> "leap months", it should be suffixed with an "L". This turns the numbe= r >>>>> value into a string value. I don't know if this is correct in the cale= ndar >>>>> system, but in theory we could do this: >>>>>=20 >>>>> [ "rrule", {}, "recur", { "rscale": " CHINESE", "freq": "YEARLY", "bym= onth": >>>>> "11L" } ] >>>>>=20 >>>>> A parser expecting a number would be pretty confused though. >>>>>=20 >>>>> Philipp >>>>>=20 >>>>>=20 >>>>> On 5/6/13 4:27 PM, Gregory Yakushev wrote: >>>>>=20 >>>>> A draft RFC to support non-Gregorian recurrence rules in iCalendar is >>>>> available for discussion. It will allow us to specify events like Chin= ese >>>>> New Year, Ramadan or Korean birthdays. Please see the links below. Com= ments >>>>> are welcome on the calsify@ietf.org mailing list. >>>>>=20 >>>>> If adopted, we are likely to start using it at Google, and recurrences= with >>>>> RSCALE parameter will appear in iCalendar data provided by us. >>>>>=20 >>>>> Grigory Yakushev >>>>> Google Inc. >>>>>=20 >>>>> Title: Non-Gregorian Recurrence Rules in iCalendar >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-daboo-icalendar-rscale-00.tx= t >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-daboo-icalendar-rscale >>>>> Htmlized: http://tools.ietf.org/html/draft-daboo-icalendar-rsca= le-00 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> calsify mailing list >>>>> calsify@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/calsify >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jcardcal mailing list >>>>> jcardcal@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jcardcal >>>=20 >>>=20 >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --Apple-Mail-0F4AD0BA-DAF5-4FAB-8F1C-24A3E04A46EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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@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@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@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@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@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
--Apple-Mail-0F4AD0BA-DAF5-4FAB-8F1C-24A3E04A46EB-- From james@lightsofapollo.com Mon May 6 16:04:21 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 11DFB21F92CB for ; Mon, 6 May 2013 16:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 rSeOef2CmJuf for ; Mon, 6 May 2013 16:04:16 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2321F9299 for ; Mon, 6 May 2013 16:04:16 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id 5so2263801pdd.31 for ; Mon, 06 May 2013 16:04:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=apcF/2ewTIU1ackG4eBujdJ8g8tfw8Aw8995rwX8JlY=; b=jdAqxSdI1IBfltTWuCGpEPBwvPOgSKFkatdjy6cfYw9st/91DNYrhUEYJ+sF3I2Jau T7Locx7/nYm06LO/KLvFpWHsj/KlMym74exVDkD8y8i+GmitZKggfVPpFhZyf4nd6Kec 0v32WUP5o1/qqnb7WejAWaqEIY3JkLF541XxsSNF2w4GmeXs7vSKEKMu2Os0l+rgr32s TjoRctvJggJUCuDw6vmif11xeNWp02nIeUCmiDgNgnvtuK2LLUNtvVoCMx/d9JwUdqL7 4BjSLxR8PKEpzumTmfA8W8otbGMPC1IZ659tZYge9k8qKcUmfWyPr1LUaSe5LXy90t2E JDTQ== MIME-Version: 1.0 X-Received: by 10.68.49.130 with SMTP id u2mr27742757pbn.124.1367881456260; Mon, 06 May 2013 16:04:16 -0700 (PDT) Received: by 10.66.155.2 with HTTP; Mon, 6 May 2013 16:04:16 -0700 (PDT) X-Originating-IP: [76.102.51.255] In-Reply-To: <0F9E6C44-6D96-45A0-ADCD-A69D9561996C@gmail.com> References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> <0F9E6C44-6D96-45A0-ADCD-A69D9561996C@gmail.com> Date: Mon, 6 May 2013 16:04:16 -0700 Message-ID: From: James Lal To: Philipp Kewisch Content-Type: multipart/alternative; boundary=bcaec544ef924bb04b04dc14b856 X-Gm-Message-State: ALoCoQnECo7HHcT+G81pJfPuF6htIKPAfdYL+rW53qAF22M7EkERRPKZ6rU8TE4D6aIN1U7H/FSW Cc: "jcardcal@ietf.org" , Calsify 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, 06 May 2013 23:04:21 -0000 --bcaec544ef924bb04b04dc14b856 Content-Type: text/plain; charset=ISO-8859-1 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 listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify >>> >>> >>> >>> >>> _______________________________________________ >>> jcardcal mailing listjcardcal@ietf.orghttps://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 > > --bcaec544ef924bb04b04dc14b856 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
BYLEAPMONTH+1 gives us a clear(er) way to opt-into new fea= tures and optimize specifically for them..
On Mon, May 6, 2013 at 2:16 PM, Philipp Kewisc= h <kewisch@gmail.com> wrote:
In= that case the RSCALE draft should also be changed to add BYLEAPMONTH. I wo= uld be fine with this implementation, parsers that don't know rscale wo= n'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:=A0[ "rrule", {}, "recur", {= "rscale": " CHINESE", "freq": "YEARLY&q= uot;, "bymonth": [8], "byleapmonth": [11] } ]

On Mon, May 6, 2013 at 10:31 PM, Gregory= Yakushev <yakushev@google.com> wrote:
Our primary motivation to use 'L' suffix over LEAP= MONTH=3DTRUE was that RRULE is a string anyway, and 'L' is shorter.= But if you have a structured representation of RRULE, using a separate boo= lean makes total sense. To expand the RRULE you will need some library (suc= h as=A0icu-project.org= ), which probably accepts leap months as a boolean and not an 'L= 9; suffix.

For clients not supporting RSCALE parameter it is actually b= etter 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@gmail.com&= gt; wrote:
=20 =20 =20 =20
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": " CH=
INESE", "freq": "YEARLY",
"bymonth": 11, "leapMonth": true } ]

-Mike

On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch <kewisch@gmail.com> wrote:

I wonder how we should handle this for jCal. the rsc=
ale 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 calen=
dar
system, but in theory we could do this:

[ "rrule", {}, "recur", { "rscale": " CH=
INESE", "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 ca=
lsify@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-rscal=
e
Htmlized:        http://tools.ietf.org/html/draft-daboo-icale=
ndar-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<= br> https://www.ietf.org/mailman/listinfo/calsify



___________________= ____________________________
calsify mailing listcalsify@ietf.o= rg
https://www.ietf.org/mailman/listinfo/calsify

__________________________________________= _____
jcardcal mailing list
jcardcal@ietf.org
https://www.ietf.org/mailman/listinfo/jcardcal


--bcaec544ef924bb04b04dc14b856-- From yakushev@google.com Tue May 7 13:20:38 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 CFA4421F86D6 for ; Tue, 7 May 2013 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.427 X-Spam-Level: X-Spam-Status: No, score=-101.427 tagged_above=-999 required=5 tests=[AWL=1.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 kgCm7agMCsok for ; Tue, 7 May 2013 13:20:33 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id E156A21F92BC for ; Tue, 7 May 2013 13:20:23 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id gd11so983090vcb.28 for ; Tue, 07 May 2013 13:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BvXvQzvQs4tGlJ7aum7GdRnT453sq4U96x/yidBqMJQ=; b=jBQ26cWYtnaVEy7Qn65l0LOnkIUJK5Q4/24WYU/t0D0+gjI6umsNywrdRmhN+g3uv8 riZ5PcIBgT90CYJkfmGxS5HaVZDMz+YTkaugZiWSTzeHGWpxGLaw6wJN5mbBehWwxJ6i RLos95tOvJB1MmBDuF0qGd4lVYU09Ktm4cpLdD5ZniDCmJCwiE8DMWlhkCP3MgbGO/jT g9rt//AqfhMyLnhooMrrrrm8mQOQ7eR8O6dHRK7HLBWxxjhcjPmOFLln1xUj/xdpZS9z uz/0HKAZQsRAmtBN0NIs59d0sALe4M36c10KbymOFXMZJXzCA/BCt0SpTE84T00Fx52X CGzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=BvXvQzvQs4tGlJ7aum7GdRnT453sq4U96x/yidBqMJQ=; b=c2IJTDIMTizqN0IfAMgV+7RkWuSH+gqDeFowoX0e2xu3U4Z67sHbzsqost3oNemTB0 x3Qk72KXOwQODJV4sCyIfoi+FImJIByVeeRPvu0hCwX3iTvsXeEMovSmYUr6JTDw03lH 82EDb68nnIsUqmNGQHVkR83KPvh669k9pQlKDSAH4ij8jX7qN5mvZwyV+Fu0gyg8Ldin 6suWAwigyczSG7nkj6lgiDEBTOLeAenui6w+cBwafsokktVKlqZ5TKtjS4Nt/B9bPnkJ NpeSLMh4gjfw3C//ShdyyGsOkRHJedhQGzr4jNxKkIOVvpGoX2XwSTbtDdZsIJ1SbXvF R49w== MIME-Version: 1.0 X-Received: by 10.52.174.208 with SMTP id bu16mr2088605vdc.21.1367958023242; Tue, 07 May 2013 13:20:23 -0700 (PDT) Received: by 10.59.5.165 with HTTP; Tue, 7 May 2013 13:20:23 -0700 (PDT) In-Reply-To: References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> <0F9E6C44-6D96-45A0-ADCD-A69D9561996C@gmail.com> Date: Tue, 7 May 2013 22:20:23 +0200 Message-ID: From: Gregory Yakushev To: James Lal Content-Type: multipart/alternative; boundary=bcaec51ba0c90b281904dc268cfa X-Gm-Message-State: ALoCoQkoZAXTyMrf1xyDXordyT7/XcJbymWnHyIJ2re1Ji37iqetWNurHKDR9ru+cZ5+e2Vulnu3vpCT1WXgYA/tcBSEXT4IRSk8lfW40cLjim8+Lg3XfRD/1pg/dNsi+TYIQd72aSYkg85yQmoQGfqQvuc7SA4jdkh3aClcEa8TsSxPAp9l3JglBOn+pCiT40vXnsa9PZ2d 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: Tue, 07 May 2013 20:20:38 -0000 --bcaec51ba0c90b281904dc268cfa Content-Type: text/plain; charset=ISO-8859-1 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 listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> jcardcal mailing listjcardcal@ietf.orghttps://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 >> >> > --bcaec51ba0c90b281904dc268cfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the comments! We will consider replacing 'L= ' suffix with BYLEAPMONTH parameter in the next draft. There will be sl= ight delay because my coauthor (Cyrus Daboo) is on vacation.

Is there anything else that sticks out in the proposal?


On Tue, Ma= y 7, 2013 at 1:04 AM, James Lal <james@lightsofapollo.com> wrote:
BYLEAPMONTH+1 gives us a cl= ear(er) way to opt-into new features and optimize 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 BYLEAPMONTH. I wo= uld be fine with this implementation, parsers that don't know rscale wo= n't totally freak out.

Philipp


<= /div>
I see your point = about the {8, "11L"} case. As an option, you can do this:=A0[ "rrule", {}, "recur", {= "rscale": " CHINESE", "freq": "YEARLY&q= uot;, "bymonth": [8], "byleapmonth": [11] } ]

On Mon, May 6, 2013 at 10:31 PM, Gregory= Yakushev <yakushev@google.com> wrote:
Our primary motivation to use 'L' suffix over LEAP= MONTH=3DTRUE was that RRULE is a string anyway, and 'L' is shorter.= But if you have a structured representation of RRULE, using a separate boo= lean makes total sense. To expand the RRULE you will need some library (suc= h as=A0icu-project.org= ), which probably accepts leap months as a boolean and not an 'L= 9; suffix.

For clients not supporting RSCALE parameter it is actually b= etter 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@gmail.com&= gt; wrote:
=20 =20 =20 =20
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": " CH=
INESE", "freq": "YEARLY",
"bymonth": 11, "leapMonth": true } ]

-Mike

On Mon, May 6, 2013 at 2:19 PM, Philipp Kewisch <kewisch@gmail.com> wrote:

I wonder how we should handle this for jCal. the rsc=
ale 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 calen=
dar
system, but in theory we could do this:

[ "rrule", {}, "recur", { "rscale": " CH=
INESE", "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 ca=
lsify@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-rscal=
e
Htmlized:        http://tools.ietf.org/html/draft-daboo-icale=
ndar-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<= br> https://www.ietf.org/mailman/listinfo/calsify



___________________= ____________________________
calsify mailing listcalsify@ietf.o= rg
https://www.ietf.org/mailman/listinfo/calsify

__________________________________________= _____
jcardcal mailing list
jcardcal@ietf.org
https://www.ietf.org/mailman/listinfo/jcardcal



--bcaec51ba0c90b281904dc268cfa-- From yakushev@google.com Tue May 7 14:37:17 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 6EF5B21F9134 for ; Tue, 7 May 2013 14:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 eoNU8ie0xXhg for ; Tue, 7 May 2013 14:37:16 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0F48321F90DF for ; Tue, 7 May 2013 14:37:15 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id pb11so1125905veb.33 for ; Tue, 07 May 2013 14:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=X5hlahAdvlGCR+vZgNFOgeUUmQtcawIQhfRfk7sYasY=; b=NlZPOLGgMBYBUOYj7z4IsL99/8TWvdwccXV60/WIPn3Ex4rR/hvvKH1t/PwwMr5uOt Pr5CMQNoaXW+QeYwLdcRn7GtLJnM62K14lfc1Zrvv9hkF+ZkMOafFqV8muqn9qyIfYeQ QXlyM8d3itAqC0hgC+fufu9KAkBNBGek5y5TafFu249kFLqIGGp1FuZSEEKPzxwqIum8 2fPd27gDQJ6BhjTyay43j+zClhA2WCokJ7xkGvTJHbyStuzDpKKXYa0b0APxo27f/EhI n1vdYk4Kjc688yRvfHI8oqq+XQ6RlscU+4q7Sr8ot1EA4FdVUIXXTbEbYxrBJtvDHmxd S/rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=X5hlahAdvlGCR+vZgNFOgeUUmQtcawIQhfRfk7sYasY=; b=I+NLJbYxGEiVc1rFyQPIX2oVRijGDheqdEX9S0WwtsT5/8rBdaFCdUc3IeU8n9VaWF 4tT8yHCHog+TN7ELZQkMT3byyK337TPssRTTrJlmYECTCzaEC7DgkRWr2TDPakdP1Auq pa8UOCZye5ktUatJWYfwza9xyJJynxsdrEpEzlF8dWFVQmI+lOMFPwzn6am0E81XtOtV 2ESDHCa4ecoyuO9hrHwuERGygD40kIwmVHd3YIyUONuTuuHVJxF2AoQ5uCLrwvsZ6tfG XxmNe0y0gFqMYy7+ZBn9zL4HMpAHugqjO2vNZKkeaMeyWMQ0sW1jf47ISXl86VudL8T+ 2QtQ== MIME-Version: 1.0 X-Received: by 10.52.174.208 with SMTP id bu16mr2237070vdc.21.1367962635247; Tue, 07 May 2013 14:37:15 -0700 (PDT) Received: by 10.59.5.165 with HTTP; Tue, 7 May 2013 14:37:15 -0700 (PDT) In-Reply-To: References: <5187F44B.5030502@gmail.com> <518803C4.6070609@gmail.com> <0F9E6C44-6D96-45A0-ADCD-A69D9561996C@gmail.com> Date: Tue, 7 May 2013 23:37:15 +0200 Message-ID: From: Gregory Yakushev To: Caleb Richardson Content-Type: multipart/alternative; boundary=bcaec51ba0c9f0bbe704dc279e21 X-Gm-Message-State: ALoCoQnNmeDWeZCKEPZQ6p0sHUc1SLNuqUPglzDSKuZalsZzr59BqKzNyIneJ9EH0LmWSaVdbUI+T3gZYk/LQhPyEssU1o1zxM1+bp4kJh/RETWC50LgpANYweR5Zn/SZjc+8WI1sWUSsbAMYMEGa4nHgYz7DDBn3IapWn45fH3+iwNsmi6tqpnO7PY1RKrjjh9vWGH4B0n4 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: Tue, 07 May 2013 21:37:17 -0000 --bcaec51ba0c9f0bbe704dc279e21 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --bcaec51ba0c9f0bbe704dc279e21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I think there's no strong reason for that require= ment, 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 p= robably 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> wrote:
> 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> wrote:
>> 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
>>> <kewisch@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
>>>> calsify@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
>>>>
>>>> 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


--bcaec51ba0c9f0bbe704dc279e21--