From nobody Fri Apr 11 09:44:26 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5865B1A0701 for ; Fri, 11 Apr 2014 09:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WJeiFw9FD0n for ; Fri, 11 Apr 2014 09:44:24 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) by ietfa.amsl.com (Postfix) with ESMTP id D893F1A06FF for ; Fri, 11 Apr 2014 09:44:23 -0700 (PDT) Received: from localhost.localdomain (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s3BGiLqC029883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 11 Apr 2014 12:44:21 -0400 Message-ID: <53481BE5.4070607@andrew.cmu.edu> Date: Fri, 11 Apr 2014 12:44:21 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: multipart/alternative; boundary="------------030506090000080500000005" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.11.163622 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_50_70 0.1, HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BAT_BOUNDARY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HTML_FONT_GREEN 0, __HTML_FONT_RED 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_START 0, __SUBJ_ALPHA_START_END 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/aCEsCjHyQJRdhjMXaFjohfhe3S8 Subject: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:44:25 -0000 This is a multi-part message in MIME format. --------------030506090000080500000005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, A couple of random thoughts as I attempt to add RSCALE support to libical: 1) Maybe I'm missing the point of the "L" suffix, but shouldn't the RRULE in example 4.2.3 include the "L" suffix? E.g.: RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD If not, can an example be added that includes the "L" suffix? In either case, I'm thinking an example or two of a non-yearly recurrence might be helpful. 2) Also, if I understand SKIP correctly, can the handling of the Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps an example of this is also warranted, such as (borrowed from one of the CalConnect etherpads): DTSTART:20120229T120000Z RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z Occurs: 20120229T120000Z 20130301T120000Z Does not occur: 20140301T120000Z -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------030506090000080500000005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

A couple of random thoughts as I attempt to add RSCALE support to libical:

1)  Maybe I'm missing the point of the "L" suffix, but shouldn't the RRULE in example 4.2.3 include the "L" suffix?  E.g.:

RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6L;BYMONTHDAY=8;SKIP=FORWARD

If not, can an example be added that includes the "L" suffix?  In either case, I'm thinking an example or two of a non-yearly recurrence might be helpful.

2)  Also, if I understand SKIP correctly, can the handling of the Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD?  If so, perhaps an example of this is also warranted, such as (borrowed from one of the CalConnect etherpads):

DTSTART:20120229T120000Z
RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z

Occurs:
20120229T120000Z
20130301T120000Z

Does not occur:
20140301T120000Z

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------030506090000080500000005-- From nobody Mon Apr 14 09:04:56 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF221A01CB for ; Mon, 14 Apr 2014 09:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG36NSrr-9lT for ; Mon, 14 Apr 2014 09:04:50 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5E1A04CA for ; Mon, 14 Apr 2014 09:04:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 190CB62FEBC9; Mon, 14 Apr 2014 12:04:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMS_rRUdhZpU; Mon, 14 Apr 2014 12:04:47 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 2614062FEBAB; Mon, 14 Apr 2014 12:04:46 -0400 (EDT) Date: Mon, 14 Apr 2014 12:03:42 -0400 From: Cyrus Daboo To: Ken Murchison , calsify@ietf.org Message-ID: <151706F27F9F2B2361A9C095@caldav.corp.apple.com> In-Reply-To: <53481BE5.4070607@andrew.cmu.edu> References: <53481BE5.4070607@andrew.cmu.edu> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2621 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/UW9ROYi8To55bNhHZ6HOsO56zTE Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:04:54 -0000 Hi Ken, --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison wrote: > 1) Maybe I'm missing the point of the "L" suffix, but shouldn't the > RRULE in example 4.2.3 include the "L" suffix? E.g.: > > RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD > > If not, can an example be added that includes the "L" suffix? In either > case, I'm thinking an example or two of a non-yearly recurrence might be > helpful. In most calendar systems with a leap month, months are counted 1 through 12, with the leap month being tagged with the "L" suffix where it appears during the year. In the Hebrew calendar implementation in the unicode ICU library, the months are actually numbered 1 through 13. In non-leap years, month number 6 is simply skipped. That is already described in section 4.1 of the current draft. Now, I suspect from an implementation standpoint, one might want to use isLeapYear(N) as the trigger for adding the "L" suffix and I suspect (but have not checked) that would return true for Hebrew month 6. If that is the case, then I would agree we should probably require that behavior for RSCALE. What do others think? Should we change section 4.1 to state that "L" is always added to the leap month even in the Hebrew case? > 2) Also, if I understand SKIP correctly, can the handling of the > Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by > using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps an example > of this is also warranted, such as (borrowed from one of the CalConnect > etherpads): > > DTSTART:20120229T120000Z > RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z > > Occurs: > 20120229T120000Z > 20130301T120000Z > > Does not occur: > 20140301T120000Z Yes, one "side-effect" of RSCALE is that it does address the problem of how to deal with the Gregorian leap day by providing the skip option. Adding an example of that in section 4.2. That said, the current description of SKIP in Section 4 (list item 4) only refers to skipping leap months. In addition to the Gregorian leap day, there are other kinds of skips that occur - e.g., a monthly recurrence on January 31st (as currently defined by 5545) should only occur in months with 31 days - the others should be skipped. Should SKIP apply to that as well? It may not be necessary in all cases (e.g. the January 31st example is likely meant to be "last day of the month" which can be encoded precisely in RRULE - but if the intent was "the 31st or the 1st of the next month" then skip would be handy). -- Cyrus Daboo From nobody Mon Apr 14 14:01:18 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132251A065A for ; Mon, 14 Apr 2014 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYNtEiuWEeam for ; Mon, 14 Apr 2014 14:01:11 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6593D1A0447 for ; Mon, 14 Apr 2014 14:01:11 -0700 (PDT) Received: from localhost.localdomain (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s3EL0xX0019513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Apr 2014 17:00:59 -0400 Message-ID: <534C4C84.1040200@andrew.cmu.edu> Date: Mon, 14 Apr 2014 17:00:52 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> In-Reply-To: <151706F27F9F2B2361A9C095@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.14.205418 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __INT_PROD_LOC 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/aRehJRX8G91xYVznlcUb3NwFxV0 Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:01:16 -0000 Hi Cyrus, On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > Hi Ken, > > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison > wrote: > >> 1) Maybe I'm missing the point of the "L" suffix, but shouldn't the >> RRULE in example 4.2.3 include the "L" suffix? E.g.: >> >> RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD >> >> If not, can an example be added that includes the "L" suffix? In either >> case, I'm thinking an example or two of a non-yearly recurrence might be >> helpful. > > In most calendar systems with a leap month, months are counted 1 > through 12, with the leap month being tagged with the "L" suffix where > it appears during the year. In the Hebrew calendar implementation in > the unicode ICU library, the months are actually numbered 1 through > 13. In non-leap years, month number 6 is simply skipped. That is > already described in section 4.1 of the current draft. > > Now, I suspect from an implementation standpoint, one might want to > use isLeapYear(N) as the trigger for adding the "L" suffix and I > suspect (but have not checked) that would return true for Hebrew month > 6. If that is the case, then I would agree we should probably require > that behavior for RSCALE. > > What do others think? Should we change section 4.1 to state that "L" > is always added to the leap month even in the Hebrew case? I just ran a quick test using ICU within libical, and it doesn't appear to set the IS_LEAP_MONTH flag for the Hebrew calendar for month 6. I haven't tried it with other calendars (i.e. Chinese) to see if its cal-specific. In any case, it would seem to me that the fact that ICU numbers the months 1-13 is an internal implementation detail. How is the generator of the iCalendar data supposed to know how the receiver numbers its months? Or am I completely missing the point of "L"? > >> 2) Also, if I understand SKIP correctly, can the handling of the >> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by >> using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps an example >> of this is also warranted, such as (borrowed from one of the CalConnect >> etherpads): >> >> DTSTART:20120229T120000Z >> RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z >> >> Occurs: >> 20120229T120000Z >> 20130301T120000Z >> >> Does not occur: >> 20140301T120000Z > > Yes, one "side-effect" of RSCALE is that it does address the problem > of how to deal with the Gregorian leap day by providing the skip > option. Adding an example of that in section 4.2. > > That said, the current description of SKIP in Section 4 (list item 4) > only refers to skipping leap months. In addition to the Gregorian leap > day, there are other kinds of skips that occur - e.g., a monthly > recurrence on January 31st (as currently defined by 5545) should only > occur in months with 31 days - the others should be skipped. Should > SKIP apply to that as well? It may not be necessary in all cases (e.g. > the January 31st example is likely meant to be "last day of the month" > which can be encoded precisely in RRULE - but if the intent was "the > 31st or the 1st of the next month" then skip would be handy). > Hmm. My thoughts are that SKIP should only apply to leap months and possibly leap days. I'm not sure we want to venture any further than that. I would think that 5545 should have handled the other cases already. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Apr 16 13:28:02 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540E91A02AC for ; Wed, 16 Apr 2014 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t2nr41vFSOi for ; Wed, 16 Apr 2014 13:27:56 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 352491A0284 for ; Wed, 16 Apr 2014 13:27:56 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so12352819qcx.21 for ; Wed, 16 Apr 2014 13:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=2d2VXF7wSXPrzyq+gHSC5pfJG4MiULYTLSQ1wXOKRIU=; b=E+NHyisD5OX7HGoNFYJ646sg3cUzExollSNysZfdQEQYPSwcyD/qw4OGlAfVH6ZTWU hYV4kBHlPzgMUJUSOEtTEgaGQFwxkKquqPfrd4mO9knqFPttJVCVGk5Ah4Ig2K6RR5O9 dENwiVWrAnuq5/SK7vKuZIpXWAB6/F4qrhsJPOSIwErK/Up++BAMC/UL6WzPIn+rq18o AxP+l0MLr79v1j3az7hWh2NgcwrCikJbKzjfvM0yJiDKbQ0Y0R6MWfSfq4/L1HaZXww5 TRjQPcc2iR5bSA4dZqkS0h6QWEnIHUzNOQG9IvpFXSS2LRRsinogvigw08E8bcOXDHwi QE9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=2d2VXF7wSXPrzyq+gHSC5pfJG4MiULYTLSQ1wXOKRIU=; b=eSApkFL9XQfSwmj8W1AFXKZMe94Anki/YiQC3XbY83RovrZJKAvdoF1ruhzVEsveoW zHft7+h8AFL104cQd/NapI1lX62mb4ig/i5X49amy+nqcwroYrBshKJrmR3TjG7KoM2A H66yUyCNmUwPSVLxl8KcuOiAVD+35Luibe0Nz9LeZfKiV3gtvdqfIpoSVmlj67hnMkvJ yGljjGcfe7DaNrn1ckZ5ZPBXyUn1cBXSNbwX5/FlZuJJoqgvGQ9Tfk06HagXWoj6owxq zkyZ0vFiM7avQaOwTDNFeV9pFoi4pR+k3h3SGt77nGGWGNQugj2WSiVNtXkdw9NrTI7F oYmQ== X-Gm-Message-State: ALoCoQkx+27es7gA8um2AAfvGfpxTftcVAopskDoRR6jcN93StLwENcrwqq/8UKp6/tmk4TjeGYVJR13E536FDDJd43dVkHsMz8YvsBPHeFrdwVH67k+/EizHi/qQWw2ySAwQaQqklbu8+8wcnflkWxXREElSRc480a8RQJzLylE7bqvmykP5L/zbEp2jWFL8RTjP0mFy6YI X-Received: by 10.224.125.194 with SMTP id z2mr5345642qar.99.1397680072495; Wed, 16 Apr 2014 13:27:52 -0700 (PDT) MIME-Version: 1.0 References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> <534C4C84.1040200@andrew.cmu.edu> From: Gregory Yakushev Date: Wed, 16 Apr 2014 20:27:52 +0000 Message-ID: To: murch@andrew.cmu.edu, cyrus@daboo.name, calsify@ietf.org, "markdavis@google.com" Content-Type: multipart/alternative; boundary=001a11c206883b2f7204f72ec07f Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/8CsMJkr4jNC8blqlrkDFJwcrVRY Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 20:28:00 -0000 --001a11c206883b2f7204f72ec07f Content-Type: text/plain; charset=UTF-8 Some thoughts are inlined below. Adding Mark Davis for ICU perspective on Hebrew leap month implementation. On Mon Apr 14 2014 at 11:01:38 PM, Ken Murchison wrote: > Hi Cyrus, > > > > On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > > Hi Ken, > > > > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison > > wrote: > > > >> 1) Maybe I'm missing the point of the "L" suffix, but shouldn't the > >> RRULE in example 4.2.3 include the "L" suffix? E.g.: > >> > >> RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD > >> > >> If not, can an example be added that includes the "L" suffix? In either > >> case, I'm thinking an example or two of a non-yearly recurrence might be > >> helpful. > > > > In most calendar systems with a leap month, months are counted 1 > > through 12, with the leap month being tagged with the "L" suffix where > > it appears during the year. In the Hebrew calendar implementation in > > the unicode ICU library, the months are actually numbered 1 through > > 13. In non-leap years, month number 6 is simply skipped. That is > > already described in section 4.1 of the current draft. > > > > Now, I suspect from an implementation standpoint, one might want to > > use isLeapYear(N) as the trigger for adding the "L" suffix and I > > suspect (but have not checked) that would return true for Hebrew month > > 6. If that is the case, then I would agree we should probably require > > that behavior for RSCALE. > > > > What do others think? Should we change section 4.1 to state that "L" > > is always added to the leap month even in the Hebrew case? > > > I just ran a quick test using ICU within libical, and it doesn't appear > to set the IS_LEAP_MONTH flag for the Hebrew calendar for month 6. I > haven't tried it with other calendars (i.e. Chinese) to see if its > cal-specific. > > In any case, it would seem to me that the fact that ICU numbers the > months 1-13 is an internal implementation detail. How is the generator > of the iCalendar data supposed to know how the receiver numbers its > months? Or am I completely missing the point of "L"? > > We initially decided for the implementation to be calendaring system agnostic. We delegate all the logic to ICU, and don't make any special-casing for various calendaring systems. Such an approach has some advantages: 1. Any RSCALE implementation will support new RSCALES naturally as they become available in ICU 2. Any client using ICU for other calendaring arithmetics or localisation does not need any special-casing either: ICU will localize month 6 as Adar II, and non-leap. Otherwise clients would have to 'undo' our special-casing. 3. I know there's internal discussion among ICU developers on this issue. They may opt for introducing another calendaring system (HEBREW2 or something like that) which will treat leap month differently. If that will happen - RSCALE implementations will support it natively without any modification. The disadvantage is that we essentially tie RSCALE implementation to ICU implementation. Personally I prefer it this way because it makes life easier for the clients, but I see that its a debatable choice. >> 2) Also, if I understand SKIP correctly, can the handling of the > >> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by > >> using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps an > example > >> of this is also warranted, such as (borrowed from one of the CalConnect > >> etherpads): > >> > >> DTSTART:20120229T120000Z > >> RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z > >> > >> Occurs: > >> 20120229T120000Z > >> 20130301T120000Z > >> > >> Does not occur: > >> 20140301T120000Z > > > > Yes, one "side-effect" of RSCALE is that it does address the problem > > of how to deal with the Gregorian leap day by providing the skip > > option. Adding an example of that in section 4.2. > > > > That said, the current description of SKIP in Section 4 (list item 4) > > only refers to skipping leap months. In addition to the Gregorian leap > > day, there are other kinds of skips that occur - e.g., a monthly > > recurrence on January 31st (as currently defined by 5545) should only > > occur in months with 31 days - the others should be skipped. Should > > SKIP apply to that as well? It may not be necessary in all cases (e.g. > > the January 31st example is likely meant to be "last day of the month" > > which can be encoded precisely in RRULE - but if the intent was "the > > 31st or the 1st of the next month" then skip would be handy). > > > > Hmm. My thoughts are that SKIP should only apply to leap months and > possibly leap days. I'm not sure we want to venture any further than > that. I would think that 5545 should have handled the other cases already. > The support for Feb 29th and Jan 31st comes naturally from calendaring-system agnostic implementation. I'd prefer not to add a special case just to remove some functionality. We can point out that instead of specifying RSCALE=GREGORIAN;BYDAY=31;SKIP=BACKWARD clients may specify BYDAY=-1 and get compatibility advantage with non-RSCALE implementations. I still think that if everybody supports RSCALE, the former syntax is cleaner and works better for BYDAY=30. > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c206883b2f7204f72ec07f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some thoughts are inlined below. Adding Mark Davis for ICU perspective on H= ebrew leap month implementation.

On Mon Apr 14 2014 at 11:01:38= PM, Ken Murchison <murch@andrew= .cmu.edu> wrote:
Hi Cyrus,



On 04/14/2014 12:03 PM, Cyrus Daboo wrote:
> Hi Ken,
>
> --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison
> <murch@an= drew.cmu.edu> wrote:
>
>> 1) =C2=A0Maybe I'm missing the point of the "L" suff= ix, but shouldn't the
>> RRULE in example 4.2.3 include the "L" suffix? =C2=A0E.g= .:
>>
>> RRULE:RSCALE=3DHEBREW;FREQ=3DYEARLY;BYMONTH=3D6*L*;B= YMONTHDAY=3D8;SKIP=3DFORWARD
>>
>> If not, can an example be added that includes the "L" su= ffix? In either
>> case, I'm thinking an example or two of a non-yearly recurrenc= e might be
>> helpful.
>
> In most calendar systems with a leap month, months are counted 1
> through 12, with the leap month being tagged with the "L" su= ffix where
> it appears during the year. In the Hebrew calendar implementation in > the unicode ICU library, the months are actually numbered 1 through > 13. In non-leap years, month number 6 is simply skipped. That is
> already described in section 4.1 of the current draft.
>
> Now, I suspect from an implementation standpoint, one might want to > use isLeapYear(N) as the trigger for adding the "L" suffix a= nd I
> suspect (but have not checked) that would return true for Hebrew month=
> 6. If that is the case, then I would agree we should probably require<= br> > that behavior for RSCALE.
>
> What do others think? Should we change section 4.1 to state that "= ;L"
> is always added to the leap month even in the Hebrew case?


I just ran a quick test using ICU within libical, and it doesn't appear=
to set the IS_LEAP_MONTH flag for the Hebrew calendar for month 6. =C2=A0I<= br> haven't tried it with other calendars (i.e. Chinese) to see if its
cal-specific.

In any case, it would seem to me that the fact that ICU numbers the
months 1-13 is an internal implementation detail. =C2=A0How is the generato= r
of the iCalendar data supposed to know how the receiver numbers its
months? =C2=A0Or am I completely missing the point of "L"?


We initially decided for the implement= ation to be calendaring system agnostic. We delegate all the logic to ICU, = and don't make any special-casing for various calendaring systems. Such= an approach has some advantages:
1. Any RSCALE implementation will support new RSCALES naturally as the= y become available in ICU
2. Any client using ICU for other calen= daring arithmetics or localisation does not need any special-casing either:= ICU will localize month 6 as Adar II, and non-leap. Otherwise clients woul= d have to 'undo' our special-casing.
3. I know there's internal discussion among ICU developers on this= issue. They may opt for introducing another calendaring system (HEBREW2 or= something like that) which will treat leap month differently. If that will= happen - RSCALE implementations will support it natively without any modif= ication.

The disadvantage is that we essentially tie RSCALE impl= ementation to ICU implementation. Personally I prefer it this way because i= t makes life easier for the clients, but I see that its a debatable choice.=

>> 2) =C2=A0Also, if I understand SKIP correctly, can the handling of= the
>> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavio= r by
>> using RSCALE=3DGREGORIAN;SKIP=3DBACKWARD/FORWARD? =C2=A0If = so, perhaps an example
>> of this is also warranted, such as (borrowed from one of the CalCo= nnect
>> etherpads):
>>
>> DTSTART:20120229T120000Z
>> RRULE:RSCALE=3DGREGORIAN;SKIP=3DFORWARD;FREQ=3DYEARLY;UNTIL= =3D20140301T115959Z
>>
>> Occurs:
>> 20120229T120000Z
>> 20130301T120000Z
>>
>> Does not occur:
>> 20140301T120000Z
>
> Yes, one "side-effect" of RSCALE is that it does address the= problem
> of how to deal with the Gregorian leap day by providing the skip
> option. Adding an example of that in section 4.2.
>
> That said, the current description of SKIP in Section 4 (list item 4)<= br> > only refers to skipping leap months. In addition to the Gregorian leap=
> day, there are other kinds of skips that occur - e.g., a monthly
> recurrence on January 31st (as currently defined by 5545) should only<= br> > occur in months with 31 days - the others should be skipped. Should > SKIP apply to that as well? It may not be necessary in all cases (e.g.=
> the January 31st example is likely meant to be "last day of the m= onth"
> which can be encoded precisely in RRULE - but if the intent was "= the
> 31st or the 1st of the next month" then skip would be handy).
>

Hmm. =C2=A0My thoughts are that SKIP should only apply to leap months and possibly leap days. =C2=A0I'm not sure we want to venture any further t= han
that. =C2=A0I would think that 5545 should have handled the other cases alr= eady.

The support for Feb 29th and Jan = 31st comes naturally from calendaring-system agnostic implementation. I'= ;d prefer not to add a special case just to remove some functionality. We c= an point out that instead of specifying RSCALE=3DGREGORIAN;BYDAY=3D31;SKIP= =3DBACKWARD clients may specify BYDAY=3D-1 and get compatibility advantage = with non-RSCALE implementations. I still think that if everybody supports R= SCALE, the former syntax is cleaner and works better for BYDAY=3D30.
=C2=A0

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a11c206883b2f7204f72ec07f-- From nobody Thu Apr 24 07:14:23 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA01A02C8 for ; Thu, 24 Apr 2014 07:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qacO7nRfVgxk for ; Thu, 24 Apr 2014 07:14:16 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) by ietfa.amsl.com (Postfix) with ESMTP id 235CE1A02CC for ; Thu, 24 Apr 2014 07:14:14 -0700 (PDT) Received: from localhost.localdomain (cpe-76-180-146-83.buffalo.res.rr.com [76.180.146.83]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s3OEE009026934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 10:14:00 -0400 Message-ID: <53591C27.20005@andrew.cmu.edu> Date: Thu, 24 Apr 2014 10:13:59 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> In-Reply-To: <151706F27F9F2B2361A9C095@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.140619 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1400_1499 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Fv18rbKFsiIlR7qV-xF77jrTsbk Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:14:20 -0000 On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > Hi Ken, > > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison > wrote: > > > >> 2) Also, if I understand SKIP correctly, can the handling of the >> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by >> using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps an example >> of this is also warranted, such as (borrowed from one of the CalConnect >> etherpads): >> >> DTSTART:20120229T120000Z >> RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z >> >> Occurs: >> 20120229T120000Z >> 20130301T120000Z >> >> Does not occur: >> 20140301T120000Z > > Yes, one "side-effect" of RSCALE is that it does address the problem > of how to deal with the Gregorian leap day by providing the skip > option. Adding an example of that in section 4.2. > > That said, the current description of SKIP in Section 4 (list item 4) > only refers to skipping leap months. I'd be fine if SKIP only dealt with leap months, but the fact that the comment under the definition of SKIP states that that SKIP defaults to YES when RSCALE is not present, leads me to believe that SKIP was at one point thought to be used with outside of RSCALE. Perhaps this is leftover from an earlier revision of the spec. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Thu Apr 24 08:23:06 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78501A03AD for ; Thu, 24 Apr 2014 08:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb72B5kigTzv for ; Thu, 24 Apr 2014 08:23:02 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5751A1A0286 for ; Thu, 24 Apr 2014 08:23:02 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so2722297qga.11 for ; Thu, 24 Apr 2014 08:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=jCq04DjUHmX6VQULMK2+6plU7zqRgSxY+MoVfBC6iFc=; b=QCEnldiYoqHSizryeCjeYvXWYdpvR4ZzDRdcuST6NcHW2Q9fwoaNb0JVuno5FbateC LjiXBW1HYRu64jwzfpgjqhJxMNUHlw8h5DLwIE8IqhSRCgyjdw+/qHG6pvZLMKMKH/I8 9YxY1MRr+7TpL6Zdf1Z0pdw/85UgNrn2xJfK7yyvWit+IwO+IhYWv1dv/flRRc0OZueW P7JhD8yXqrj/TsozKMO+roJZh7MpdFln8W4po2JiHCazOfMGFPhG4gKPj/FJCH10/T7p lfnrRDoQiId8z3LJtLqynSWDAS8RvKpOZ4leGXndzpEyG8SjP/xAGsRPeFqbJzF5NLxG dsXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=jCq04DjUHmX6VQULMK2+6plU7zqRgSxY+MoVfBC6iFc=; b=BV8F9NAU14x0108uSmPl4uo14p/+dcYe5NCSYNoeoWE60XASj467QclY0KJzf7UHKs I6sAiHzKxc0rTlnEplj/artyBJDktkuEDG+SIJtvk8eNfFvn28nD5vMZr5wy5344tJLh TkElqkcz2ZNer3RTG/NGuHZyXT2ah05SKFXSQAbjYQlaDNOYlUgpYdUadAXA6DGAEjBf 6GCItbsUHwKofSWkK2ePAufcTM+vsE5w0ztUblfrYWNIxw2UPeLIVU4FtMrgzoXljxC1 27IlAM4j2PhtemUwKiMF7B9c1p46i/GtC/1F5v8MGDgKsKR3lekDJNMK1K2E5Qk97Sni bHFg== X-Gm-Message-State: ALoCoQkVpodXGNw/QrGhq3QjCchB87QTcQlHakp49b63YQDDsbR3L8VKItkhCZBgogLOcZQqZ3DTBPlhXgt4F77g8yO308PrZZ0fYvhPzQ3Aqiy6Ah5t1Ysdoq97LHKBKd1W2TE8n09CeKrCeJbdRzoyXSUGQTGZlE4E1P7U5h8CllFUFEF5In0F4SelIhehZ0NKeKlk3q19 X-Received: by 10.140.26.38 with SMTP id 35mr3304310qgu.111.1398352975943; Thu, 24 Apr 2014 08:22:55 -0700 (PDT) MIME-Version: 1.0 References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> <53591C27.20005@andrew.cmu.edu> From: Gregory Yakushev Date: Thu, 24 Apr 2014 15:22:55 +0000 Message-ID: To: Ken Murchison , Cyrus Daboo , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a11c14a4667725e04f7cb6c44 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/nzxoUze7KGrLDw6LxslKHb6QTE8 Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:23:03 -0000 --001a11c14a4667725e04f7cb6c44 Content-Type: text/plain; charset=UTF-8 It just references what the current, pre-RSCALE specification does. I.e. BYDAY=30 is identical to RSCALE=GREGORIAN;BYDAY=30;SKIP=YES. Maybe we should phrase it differently? On Thu Apr 24 2014 at 4:14:18 PM, Ken Murchison wrote: > On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > > Hi Ken, > > > > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison > > wrote: > > > > > > > >> 2) Also, if I understand SKIP correctly, can the handling of the > >> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by > >> using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps an > example > >> of this is also warranted, such as (borrowed from one of the CalConnect > >> etherpads): > >> > >> DTSTART:20120229T120000Z > >> RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z > >> > >> Occurs: > >> 20120229T120000Z > >> 20130301T120000Z > >> > >> Does not occur: > >> 20140301T120000Z > > > > Yes, one "side-effect" of RSCALE is that it does address the problem > > of how to deal with the Gregorian leap day by providing the skip > > option. Adding an example of that in section 4.2. > > > > That said, the current description of SKIP in Section 4 (list item 4) > > only refers to skipping leap months. > > I'd be fine if SKIP only dealt with leap months, but the fact that the > comment under the definition of SKIP states that that SKIP defaults to > YES when RSCALE is not present, leads me to believe that SKIP was at one > point thought to be used with outside of RSCALE. Perhaps this is > leftover from an earlier revision of the spec. > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c14a4667725e04f7cb6c44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It just references what the current, pre-RSCALE specification does. I.e. BY= DAY=3D30 is identical to RSCALE=3DGREGORIAN;BYDAY=3D30;SKIP=3DYES. Maybe we= should phrase it differently?

On Thu Apr 24 2014 at 4:14:18 PM= , Ken Murchison <murch@andrew.cm= u.edu> wrote:
On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > Hi Ken,
>
> --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison
> <murch@an= drew.cmu.edu> wrote:
>
>
>
>> 2) =C2=A0Also, if I understand SKIP correctly, can the handling of= the
>> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavio= r by
>> using RSCALE=3DGREGORIAN;SKIP=3DBACKWARD/FORWARD? =C2=A0If = so, perhaps an example
>> of this is also warranted, such as (borrowed from one of the CalCo= nnect
>> etherpads):
>>
>> DTSTART:20120229T120000Z
>> RRULE:RSCALE=3DGREGORIAN;SKIP=3DFORWARD;FREQ=3DYEARLY;UNTIL= =3D20140301T115959Z
>>
>> Occurs:
>> 20120229T120000Z
>> 20130301T120000Z
>>
>> Does not occur:
>> 20140301T120000Z
>
> Yes, one "side-effect" of RSCALE is that it does address the= problem
> of how to deal with the Gregorian leap day by providing the skip
> option. Adding an example of that in section 4.2.
>
> That said, the current description of SKIP in Section 4 (list item 4)<= br> > only refers to skipping leap months.

I'd be fine if SKIP only dealt with leap months, but the fact that the<= br> comment under the definition of SKIP states that that SKIP defaults to
YES when RSCALE is not present, leads me to believe that SKIP was at one point thought to be used with outside of RSCALE. Perhaps this is
leftover from an earlier revision of the spec.


--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a11c14a4667725e04f7cb6c44-- From nobody Thu Apr 24 08:28:23 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC31A0394 for ; Thu, 24 Apr 2014 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxjsuLaujQUm for ; Thu, 24 Apr 2014 08:28:17 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0364E1A03BD for ; Thu, 24 Apr 2014 08:28:16 -0700 (PDT) Received: from localhost.localdomain (cpe-76-180-155-12.buffalo.res.rr.com [76.180.155.12]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s3OFS8V2000413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 11:28:08 -0400 Message-ID: <53592D88.7010505@andrew.cmu.edu> Date: Thu, 24 Apr 2014 11:28:08 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Gregory Yakushev , Cyrus Daboo , calsify@ietf.org References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> <53591C27.20005@andrew.cmu.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010400070802070901030108" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.151517 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/H-ooNBVN4gkz1Dp3ZP_xFF5pqsc Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:28:19 -0000 This is a multi-part message in MIME format. --------------010400070802070901030108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Since the text of section 4 says that the SKIP, "L", etc changes only occur in the presence of RSCALE, I don't think we need a default for SKIP without RSCALE. SKIP should be ignored (or cause an error) unless RSCALE is present. On 04/24/2014 11:22 AM, Gregory Yakushev wrote: > It just references what the current, pre-RSCALE specification does. > I.e. BYDAY=30 is identical to RSCALE=GREGORIAN;BYDAY=30;SKIP=YES. > Maybe we should phrase it differently? > > On Thu Apr 24 2014 at 4:14:18 PM, Ken Murchison > wrote: > > On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > > Hi Ken, > > > > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison > > > wrote: > > > > > > > >> 2) Also, if I understand SKIP correctly, can the handling of the > >> Gregorian leap day (Feb 29) be changed from the non-RSCALE > behavior by > >> using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD? If so, perhaps > an example > >> of this is also warranted, such as (borrowed from one of the > CalConnect > >> etherpads): > >> > >> DTSTART:20120229T120000Z > >> > RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z > >> > >> Occurs: > >> 20120229T120000Z > >> 20130301T120000Z > >> > >> Does not occur: > >> 20140301T120000Z > > > > Yes, one "side-effect" of RSCALE is that it does address the problem > > of how to deal with the Gregorian leap day by providing the skip > > option. Adding an example of that in section 4.2. > > > > That said, the current description of SKIP in Section 4 (list > item 4) > > only refers to skipping leap months. > > I'd be fine if SKIP only dealt with leap months, but the fact that the > comment under the definition of SKIP states that that SKIP defaults to > YES when RSCALE is not present, leads me to believe that SKIP was > at one > point thought to be used with outside of RSCALE. Perhaps this is > leftover from an earlier revision of the spec. > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------010400070802070901030108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Since the text of section 4 says that the SKIP, "L", etc changes only occur in the presence of RSCALE, I don't think we need a default for SKIP without RSCALE.  SKIP should be ignored (or cause an error) unless RSCALE is present.


On 04/24/2014 11:22 AM, Gregory Yakushev wrote:
It just references what the current, pre-RSCALE specification does. I.e. BYDAY=30 is identical to RSCALE=GREGORIAN;BYDAY=30;SKIP=YES. Maybe we should phrase it differently?

On Thu Apr 24 2014 at 4:14:18 PM, Ken Murchison <murch@andrew.cmu.edu> wrote:
On 04/14/2014 12:03 PM, Cyrus Daboo wrote:
> Hi Ken,
>
> --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison
> <murch@andrew.cmu.edu> wrote:
>
>
>
>> 2)  Also, if I understand SKIP correctly, can the handling of the
>> Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by
>> using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD?  If so, perhaps an example
>> of this is also warranted, such as (borrowed from one of the CalConnect
>> etherpads):
>>
>> DTSTART:20120229T120000Z
>> RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z
>>
>> Occurs:
>> 20120229T120000Z
>> 20130301T120000Z
>>
>> Does not occur:
>> 20140301T120000Z
>
> Yes, one "side-effect" of RSCALE is that it does address the problem
> of how to deal with the Gregorian leap day by providing the skip
> option. Adding an example of that in section 4.2.
>
> That said, the current description of SKIP in Section 4 (list item 4)
> only refers to skipping leap months.

I'd be fine if SKIP only dealt with leap months, but the fact that the
comment under the definition of SKIP states that that SKIP defaults to
YES when RSCALE is not present, leads me to believe that SKIP was at one
point thought to be used with outside of RSCALE. Perhaps this is
leftover from an earlier revision of the spec.


--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------010400070802070901030108-- From nobody Thu Apr 24 08:39:16 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37DF1A02A4 for ; Thu, 24 Apr 2014 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrUFhodcuD_e for ; Thu, 24 Apr 2014 08:39:12 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 240D31A0275 for ; Thu, 24 Apr 2014 08:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A41166422469; Thu, 24 Apr 2014 11:39:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hie3zEGcUvAR; Thu, 24 Apr 2014 11:39:05 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id C8B41642245B; Thu, 24 Apr 2014 11:39:04 -0400 (EDT) Date: Thu, 24 Apr 2014 11:38:29 -0400 From: Cyrus Daboo To: Ken Murchison , calsify@ietf.org Message-ID: <95E24CDE510D13C89F452259@caldav.corp.apple.com> In-Reply-To: <53591C27.20005@andrew.cmu.edu> References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> <53591C27.20005@andrew.cmu.edu> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=697 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/P1YfopipMf70SwssxPbUV2ZLVuk Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:39:13 -0000 Hi Ken, --On April 24, 2014 at 10:13:59 AM -0400 Ken Murchison wrote: > I'd be fine if SKIP only dealt with leap months, but the fact that the > comment under the definition of SKIP states that that SKIP defaults to > YES when RSCALE is not present, leads me to believe that SKIP was at one > point thought to be used with outside of RSCALE. Perhaps this is leftover > from an earlier revision of the spec. > I think that comment is wrong. Here is a proposed change: skip = ("YES" / "BACKWARD" / "FORWARD") ; Optional, with default value "BACKWARD", ; and MUST only appear if "RSCALE" is present. -- Cyrus Daboo From nobody Thu Apr 24 09:22:52 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D4F1A0395 for ; Thu, 24 Apr 2014 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH4Y0scpT_gs for ; Thu, 24 Apr 2014 09:22:49 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4E41A0391 for ; Thu, 24 Apr 2014 09:22:48 -0700 (PDT) Received: from localhost.localdomain (cpe-76-180-155-12.buffalo.res.rr.com [76.180.155.12]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s3OGMfII004684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 12:22:42 -0400 Message-ID: <53593A51.3010605@andrew.cmu.edu> Date: Thu, 24 Apr 2014 12:22:41 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> <53591C27.20005@andrew.cmu.edu> <95E24CDE510D13C89F452259@caldav.corp.apple.com> In-Reply-To: <95E24CDE510D13C89F452259@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.161216 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/r5Hw7D7X98SXVUTLPDWeGWz1H-k Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:22:50 -0000 On 04/24/2014 11:38 AM, Cyrus Daboo wrote: > Hi Ken, > > --On April 24, 2014 at 10:13:59 AM -0400 Ken Murchison > wrote: > >> I'd be fine if SKIP only dealt with leap months, but the fact that the >> comment under the definition of SKIP states that that SKIP defaults to >> YES when RSCALE is not present, leads me to believe that SKIP was at one >> point thought to be used with outside of RSCALE. Perhaps this is >> leftover >> from an earlier revision of the spec. >> > > I think that comment is wrong. Here is a proposed change: > > skip = ("YES" / "BACKWARD" / "FORWARD") > ; Optional, with default value "BACKWARD", > ; and MUST only appear if "RSCALE" is present. > > Work for me. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Apr 29 09:23:38 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FC61A0776 for ; Tue, 29 Apr 2014 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Apa14vcpyK for ; Tue, 29 Apr 2014 09:23:33 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.37]) by ietfa.amsl.com (Postfix) with ESMTP id 803C51A0919 for ; Tue, 29 Apr 2014 09:23:31 -0700 (PDT) Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.7/8.14.8) with ESMTP id s3TGNK5m025589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Apr 2014 12:23:21 -0400 Message-ID: <535FD1F8.5020804@andrew.cmu.edu> Date: Tue, 29 Apr 2014 12:23:20 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: <53481BE5.4070607@andrew.cmu.edu> <151706F27F9F2B2361A9C095@caldav.corp.apple.com> In-Reply-To: <151706F27F9F2B2361A9C095@caldav.corp.apple.com> Content-Type: multipart/alternative; boundary="------------080802090306090401080608" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.29.161218 X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __INT_PROD_LOC 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 27% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/ywz2_UnCiPYcN5FVHYzle2QEaiE Subject: Re: [calsify] draft-daboo-icalendar-rscale and "L" suffix X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:23:36 -0000 This is a multi-part message in MIME format. --------------080802090306090401080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/14/2014 12:03 PM, Cyrus Daboo wrote: > Hi Ken, > > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison > wrote: > >> 1) Maybe I'm missing the point of the "L" suffix, but shouldn't the >> RRULE in example 4.2.3 include the "L" suffix? E.g.: >> >> RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD >> >> If not, can an example be added that includes the "L" suffix? In either >> case, I'm thinking an example or two of a non-yearly recurrence might be >> helpful. > > In most calendar systems with a leap month, months are counted 1 > through 12, with the leap month being tagged with the "L" suffix where > it appears during the year. In the Hebrew calendar implementation in > the unicode ICU library, the months are actually numbered 1 through > 13. In non-leap years, month number 6 is simply skipped. That is > already described in section 4.1 of the current draft. > > Now, I suspect from an implementation standpoint, one might want to > use isLeapYear(N) as the trigger for adding the "L" suffix and I > suspect (but have not checked) that would return true for Hebrew month > 6. If that is the case, then I would agree we should probably require > that behavior for RSCALE. > > What do others think? Should we change section 4.1 to state that "L" > is always added to the leap month even in the Hebrew case? Hi Cyrus, After just about completing an RSCALE implementation in libical using ICU, I'm more convinced that we shouldn't be exposing ICU warts in the RSCALE spec. The fact that ICU treats leap months in the Hebrew calendar different from the Chinese calendar is unfortunate , but that fact should be handled by the implementation using ICU, not the RSCALE spec where the ICU idiosyncrasies get forced on other non-ICU-based implementations. So, I'm proposing that the leap month in the Hebrew calendar be 6L (or even 5L) in RSCALE with the last month being 12 (not 13). Month 13 should only be used in RSCALE for calendars that have 13-month non-leap years (Coptic, Ethiopic). Implementations based in ICU already have to translate month numbers from being 1-based in iCalendar to 0-based in ICU, so tweaking the translation for the Hebrew calendar shouldn't be a problem: 1-5 -> 0-4, 6L -> 5, 6-12 -> 6-12. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------080802090306090401080608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/14/2014 12:03 PM, Cyrus Daboo wrote:
Hi Ken,

--On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison <murch@andrew.cmu.edu> wrote:

1)  Maybe I'm missing the point of the "L" suffix, but shouldn't the
RRULE in example 4.2.3 include the "L" suffix?  E.g.:

RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD

If not, can an example be added that includes the "L" suffix?  In either
case, I'm thinking an example or two of a non-yearly recurrence might be
helpful.

In most calendar systems with a leap month, months are counted 1 through 12, with the leap month being tagged with the "L" suffix where it appears during the year. In the Hebrew calendar implementation in the unicode ICU library, the months are actually numbered 1 through 13. In non-leap years, month number 6 is simply skipped. That is already described in section 4.1 of the current draft.

Now, I suspect from an implementation standpoint, one might want to use isLeapYear(N) as the trigger for adding the "L" suffix and I suspect (but have not checked) that would return true for Hebrew month 6. If that is the case, then I would agree we should probably require that behavior for RSCALE.

What do others think? Should we change section 4.1 to state that "L" is always added to the leap month even in the Hebrew case?

Hi Cyrus,

After just about completing an RSCALE implementation in libical using ICU, I'm more convinced that we shouldn't be exposing ICU warts in the RSCALE spec.  The fact that ICU treats leap months in the Hebrew calendar different from the Chinese calendar is unfortunate, but that fact should be handled by the implementation using ICU, not the RSCALE spec where the ICU idiosyncrasies get forced on other non-ICU-based implementations.

So, I'm proposing that the leap month in the Hebrew calendar be 6L (or even 5L) in RSCALE with the last month being 12 (not 13).  Month 13 should only be used in RSCALE for calendars that have 13-month non-leap years (Coptic, Ethiopic).

Implementations based in ICU already have to translate month numbers from being 1-based in iCalendar to 0-based in ICU, so tweaking the translation for the Hebrew calendar shouldn't be a problem: 1-5 -> 0-4, 6L -> 5, 6-12 -> 6-12.


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------080802090306090401080608--