From nobody Mon Feb 2 11:06:50 2015 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 25E2F1A894F for ; Mon, 2 Feb 2015 11:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.222 X-Spam-Level: *** X-Spam-Status: No, score=3.222 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, 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 lwMucdnkWZKV for ; Mon, 2 Feb 2015 11:06:34 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72F41A893F for ; Mon, 2 Feb 2015 11:06:29 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id q108so48954730qgd.13 for ; Mon, 02 Feb 2015 11:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=aBqFFWcM4yA2feM0KZBVZzJImyZaFgqBdgO/5RJPE24=; b=NjbemU+n9jeXBZmJR+C+z8leYdkOP0O01AktMnfoLbk5KuFCNP9EdLYMk2E5GhwYms tLG2qI8tLBhrnA/YJIWd6zxt1FkwxnKDRmuZo++NeYVg9rTYks7oj1ntDg8KQ6x48epB vcJf4WZN2mOJMdiLHePI1dqejxQ/t70ndPluSzCb99xwwmjbM7/UllPPMD7O10YdkYny W1Kwy7aWwEuGrls3nZ1avrl/B7c1oBSOObggqVZaCiX7LhmcovTha9FfyJeouZwbnXDy Rjz5C9mwWsHyof1Jvoxl8bb2e4BdqrUK36hEKSB6+PEp1jhgap+eCqVJOqjTBtSeVoBd RGPg== MIME-Version: 1.0 X-Received: by 10.229.89.196 with SMTP id f4mr1268238qcm.3.1422903988924; Mon, 02 Feb 2015 11:06:28 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.163 with HTTP; Mon, 2 Feb 2015 11:06:28 -0800 (PST) In-Reply-To: <54CA9012.9090603@andrew.cmu.edu> References: <54CA9012.9090603@andrew.cmu.edu> Date: Mon, 2 Feb 2015 14:06:28 -0500 X-Google-Sender-Auth: KrQm14ndQIvbnu4qc4hk1lEDgYc Message-ID: From: Barry Leiba To: Calsify Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 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, 02 Feb 2015 19:06:36 -0000 Marten and Ken, thanks for the replies. You've both addressed some of the same comments, so I'll try to reply in one message. --- On point 2: >> It seems funny that SKIP has a fixed default, rather than being >> dependent upon the RSCALE. For the Hebrew calendar, for example, the >> default is wrong, and one always needs SKIP=FORWARD. It seems likely >> that there'll be lots of errors involved in forgetting the SKIP and >> having the default be wrong for the calendar that's being used, which >> will cause interoperability problems that would be avoided if the >> default depended on the calendar. (See also my comment #8 below >> about Section 4.2.4.) Marten says... > Having the same default value for all calendar scales at least guarantees > consistent results among different implementations when you forget the SKIP > value. IMHO, having per-calendar-scale default values adds unnecessary > complexity and it's questionable if you can find consensus on what the > default should be for various scales (I don't think that the CLDR has > defined default skip values so far). > Also, I think the likelihood of implementing the per-calendar-scale default > values wrong, is probably just as high as forgetting a SKIP value. > > Setting the default to "SKIP=YES" (or "SKIP=OMIT", which sounds reasonable > to me) would be the simplest solution, because it's the current behavior > anyway. Ken says... > Perhaps an alternative to having a per-calendar default would be to make > SKIP mandatory in the presence of RSCALE, thereby forcing the user/client to > be explicit in their expectations. To Marten, the point I'm making is that in order to support various calendars correctly, implementations need to understand how to correctly skip within each calendar anyway. That is, all implementations that support the Hebrew calendar will need to know that when Adar I (5L) is not present, you have to skip forward to Adar (6)... and they'll need to know that regardless of what default we place on SKIP. That means that generating a Hebrew calendar entry in Adar I without SKIP is an error. It seems to be inviting problems to take an attribute whose value is fixed to the calendar, and to give it a default that is always correct for some calendars and always wrong for others... is the wrong approach. Consider what happens when a buggy implementation incorrectly omits SKIP. Consumers of that entry will then necessarily get things wrong for the Hebrew calendar, always (well, always for entries in Adar I). I think the default either has to be set appropriately for each calendar (and Marten is right that there's a problem with that, in that you have to have some place to make that assignment, which would have to mean a registry for it), or to do as Ken suggests and make SKIP=OMIT be the default. I think I like that answer. But making SKIP required would also work, and I'd be happy with that alternative as well. --- On point 7: >> 7. Section 4.2.2 >> I don't understand why this example needs the BYMONTH value, and why >> FREQ=YEARLY isn't enough. Isn't this exactly the same as the example >> in 4.2.1, where "BYMONTH=1" isn't needed? Marten says... > True, it's not necessary to specify BYMONTH and BYMONTHDAY in sections 4.2.2 > and 4.2.3. But according to RFC 5545 it's completely valid and you can see > many rules like that in the wild. > The purpose of an example is to show how an RRULE could look like in real > life and how you have to interpret it. To me it perfectly makes sense to > give examples of both types of rules (i.e. with and without redundant > BYMONTH and BYMONTHDAY parts). Ken says... > As you point out, BYMONTH technically isn't needed. I had suggested this > example to Cyrus to illustrate to readers the fact that BYMONTH can take a > value > 12 depending on the calendar. If you feel that illustrating this > point isn't necessary, or feel that a better example should be considered, > I'm fine either way. I understand that, while it's not needed, it's legal. My point was that I didn't see that this example was any different from the previous one, so why have it? It might actually lead a reader to believe that BYMONTH was necessary in this case. Thanks to both Marten and Ken for explaining reasons to have the example. I think it's useful to illustrate the points that it can be there even though it's not required, and that it can have a value > 12. I think it would help to have text in the example that explains both of those points. --- On point 8: >> 8. Section 4.2.4 >> Ooh, this seems completely wrong unless SKIP is redefined to be >> dependent upon the calendar. In 4.2.3, you're showing me how >> SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the >> same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29. Of course, >> that's what we want to happen, but how can I know that from the >> explanation of SKIP? More to the point, it's clear from these two >> examples that the behaviour of SKIP has to depend upon the calendar >> that's in effect, and trying to define it to be independent doesn't >> work. Marten says... > The idea is: If you skip a leap month, you go forward (or backwards) by one > month. If you skip a leap day you go forward (or backwards) by one day. > I guess that should be pointed out somewhere. Ken says... > I'd be in favor of additional text clarifying that the effect of SKIP > depends on whether the recurrence falls on an intercalary day or month. Indeed: there's nothing at all in the document that says that SKIP works differently in different situations, and I think it's necessary to have very clear text there that specifies exactly how skip works when. And I think this makes it more evident that "SKIP=OMIT" should be the default... otherwise, the default for anyone who specifies "RSCALE=GREGORIAN" will turn 29 Feb into 28 Feb. It'd be far better for it to work as it does today, unless SKIP is explicitly specified. --- On point 9: Marten says... > #9: > I think that part has been added after I asked about the case-sensitivity of > the RSCALE value. In general most calendar applications tend to use the > upper-case representation of names and tokens, but the CLDR calendar scale > names are defined in lower case (as in > http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml). > I know it's just an implementation detail rather than being relevant for > this standard, but being able to make assumptions about the case allows for > certain optimization that wouldn't be possible otherwise. On a mobile device > with very limited resources that can make a difference. > In this context I think "for consistency" means consistency between > implementations, i.e. ideally all implementations would use the upper-case > version, even though the standard doesn't enforce it (because most things in > RFC 5545 are, by definition, case-insensitive). Ah, but because it's defined as being case insensitive, you're *not* able to make assumptions about the case, and you can't optimize anything. You don't know when you might be handed something that doesn't follow that SHOULD, so your code has to handle it (and I'd argue that if your code requires that it be in upper case, and doesn't work if it's not, your code is broken). I think we should have required upper case in the base iCalendar spec. But the fact that we didn't is a ship that's sailed under the bridge and through the barn door. Sigh. But that means that the SHOULD is really pointless. I'm happy if you use plain English to say that there are advantages to using upper case, and remind readers that iCalendar strongly recommends it. I don't think 2119 SHOULD is appropriate. > I guess the same applies to the SKIP values and the "L" of leap months. Does > this spec allow a lower case "l"? It does, because literals in ABNF are case-insensitive (see RFC 5234). --- Barry From nobody Mon Feb 2 19:33:24 2015 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 1FAA91A1DBC for ; Mon, 2 Feb 2015 19:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pyiwITYf9U8r for ; Mon, 2 Feb 2015 19:33:20 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453961A1BED for ; Mon, 2 Feb 2015 19:33:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B5C77AB828C; Mon, 2 Feb 2015 22:33:17 -0500 (EST) 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 1l_VyzvWV1Yu; Mon, 2 Feb 2015 22:33:17 -0500 (EST) Received: from [10.0.1.25] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id EF451AB8281; Mon, 2 Feb 2015 22:33:16 -0500 (EST) Date: Mon, 02 Feb 2015 22:33:13 -0500 From: Cyrus Daboo To: Calsify Message-ID: <68FCD7D11F934509267D5915@cyrus.local> 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=1327 Archived-At: Cc: Barry Leiba Subject: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 03:33:22 -0000 Hi, (Dealing with Barry's AD review issues #2 and #8 in a separate thread) OK, so I think you have identified a legitimate issue with SKIP. I would like to clarify the skip behavior as described below. I will propose concrete changes to the draft once we have agreed on the basic concepts. When a recurrence generates an invalid date, the following applies when SKIP is set to FORWARD or BACKWARD: 1) If the invalid date was generated from a rule starting on a leap day or a leap month: the SKIP value for forward/backward is then a day or a month, respectively. 2) If the invalid date was generated from a rule starting on a day-of-month not valid in the current month: the SKIP value for forward/backward is to the nearest valid day. 3) If the invalid date was generated from a rule with a BYMONTHDAY that results in a day-of-month not valid in the current month: the SKIP value for forward/backward is to the nearest valid day. Note that the above "rules" for SKIP are independent of the actual RSCALE value, which I believe is the correct approach (because otherwise we would need some kind of registry or an indicator from ICU as to what the behavior should be for each calendar scale). Can other RRULE experts please review the above and make sure those three descriptions are valid? -- Cyrus Daboo From nobody Mon Feb 2 19:41:24 2015 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 2B3101A1C02 for ; Mon, 2 Feb 2015 19:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 XtJ6aOVcmDkM for ; Mon, 2 Feb 2015 19:41:21 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925671A1BBE for ; Mon, 2 Feb 2015 19:41:20 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id pn19so1558419lab.2 for ; Mon, 02 Feb 2015 19:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hnNQLKONT04T0mCDC2oaKyThHRugH6bp+YEtvkME3n0=; b=DN/SExXq+HWISKadFtm2ud+Xt95pG9H1vlvuEpTuo9+TsTQY0c5DGV1eFmylZJMws3 YY9/NKRCYKSJot+bA4WAuiABb6P9NjFYGu9004RyUHBsV65WAzDflGHuVtlgGw6Kb2SR 7PJ3kxApgcmKxzYmYq6wbiECp8gH6O5AEJtE+FcpJOmgteIVg65xZCuV1JY6P/T4+ca8 Kbu3+APzA32qb5bXsu+y2ESsUrXAlt3j/bZweLgN5bXlnm2OxNwto3tbta5LFWsAI38y 971I6nrVmMJGq95zu5jGXy86KiAm5XslVHk7YbNSC2GIZ8S35vuazVqXwKYxIPWSLlOV I6kQ== MIME-Version: 1.0 X-Received: by 10.112.217.68 with SMTP id ow4mr22299120lbc.97.1422934878738; Mon, 02 Feb 2015 19:41:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 2 Feb 2015 19:41:18 -0800 (PST) In-Reply-To: <68FCD7D11F934509267D5915@cyrus.local> References: <68FCD7D11F934509267D5915@cyrus.local> Date: Mon, 2 Feb 2015 22:41:18 -0500 X-Google-Sender-Auth: izn8Ex7KrOgB45bNQ4umuooo9io Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: multipart/alternative; boundary=001a1134c93efc5fb6050e26d7c0 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 03:41:22 -0000 --001a1134c93efc5fb6050e26d7c0 Content-Type: text/plain; charset=ISO-8859-1 I think those descriptions are clear, and they look correct and complete to me. I'd be happy with them if the working group agrees. But let me present an alternative formulation: 1. If the date is invalid because the month is not a valid month in the currect year, the SKIP is to the next (forward) or previous (backward) valid month. 2. Otherwise, the SKIP is to the next (forward) or previous (backward) valid day. I think that covers the situation. If you think you need to explain the different "day" situations further, which is never a bad thing, that can be added as explanatory text. Yes/no? Barry On Monday, February 2, 2015, Cyrus Daboo wrote: > Hi, > (Dealing with Barry's AD review issues #2 and #8 in a separate thread) > > OK, so I think you have identified a legitimate issue with SKIP. I would > like to clarify the skip behavior as described below. I will propose > concrete changes to the draft once we have agreed on the basic concepts. > > When a recurrence generates an invalid date, the following applies when > SKIP is set to FORWARD or BACKWARD: > > 1) If the invalid date was generated from a rule starting on a leap day or > a leap month: the SKIP value for forward/backward is then a day or a month, > respectively. > > 2) If the invalid date was generated from a rule starting on a > day-of-month not valid in the current month: the SKIP value for > forward/backward is to the nearest valid day. > > 3) If the invalid date was generated from a rule with a BYMONTHDAY that > results in a day-of-month not valid in the current month: the SKIP value > for forward/backward is to the nearest valid day. > > Note that the above "rules" for SKIP are independent of the actual RSCALE > value, which I believe is the correct approach (because otherwise we would > need some kind of registry or an indicator from ICU as to what the behavior > should be for each calendar scale). > > Can other RRULE experts please review the above and make sure those three > descriptions are valid? > > -- > Cyrus Daboo > > --001a1134c93efc5fb6050e26d7c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think those descriptions are clear, and they look correct and complete to= me.=A0 I'd be happy with them if the working group agrees.

But let me present an alternative formulation:

=
1. If the date is invalid because the month is not a valid month in th= e currect year, the SKIP is to the next (forward) or previous (backward) va= lid=A0month.

2. Otherwise, the SKIP=A0is to the=A0= next (forward) o= r previous (backward) valid day.
=
I think that covers the situation.=A0 If yo= u think you need to explain the different "day" situations furthe= r, which is never a bad thing, that can be added as explanatory text.=A0 Ye= s/no?

Barry

On Monday, February= 2, 2015, Cyrus Daboo <cyrus@daboo.n= ame> wrote:
Hi,
(Dealing with Barry's AD review issues #2 and #8 in a separate thread)<= br>
OK, so I think you have identified a legitimate issue with SKIP. I would li= ke to clarify the skip behavior as described below. I will propose concrete= changes to the draft once we have agreed on the basic concepts.

When a recurrence generates an invalid date, the following applies when SKI= P is set to FORWARD or BACKWARD:

1) If the invalid date was generated from a rule starting on a leap day or = a leap month: the SKIP value for forward/backward is then a day or a month,= respectively.

2) If the invalid date was generated from a rule starting on a day-of-month= not valid in the current month: the SKIP value for forward/backward is to = the nearest valid day.

3) If the invalid date was generated from a rule with a BYMONTHDAY that res= ults in a day-of-month not valid in the current month: the SKIP value for f= orward/backward is to the nearest valid day.

Note that the above "rules" for SKIP are independent of the actua= l RSCALE value, which I believe is the correct approach (because otherwise = we would need some kind of registry or an indicator from ICU as to what the= behavior should be for each calendar scale).

Can other RRULE experts please review the above and make sure those three d= escriptions are valid?

--
Cyrus Daboo

--001a1134c93efc5fb6050e26d7c0-- From nobody Mon Feb 2 20:10:30 2015 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 860DA1A1DE2 for ; Mon, 2 Feb 2015 20:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gPOOZAZuuxYQ for ; Mon, 2 Feb 2015 20:10:25 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CA61A1EEE for ; Mon, 2 Feb 2015 20:10:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id ED02CAB901A; Mon, 2 Feb 2015 23:10:16 -0500 (EST) 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 LmoTAB5Z4XOa; Mon, 2 Feb 2015 23:10:16 -0500 (EST) Received: from [10.0.1.25] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 014DFAB900A; Mon, 2 Feb 2015 23:10:15 -0500 (EST) Date: Mon, 02 Feb 2015 23:10:14 -0500 From: Cyrus Daboo To: Barry Leiba Message-ID: <7FF77F2FE3390FFD1149E953@cyrus.local> In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> 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=1596 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 04:10:27 -0000 Hi Barry, --On February 2, 2015 at 10:41:18 PM -0500 Barry Leiba wrote: > I think those descriptions are clear, and they look correct and complete > to me. I'd be happy with them if the working group agrees. > > But let me present an alternative formulation: > > 1. If the date is invalid because the month is not a valid month in the > currect year, the SKIP is to the next (forward) or previous (backward) > valid month. > > 2. Otherwise, the SKIP is to the next (forward) or previous (backward) > valid day. > > I think that covers the situation. If you think you need to explain the > different "day" situations further, which is never a bad thing, that can > be added as explanatory text. Yes/no? That might be sufficient, but with one further complication that just occurred to me. For the case of a leap month, what happens if the day-of-month value in the skipped to non-leap month is now not valid for that month? e.g., leap month has 30 days, following month only has 29 days. Do we then also apply the forward/backward nearest valid day skip to the resulting invalid date too? I think we have to state that as well. So with your rules, #2 is not an "otherwise". So perhaps this: 1. If the date is invalid because the month is not a valid month in the correct year, the SKIP is to the next (forward) or previous (backward) valid month. Use the resulting date for the next test. 2. If the date is invalid because the day-of-month is not valid for that month, the SKIP is to the next (forward) or previous (backward) valid day. -- Cyrus Daboo From nobody Mon Feb 2 20:12:18 2015 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 736061A1EEB for ; Mon, 2 Feb 2015 20:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 oPFeKRuD5QNx for ; Mon, 2 Feb 2015 20:12:16 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BEA1A1DE2 for ; Mon, 2 Feb 2015 20:12:15 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gm9so47861421lab.0 for ; Mon, 02 Feb 2015 20:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eS6yrrCyWIhmf4Cc99heQecWeDGZi5FgiXCbzFrhPO8=; b=cZ1CjyBXFlB3u4QCdrD31iio/e8PfKYx5P682K+2V1SaVBmqNDmyuPzHFQuyly6NJC pQjI3coCm02Ie3AF4MhIp9NLCsIpB7fp4DJAuhUUVGoY42Xfjegq4RqFH9mkCPbzKZME Ompft5+SdkufozDPQklTAM+KOa4Djh15z8OJinw+Xkgu91KNOtTZTiZdlCZMBtT9tu+J cu+HMdiNjBG4UvdBhtBVLdZ052mNkNYuIbIl8ONnJwOc/PmNoG2r+0S07o+71FwyaIEV 1AZDrrB1Ux/pMVhcuaxUZ5oJQ2MipxYsBZy/yVXBt8SVy+fYZqmZwZ2MjU/SaIA8KC4h jYeg== MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr22479239lab.1.1422936734142; Mon, 02 Feb 2015 20:12:14 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 2 Feb 2015 20:12:14 -0800 (PST) In-Reply-To: <7FF77F2FE3390FFD1149E953@cyrus.local> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> Date: Mon, 2 Feb 2015 23:12:14 -0500 X-Google-Sender-Auth: eM4cT9jyR8NH0V2PMiAfN0r0QoM Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: multipart/alternative; boundary=001a1132f49a9398cf050e27461b Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 04:12:17 -0000 --001a1132f49a9398cf050e27461b Content-Type: text/plain; charset=ISO-8859-1 Yes... I thought about that as I was sending the last message, but then figured that never happens. But maybe it can. I think your version here does cover it. b On Monday, February 2, 2015, Cyrus Daboo wrote: > Hi Barry, > > --On February 2, 2015 at 10:41:18 PM -0500 Barry Leiba < > barryleiba@computer.org> wrote: > > I think those descriptions are clear, and they look correct and complete >> to me. I'd be happy with them if the working group agrees. >> >> But let me present an alternative formulation: >> >> 1. If the date is invalid because the month is not a valid month in the >> currect year, the SKIP is to the next (forward) or previous (backward) >> valid month. >> >> 2. Otherwise, the SKIP is to the next (forward) or previous (backward) >> valid day. >> >> I think that covers the situation. If you think you need to explain the >> different "day" situations further, which is never a bad thing, that can >> be added as explanatory text. Yes/no? >> > > That might be sufficient, but with one further complication that just > occurred to me. For the case of a leap month, what happens if the > day-of-month value in the skipped to non-leap month is now not valid for > that month? e.g., leap month has 30 days, following month only has 29 days. > Do we then also apply the forward/backward nearest valid day skip to the > resulting invalid date too? I think we have to state that as well. So with > your rules, #2 is not an "otherwise". So perhaps this: > > 1. If the date is invalid because the month is not a valid month in the > correct year, the SKIP is to the next (forward) or previous (backward) > valid month. Use the resulting date for the next test. > > 2. If the date is invalid because the day-of-month is not valid for that > month, the SKIP is to the next (forward) or previous (backward) valid day. > > > -- > Cyrus Daboo > > --001a1132f49a9398cf050e27461b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes... I thought about that as I was sending the last message, but then fig= ured that never happens.=A0 But maybe it can.=A0 I think your version here= =A0does cover it.

b

On Monday, February 2, 2015, = Cyrus Daboo <cyrus@daboo.name>= ; wrote:
Hi Barry,

--On February 2, 2015 at 10:41:18 PM -0500 Barry Leiba <barryleiba@co= mputer.org> wrote:

I think those descriptions are clear, and they look correct and complete to me.=A0 I'd be happy with them if the working group agrees.

But let me present an alternative formulation:

1. If the date is invalid because the month is not a valid month in the
currect year, the SKIP is to the next (forward) or previous (backward)
valid month.

2. Otherwise, the SKIP is to the next (forward) or previous (backward)
valid day.

I think that covers the situation.=A0 If you think you need to explain the<= br> different "day" situations further, which is never a bad thing, t= hat can
be added as explanatory text.=A0 Yes/no?

That might be sufficient, but with one further complication that just occur= red to me. For the case of a leap month, what happens if the day-of-month v= alue in the skipped to non-leap month is now not valid for that month? e.g.= , leap month has 30 days, following month only has 29 days. Do we then also= apply the forward/backward nearest valid day skip to the resulting invalid= date too? I think we have to state that as well. So with your rules, #2 is= not an "otherwise". So perhaps this:

1. If the date is invalid because the month is not a valid month in the
correct year, the SKIP is to the next (forward) or previous (backward)
valid month. Use the resulting date for the next test.

2. If the date is invalid because the day-of-month is not valid for that mo= nth, the SKIP is to the next (forward) or previous (backward) valid day.

--
Cyrus Daboo

--001a1132f49a9398cf050e27461b-- From nobody Tue Feb 3 06:50:44 2015 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 67F111A0404 for ; Tue, 3 Feb 2015 06:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 P3OQHGs6PUXg for ; Tue, 3 Feb 2015 06:50:41 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98771A03A9 for ; Tue, 3 Feb 2015 06:50:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id EA248AC21EB; Tue, 3 Feb 2015 09:50:39 -0500 (EST) 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 ZAdytu9CeJS0; Tue, 3 Feb 2015 09:50:39 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id D05E3AC21E0; Tue, 3 Feb 2015 09:50:38 -0500 (EST) Date: Tue, 03 Feb 2015 09:51:01 -0500 From: Cyrus Daboo To: Barry Leiba Message-ID: In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> 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=1535 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 14:50:43 -0000 Hi Barry, --On February 2, 2015 at 11:12:14 PM -0500 Barry Leiba wrote: > Yes... I thought about that as I was sending the last message, but then > figured that never happens. But maybe it can. I think your version > here does cover it. Actually I have thought some more about it too and come to a slightly different conclusion. I think when a SKIP=FORWARD is used with a leap month, the correct behavior, if the resulting date is invalid, is to keep the (valid) month fixed, and instead change the date to the last day of that month (in effect a SKIP=BACKWARD for the invalid date). I think that makes sense because if my birthday was the last day of a leap month I would probably want to celebrate on the last day of the next month, not the first day of the month after that. Similarly, if SKIP=BACKWARD is used with a leap month, then SKIP=BACKWARD should also be applied to any invalid date that results - the same argument for SKIP=FORWARD being relevant. So I now have this: 1. If the date is invalid because the month is not a valid month in the correct year, the SKIP is to the next (forward) or previous (backward) valid month. If the resulting date is invalid (the day-of-month exceeds the number of days in the specified month) then adjust the day-of-month to the last (valid) value for that month. 2. Otherwise, if the date is invalid because the day-of-month is not valid for that month, the SKIP is to the next (forward) or previous (backward) valid day. -- Cyrus Daboo From nobody Tue Feb 3 07:02:19 2015 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 683191A0377 for ; Tue, 3 Feb 2015 07:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 bUMCu-rNsB_J for ; Tue, 3 Feb 2015 07:02:11 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4C41A036E for ; Tue, 3 Feb 2015 07:02:11 -0800 (PST) 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.8/8.14.8) with ESMTP id t13F21HM001496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 10:02:02 -0500 Message-ID: <54D0E2E9.2030505@andrew.cmu.edu> Date: Tue, 03 Feb 2015 10:02:01 -0500 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 , Barry Leiba References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030507000303010300080908" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.3.145118 X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODYTEXTH_SIZE_10000_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, REFERENCES 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, __MAL_TELEKOM_URI 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 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.105.203 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 15:02:14 -0000 This is a multi-part message in MIME format. --------------030507000303010300080908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Cyrus, On 02/03/2015 09:51 AM, Cyrus Daboo wrote: > Hi Barry, > > --On February 2, 2015 at 11:12:14 PM -0500 Barry Leiba > wrote: > >> Yes... I thought about that as I was sending the last message, but then >> figured that never happens. But maybe it can. I think your version >> here does cover it. > > Actually I have thought some more about it too and come to a slightly > different conclusion. I think when a SKIP=FORWARD is used with a leap > month, the correct behavior, if the resulting date is invalid, is to > keep the (valid) month fixed, and instead change the date to the last > day of that month (in effect a SKIP=BACKWARD for the invalid date). I > think that makes sense because if my birthday was the last day of a > leap month I would probably want to celebrate on the last day of the > next month, not the first day of the month after that. Similarly, if > SKIP=BACKWARD is used with a leap month, then SKIP=BACKWARD should > also be applied to any invalid date that results - the same argument > for SKIP=FORWARD being relevant. > > So I now have this: > > 1. If the date is invalid because the month is not a valid month in the > correct year, the SKIP is to the next (forward) or previous (backward) > valid month. If the resulting date is invalid (the day-of-month > exceeds the number of days in the specified month) then adjust the > day-of-month to the last (valid) value for that month. > > 2. Otherwise, if the date is invalid because the day-of-month is not > valid for that month, the SKIP is to the next (forward) or previous > (backward) valid day. I was also thinking about birthdays and doing some research. For the case of birthdays on the Hebrew calendar, if we can trust Wikipedia , its fairly complex: "Based on a line in the Mishnah declaring that Purim must be celebrated in Adar II in a leap year (Megillah 1:4), Adar I is considered the "extra" month. As a result, someone born in Adar during a non leap year would celebrate his birthday in Adar II during a leap year. However, someone born during either Adar in a leap year will celebrate his birthday during Adar in a non-leap year, except that someone born on 30 Adar I will celebrate his birthday on 1 Nisan in a non-leap year because Adar in a non-leap year has only 29 days.^[1] " It appears your previous rules properly handle the 30 Adar I (leap year) case, but the new rules do not. Can we come up with rules that can model the 3 cases listed above? I'm doing some more digging on this and probably need to look at what the Chinese do to celebrate birthdates in leap years as well. Do we have any i8ln experts in the IETF that we can lean on for this stuff? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------030507000303010300080908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Cyrus,

On 02/03/2015 09:51 AM, Cyrus Daboo wrote:
Hi Barry,

--On February 2, 2015 at 11:12:14 PM -0500 Barry Leiba <barryleiba@computer.org> wrote:

Yes... I thought about that as I was sending the last message, but then
figured that never happens.  But maybe it can.  I think your version
here does cover it.

Actually I have thought some more about it too and come to a slightly different conclusion. I think when a SKIP=FORWARD is used with a leap month, the correct behavior, if the resulting date is invalid, is to keep the (valid) month fixed, and instead change the date to the last day of that month (in effect a SKIP=BACKWARD for the invalid date). I think that makes sense because if my birthday was the last day of a leap month I would probably want to celebrate on the last day of the next month, not the first day of the month after that. Similarly, if SKIP=BACKWARD is used with a leap month, then SKIP=BACKWARD should also be applied to any invalid date that results - the same argument for SKIP=FORWARD being relevant.

So I now have this:

1. If the date is invalid because the month is not a valid month in the
correct year, the SKIP is to the next (forward) or previous (backward)
valid month. If the resulting date is invalid (the day-of-month exceeds the number of days in the specified month) then adjust the day-of-month to the last (valid) value for that month.

2. Otherwise, if the date is invalid because the day-of-month is not valid for that month, the SKIP is to the next (forward) or previous (backward) valid day.

I was also thinking about birthdays and doing some research.  For the case of birthdays on the Hebrew calendar, if we can trust Wikipedia, its fairly complex:

"Based on a line in the Mishnah declaring that Purim must be celebrated in Adar II in a leap year (Megillah 1:4), Adar I is considered the "extra" month. As a result, someone born in Adar during a non leap year would celebrate his birthday in Adar II during a leap year. However, someone born during either Adar in a leap year will celebrate his birthday during Adar in a non-leap year, except that someone born on 30 Adar I will celebrate his birthday on 1 Nisan in a non-leap year because Adar in a non-leap year has only 29 days.[1]"

It appears your previous rules properly handle the 30 Adar I (leap year) case, but the new rules do not.  Can we come up with rules that can model the 3 cases listed above?

I'm doing some more digging on this and probably need to look at what the Chinese do to celebrate birthdates in leap years as well.

Do we have any i8ln experts in the IETF that we can lean on for this stuff?
-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------030507000303010300080908-- From nobody Tue Feb 3 07:08:24 2015 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 F1BD31A0687 for ; Tue, 3 Feb 2015 07:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CtXME8GO742t for ; Tue, 3 Feb 2015 07:08:20 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD071A06E9 for ; Tue, 3 Feb 2015 07:08:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 123F4AC25DD; Tue, 3 Feb 2015 10:08:20 -0500 (EST) 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 plg__ApR0c0d; Tue, 3 Feb 2015 10:08:19 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 6A5DEAC25CE; Tue, 3 Feb 2015 10:08:17 -0500 (EST) Date: Tue, 03 Feb 2015 10:08:12 -0500 From: Cyrus Daboo To: Ken Murchison , Barry Leiba Message-ID: <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> In-Reply-To: <54D0E2E9.2030505@andrew.cmu.edu> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@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=937 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 15:08:23 -0000 Hi Ken, --On February 3, 2015 at 10:02:01 AM -0500 Ken Murchison wrote: > It appears your previous rules properly handle the 30 Adar I (leap year) > case, but the new rules do not. Can we come up with rules that can model > the 3 cases listed above? OK thanks for looking into that. If we want to provide full flexibility to control what happens we would need to have two "skip" indicators, one for skipping invalid months and one for skipping invalid days (with the month one applied first, followed by the day one). So: RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=FORWARD Would match the Hebrew birthday case you found. RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=BACKWARD Would match the behavior from my last email. If we find there really is never a use case for the above, then we could stick with the single SKIP option. But lets see if we can get a confirmation on that. -- Cyrus Daboo From nobody Tue Feb 3 07:11:52 2015 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 9536C1A0636 for ; Tue, 3 Feb 2015 07:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 21Na6A04jFyI for ; Tue, 3 Feb 2015 07:11:47 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABD51A0065 for ; Tue, 3 Feb 2015 07:11:47 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so52833687lam.5 for ; Tue, 03 Feb 2015 07:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GeyFekLORNz7pbDvZ1tsueqjo5OTlZpd/NcSph8Eimc=; b=NIuesQndxLIe08a02bHTcgxH9SdgPFzC+odTaBjITB5ecww+h8byGikOHwcwWCCCkO KK4YHG4JqLYtxtBzU4xCyYA+EzYTuAbJgUirep9XC6sOIh+a1IpDh6b8T+C1wk8caZMh b6jdR4BuLOcn3rnX35ogmrxqtIbezOLWm0vklxSOrjI+OpWXEWjpn9xl6HqaiWnGGhQx KnyblDnJAAQmcrtAkitPH879aBw7soetESTu+HLWGOBZaIOP7OkjTFByDgfJ4BGhRDrt pj3zzC29DCmUrgznsDa8R8NfMtVaj7jPjkgkmNo9ti+oSDnPNcbRM82u1+amsMP9coUn OLgw== MIME-Version: 1.0 X-Received: by 10.152.29.6 with SMTP id f6mr13683770lah.82.1422976305761; Tue, 03 Feb 2015 07:11:45 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 3 Feb 2015 07:11:45 -0800 (PST) In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> Date: Tue, 3 Feb 2015 10:11:45 -0500 X-Google-Sender-Auth: wXRkNIlajFTz231AGgppGQJc6zA Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 15:11:51 -0000 > So I now have this: > > 1. If the date is invalid because the month is not a valid month in the > correct year, the SKIP is to the next (forward) or previous (backward) > valid month. If the resulting date is invalid (the day-of-month exceeds the > number of days in the specified month) then adjust the day-of-month to the > last (valid) value for that month. > > 2. Otherwise, if the date is invalid because the day-of-month is not valid > for that month, the SKIP is to the next (forward) or previous (backward) > valid day. I think you want "current year", rather than "correct year", no? Otherwise, this (and your reasoning) seems good. b From nobody Tue Feb 3 07:18:44 2015 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 62A601A0469 for ; Tue, 3 Feb 2015 07:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 yBlgHfylWsAx for ; Tue, 3 Feb 2015 07:18:41 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F029A1A09CF for ; Tue, 3 Feb 2015 07:18:28 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ms9so52772932lab.1 for ; Tue, 03 Feb 2015 07:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5d8lcuZ+PiZwtqeJCJoBcNfFCUFdH2Ff4o5/Eb0iKk8=; b=BX5rj/wYqojjlOFjLT6di221nppaEiXytYY/dtmhFismfh9EokaDmMFGiZesPT+fys YVmqNLqeX/lfrZkTFUyFVcJpX6LAQaI9VS7eVgUTLJtSKwKH9Dx3rBKpfRmmnYVVczWx AYrr8B5Zv+2kg/7Ws3AUqiV2WLMKxTWupDB6yAmehNg+Md7Xrnc5aDPmgwFfu4Qh0Sjd 8ESj13XXAHaxzpp4X1cmnhY/Zsf/ckA6Ef/16hytE9UZkyJgDM7Yl+PjKeqCe2vYrxot t5pK5CurauL6zUyvjm5kIMR0MApfM620sTJmMSSoc9je2VkhKuQVASuadHGcntQFXISA 4rew== MIME-Version: 1.0 X-Received: by 10.152.87.210 with SMTP id ba18mr24914942lab.3.1422976707407; Tue, 03 Feb 2015 07:18:27 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 3 Feb 2015 07:18:27 -0800 (PST) In-Reply-To: <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> Date: Tue, 3 Feb 2015 10:18:27 -0500 X-Google-Sender-Auth: ax0aOJ7XisVp5ri_4QZz4eIrB54 Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 15:18:42 -0000 Yes, so this is starting to show the complexity of trying to have general rules that one can apply, rather than "just knowing" how each calendar works -- that is, saying that the behaviour is specific to each calendar, and you have to know, when you implement a calendar, how that calendar works. In fact, you do: you have to know it in order to know how to generate the correct SKIP entries. So why don't we just say that you have to know it on both ends, and in most cases SKIP won't be used (it's only to make exceptions from the normal case)? Maybe that means we should have a registry for calendars and their SKIP behaviour, where we could put in at least the common calendars we expect to see used -- there can't be that many. Or... or maybe we just say that if you're going to support a calendar, you have to do the research and know how that calendar works in practice. Does that latter mean that we might get bad implementations that don't do it right? Sure. But with SKIP as we're doing it, we also might get bad implementation that don't generate the SKIP(s) right. Barry On Tue, Feb 3, 2015 at 10:08 AM, Cyrus Daboo wrote: > Hi Ken, > > --On February 3, 2015 at 10:02:01 AM -0500 Ken Murchison > wrote: > >> It appears your previous rules properly handle the 30 Adar I (leap year) >> case, but the new rules do not. Can we come up with rules that can model >> the 3 cases listed above? > > > OK thanks for looking into that. If we want to provide full flexibility to > control what happens we would need to have two "skip" indicators, one for > skipping invalid months and one for skipping invalid days (with the month > one applied first, followed by the day one). So: > > RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=FORWARD > > Would match the Hebrew birthday case you found. > > RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=BACKWARD > > Would match the behavior from my last email. If we find there really is > never a use case for the above, then we could stick with the single SKIP > option. But lets see if we can get a confirmation on that. > > -- > Cyrus Daboo > From nobody Tue Feb 3 09:19:42 2015 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 16C3B1A1A66 for ; Tue, 3 Feb 2015 09:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XEkrOdLsqwsN for ; Tue, 3 Feb 2015 09:19:30 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D401A6F96 for ; Tue, 3 Feb 2015 09:18:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A7316AC4E8D; Tue, 3 Feb 2015 12:18:47 -0500 (EST) 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 pDZnGqR7F_JB; Tue, 3 Feb 2015 12:18:47 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A994CAC4E82; Tue, 3 Feb 2015 12:18:45 -0500 (EST) Date: Tue, 03 Feb 2015 12:18:41 -0500 From: Cyrus Daboo To: Barry Leiba , calsify@ietf.org Message-ID: <119F87D2E7D9F450CD430787@caldav.corp.apple.com> In-Reply-To: References: 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=6915 Archived-At: Cc: draft-ietf-calext-rscale.all@tools.ietf.org Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 17:19:32 -0000 Hi Barry, Thanks for your review. Comments below. I have applied the fixes below to my working copy. --On January 29, 2015 at 12:05:18 AM +0100 Barry Leiba wrote: > 0. I asked Donald, in his role as document shepherd, about the use of > "updates" metadata with respect to the iCalendar, xCal, and jCal > specs. Here's his response: > >> The document changes iCalendar, xCal, and jCal by performing surgery >> on the language syntax in a way not anticipated when the base >> documents were written. See the three indented one-sentence paragraphs >> at the end of Section 1. Sorry we failed to change the word "extend" >> to "change" in the first of those. That would be easy to fix. > > But that's the thing: I don't believe it does. There's nothing done > here that requires all iCalendar implementations to support it. This > is an extension... if you don't know about the extension, then you > don't support the extension, but I don't think this qualifies as > "updates". Please see my answer to point #11 below. > 1. Section 2 > Where you explain the {C} (etc.) notation, it'd probably help to be > explicitly clear that it's only for illustrative purposes, and that > {X} never appears in actual iCalendar objects. Additional clarifying text added, as suggested. > 3. Also, I don't want to break existing implementations, but > "SKIP=YES" doesn't seem to be the right way to put it... something > parallel to "BACKWARD" and "FORWARD" would be better. Perhaps > "SKIP=OMIT". Will wait on this until the outcome of the SKIP discussion. > 4. Also also, in the grammar, please make this change: > OLD > ; and MUST only be present if "RSCALE" is present. > NEW > ; and MUST NOT be present if "RSCALE" is not present. > > (I don't think the "MUST only" construct is clear, especially to all > varieties of non-native speakers.) Text adjusted (as per Aron Roberts alternative). > 5. Section 4.1 > In the last paragraph, I suggest being even clearer in the final > sentence, to avoid misunderstandings on the mapping: 'In iCalendar, > this would map to months 1 through 12 with "5L" as the leap month (ICU > month 6). ICU months 7 through 13 would map to iCalendar months 6 > through 12.' Text adjusted to: Thus ICU months 1 through 5 map to iCalendar months 1 through 5, ICU month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map to iCalendar months 6 through 12. > 6. Section 4.2.1 > It seemed odd to me at first that you were repeating the example. > Maybe explicitly saying that will make it less odd: "Consider the > Chinese New Year example above:" (and then go ahead and repeat the > example). I just added "(from the example above)" to the end of the first sentence. > 7. Section 4.2.2 > I don't understand why this example needs the BYMONTH value, and why > FREQ=YEARLY isn't enough. Isn't this exactly the same as the example > in 4.2.1, where "BYMONTH=1" isn't needed? I propose changing the example rule to: RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13 That one does require the presence of BYMONTH to limit the set of dates to just the one month. I will also add the following to the sentence following the RRULE: Whilst there are a number of alternative ways of writing the RRULE above to achieve the same pattern of recurring dates, the one above was chosen to illustrate a BYMONTH value exceeding the limit of 12, previously described in iCalendar (Section 3.3.10 of [RFC5545]). > 9. Section 5 > I have never understood the statement that things in iCalendar are > case insensitive, but "SHOULD be in upper case." If they're case > insensitive, why does it matter? And, certainly, why does it matter > at a SHOULD level? What's this "for consistency" thing? Does that > mean that it's nicer, when humans read it, to have things in a > consistent case? If so, that's a fine thing to say, but it's not an > interoperability SHOULD. I have changed that sentence to: "RSCALE" values are case-insensitive, but upper case is preferred. That matches the descriptions used in formal syntax comments else where in the document. > 10. Where you talk about CLDR alias values, you say they 'MUST be > treated as valid "RSCALE" element values.' Of course they must, as I > presume they're syntactically valid. The point you want is that the > aliases MUST be treated as the same calendar as what they alias, yes? I changed the relevant sentence to: These alias values can be used as "RSCALE" values and are treated the same as the equivalent CLDR calendar system they are an alias for. > 11. Section 6 > I don't understand why this section is only for iTIP. The iTIP > responses are, sure, but what to do if you encounter an RSCALE with a > calendar you don't support is not, and advice on that needs to be > given more generally. Yes you are right we need advice on what to do when seeing RSCALE in "normal" parsing situations - not use iTIP. As a result, I think that does mean this specification will update iCalendar (and xCal, jCal) as it will be necessary (or at least good practice) for iCalendar parsers to at least be aware of the fact that RSCALE might appear, even if they do nothing with it. So that will address point #0. I propose adding a new section before the existing iTIP section: 6. Compatibility For calendar user agents that do not support the "RSCALE" element, or do not support the calendar system specified by the "RSCALE" element value, the following behaviors are possible when processing iCalendar data: 1. The calendar user agent can reject the entire iCalendar object within which at least one iCalendar component uses the unrecognized "RSCALE" element or element value. 2. The calendar user agent can reject just the iCalendar components containing an unrecognized "RSCALE" element or element value. Note that any overridden components associated with those rejected components MUST also be rejected (i.e., any other components with the same "UID" property value as the one with the unrecognized "RSCALE" element or element value). 3. The calendar user agent can fallback to a non-recurring behavior for the iCalendar component containing the unrecognized "RSCALE" element or element value (effectively ignoring the "RRULE" property). However, any overridden components SHOULD be rejected as they would represent "orphaned" instances that would seem to be out of place. In general, the best choice for a calendar user agent would be option (2) above, as it would be the least disruptive choice. Note that when processing iTIP [RFC5546] messages, the manner of the rejection is covered in the next section. -- Cyrus Daboo From nobody Tue Feb 3 09:38:37 2015 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 DAF3E1A7017 for ; Tue, 3 Feb 2015 09:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 QfjMvjn2q7lP for ; Tue, 3 Feb 2015 09:38:32 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1224B1A701F for ; Tue, 3 Feb 2015 09:36:53 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gm9so53745106lab.0 for ; Tue, 03 Feb 2015 09:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pVYhYVGdwDjCKngaoB9nHTSy5BAOaXp/1dF1MneNij4=; b=BKb+0HWlUrVmLygIEyuOilsZKYYkHy20RCBDk30ZIL8kmxXx6vcxYLWthdHiRV+NsT KZVOXOPtoL1uIBM3uE91Toyyaf1+0vv6+cmZOl+PFTp8ZITq3o12vHaZKyqZT3wmHJuZ XcM7ZGdSbDVOUgaU2x/6wr4CbaVzTlO5Xch4JFBrzg6JMJ6pgrdo9XmeB8+v9orGB2+S +0sAIxywNTQutLCUD0bcQqlJn+0zI0X3NZuxyFH7ZuN0OsVUsFs5ajKAMD1EeGK+0Z4d xLx0RvZ3T8hl8QrFuYa4TLzIiqFBaOQH7XTIWdkedyuKFOi6s126S92qlkjYzMEBNVhf ozMw== MIME-Version: 1.0 X-Received: by 10.112.217.68 with SMTP id ow4mr25867441lbc.97.1422985012476; Tue, 03 Feb 2015 09:36:52 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 3 Feb 2015 09:36:52 -0800 (PST) In-Reply-To: <119F87D2E7D9F450CD430787@caldav.corp.apple.com> References: <119F87D2E7D9F450CD430787@caldav.corp.apple.com> Date: Tue, 3 Feb 2015 12:36:52 -0500 X-Google-Sender-Auth: iHFJD6pPAPuy857H7218TkvNSOc Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: draft-ietf-calext-rscale.all@tools.ietf.org, "calsify@ietf.org" Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 17:38:34 -0000 Thanks, Cyrus, for the response and the changes. Quick notes: >> 3. Also, I don't want to break existing implementations, but >> "SKIP=YES" doesn't seem to be the right way to put it... something >> parallel to "BACKWARD" and "FORWARD" would be better. Perhaps >> "SKIP=OMIT". > > Will wait on this until the outcome of the SKIP discussion. Indeed; lots could change... or not. > Text adjusted to: > > Thus ICU months 1 through 5 map to iCalendar months 1 through 5, ICU > month 6 maps to iCalendar month "5L", and ICU months 7 through 13 map > to iCalendar months 6 through 12. Perfect. >> 6. Section 4.2.1 >> It seemed odd to me at first that you were repeating the example. >> Maybe explicitly saying that will make it less odd: "Consider the >> Chinese New Year example above:" (and then go ahead and repeat the >> example). > > I just added "(from the example above)" to the end of the first sentence. That works. > I propose changing the example rule to: > > RRULE:RSCALE=ETHIOPIC;FREQ=MONTHLY;BYMONTH=13 > > That one does require the presence of BYMONTH to limit the set of dates to > just the one month. I will also add the following to the sentence following > the RRULE: > > Whilst there are a number of alternative ways of writing the RRULE > above to achieve the same pattern of recurring dates, the one above was > chosen to illustrate a BYMONTH value exceeding the limit of 12, > previously described in iCalendar (Section 3.3.10 of [RFC5545]). A fine way to handle this; thanks. > I have changed that sentence to: > > "RSCALE" values are case-insensitive, but upper case is preferred. > > That matches the descriptions used in formal syntax comments else where in > the document. Great! > I changed the relevant sentence to: > > These alias values can be used as "RSCALE" values and are treated the > same as the equivalent CLDR calendar system they are an alias for. Also perfect. >> 11. Section 6 >> I don't understand why this section is only for iTIP. The iTIP >> responses are, sure, but what to do if you encounter an RSCALE with a >> calendar you don't support is not, and advice on that needs to be >> given more generally. > > Yes you are right we need advice on what to do when seeing RSCALE in > "normal" parsing situations - not use iTIP. As a result, I think that does > mean this specification will update iCalendar (and xCal, jCal) as it will be > necessary (or at least good practice) for iCalendar parsers to at least be > aware of the fact that RSCALE might appear, even if they do nothing with it. > So that will address point #0. OK; I accept that explanation. It might be worth pointing to the new Section 6 (below) in the introduction, where you mention the updates. > I propose adding a new section before the existing iTIP section: > > 6. Compatibility > > For calendar user agents that do not support the "RSCALE" element, or > do not support the calendar system specified by the "RSCALE" element > value, the following behaviors are possible when processing iCalendar > data: > > 1. The calendar user agent can reject the entire iCalendar object > within which at least one iCalendar component uses the > unrecognized "RSCALE" element or element value. > > 2. The calendar user agent can reject just the iCalendar components > containing an unrecognized "RSCALE" element or element value. > Note that any overridden components associated with those > rejected components MUST also be rejected (i.e., any other > components with the same "UID" property value as the one with the > unrecognized "RSCALE" element or element value). > > 3. The calendar user agent can fallback to a non-recurring behavior > for the iCalendar component containing the unrecognized "RSCALE" > element or element value (effectively ignoring the "RRULE" > property). However, any overridden components SHOULD be rejected > as they would represent "orphaned" instances that would seem to > be out of place. > > In general, the best choice for a calendar user agent would be option > (2) above, as it would be the least disruptive choice. Note that > when processing iTIP [RFC5546] messages, the manner of the rejection > is covered in the next section. This looks good. So I think we're all set except for the outcome of the SKIP discussion. b From nobody Tue Feb 3 09:41:54 2015 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 487041A7011 for ; Tue, 3 Feb 2015 09:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 pq-3Sgg2TlXZ for ; Tue, 3 Feb 2015 09:41:50 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95E71A871F for ; Tue, 3 Feb 2015 09:38:55 -0800 (PST) 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.8/8.14.8) with ESMTP id t13HcqY3016038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 12:38:53 -0500 Message-ID: <54D107AC.3050706@andrew.cmu.edu> Date: Tue, 03 Feb 2015 12:38:52 -0500 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 , Barry Leiba References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> In-Reply-To: <99B9DDB4AEFC12755724C5DD@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: 2015.1.28.224819 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_1600_1699 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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 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.203 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 17:41:52 -0000 On 02/03/2015 10:08 AM, Cyrus Daboo wrote: > Hi Ken, > > --On February 3, 2015 at 10:02:01 AM -0500 Ken Murchison > wrote: > >> It appears your previous rules properly handle the 30 Adar I (leap year) >> case, but the new rules do not. Can we come up with rules that can >> model >> the 3 cases listed above? > > OK thanks for looking into that. If we want to provide full > flexibility to control what happens we would need to have two "skip" > indicators, one for skipping invalid months and one for skipping > invalid days (with the month one applied first, followed by the day > one). So: > > RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=FORWARD > > Would match the Hebrew birthday case you found. > > RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=BACKWARD > > Would match the behavior from my last email. If we find there really > is never a use case for the above, then we could stick with the single > SKIP option. But lets see if we can get a confirmation on that. > Cyrus, I believe we can get by with just a single SKIP and your previous rules to handle both cases above (using Hebrew leap month): RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 Would yield 1 Nisan (skipping forward both a month and day) RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 Would yield 29 Adar (skipping forward just a month) For the BACKWARD cases, both BYMONTHDAY=30 and BYMONTHDAY=-1 would yield Shevat 30. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Feb 3 09:51:53 2015 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 921521A6FF1 for ; Tue, 3 Feb 2015 09:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8VWuGOGD7oPP for ; Tue, 3 Feb 2015 09:51:50 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792C01A6FF0 for ; Tue, 3 Feb 2015 09:51:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C47B8AC5D09; Tue, 3 Feb 2015 12:51:49 -0500 (EST) 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 ytDvj835zEA1; Tue, 3 Feb 2015 12:51:49 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 16F9FAC5CF9; Tue, 3 Feb 2015 12:51:47 -0500 (EST) Date: Tue, 03 Feb 2015 12:51:43 -0500 From: Cyrus Daboo To: Ken Murchison , Barry Leiba Message-ID: <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> In-Reply-To: <54D107AC.3050706@andrew.cmu.edu> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@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=862 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 17:51:51 -0000 Hi Ken, --On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison wrote: > I believe we can get by with just a single SKIP and your previous rules > to handle both cases above (using Hebrew leap month): > > RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 > > Would yield 1 Nisan (skipping forward both a month and day) > > > RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 > > Would yield 29 Adar (skipping forward just a month) > Actually I am not convinced about that since the spec says that SKIP is applied AFTER all other rule parts are processed (except for BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last day of the invalid month, 30 Adar I, which then becomes the invalid date 30 Adar after the month skip and then 1 Nisan after the day skip. -- Cyrus Daboo From nobody Tue Feb 3 09:53:28 2015 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 C25D61A7029 for ; Tue, 3 Feb 2015 09:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 3qCeqT6SLSLo for ; Tue, 3 Feb 2015 09:53:25 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DE31A6FFF for ; Tue, 3 Feb 2015 09:53:25 -0800 (PST) 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.8/8.14.8) with ESMTP id t13HrMHl017291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 12:53:23 -0500 Message-ID: <54D10B12.3020205@andrew.cmu.edu> Date: Tue, 03 Feb 2015 12:53:22 -0500 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 , Barry Leiba References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> In-Reply-To: <54D107AC.3050706@andrew.cmu.edu> Content-Type: multipart/alternative; boundary="------------020407030700010609050607" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.3.164219 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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 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.105.203 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 17:53:27 -0000 This is a multi-part message in MIME format. --------------020407030700010609050607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/03/2015 12:38 PM, Ken Murchison wrote: > On 02/03/2015 10:08 AM, Cyrus Daboo wrote: >> Hi Ken, >> >> --On February 3, 2015 at 10:02:01 AM -0500 Ken Murchison >> wrote: >> >>> It appears your previous rules properly handle the 30 Adar I (leap >>> year) >>> case, but the new rules do not. Can we come up with rules that can >>> model >>> the 3 cases listed above? >> >> OK thanks for looking into that. If we want to provide full >> flexibility to control what happens we would need to have two "skip" >> indicators, one for skipping invalid months and one for skipping >> invalid days (with the month one applied first, followed by the day >> one). So: >> >> RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=FORWARD >> >> Would match the Hebrew birthday case you found. >> >> RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=BACKWARD >> >> Would match the behavior from my last email. If we find there really >> is never a use case for the above, then we could stick with the >> single SKIP option. But lets see if we can get a confirmation on that. >> > > Cyrus, > > I believe we can get by with just a single SKIP and your previous > rules to handle both cases above (using Hebrew leap month): > > RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 > > Would yield 1 Nisan (skipping forward both a month and day) > > > RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 > > Would yield 29 Adar (skipping forward just a month) > > > For the BACKWARD cases, both BYMONTHDAY=30 and BYMONTHDAY=-1 would > yield Shevat 30. > And it turns out that the BACKWARD case works for celebrating birthdays in the Chinese calendar, based on the following in Wikipedia : "The birthday is the day in each year that have the same date as the one on which someone was born. It's easy to confirm the birthday in the Chinese calendar for most people. But, if someone was born on the 30_th of a month, his birthday is the last day of that month, and if someone is born in an intercalary month, his birthday is the day with the same date in the common month of the intercalary month." -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------020407030700010609050607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/03/2015 12:38 PM, Ken Murchison wrote:
On 02/03/2015 10:08 AM, Cyrus Daboo wrote:
Hi Ken,

--On February 3, 2015 at 10:02:01 AM -0500 Ken Murchison <murch@andrew.cmu.edu> wrote:

It appears your previous rules properly handle the 30 Adar I (leap year)
case, but the new rules do not.  Can we come up with rules that can model
the 3 cases listed above?

OK thanks for looking into that. If we want to provide full flexibility to control what happens we would need to have two "skip" indicators, one for skipping invalid months and one for skipping invalid days (with the month one applied first, followed by the day one). So:

RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=FORWARD

Would match the Hebrew birthday case you found.

RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=BACKWARD

Would match the behavior from my last email. If we find there really is never a use case for the above, then we could stick with the single SKIP option. But lets see if we can get a confirmation on that.


Cyrus,

I believe we can get by with just a single SKIP and your previous rules to handle both cases above (using Hebrew leap month):

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30

Would yield 1 Nisan (skipping forward both a month and day)


RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1

Would yield 29 Adar (skipping forward just a month)


For the BACKWARD cases, both BYMONTHDAY=30 and BYMONTHDAY=-1 would yield Shevat 30.


And it turns out that the BACKWARD case works for celebrating birthdays in the Chinese calendar, based on the following in Wikipedia:

"The birthday is the day in each year that have the same date as the one on which someone was born. It's easy to confirm the birthday in the Chinese calendar for most people. But, if someone was born on the 30th of a month, his birthday is the last day of that month, and if someone is born in an intercalary month, his birthday is the day with the same date in the common month of the intercalary month."

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------020407030700010609050607-- From nobody Tue Feb 3 09:59:02 2015 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 7C2541A8720 for ; Tue, 3 Feb 2015 09:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 huOZg4TWilRh for ; Tue, 3 Feb 2015 09:58:42 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F791A8707 for ; Tue, 3 Feb 2015 09:58:42 -0800 (PST) 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.8/8.14.8) with ESMTP id t13Hwe1P018039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 12:58:40 -0500 Message-ID: <54D10C50.20909@andrew.cmu.edu> Date: Tue, 03 Feb 2015 12:58:40 -0500 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 , Barry Leiba References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> In-Reply-To: <2D953326EFEE238B1CCF867E@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: 2015.2.3.175118 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_1200_1299 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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 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.203 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 17:58:52 -0000 On 02/03/2015 12:51 PM, Cyrus Daboo wrote: > Hi Ken, > > --On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison > wrote: > >> I believe we can get by with just a single SKIP and your previous rules >> to handle both cases above (using Hebrew leap month): >> >> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 >> >> Would yield 1 Nisan (skipping forward both a month and day) >> >> >> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 >> >> Would yield 29 Adar (skipping forward just a month) >> > > Actually I am not convinced about that since the spec says that SKIP > is applied AFTER all other rule parts are processed (except for > BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last > day of the invalid month, 30 Adar I, which then becomes the invalid > date 30 Adar after the month skip and then 1 Nisan after the day skip. Hmm, I think you're right based on the current wording. I don't recall exactly how we decided on that wording, but perhaps it might needs to be adjusted. Other than violating the current wording in the spec, does my logic appear to be sane? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Feb 3 10:12:42 2015 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 10E7B1A87A1 for ; Tue, 3 Feb 2015 10:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mviNGCi8_MQ0 for ; Tue, 3 Feb 2015 10:12:41 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8481A8760 for ; Tue, 3 Feb 2015 10:12:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3180BAC6367; Tue, 3 Feb 2015 13:12:40 -0500 (EST) 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 N4fAaUEZIMKu; Tue, 3 Feb 2015 13:12:40 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A2E95AC635C; Tue, 3 Feb 2015 13:12:38 -0500 (EST) Date: Tue, 03 Feb 2015 13:12:34 -0500 From: Cyrus Daboo To: Ken Murchison , Barry Leiba Message-ID: <4D0DD03C35332EE0F64A9DD5@caldav.corp.apple.com> In-Reply-To: <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> 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=1532 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 18:12:42 -0000 Hi Ken, Barry, --On February 3, 2015 at 12:51:43 PM -0500 Cyrus Daboo wrote: >> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 >> >> Would yield 29 Adar (skipping forward just a month) >> > > Actually I am not convinced about that since the spec says that SKIP is > applied AFTER all other rule parts are processed (except for BYSETPOS, > COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last day of the > invalid month, 30 Adar I, which then becomes the invalid date 30 Adar > after the month skip and then 1 Nisan after the day skip. I think the following would work: RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L,6;BYMONTHDAY=-1;BYSETPOS=1 In a leap year that would generate the last day of 5L and 6 and BYSETPOS would select 5L. In a non-leap year that would generate the first day of 7 (the skip forward by month and by day) and the last day of 6, so BYSETPOS would select the last day of 6. These complex rules would all be great things to include in an RSCALE test suite. Of course all this just goes to prove Barry's point about trying to come up with a simple behavior that can be easily codified without having to write such complex RRULEs. But I would still prefer something that can be clearly represented in the rule and has a fixed default per calendar (with perhaps a BCP - or appendix in the current draft - that describes how common situations are handled: Hebrew calendar birthdays, Chinese calendar birthdays, other...). -- Cyrus Daboo From nobody Tue Feb 3 10:13:53 2015 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 24C6C1A8772 for ; Tue, 3 Feb 2015 10:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 P_xYyiWhCs1f for ; Tue, 3 Feb 2015 10:13:50 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE271A8760 for ; Tue, 3 Feb 2015 10:13:50 -0800 (PST) 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.8/8.14.8) with ESMTP id t13IDllW020159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 13:13:48 -0500 Message-ID: <54D10FDB.6070001@andrew.cmu.edu> Date: Tue, 03 Feb 2015 13:13:47 -0500 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 , Barry Leiba References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> In-Reply-To: <54D10C50.20909@andrew.cmu.edu> 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: 2015.2.3.180619 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_1900_1999 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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 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.203 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 18:13:52 -0000 On 02/03/2015 12:58 PM, Ken Murchison wrote: > On 02/03/2015 12:51 PM, Cyrus Daboo wrote: >> Hi Ken, >> >> --On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison >> wrote: >> >>> I believe we can get by with just a single SKIP and your previous rules >>> to handle both cases above (using Hebrew leap month): >>> >>> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 >>> >>> Would yield 1 Nisan (skipping forward both a month and day) >>> >>> >>> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 >>> >>> Would yield 29 Adar (skipping forward just a month) >>> >> >> Actually I am not convinced about that since the spec says that SKIP >> is applied AFTER all other rule parts are processed (except for >> BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last >> day of the invalid month, 30 Adar I, which then becomes the invalid >> date 30 Adar after the month skip and then 1 Nisan after the day skip. > > Hmm, I think you're right based on the current wording. I don't > recall exactly how we decided on that wording, but perhaps it might > needs to be adjusted. Looking at RFC 5545: If multiple BYxxx rule parts are specified, then after evaluating the specified FREQ and INTERVAL rule parts, the BYxxx rule parts are applied to the current set of evaluated occurrences in the following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. I'm wondering if we shouldn't have SKIP applied both immediately following BYMONTH and BYMONTHDAY evaluation. I don't think we want the other BYxxx rule parts to be operating on invalid dates at any point. Thoughts? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Feb 3 12:08:49 2015 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 029501A88D5 for ; Tue, 3 Feb 2015 12:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 ugwqFtmG6mZ5 for ; Tue, 3 Feb 2015 12:08:34 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA93D1A88C3 for ; Tue, 3 Feb 2015 12:08:20 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id m14so47086325wev.11 for ; Tue, 03 Feb 2015 12:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=3XhdBX1gVwOvJ92mFBbqWV2sB4dh2v2y7cB7PXhhCHg=; b=SphY5AmF5olhUKZznF41RteilMGdH4IfgkN1nmD1KdTYQDcV+hyoTY3b8L5w0nbrBN B0fcucedwNkHEQjswqkrayBLb1dy0Fr6fS13Mu7qOYZn6nHkXFLw4AhikDx2uxRmvpRN o0a0NT4SSC19YyQvkUzHYG3E3LUlwwC95OTB0iuRuRhAUzf7lvS6HhJSda8hwDiZsygl yOb19UQlStC22BNwWX9EANUT+EI4Jfx1X+pOkCi+eNS6FLXbSmLez/zsfsQxSmwzIRQb 3FmuGqzbWsTI8kNZpKMycX/ndQicco8pWgTTVN4V6M7EI2ThoqB0msm2UNJUBX06rxkc wU9A== X-Received: by 10.194.61.51 with SMTP id m19mr8435379wjr.39.1422994097290; Tue, 03 Feb 2015 12:08:17 -0800 (PST) Received: from smtp.dmfs.org (p4FF0E66A.dip0.t-ipconnect.de. [79.240.230.106]) by mx.google.com with ESMTPSA id mx4sm26001604wic.24.2015.02.03.12.08.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Feb 2015 12:08:16 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (unknown [89.204.138.240]) by smtp.dmfs.org (Postfix) with ESMTPSA id AE894615 for ; Tue, 3 Feb 2015 21:08:13 +0100 (CET) Message-ID: <54D12AAC.7000202@dmfs.org> Date: Tue, 03 Feb 2015 21:08:12 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> In-Reply-To: <54D10FDB.6070001@andrew.cmu.edu> Content-Type: multipart/alternative; boundary="------------060700080104020105050103" Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 20:08:41 -0000 This is a multi-part message in MIME format. --------------060700080104020105050103 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit @Ken: Sorry for the double post, I hit the wrong reply button Am 03.02.2015 um 19:13 schrieb Ken Murchison: > On 02/03/2015 12:58 PM, Ken Murchison wrote: >> On 02/03/2015 12:51 PM, Cyrus Daboo wrote: >>> Hi Ken, >>> >>> --On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison >>> wrote: >>> >>>> I believe we can get by with just a single SKIP and your previous >>>> rules >>>> to handle both cases above (using Hebrew leap month): >>>> >>>> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 >>>> >>>> Would yield 1 Nisan (skipping forward both a month and day) >>>> >>>> >>>> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 >>>> >>>> Would yield 29 Adar (skipping forward just a month) >>>> >>> >>> Actually I am not convinced about that since the spec says that SKIP >>> is applied AFTER all other rule parts are processed (except for >>> BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last >>> day of the invalid month, 30 Adar I, which then becomes the invalid >>> date 30 Adar after the month skip and then 1 Nisan after the day skip. >> >> Hmm, I think you're right based on the current wording. I don't >> recall exactly how we decided on that wording, but perhaps it might >> needs to be adjusted. > > Looking at RFC 5545: > > If multiple BYxxx rule parts are specified, then after evaluating > the specified FREQ and INTERVAL rule parts, the BYxxx rule parts > are applied to the current set of evaluated occurrences in the > following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, > BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are > evaluated. > > > I'm wondering if we shouldn't have SKIP applied both immediately > following BYMONTH and BYMONTHDAY evaluation. I don't think we want > the other BYxxx rule parts to be operating on invalid dates at any > point. Thoughts? > The only reason I can come up with right now, is that a rule with RSCALE & SKIP=OMIT could have different results than the same rule without RSCALE and SKIP. example: DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU -> all Sundays in February, every year DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;BYMONTH=2;BYDAY=SU;SKIP=OMIT -> all Sundays in February, but only in leap years, since SKIP would filter Feb. 29th in non-leap years before BYDAY is evaluated Marten -- *Marten Gajda* Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------060700080104020105050103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit @Ken: Sorry for the double post, I hit the wrong reply button

Am 03.02.2015 um 19:13 schrieb Ken Murchison:
On 02/03/2015 12:58 PM, Ken Murchison wrote:
On 02/03/2015 12:51 PM, Cyrus Daboo wrote:
Hi Ken,

--On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison <murch@andrew.cmu.edu> wrote:

I believe we can get by with just a single SKIP and your previous rules
to handle both cases above (using Hebrew leap month):

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30

Would yield 1 Nisan (skipping forward both a month and day)


RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1

Would yield 29 Adar (skipping forward just a month)


Actually I am not convinced about that since the spec says that SKIP is applied AFTER all other rule parts are processed (except for BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last day of the invalid month, 30 Adar I, which then becomes the invalid date 30 Adar after the month skip and then 1 Nisan after the day skip.

Hmm, I think you're right based on the current wording.  I don't recall exactly how we decided on that wording, but perhaps it might needs to be adjusted.

Looking at RFC 5545:

      If multiple BYxxx rule parts are specified, then after evaluating
      the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
      are applied to the current set of evaluated occurrences in the
      following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
      BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
      evaluated.


I'm wondering if we shouldn't have SKIP applied both immediately following BYMONTH and BYMONTHDAY evaluation.  I don't think we want the other BYxxx rule parts to be operating on invalid dates at any point.  Thoughts?

The only reason I can come up with right now, is that a rule with RSCALE & SKIP=OMIT could have different results than the same rule without RSCALE and SKIP.

example:

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU

-> all Sundays in February, every year

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;BYMONTH=2;BYDAY=SU;SKIP=OMIT

-> all Sundays in February, but only in leap years, since SKIP would filter Feb. 29th in non-leap years before BYDAY is evaluated



Marten

--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

--------------060700080104020105050103-- From nobody Tue Feb 3 12:24:16 2015 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 9DF981A8965 for ; Tue, 3 Feb 2015 12:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 BBZM5_VFaUwT for ; Tue, 3 Feb 2015 12:24:11 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242211A897A for ; Tue, 3 Feb 2015 12:23:20 -0800 (PST) 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.8/8.14.8) with ESMTP id t13KNDB7008327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 15:23:13 -0500 Message-ID: <54D12E31.4020506@andrew.cmu.edu> Date: Tue, 03 Feb 2015 15:23:13 -0500 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: Marten Gajda , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> In-Reply-To: <54D12AAC.7000202@dmfs.org> Content-Type: multipart/alternative; boundary="------------020000070805070907090209" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.3.201820 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 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.203 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 20:24:13 -0000 This is a multi-part message in MIME format. --------------020000070805070907090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/03/2015 03:08 PM, Marten Gajda wrote: > @Ken: Sorry for the double post, I hit the wrong reply button > > Am 03.02.2015 um 19:13 schrieb Ken Murchison: >> On 02/03/2015 12:58 PM, Ken Murchison wrote: >>> On 02/03/2015 12:51 PM, Cyrus Daboo wrote: >>>> Hi Ken, >>>> >>>> --On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison >>>> wrote: >>>> >>>>> I believe we can get by with just a single SKIP and your previous >>>>> rules >>>>> to handle both cases above (using Hebrew leap month): >>>>> >>>>> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30 >>>>> >>>>> Would yield 1 Nisan (skipping forward both a month and day) >>>>> >>>>> >>>>> RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1 >>>>> >>>>> Would yield 29 Adar (skipping forward just a month) >>>>> >>>> >>>> Actually I am not convinced about that since the spec says that >>>> SKIP is applied AFTER all other rule parts are processed (except >>>> for BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the >>>> last day of the invalid month, 30 Adar I, which then becomes the >>>> invalid date 30 Adar after the month skip and then 1 Nisan after >>>> the day skip. >>> >>> Hmm, I think you're right based on the current wording. I don't >>> recall exactly how we decided on that wording, but perhaps it might >>> needs to be adjusted. >> >> Looking at RFC 5545: >> >> If multiple BYxxx rule parts are specified, then after evaluating >> the specified FREQ and INTERVAL rule parts, the BYxxx rule parts >> are applied to the current set of evaluated occurrences in the >> following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, >> BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are >> evaluated. >> >> >> I'm wondering if we shouldn't have SKIP applied both immediately >> following BYMONTH and BYMONTHDAY evaluation. I don't think we want >> the other BYxxx rule parts to be operating on invalid dates at any >> point. Thoughts? >> > The only reason I can come up with right now, is that a rule with > RSCALE & SKIP=OMIT could have different results than the same rule > without RSCALE and SKIP. > > example: > > DTSTART;VALUE=DATE:20120229 > RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU > > -> all Sundays in February, every year > > DTSTART;VALUE=DATE:20120229 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;BYMONTH=2;BYDAY=SU;SKIP=OMIT > > -> all Sundays in February, but only in leap years, since SKIP would > filter Feb. 29th in non-leap years before BYDAY is evaluated I think both of these come out the same (and my libical computes the same) as there is no BYMONTHDAY or anything else forcing the expansion onto Feb 29 in a non-leap year. In this case the DTSTART just gives us the first instance (which in this case doesn't fall on a Sunday so isn't included). After that, the BYMONTH+BYDAY is what really drives the expansion. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------020000070805070907090209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/03/2015 03:08 PM, Marten Gajda wrote:
@Ken: Sorry for the double post, I hit the wrong reply button

Am 03.02.2015 um 19:13 schrieb Ken Murchison:
On 02/03/2015 12:58 PM, Ken Murchison wrote:
On 02/03/2015 12:51 PM, Cyrus Daboo wrote:
Hi Ken,

--On February 3, 2015 at 12:38:52 PM -0500 Ken Murchison <murch@andrew.cmu.edu> wrote:

I believe we can get by with just a single SKIP and your previous rules
to handle both cases above (using Hebrew leap month):

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=30

Would yield 1 Nisan (skipping forward both a month and day)


RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;BYMONTH=5L;BYMONTHDAY=-1

Would yield 29 Adar (skipping forward just a month)


Actually I am not convinced about that since the spec says that SKIP is applied AFTER all other rule parts are processed (except for BYSETPOS, COUNT and UNTIL). So the BYMONTHDAY=-1 refers to the last day of the invalid month, 30 Adar I, which then becomes the invalid date 30 Adar after the month skip and then 1 Nisan after the day skip.

Hmm, I think you're right based on the current wording.  I don't recall exactly how we decided on that wording, but perhaps it might needs to be adjusted.

Looking at RFC 5545:

      If multiple BYxxx rule parts are specified, then after evaluating
      the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
      are applied to the current set of evaluated occurrences in the
      following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
      BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
      evaluated.


I'm wondering if we shouldn't have SKIP applied both immediately following BYMONTH and BYMONTHDAY evaluation.  I don't think we want the other BYxxx rule parts to be operating on invalid dates at any point.  Thoughts?

The only reason I can come up with right now, is that a rule with RSCALE & SKIP=OMIT could have different results than the same rule without RSCALE and SKIP.

example:

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=SU

-> all Sundays in February, every year

DTSTART;VALUE=DATE:20120229
RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;BYMONTH=2;BYDAY=SU;SKIP=OMIT

-> all Sundays in February, but only in leap years, since SKIP would filter Feb. 29th in non-leap years before BYDAY is evaluated

I think both of these come out the same (and my libical computes the same) as there is no BYMONTHDAY or anything else forcing the expansion onto Feb 29 in a non-leap year.  In this case the DTSTART just gives us the first instance (which in this case doesn't fall on a Sunday so isn't included).  After that, the BYMONTH+BYDAY is what really drives the expansion.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------020000070805070907090209-- From nobody Tue Feb 3 12:48:58 2015 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 858191A88D1 for ; Tue, 3 Feb 2015 12:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 U5qb5msK12Kk for ; Tue, 3 Feb 2015 12:48:52 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEE71A88A1 for ; Tue, 3 Feb 2015 12:48:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B519BAC95FA; Tue, 3 Feb 2015 15:48:51 -0500 (EST) 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 y5sL_4ok7kpz; Tue, 3 Feb 2015 15:48:51 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id DFDDFAC95EC; Tue, 3 Feb 2015 15:48:49 -0500 (EST) Date: Tue, 03 Feb 2015 15:48:45 -0500 From: Cyrus Daboo To: Ken Murchison , Marten Gajda , calsify@ietf.org Message-ID: <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> In-Reply-To: <54D12E31.4020506@andrew.cmu.edu> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@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=889 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 20:48:56 -0000 Hi Ken, --On February 3, 2015 at 3:23:13 PM -0500 Ken Murchison wrote: > I think both of these come out the same (and my libical computes the > same) as there is no BYMONTHDAY or anything else forcing the expansion > onto Feb 29 in a non-leap year. In this case the DTSTART just gives us > the first instance (which in this case doesn't fall on a Sunday so isn't > included). After that, the BYMONTH+BYDAY is what really drives the > expansion. But if we use 20140229 as the DTSTART - and that is a leap day on a Sunday - then I think Marten is write that apply the SKIP after the BYMONTH and before the BYDAY would result in only Sundays in leap years being returned. I think having those two rules return different results would be counterintuitive so I would prefer we left the order of BYxxx element and SKIP processing as it is now. -- Cyrus Daboo From nobody Tue Feb 3 12:57:31 2015 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 429D71A1A6D for ; Tue, 3 Feb 2015 12:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 dD3GoWslspuE for ; Tue, 3 Feb 2015 12:57:26 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD9A1A19F4 for ; Tue, 3 Feb 2015 12:57:26 -0800 (PST) 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.8/8.14.8) with ESMTP id t13KvNE0011871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 15:57:23 -0500 Message-ID: <54D13633.3040600@andrew.cmu.edu> Date: Tue, 03 Feb 2015 15:57:23 -0500 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 , Marten Gajda , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> In-Reply-To: <55A07C99191DC58DAAA160D5@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: 2015.2.3.205118 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_1300_1399 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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 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.203 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 20:57:28 -0000 On 02/03/2015 03:48 PM, Cyrus Daboo wrote: > Hi Ken, > > --On February 3, 2015 at 3:23:13 PM -0500 Ken Murchison > wrote: > >> I think both of these come out the same (and my libical computes the >> same) as there is no BYMONTHDAY or anything else forcing the expansion >> onto Feb 29 in a non-leap year. In this case the DTSTART just gives us >> the first instance (which in this case doesn't fall on a Sunday so isn't >> included). After that, the BYMONTH+BYDAY is what really drives the >> expansion. > > But if we use 20140229 as the DTSTART - and that is a leap day on a > Sunday - then I think Marten is write that apply the SKIP after the > BYMONTH and before the BYDAY would result in only Sundays in leap > years being returned. > > I think having those two rules return different results would be > counterintuitive so I would prefer we left the order of BYxxx element > and SKIP processing as it is now. What I was thinking, and probably wasn't clear, is that we apply SKIP to the month after BYMONTH and apply SKIP to the day after BYMONTHDAY/BYDAY. I don't think we want any of the down stream rule parts to be operating on a bogus month. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Feb 3 12:59:10 2015 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 872FE1A8737 for ; Tue, 3 Feb 2015 12:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_75=0.6, 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 2Qvbiu5hYeNV for ; Tue, 3 Feb 2015 12:59:03 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AA21A1A6D for ; Tue, 3 Feb 2015 12:59:03 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id u56so47321139wes.0 for ; Tue, 03 Feb 2015 12:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=LWlWPnqQWE+REQ7ztw215MT6Skgc7FGqSM1a/53EpKQ=; b=l9QZzdj3NPqbveWwb3z8yayldpKaea0/5ZVcjwHwU36hppWYgnJb+z2s+kYzXoRbJE MRUda9WQyxl5HuSqIBkiiiUXpY1SVOrb0q8RAmn3TIJKyIvz7Ucq9IBK+Rtspuz815yS DXSpddNtKPj0/fJbR4x6E/X2GyitLyAII0KfyGVRLGdPxA27HBG9ftp43o1ZWX7SlC6N LmA94ype0ZjA2tLSxMSFbcyos9TgIuK/v4vviM8V3g7nQCky/QwVdwzhKISBp8YP/H9R vY89nFEErTDZFddh+9F7U2qFwMl4VMWQwPz5+x6Jzc/wej0iMWVnvtDhBRp2/Hlus7RX xErg== X-Received: by 10.180.92.199 with SMTP id co7mr39030039wib.47.1422997142063; Tue, 03 Feb 2015 12:59:02 -0800 (PST) Received: from smtp.dmfs.org (p4FF0E66A.dip0.t-ipconnect.de. [79.240.230.106]) by mx.google.com with ESMTPSA id pp10sm10892393wjc.31.2015.02.03.12.58.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Feb 2015 12:59:00 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (unknown [89.204.138.240]) by smtp.dmfs.org (Postfix) with ESMTPSA id 16E00615; Tue, 3 Feb 2015 21:58:56 +0100 (CET) Message-ID: <54D1368F.2000501@dmfs.org> Date: Tue, 03 Feb 2015 21:58:55 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Cyrus Daboo , Ken Murchison , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> In-Reply-To: <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> Content-Type: multipart/alternative; boundary="------------070802010100090201030200" Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 20:59:07 -0000 This is a multi-part message in MIME format. --------------070802010100090201030200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 03.02.2015 um 21:48 schrieb Cyrus Daboo: > Hi Ken, > > --On February 3, 2015 at 3:23:13 PM -0500 Ken Murchison > wrote: > >> I think both of these come out the same (and my libical computes the >> same) as there is no BYMONTHDAY or anything else forcing the expansion >> onto Feb 29 in a non-leap year. In this case the DTSTART just gives us >> the first instance (which in this case doesn't fall on a Sunday so isn't >> included). After that, the BYMONTH+BYDAY is what really drives the >> expansion. > > But if we use 20140229 as the DTSTART - and that is a leap day on a > Sunday - then I think Marten is write that apply the SKIP after the > BYMONTH and before the BYDAY would result in only Sundays in leap > years being returned. > > I think having those two rules return different results would be > counterintuitive so I would prefer we left the order of BYxxx element > and SKIP processing as it is now. > you meant 20040229, right? The point is, that evaluating SKIP=OMIT after BYMONTH=2 would remove Feb 29th in non-leap years and there would be nothing left for BYDAY to expand. I'd also prefer having SKIP=OMIT behave like a rule without RSCALE. -- *Marten Gajda* Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------070802010100090201030200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 03.02.2015 um 21:48 schrieb Cyrus Daboo:
Hi Ken,

--On February 3, 2015 at 3:23:13 PM -0500 Ken Murchison <murch@andrew.cmu.edu> wrote:

I think both of these come out the same (and my libical computes the
same) as there is no BYMONTHDAY or anything else forcing the expansion
onto Feb 29 in a non-leap year.  In this case the DTSTART just gives us
the first instance (which in this case doesn't fall on a Sunday so isn't
included).  After that, the BYMONTH+BYDAY is what really drives the
expansion.

But if we use 20140229 as the DTSTART - and that is a leap day on a Sunday - then I think Marten is write that apply the SKIP after the BYMONTH and before the BYDAY would result in only Sundays in leap years being returned.

I think having those two rules return different results would be counterintuitive so I would prefer we left the order of BYxxx element and SKIP processing as it is now.

you meant 20040229, right?

The point is, that evaluating SKIP=OMIT after BYMONTH=2 would remove Feb 29th in non-leap years and there would be nothing left for BYDAY to expand.

I'd also prefer having SKIP=OMIT behave like a rule without RSCALE.

--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

--------------070802010100090201030200-- From nobody Tue Feb 3 13:04:26 2015 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 26D731A898F for ; Tue, 3 Feb 2015 13:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dSpQ76yirS0H for ; Tue, 3 Feb 2015 13:04:21 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8E31A8725 for ; Tue, 3 Feb 2015 13:04:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id F2C19AC9ABB; Tue, 3 Feb 2015 16:04:20 -0500 (EST) 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 shCi0G1GuuGZ; Tue, 3 Feb 2015 16:04:20 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 74130AC9AAA; Tue, 3 Feb 2015 16:04:19 -0500 (EST) Date: Tue, 03 Feb 2015 16:04:15 -0500 From: Cyrus Daboo To: Marten Gajda , Ken Murchison , calsify@ietf.org Message-ID: <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> In-Reply-To: <54D1368F.2000501@dmfs.org> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> 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=1219 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 21:04:24 -0000 Hi Marten, --On February 3, 2015 at 9:58:55 PM +0100 Marten Gajda wrote: >> But if we use 20140229 as the DTSTART - and that is a leap day on a >> Sunday - then I think Marten is write that apply the SKIP after the >> BYMONTH and before the BYDAY would result in only Sundays in leap >> years being returned. >> >> I think having those two rules return different results would be >> counterintuitive so I would prefer we left the order of BYxxx element >> and SKIP processing as it is now. >> > you meant 20040229, right? Yes! > The point is, that evaluating SKIP=OMIT after BYMONTH=2 would remove Feb > 29th in non-leap years and there would be nothing left for BYDAY to > expand. > > I'd also prefer having SKIP=OMIT behave like a rule without RSCALE. > I think Ken's idea is that you apply the SKIP after BYMONTH only if the invalid data corresponds to an invalid leap month as opposed to a leap day. In which case the SKIP would not have applied after BYMONTH in your example. But I think a behavior like that is going to be really tricky for implementors to get right and hard to describe really well without having to delve into the gory details of RRULE processing. -- Cyrus Daboo From nobody Tue Feb 3 13:50:12 2015 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 C73C01A1A88 for ; Tue, 3 Feb 2015 13:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 ZBAqhPbWmf-2 for ; Tue, 3 Feb 2015 13:50:09 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84521A1A5E for ; Tue, 3 Feb 2015 13:50:08 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id fb4so24785444wid.2 for ; Tue, 03 Feb 2015 13:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=tf9cC3yse5loYSI+GmSIWp44rAJULfio3ujUNhShYfQ=; b=SHrOFh4W9iTwtn/lNiSkQ5ss46M1y3xTw4fGIB4rwMXLmFMlczJ/tyXUuNgeOJHhpb OdPTGx5h3zt9v4oc8TbyqNQF0K8YjwncYmDE0I6DTQ/vdDsZdo19PlYrGy4VJPn1jt9Q w/xIGJ2NH8CJbVt1LU85pCVlUSj2fRsw39/zDzIEyDn7qmawAnasWN8O0u3jMgFiKeXA vdJPHf3T4//qhxTjnLqbQpkI19HwooIHkyn141NjdJVV5yExwmtnNmaTGWS8QkpbIU9Y MdQcLv8MU1koJ1uknSyZYFHHxsFb3d8ugruW5U3bNXwFdNyQkpB9hZ865x6X+3s4TvD5 ITyw== X-Received: by 10.194.88.131 with SMTP id bg3mr56618082wjb.99.1423000207292; Tue, 03 Feb 2015 13:50:07 -0800 (PST) Received: from smtp.dmfs.org (p4FF0E66A.dip0.t-ipconnect.de. [79.240.230.106]) by mx.google.com with ESMTPSA id vh8sm34338792wjc.12.2015.02.03.13.50.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Feb 2015 13:50:06 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (unknown [89.204.138.240]) by smtp.dmfs.org (Postfix) with ESMTPSA id 4891536B; Tue, 3 Feb 2015 22:50:03 +0100 (CET) Message-ID: <54D14289.90201@dmfs.org> Date: Tue, 03 Feb 2015 22:50:01 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Cyrus Daboo , Ken Murchison , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> In-Reply-To: <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> Content-Type: multipart/alternative; boundary="------------060301000708080608050505" Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 03 Feb 2015 21:50:11 -0000 This is a multi-part message in MIME format. --------------060301000708080608050505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 03.02.2015 um 22:04 schrieb Cyrus Daboo: > I think Ken's idea is that you apply the SKIP after BYMONTH only if > the invalid data corresponds to an invalid leap month as opposed to a > leap day. In which case the SKIP would not have applied after BYMONTH > in your example. But I think a behavior like that is going to be > really tricky for implementors to get right and hard to describe > really well without having to delve into the gory details of RRULE > processing. > Ah, got it. So, considering the following Applying SKIP=FORWARD after BYDAY on the following rule FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD results in 30 instances in leap years and in non-leap years, since it would expand the week days in Adar I and roll them forward afterwards Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 instances in leap years, but 29 instances in non-leap years, since the weekdays would be expanded for Adar instead of Adar I. It's similar when the month following the leap month has more days than the leap month itself. In essence, applying SKIP after all BYxxx parts won't change the number of instances (given they don't fall on another instance), but Ken's approach might do that. Not sure what's preferable in this case. -- *Marten Gajda* Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------060301000708080608050505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 03.02.2015 um 22:04 schrieb Cyrus Daboo:
I think Ken's idea is that you apply the SKIP after BYMONTH only if the invalid data corresponds to an invalid leap month as opposed to a leap day. In which case the SKIP would not have applied after BYMONTH in your example. But I think a behavior like that is going to be really tricky for implementors to get right and hard to describe really well without having to delve into the gory details of RRULE processing.

Ah, got it.

So, considering the following

Applying SKIP=FORWARD after BYDAY on the following rule

FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD

results in 30 instances in leap years and in non-leap years, since it would expand the week days in Adar I and roll them forward afterwards

Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 instances in leap years, but 29 instances in non-leap years, since the weekdays would be expanded for Adar instead of Adar I.

It's similar when the month following the leap month has more days than the leap month itself.

In essence, applying SKIP after all BYxxx parts won't change the number of instances (given they don't fall on another instance), but Ken's approach might do that.

Not sure what's preferable in this case.



--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

--------------060301000708080608050505-- From nobody Wed Feb 4 02:42:23 2015 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 CFF8F1A1A92 for ; Wed, 4 Feb 2015 02:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.112 X-Spam-Level: *** X-Spam-Status: No, score=3.112 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FfLSYvRnS6RA for ; Wed, 4 Feb 2015 02:42:17 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25F11A870B for ; Wed, 4 Feb 2015 02:42:16 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id l6so486283qcy.13 for ; Wed, 04 Feb 2015 02:42:15 -0800 (PST) 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=hglxpD4rGzckH+a7rAilxdGkKcyRd95FcScwKxR4q7c=; b=nH3LsAl56GOa8EUYSjOHiyAWSxOrprTzfEtiNxu9S5e5LXuC7oqeFrFeNJCCegM9rB jIk4fbDK5wo6d4xl7S6CqStFCK5rSUCJ6S/pluJqgM8bw4lj4XBxEe8iJ45vPps1VP7h ps/uaAlBJTfoGkaEbk8s9mwi60IoVKlC6n5f27mcP07fIHXAlB8BzZ+cboU5zQzolABB lWFoGRtbFHUHJ4KuOkaRVeCdTTXmCBg/nlMJvE1IHYLA6aLWUzmiRbODg0legaDZJs1Q oaPgE1PgSVqFS/1wPxXZ8l/xN6aoQZnv21PwR+ZE5cR4u2FcOLuBu/6TH8OnQrCT3cqR Qpyg== 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=hglxpD4rGzckH+a7rAilxdGkKcyRd95FcScwKxR4q7c=; b=iM4/9YJoeKYe5ehn2gNolrG42J1knfiqfSH+F1ojDRygSAIp1bwzaKghGLuy+IWTG3 ujHmqWo41bm0OwYGZTdptVs+wOGT5M1rBSkyUuIjcXCyT/iipcvbDPuTfEMRtYdHPtkm wToSAF5pZnz5pLonRZCSSF5ADIuqkYJfj2pVXFEv/JJ6AO9ym09T8r4Ub6IQYEKNEeJF n5oTI2eNCXcAC7hTiIwfGIWfYfQj7ObD0dJCtQcDe5+bA2llNqBU9iACPMVxV4lJDVzj VLTAeA0j86LwN6la6+NVbuna0rgFKQjnUZ9FwKBzUj10tALSgIEtGh8ZglkCkNLfLHrv u0Ow== X-Gm-Message-State: ALoCoQlfbOwsozjSLOIYVYOpxpK7nShMx3tDxkj/Qhx8hok26CF+YUxlOWve4A/e6hf5ZtexrVun X-Received: by 10.224.160.81 with SMTP id m17mr54027914qax.63.1423046535739; Wed, 04 Feb 2015 02:42:15 -0800 (PST) MIME-Version: 1.0 References: <54CA9012.9090603@andrew.cmu.edu> From: Gregory Yakushev Date: Wed, 04 Feb 2015 10:42:14 +0000 Message-ID: To: Barry Leiba , Calsify Content-Type: multipart/alternative; boundary=047d7bacc382434ada050e40d7f8 Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 10:42:21 -0000 --047d7bacc382434ada050e40d7f8 Content-Type: text/plain; charset=UTF-8 I see that most of the points are cleared, so my only comment is on the SKIP behavior, below. On Mon Feb 02 2015 at 8:06:52 PM Barry Leiba wrote: > Marten and Ken, thanks for the replies. You've both addressed some of > the same comments, so I'll try to reply in one message. > > --- > On point 2: > >> It seems funny that SKIP has a fixed default, rather than being > >> dependent upon the RSCALE. For the Hebrew calendar, for example, the > >> default is wrong, and one always needs SKIP=FORWARD. It seems likely > >> that there'll be lots of errors involved in forgetting the SKIP and > >> having the default be wrong for the calendar that's being used, which > >> will cause interoperability problems that would be avoided if the > >> default depended on the calendar. (See also my comment #8 below > >> about Section 4.2.4.) > > Marten says... > > Having the same default value for all calendar scales at least guarantees > > consistent results among different implementations when you forget the > SKIP > > value. IMHO, having per-calendar-scale default values adds unnecessary > > complexity and it's questionable if you can find consensus on what the > > default should be for various scales (I don't think that the CLDR has > > defined default skip values so far). > > Also, I think the likelihood of implementing the per-calendar-scale > default > > values wrong, is probably just as high as forgetting a SKIP value. > > > > Setting the default to "SKIP=YES" (or "SKIP=OMIT", which sounds > reasonable > > to me) would be the simplest solution, because it's the current behavior > > anyway. > > Ken says... > > Perhaps an alternative to having a per-calendar default would be to make > > SKIP mandatory in the presence of RSCALE, thereby forcing the > user/client to > > be explicit in their expectations. > > To Marten, the point I'm making is that in order to support various > calendars correctly, implementations need to understand how to > correctly skip within each calendar anyway. That is, all > implementations that support the Hebrew calendar will need to know > that when Adar I (5L) is not present, you have to skip forward to Adar > (6)... and they'll need to know that regardless of what default we > place on SKIP. That means that generating a Hebrew calendar entry in > Adar I without SKIP is an error. > > It seems to be inviting problems to take an attribute whose value is > fixed to the calendar, and to give it a default that is always correct > for some calendars and always wrong for others... is the wrong > approach. Consider what happens when a buggy implementation > incorrectly omits SKIP. Consumers of that entry will then necessarily > get things wrong for the Hebrew calendar, always (well, always for > entries in Adar I). > > I think the default either has to be set appropriately for each > calendar (and Marten is right that there's a problem with that, in > that you have to have some place to make that assignment, which would > have to mean a registry for it), or to do as Ken suggests and make > SKIP=OMIT be the default. I think I like that answer. > > But making SKIP required would also work, and I'd be happy with that > alternative as well. > For completeness of this discussion I'd like to reiterate the reason we chose BACKWARD as default, because this reason is still valid. Defaults are nice because they conserve space for both computers and readers. So when choosing a default it makes sense to choose the most popular option, so most users won't need to specify it for their RRULEs to 'just work'. The BACKWARD is expected to be by far the most popular option in most calendars (except Hebrew), so choosing this default saves effort for the vast majority of users. Any other option would require vast majority of users to always include extra text in RRULE. It leaves Hebrew users with inconvenience of specifying SKIP=FORWARD for some rules though. The only option that doesn't require this effort is to use per-Calendar default, which implies keeping a registry just for this purpose. I don't think this particular case is worth the effort. I strongly oppose SKIP parameter to be required because of the above point, and also because for many RRULEs it never matters (e.g. daily, weekly, New Year celebrations etc.). It is acceptable to make OMIT to be default. It will require extra text in most RRULEs, but it simplifies the spec and is consistent with RRULE behavior when RSCALE is not present. To recap: my favorite default option is still BACKWARD, but OMIT is acceptable if consensus points in this direction. I'd prefer to avoid making SKIP required or having a per-Calendar default. My RSCALE implementation is deployed with Google Calendar, but it is not 'officially' launched, so changing implementation slightly should be OK at this point. > --- > On point 7: > >> 7. Section 4.2.2 > >> I don't understand why this example needs the BYMONTH value, and why > >> FREQ=YEARLY isn't enough. Isn't this exactly the same as the example > >> in 4.2.1, where "BYMONTH=1" isn't needed? > > Marten says... > > True, it's not necessary to specify BYMONTH and BYMONTHDAY in sections > 4.2.2 > > and 4.2.3. But according to RFC 5545 it's completely valid and you can > see > > many rules like that in the wild. > > The purpose of an example is to show how an RRULE could look like in real > > life and how you have to interpret it. To me it perfectly makes sense to > > give examples of both types of rules (i.e. with and without redundant > > BYMONTH and BYMONTHDAY parts). > > Ken says... > > As you point out, BYMONTH technically isn't needed. I had suggested this > > example to Cyrus to illustrate to readers the fact that BYMONTH can take > a > > value > 12 depending on the calendar. If you feel that illustrating this > > point isn't necessary, or feel that a better example should be > considered, > > I'm fine either way. > > I understand that, while it's not needed, it's legal. My point was > that I didn't see that this example was any different from the > previous one, so why have it? It might actually lead a reader to > believe that BYMONTH was necessary in this case. Thanks to both > Marten and Ken for explaining reasons to have the example. I think > it's useful to illustrate the points that it can be there even though > it's not required, and that it can have a value > 12. I think it > would help to have text in the example that explains both of those > points. > > --- > On point 8: > >> 8. Section 4.2.4 > >> Ooh, this seems completely wrong unless SKIP is redefined to be > >> dependent upon the calendar. In 4.2.3, you're showing me how > >> SKIP=FORWARD turns 5L-08 into 6-08, but then here you tell me that the > >> same SKIP=FORWARD turns 2-29 into 3-01, rather than 3-29. Of course, > >> that's what we want to happen, but how can I know that from the > >> explanation of SKIP? More to the point, it's clear from these two > >> examples that the behaviour of SKIP has to depend upon the calendar > >> that's in effect, and trying to define it to be independent doesn't > >> work. > > Marten says... > > The idea is: If you skip a leap month, you go forward (or backwards) by > one > > month. If you skip a leap day you go forward (or backwards) by one day. > > I guess that should be pointed out somewhere. > > Ken says... > > I'd be in favor of additional text clarifying that the effect of SKIP > > depends on whether the recurrence falls on an intercalary day or month. > > Indeed: there's nothing at all in the document that says that SKIP > works differently in different situations, and I think it's necessary > to have very clear text there that specifies exactly how skip works > when. > > And I think this makes it more evident that "SKIP=OMIT" should be the > default... otherwise, the default for anyone who specifies > "RSCALE=GREGORIAN" will turn 29 Feb into 28 Feb. It'd be far better > for it to work as it does today, unless SKIP is explicitly specified. > > --- > On point 9: > > Marten says... > > #9: > > I think that part has been added after I asked about the > case-sensitivity of > > the RSCALE value. In general most calendar applications tend to use the > > upper-case representation of names and tokens, but the CLDR calendar > scale > > names are defined in lower case (as in > > http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml). > > I know it's just an implementation detail rather than being relevant for > > this standard, but being able to make assumptions about the case allows > for > > certain optimization that wouldn't be possible otherwise. On a mobile > device > > with very limited resources that can make a difference. > > In this context I think "for consistency" means consistency between > > implementations, i.e. ideally all implementations would use the > upper-case > > version, even though the standard doesn't enforce it (because most > things in > > RFC 5545 are, by definition, case-insensitive). > > Ah, but because it's defined as being case insensitive, you're *not* > able to make assumptions about the case, and you can't optimize > anything. You don't know when you might be handed something that > doesn't follow that SHOULD, so your code has to handle it (and I'd > argue that if your code requires that it be in upper case, and doesn't > work if it's not, your code is broken). > > I think we should have required upper case in the base iCalendar spec. > But the fact that we didn't is a ship that's sailed under the bridge > and through the barn door. Sigh. But that means that the SHOULD is > really pointless. I'm happy if you use plain English to say that > there are advantages to using upper case, and remind readers that > iCalendar strongly recommends it. I don't think 2119 SHOULD is > appropriate. > > > I guess the same applies to the SKIP values and the "L" of leap months. > Does > > this spec allow a lower case "l"? > > It does, because literals in ABNF are case-insensitive (see RFC 5234). > > --- > Barry > Thanks, Grisha > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --047d7bacc382434ada050e40d7f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see th= at most of the points are cleared, so my only comment is on the SKIP behavi= or, below.

On Mon Feb 02 201= 5 at 8:06:52 PM Barry Leiba <= barryleiba@computer.org> wrote:
Ma= rten and Ken, thanks for the replies.=C2=A0 You've both addressed some = of
the same comments, so I'll try to reply in one message.

---
On point 2:
>> It seems funny that SKIP has a fixed default, rather than being >> dependent upon the RSCALE.=C2=A0 For the Hebrew calendar, for exam= ple, the
>> default is wrong, and one always needs SKIP=3DFORWARD.=C2=A0 It se= ems likely
>> that there'll be lots of errors involved in forgetting the SKI= P and
>> having the default be wrong for the calendar that's being used= , which
>> will cause interoperability problems that would be avoided if the<= br> >> default depended on the calendar.=C2=A0 (See also my comment #8 be= low
>> about Section 4.2.4.)

Marten says...
> Having the same default value for all calendar scales at least guarant= ees
> consistent results among different implementations when you forget the= SKIP
> value. IMHO, having per-calendar-scale default values adds unnecessary=
> complexity and it's questionable if you can find consensus on what= the
> default should be for various scales (I don't think that the CLDR = has
> defined default skip values so far).
> Also, I think the likelihood of implementing=C2=A0 the per-calendar-sc= ale default
> values wrong, is probably just as high as forgetting a SKIP value.
>
> Setting the default to "SKIP=3DYES" (or "SKIP=3DOMIT&qu= ot;, which sounds reasonable
> to me) would be the simplest solution, because it's the current be= havior
> anyway.

Ken says...
> Perhaps an alternative to having a per-calendar default would be to ma= ke
> SKIP mandatory in the presence of RSCALE, thereby forcing the user/cli= ent to
> be explicit in their expectations.

To Marten, the point I'm making is that in order to support various
calendars correctly, implementations need to understand how to
correctly skip within each calendar anyway.=C2=A0 That is, all
implementations that support the Hebrew calendar will need to know
that when Adar I (5L) is not present, you have to skip forward to Adar
(6)... and they'll need to know that regardless of what default we
place on SKIP.=C2=A0 That means that generating a Hebrew calendar entry in<= br> Adar I without SKIP is an error.

It seems to be inviting problems to take an attribute whose value is
fixed to the calendar, and to give it a default that is always correct
for some calendars and always wrong for others... is the wrong
approach.=C2=A0 Consider what happens when a buggy implementation
incorrectly omits SKIP.=C2=A0 Consumers of that entry will then necessarily=
get things wrong for the Hebrew calendar, always (well, always for
entries in Adar I).

I think the default either has to be set appropriately for each
calendar (and Marten is right that there's a problem with that, in
that you have to have some place to make that assignment, which would
have to mean a registry for it), or to do as Ken suggests and make
SKIP=3DOMIT be the default.=C2=A0 I think I like that answer.

But making SKIP required would also work, and I'd be happy with that alternative as well.

For completeness of this discussion I'd like= to reiterate the reason we chose BACKWARD as default, because this reason = is still valid.

Defaults are nice because they conserve space for bo= th computers and readers. So when choosing a default it makes sense to choo= se the most popular option, so most users won't need to specify it for = their RRULEs to 'just work'. The BACKWARD is expected to be by far = the most popular option in most calendars (except Hebrew), so choosing this= default saves effort for the vast majority of users. Any other option woul= d require vast majority of users to always include extra text in RRULE.

It leaves Hebrew users w= ith inconvenience of specifying SKIP=3DFORWARD for some rules though. The o= nly option that doesn't require this effort is to use per-Calendar defa= ult, which implies keeping a registry just for this purpose. I don't th= ink this particular case is worth the effort.

I strongly oppose SKIP parameter to be required b= ecause of the above point, and also because for many RRULEs it never matter= s (e.g. daily, weekly, New Year celebrations etc.).

It is acceptab= le to make OMIT to be default. It will require extra text in most RRULEs, b= ut it simplifies the spec and is consistent with RRULE behavior when RSCALE= is not present.

To recap: my favorite default opt= ion is still BACKWARD, but OMIT is acceptable if consensus points in this d= irection. I'd prefer to avoid making SKIP required or having a per-Cale= ndar default.

My RSCALE implementation is deployed= with Google Calendar, but it is not 'officially' launched, so chan= ging implementation slightly should be OK at this point.


---
On point 7:
>> 7. Section 4.2.2
>> I don't understand why this example needs the BYMONTH value, a= nd why
>> FREQ=3DYEARLY isn't enough.=C2=A0 Isn't this exactly the s= ame as the example
>> in 4.2.1, where "BYMONTH=3D1" isn't needed?

Marten says...
> True, it's not necessary to specify BYMONTH and BYMONTHDAY in sect= ions 4.2.2
> and 4.2.3. But according to RFC 5545 it's completely valid and you= can see
> many rules like that in the wild.
> The purpose of an example is to show how an RRULE could look like in r= eal
> life and how you have to interpret it. To me it perfectly makes sense = to
> give examples of both types of rules (i.e. with and without redundant<= br> > BYMONTH and BYMONTHDAY parts).

Ken says...
> As you point out, BYMONTH technically isn't needed.=C2=A0 I had su= ggested this
> example to Cyrus to illustrate to readers the fact that BYMONTH can ta= ke a
> value > 12 depending on the calendar.=C2=A0 If you feel that illust= rating this
> point isn't necessary, or feel that a better example should be con= sidered,
> I'm fine either way.

I understand that, while it's not needed, it's legal.=C2=A0 My poin= t was
that I didn't see that this example was any different from the
previous one, so why have it?=C2=A0 It might actually lead a reader to
believe that BYMONTH was necessary in this case.=C2=A0 Thanks to both
Marten and Ken for explaining reasons to have the example.=C2=A0 I think it's useful to illustrate the points that it can be there even though it's not required, and that it can have a value > 12.=C2=A0 I think = it
would help to have text in the example that explains both of those
points.

---
On point 8:
>> 8. Section 4.2.4
>> Ooh, this seems completely wrong unless SKIP is redefined to be >> dependent upon the calendar.=C2=A0 In 4.2.3, you're showing me= how
>> SKIP=3DFORWARD turns 5L-08 into 6-08, but then here you tell me th= at the
>> same SKIP=3DFORWARD turns 2-29 into 3-01, rather than 3-29.=C2=A0 = Of course,
>> that's what we want to happen, but how can I know that from th= e
>> explanation of SKIP?=C2=A0 More to the point, it's clear from = these two
>> examples that the behaviour of SKIP has to depend upon the calenda= r
>> that's in effect, and trying to define it to be independent do= esn't
>> work.

Marten says...
> The idea is: If you skip a leap month, you go forward (or backwards) b= y one
> month. If you skip a leap day you go forward (or backwards) by one day= .
> I guess that should be pointed out somewhere.

Ken says...
> I'd be in favor of additional text clarifying that the effect of S= KIP
> depends on whether the recurrence falls on an intercalary day or month= .

Indeed: there's nothing at all in the document that says that SKIP
works differently in different situations, and I think it's necessary to have very clear text there that specifies exactly how skip works
when.

And I think this makes it more evident that "SKIP=3DOMIT" should = be the
default... otherwise, the default for anyone who specifies
"RSCALE=3DGREGORIAN" will turn 29 Feb into 28 Feb.=C2=A0 It'd= be far better
for it to work as it does today, unless SKIP is explicitly specified.

---
On point 9:

Marten says...
> #9:
> I think that part has been added after I asked about the case-sensitiv= ity of
> the RSCALE value. In general most calendar applications tend to use th= e
> upper-case representation of names and tokens, but the CLDR calendar s= cale
> names are defined in lower case (as in
> http://unicode.org/repos/cldr/trunk/common/bcp= 47/calendar.xml).
> I know it's just an implementation detail rather than being releva= nt for
> this standard, but being able to make assumptions about the case allow= s for
> certain optimization that wouldn't be possible otherwise. On a mob= ile device
> with very limited resources that can make a difference.
> In this context I think "for consistency" means consistency = between
> implementations, i.e. ideally all implementations would use the upper-= case
> version, even though the standard doesn't enforce it (because most= things in
> RFC 5545 are, by definition, case-insensitive).

Ah, but because it's defined as being case insensitive, you're *not= *
able to make assumptions about the case, and you can't optimize
anything.=C2=A0 You don't know when you might be handed something that<= br> doesn't follow that SHOULD, so your code has to handle it (and I'd<= br> argue that if your code requires that it be in upper case, and doesn't<= br> work if it's not, your code is broken).

I think we should have required upper case in the base iCalendar spec.
But the fact that we didn't is a ship that's sailed under the bridg= e
and through the barn door.=C2=A0 Sigh.=C2=A0 But that means that the SHOULD= is
really pointless.=C2=A0 I'm happy if you use plain English to say that<= br> there are advantages to using upper case, and remind readers that
iCalendar strongly recommends it.=C2=A0 I don't think 2119 SHOULD is appropriate.

> I guess the same applies to the SKIP values and the "L" of l= eap months. Does
> this spec allow a lower case "l"?

It does, because literals in ABNF are case-insensitive (see RFC 5234).

---
Barry

Thanks,
Grisha
=C2=A0

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--047d7bacc382434ada050e40d7f8-- From nobody Wed Feb 4 03:26:38 2015 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 23B411A6F27 for ; Wed, 4 Feb 2015 03:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 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, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uybYjVVZUot0 for ; Wed, 4 Feb 2015 03:26:35 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CCB1A007C for ; Wed, 4 Feb 2015 03:26:35 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id c9so651762qcz.6 for ; Wed, 04 Feb 2015 03:26:34 -0800 (PST) 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=YK032NguHUwjo7yuVGNM+WrImJPQJNBs6fqQ5tgMdKs=; b=CKZTnruTb+Q9yWRJ4A+A8Dh1cYue9opmeGSwa9JAkbBgVjSNeGBS2gON+4TwWfZD1d 6bO/xOxkUGDwrYSpmW6Dqp1tl/+3v6ZcGv+G9/7VkkwIs2KgP5RB0o8zyEnTDl5wWX68 FXLPLv8bjeEaGOPi5NYugnNQa7ku1KdNzN6t2F3djGxzTbLTKq97G2kq5ALIRk1jQGsl 1hjYrUmyhwvgGGIJldlZSzbwWPB0m76pUjFWrafek8aFHzmv+ewN3q7f5W6t7KWW8vnp fZbMxdRMYf/jToypf9GN3nHvCStT3LCaKEld8juuu3prDhOKrXlqGficlgutqZml3EFM 1u9Q== 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=YK032NguHUwjo7yuVGNM+WrImJPQJNBs6fqQ5tgMdKs=; b=jZ5b03cOutA//xpcVJEXynOJrruYk1kBI/+no0jeLCb8ksWE6T4TMpwi94vev9iLsB WmxIo4DKqwt3zjqz1bisLSUReHZhZfby8j4xBIySbhZkkbYBHTBUYQazR6i8l3HZwOPr gsnB0SG+uB5nrEhYjNoaZo+tvKZem0GPRFUcbNVp6NEHr27ouyEvIHf4WfrEdqnIa+cC lAh988yJ0XC+Zyq1L8ag6fmljluHtnTs5aKRRB00zMKkQNfA8c6emVLnkNXB+2TaxFLR g00n3rBjj8JBF14/A2W2/+AzaKg6mmbHoSEvre3RO39x8ICmShrJF/WOz7ZSS1GoLf4L B/qg== X-Gm-Message-State: ALoCoQkBW51YHvyLhRR9BqACfTp6VM3T78LugpKA2KfIGUYb24MkFutlMVDsZ8OwR7kRsgVKRYF6 X-Received: by 10.140.38.136 with SMTP id t8mr2826287qgt.61.1423049194194; Wed, 04 Feb 2015 03:26:34 -0800 (PST) MIME-Version: 1.0 References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> From: Gregory Yakushev Date: Wed, 04 Feb 2015 11:26:33 +0000 Message-ID: To: Marten Gajda , Cyrus Daboo , Ken Murchison , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a11c12db2b7f1a5050e4175cc Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 11:26:37 -0000 --001a11c12db2b7f1a5050e4175cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Quite a discussion here, let me try to catch up. As for FREQ=3DYEARLY;RSCALE=3DHEBREW;MONTHLY=3D5L;BYDAY=3DMO,TU,WE,TH,FR,SA= ,SU;SKIP=3DFORWARD case, its clearly artificial and doesn't represent any real-world usecase, so there's no preference for our users on how to handle it. As was cleared above, SKIP behavior is clear for all Calendars except Hebrew, and for all except Hebrew people will use SKIP=3DBACKWARD for most usecases. It is important to clear the Hebrew case, but lets keep in mind this we are talking about a very narrow usecase for a relatively small number of users. It will be unfair to complicate life for billions of Chinese or Hindu users to make Hebrew case perfectly right. Do I understand correctly that current draft allows to specify an RRULE for all Hebrew cases, even though it looks ugly for Adar I 30th? Grisha On Tue Feb 03 2015 at 10:50:15 PM Marten Gajda wrote: > > Am 03.02.2015 um 22:04 schrieb Cyrus Daboo: > > I think Ken's idea is that you apply the SKIP after BYMONTH only if the > invalid data corresponds to an invalid leap month as opposed to a leap da= y. > In which case the SKIP would not have applied after BYMONTH in your > example. But I think a behavior like that is going to be really tricky fo= r > implementors to get right and hard to describe really well without having > to delve into the gory details of RRULE processing. > > Ah, got it. > > So, considering the following > > Applying SKIP=3DFORWARD after BYDAY on the following rule > > > FREQ=3DYEARLY;RSCALE=3DHEBREW;MONTHLY=3D5L;BYDAY=3DMO,TU,WE,TH,FR,SA,SU;S= KIP=3DFORWARD > > results in 30 instances in leap years and in non-leap years, since it > would expand the week days in Adar I and roll them forward afterwards > > Applying SKIP=3DFORWARD after BYMONTH but before BYDAY results in 30 > instances in leap years, but 29 instances in non-leap years, since the > weekdays would be expanded for Adar instead of Adar I. > > It's similar when the month following the leap month has more days than > the leap month itself. > > In essence, applying SKIP after all BYxxx parts won't change the number o= f > instances (given they don't fall on another instance), but Ken's approach > might do that. > > Not sure what's preferable in this case. > > > > > -- > > *Marten Gajda* > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > Germany > > tel: +49 177 4427167 > email: marten@dmfs.org > twitter: twitter.com/dmfs_org > > VAT Reg. No.: DE269072391 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c12db2b7f1a5050e4175cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Quite a discussion here, let me try to catch up.

As= for=C2=A0FREQ=3DYEARLY;RSCALE=3DHEBREW;MONTHLY=3D5L;BYDAY=3DMO,TU= ,WE,TH,FR,SA,SU;SKIP=3DFORWARD case, its clearly artificial and doe= sn't represent any real-world usecase, so there's no preference for= our users on how to handle it.

As was cleared ab= ove, SKIP behavior is clear for all Calendars except Hebrew, and for all ex= cept Hebrew people will use SKIP=3DBACKWARD for most usecases.
It is important to clear the Hebrew case, but lets keep in min= d this we are talking about a very narrow usecase for a relatively small nu= mber of users. It will be unfair to complicate life for billions of Chinese= or Hindu users to make Hebrew case perfectly right.

Do I understand correctly that current draft allows to specify an RRULE = for all Hebrew cases, even though it looks ugly for Adar I 30th?
=
Grisha


On Tue Feb 03 2015 at 10:50:15 PM Marten Gajda <marten@dmfs.org> wrote:
=20 =20 =20

Am 03.02.2015 um 22:04 schrieb Cyrus Daboo:
I think Ken's idea is that you apply the = SKIP after BYMONTH only if the invalid data corresponds to an invalid leap month as opposed to a leap day. In which case the SKIP would not have applied after BYMONTH in your example. But I think a behavior like that is going to be really tricky for implementors to get right and hard to describe really well without having to delve into the gory details of RRULE processing.

Ah, got it.

So, considering the following

Applying SKIP=3DFORWARD after BYDAY on the following rule

FREQ=3DYEARLY;RSCALE=3DHEBREW;MONTHLY=3D5L;BYDAY=3DMO,TU,WE,TH,FR,SA,SU;SKI= P=3DFORWARD

results in 30 instances in leap years and in non-leap years, since it would expand the week days in Adar I and roll them forward afterwards

Applying SKIP=3DFORWARD after BYMONTH but before BYDAY results in 30 instances in leap years, but 29 instances in non-leap years, since the weekdays would be expanded for Adar instead of Adar I.

It's similar when the month following the leap month has more days than the leap month itself.

In essence, applying SKIP after all BYxxx parts won't change the number of instances (given they don't fall on another instance), bu= t Ken's approach might do that.

Not sure what's preferable in this case.




--

Marten Gajda
Schandauer Stra=C3=9Fe 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@= dmfs.org
twitter: = twitter.com/dmfs_org

VAT Reg. No.: DE269072391

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a11c12db2b7f1a5050e4175cc-- From nobody Wed Feb 4 05:17:22 2015 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 577111A87EB for ; Wed, 4 Feb 2015 05:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_52=0.6, 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 4Llrk82WiD4T for ; Wed, 4 Feb 2015 05:17:11 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B7D1A00E4 for ; Wed, 4 Feb 2015 05:17:10 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id k11so1713421wes.2 for ; Wed, 04 Feb 2015 05:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=/sqI3pPkQxI9vQcKHOY8lKguWfj48dnZ2u6UPnY//5o=; b=0u4vh2Ctlioi48prwymqOUzNEyMhaJmB9lRR5zT6c/TorvAPx9m+pSo3X1TeLkdz6H /CVTll87IDyHCH2ggc3RlwOv0/5aQrNlIzPOPAgI+8b7z9gaUFuJyZ62SUFqzDu5b6Wo tKz6YZAgV9f/ozx8GEtG3rJdmrZ94a75REHay1UOYAj6FtMJECVDyst7+j3wIXMrm6lZ qBj29InuhPkYaF3kT3cdThRcMLGthwludZurqvo9E1JtnkPhga+HUn+shCP8zNcNAgB9 /PmZi+/XA/0iV3B/b/jT/kxmNAshKkvnyPPJsTc8k2/BmkV+knHvSLIpgaig0zHrYgJ4 f5/w== X-Received: by 10.194.85.233 with SMTP id k9mr20441354wjz.106.1423055829253; Wed, 04 Feb 2015 05:17:09 -0800 (PST) Received: from smtp.dmfs.org (p4FF0E020.dip0.t-ipconnect.de. [79.240.224.32]) by mx.google.com with ESMTPSA id li7sm29241126wic.4.2015.02.04.05.17.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Feb 2015 05:17:06 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (linux.fritz.box [192.168.2.53]) by smtp.dmfs.org (Postfix) with ESMTPSA id 5A34136B; Wed, 4 Feb 2015 14:17:04 +0100 (CET) Message-ID: <54D21BD0.7070006@dmfs.org> Date: Wed, 04 Feb 2015 14:17:04 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Gregory Yakushev , Cyrus Daboo , Ken Murchison , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040000080202090801090405" Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 13:17:19 -0000 This is a multi-part message in MIME format. --------------040000080202090801090405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 04.02.2015 um 12:26 schrieb Gregory Yakushev: > Quite a discussion here, let me try to catch up. > > As for > FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD > case, its clearly artificial and doesn't represent any real-world > usecase, so there's no preference for our users on how to handle it. That's true, but it's probably easy to generate a real world example where the execution order of SKIP and BYxxx rules matters. The question is, do we want BYDAY and BYMONTHDAY expansion to be executed on the days of the skipped leap month or on the days of the actual month? The more I think about this, the more I like the idea to apply SKIP right after BYMONTH when skipping a leap month. When you expand BYDAY=SU for a leap month you probably want to expand all Sundays in the following (or preceding) month when the year is not a leap year. The number of Sundays you expand for the skipped month might be different from the number of Sundays in the next or previous month. Also when rolling a day backwards to the previous month, a Sunday would fall on a different weekday (unless the number of days in that month is a multiple of 7). > > As was cleared above, SKIP behavior is clear for all Calendars except > Hebrew, and for all except Hebrew people will use SKIP=BACKWARD for > most usecases. > > It is important to clear the Hebrew case, but lets keep in mind this > we are talking about a very narrow usecase for a relatively small > number of users. It will be unfair to complicate life for billions of > Chinese or Hindu users to make Hebrew case perfectly right. I think the user shouldn't notice any difference. It's the developers that have to get this right. Setting the default to SKIP=OMIT sounds like the best solution to me. It doesn't prefer any specific calendar and it doesn't change the semantics of existing rule when you add RSCALE=GREGORIAN but no SKIP. Marten > > Do I understand correctly that current draft allows to specify an > RRULE for all Hebrew cases, even though it looks ugly for Adar I 30th? > > Grisha > > > On Tue Feb 03 2015 at 10:50:15 PM Marten Gajda > wrote: > > > Am 03.02.2015 um 22:04 schrieb Cyrus Daboo: >> I think Ken's idea is that you apply the SKIP after BYMONTH only >> if the invalid data corresponds to an invalid leap month as >> opposed to a leap day. In which case the SKIP would not have >> applied after BYMONTH in your example. But I think a behavior >> like that is going to be really tricky for implementors to get >> right and hard to describe really well without having to delve >> into the gory details of RRULE processing. >> > Ah, got it. > > So, considering the following > > Applying SKIP=FORWARD after BYDAY on the following rule > > FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD > > results in 30 instances in leap years and in non-leap years, since > it would expand the week days in Adar I and roll them forward > afterwards > > Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 > instances in leap years, but 29 instances in non-leap years, since > the weekdays would be expanded for Adar instead of Adar I. > > It's similar when the month following the leap month has more days > than the leap month itself. > > In essence, applying SKIP after all BYxxx parts won't change the > number of instances (given they don't fall on another instance), > but Ken's approach might do that. > > Not sure what's preferable in this case. > > > > > -- > > *Marten Gajda* > Schandauer Straße 34 > 01309 Dresden > Germany > > tel: +49 177 4427167 > email: marten@dmfs.org > twitter: twitter.com/dmfs_org > > VAT Reg. No.: DE269072391 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------040000080202090801090405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 04.02.2015 um 12:26 schrieb Gregory Yakushev:
Quite a discussion here, let me try to catch up.

As for FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD case, its clearly artificial and doesn't represent any real-world usecase, so there's no preference for our users on how to handle it.
That's true, but it's probably easy to generate a real world example where the execution order of SKIP and BYxxx rules matters.

The question is, do we want BYDAY and BYMONTHDAY expansion to be executed on the days of the skipped leap month or on the days of the actual month?

The more I think about this, the more I like the idea to apply SKIP right after BYMONTH when skipping a leap month. When you expand BYDAY=SU for a leap month you probably want to expand all Sundays in the following (or preceding) month when the year is not a leap year. The number of Sundays you expand for the skipped month might be different from the number of Sundays in the next or previous month. Also when rolling a day backwards to the previous month, a Sunday would fall on a different weekday (unless the number of days in that month is a multiple of 7).


As was cleared above, SKIP behavior is clear for all Calendars except Hebrew, and for all except Hebrew people will use SKIP=BACKWARD for most usecases.

It is important to clear the Hebrew case, but lets keep in mind this we are talking about a very narrow usecase for a relatively small number of users. It will be unfair to complicate life for billions of Chinese or Hindu users to make Hebrew case perfectly right.
I think the user shouldn't notice any difference. It's the developers that have to get this right. Setting the default to SKIP=OMIT sounds like the best solution to me. It doesn't prefer any specific calendar and it doesn't change the semantics of existing rule when you add RSCALE=GREGORIAN but no SKIP.

Marten


Do I understand correctly that current draft allows to specify an RRULE for all Hebrew cases, even though it looks ugly for Adar I 30th?

Grisha


On Tue Feb 03 2015 at 10:50:15 PM Marten Gajda <marten@dmfs.org> wrote:

Am 03.02.2015 um 22:04 schrieb Cyrus Daboo:
I think Ken's idea is that you apply the SKIP after BYMONTH only if the invalid data corresponds to an invalid leap month as opposed to a leap day. In which case the SKIP would not have applied after BYMONTH in your example. But I think a behavior like that is going to be really tricky for implementors to get right and hard to describe really well without having to delve into the gory details of RRULE processing.

Ah, got it.

So, considering the following

Applying SKIP=FORWARD after BYDAY on the following rule

FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD

results in 30 instances in leap years and in non-leap years, since it would expand the week days in Adar I and roll them forward afterwards

Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 instances in leap years, but 29 instances in non-leap years, since the weekdays would be expanded for Adar instead of Adar I.

It's similar when the month following the leap month has more days than the leap month itself.

In essence, applying SKIP after all BYxxx parts won't change the number of instances (given they don't fall on another instance), but Ken's approach might do that.

Not sure what's preferable in this case.




--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391

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


-- 
Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391
--------------040000080202090801090405-- From nobody Wed Feb 4 05:20:48 2015 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 577301A87EC for ; Wed, 4 Feb 2015 05:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ndKCTtJcgVrH for ; Wed, 4 Feb 2015 05:20:42 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02161A87EB for ; Wed, 4 Feb 2015 05:20:41 -0800 (PST) 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.8/8.14.8) with ESMTP id t14DKZrD025899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Feb 2015 08:20:35 -0500 Message-ID: <54D21CA2.5020807@andrew.cmu.edu> Date: Wed, 04 Feb 2015 08:20:34 -0500 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: Marten Gajda , Cyrus Daboo , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> In-Reply-To: <54D14289.90201@dmfs.org> Content-Type: multipart/alternative; boundary="------------070908030407060605020407" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.4.131220 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.203 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 13:20:44 -0000 This is a multi-part message in MIME format. --------------070908030407060605020407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/03/2015 04:50 PM, Marten Gajda wrote: > > Am 03.02.2015 um 22:04 schrieb Cyrus Daboo: >> I think Ken's idea is that you apply the SKIP after BYMONTH only if >> the invalid data corresponds to an invalid leap month as opposed to a >> leap day. In which case the SKIP would not have applied after BYMONTH >> in your example. But I think a behavior like that is going to be >> really tricky for implementors to get right and hard to describe >> really well without having to delve into the gory details of RRULE >> processing. >> > Ah, got it. > > So, considering the following > > Applying SKIP=FORWARD after BYDAY on the following rule > > FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD > > results in 30 instances in leap years and in non-leap years, since it > would expand the week days in Adar I and roll them forward afterwards > > Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 > instances in leap years, but 29 instances in non-leap years, since the > weekdays would be expanded for Adar instead of Adar I. > > It's similar when the month following the leap month has more days > than the leap month itself. > > In essence, applying SKIP after all BYxxx parts won't change the > number of instances (given they don't fall on another instance), but > Ken's approach might do that. > > Not sure what's preferable in this case. I'd argue that what this rule is asking for is all days of the leap month, but in non-leap years provide all days of the next month, so 30 and 29 are correct respectively. I'd also argue that BYMONTHDAY=30/31 should have different results from BYMONTHDAY=-1, in the same way that it does for GREGORIAN: RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=31 DTSTART:20150131 INSTANCES:20150131,20150301,20150331,20150501,20150531,20150701,20150731,20150831,20151001,20151031,20151201,20151231 RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=-1 DTSTART:20150131 INSTANCES:20150131,20150228,20150331,20150430,20150531,20150630,20150731,20150831,20150930,20151031,20151130,20151231 So, my proposal is to tweak the BYxxx rule part processing order in RFC 5545, Section 3.3.10 by inserting SKIP processing in the following way: BYMONTH SKIP (for invalid month only) BYWEEKNO BYYEARDAY BYMONTHDAY SKIP (for invalid day) BYDAY BYHOUR BYMINUTE BYSECOND BYSETPOS COUNT UNTIL By main argument here is that BYWEEKNO, BYYEARDAY, BYMONTHDAY should apply to a "real" month in all cases, and not a leap month in non-leap years. This leads to the following for the Hebrew calendar: RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=30;BYMONTH=5L DTSTART:20140302 INSTANCES:20140302 (30 Adar I), 20150321 (1 Nisan), 20160310 (30 Adar I), 20170328 (1 Nisan), 20180317 (1 Nisan) RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=-1;BYMONTH=5L DTSTART:20140302 INSTANCES:20140302 (30 Adar I), 20150320 (29 Adar), 20160310 (30 Adar I), 20170327 (29 Adar), 20180316 (29 Adar) -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------070908030407060605020407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 02/03/2015 04:50 PM, Marten Gajda wrote:

Am 03.02.2015 um 22:04 schrieb Cyrus Daboo:
I think Ken's idea is that you apply the SKIP after BYMONTH only if the invalid data corresponds to an invalid leap month as opposed to a leap day. In which case the SKIP would not have applied after BYMONTH in your example. But I think a behavior like that is going to be really tricky for implementors to get right and hard to describe really well without having to delve into the gory details of RRULE processing.

Ah, got it.

So, considering the following

Applying SKIP=FORWARD after BYDAY on the following rule

FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD

results in 30 instances in leap years and in non-leap years, since it would expand the week days in Adar I and roll them forward afterwards

Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 instances in leap years, but 29 instances in non-leap years, since the weekdays would be expanded for Adar instead of Adar I.

It's similar when the month following the leap month has more days than the leap month itself.

In essence, applying SKIP after all BYxxx parts won't change the number of instances (given they don't fall on another instance), but Ken's approach might do that.

Not sure what's preferable in this case.

I'd argue that what this rule is asking for is all days of the leap month, but in non-leap years provide all days of the next month, so 30 and 29 are correct respectively.

I'd also argue that BYMONTHDAY=30/31 should have different results from BYMONTHDAY=-1, in the same way that it does for GREGORIAN:


RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=31
DTSTART:20150131
INSTANCES:20150131,20150301,20150331,20150501,20150531,20150701,20150731,20150831,20151001,20151031,20151201,20151231

RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=-1
DTSTART:20150131
INSTANCES:20150131,20150228,20150331,20150430,20150531,20150630,20150731,20150831,20150930,20151031,20151130,20151231


So, my proposal is to tweak the BYxxx rule part processing order in RFC 5545, Section 3.3.10 by inserting SKIP processing in the following way:

BYMONTH
SKIP (for invalid month only)
BYWEEKNO
BYYEARDAY
BYMONTHDAY
SKIP (for invalid day)
BYDAY
BYHOUR
BYMINUTE
BYSECOND
BYSETPOS
COUNT
UNTIL


By main argument here is that BYWEEKNO, BYYEARDAY, BYMONTHDAY should apply to a "real" month in all cases, and not a leap month in non-leap years.

This leads to the following for the Hebrew calendar:

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=30;BYMONTH=5L
DTSTART:20140302
INSTANCES:20140302 (30 Adar I), 20150321 (1 Nisan), 20160310 (30 Adar I), 20170328 (1 Nisan), 20180317 (1 Nisan)

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=-1;BYMONTH=5L
DTSTART:20140302
INSTANCES:20140302 (30 Adar I), 20150320 (29 Adar), 20160310 (30 Adar I), 20170327 (29 Adar), 20180316 (29 Adar)



-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------070908030407060605020407-- From nobody Wed Feb 4 05:55:39 2015 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 B00AB1A8834 for ; Wed, 4 Feb 2015 05:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, 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 GEw7e4rmsa8s for ; Wed, 4 Feb 2015 05:55:35 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627F71A8833 for ; Wed, 4 Feb 2015 05:55:35 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so1829517wgh.10 for ; Wed, 04 Feb 2015 05:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=VwpRsTS0DSMOTaHRQ0WX8JDgn1ZQLWxhaxyQifJztig=; b=cYvt5pTjsh0kemV+8cb3YZFN7Mc6VWaGEvldgLNaRcOeOIJrjhqRblETS+9I9XOQOk Qd1CL3dKg59hfNeiTrEyTWbnaglrkpl0FLEMAtdJas5Jwt4KVyU7fwfOlEU6xcdB/OY2 J3iz1LCkZ+Zia7LbqpA0T3Lo/pqzVjEcEmBWgLWYPXp1xAmDlse0JTJ12AcJdfVOedES 7OVQp8vPUE3NK+Iny450yb/PHoEM9eZ5QyRq7rB5Adn0IV10LkN5eMWSTmaLtcAddA1V HcO9tho/ZJz3B0Dk6JQzFIY5NIt4arKqrtP6vbJ/UqeJ0VSfjQEpzsK0gKCIfFti3Wvj IImg== X-Received: by 10.194.184.212 with SMTP id ew20mr50104291wjc.88.1423058133773; Wed, 04 Feb 2015 05:55:33 -0800 (PST) Received: from smtp.dmfs.org (p4FF0E020.dip0.t-ipconnect.de. [79.240.224.32]) by mx.google.com with ESMTPSA id l6sm2831145wjx.33.2015.02.04.05.55.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Feb 2015 05:55:31 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (linux.fritz.box [192.168.2.53]) by smtp.dmfs.org (Postfix) with ESMTPSA id 2943B58B; Wed, 4 Feb 2015 14:55:29 +0100 (CET) Message-ID: <54D224D0.1050309@dmfs.org> Date: Wed, 04 Feb 2015 14:55:28 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ken Murchison , Cyrus Daboo , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> In-Reply-To: <54D21CA2.5020807@andrew.cmu.edu> Content-Type: multipart/alternative; boundary="------------030503030402090502080507" Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 13:55:37 -0000 This is a multi-part message in MIME format. --------------030503030402090502080507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 for Ken's proposal. I couldn't find it in the latest draft (maybe I just didn't look close enough), but I think it should be pointed out that in this context "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't apply to Feb 30 or similar dates. Am 04.02.2015 um 14:20 schrieb Ken Murchison: > On 02/03/2015 04:50 PM, Marten Gajda wrote: >> >> Am 03.02.2015 um 22:04 schrieb Cyrus Daboo: >>> I think Ken's idea is that you apply the SKIP after BYMONTH only if >>> the invalid data corresponds to an invalid leap month as opposed to >>> a leap day. In which case the SKIP would not have applied after >>> BYMONTH in your example. But I think a behavior like that is going >>> to be really tricky for implementors to get right and hard to >>> describe really well without having to delve into the gory details >>> of RRULE processing. >>> >> Ah, got it. >> >> So, considering the following >> >> Applying SKIP=FORWARD after BYDAY on the following rule >> >> FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD >> >> results in 30 instances in leap years and in non-leap years, since it >> would expand the week days in Adar I and roll them forward afterwards >> >> Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 >> instances in leap years, but 29 instances in non-leap years, since >> the weekdays would be expanded for Adar instead of Adar I. >> >> It's similar when the month following the leap month has more days >> than the leap month itself. >> >> In essence, applying SKIP after all BYxxx parts won't change the >> number of instances (given they don't fall on another instance), but >> Ken's approach might do that. >> >> Not sure what's preferable in this case. > > I'd argue that what this rule is asking for is all days of the leap > month, but in non-leap years provide all days of the next month, so 30 > and 29 are correct respectively. > > I'd also argue that BYMONTHDAY=30/31 should have different results > from BYMONTHDAY=-1, in the same way that it does for GREGORIAN: > > > RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=31 > DTSTART:20150131 > INSTANCES:20150131,20150301,20150331,20150501,20150531,20150701,20150731,20150831,20151001,20151031,20151201,20151231 > > RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=-1 > DTSTART:20150131 > INSTANCES:20150131,20150228,20150331,20150430,20150531,20150630,20150731,20150831,20150930,20151031,20151130,20151231 > > > So, my proposal is to tweak the BYxxx rule part processing order in > RFC 5545, Section 3.3.10 by inserting SKIP processing in the following > way: > > BYMONTH > SKIP (for invalid month only) > BYWEEKNO > BYYEARDAY > BYMONTHDAY > SKIP (for invalid day) > BYDAY > BYHOUR > BYMINUTE > BYSECOND > BYSETPOS > COUNT > UNTIL > > > By main argument here is that BYWEEKNO, BYYEARDAY, BYMONTHDAY should > apply to a "real" month in all cases, and not a leap month in non-leap > years. > > This leads to the following for the Hebrew calendar: > > RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=30;BYMONTH=5L > DTSTART:20140302 > INSTANCES:20140302 (30 Adar I), 20150321 (1 Nisan), 20160310 (30 Adar > I), 20170328 (1 Nisan), 20180317 (1 Nisan) > > RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=-1;BYMONTH=5L > DTSTART:20140302 > INSTANCES:20140302 (30 Adar I), 20150320 (29 Adar), 20160310 (30 Adar > I), 20170327 (29 Adar), 20180316 (29 Adar) > > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------030503030402090502080507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
+1 for Ken's proposal.

I couldn't find it in the latest draft (maybe I just didn't look close enough), but I think it should be pointed out that in this context "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't apply to Feb 30 or similar dates.

Am 04.02.2015 um 14:20 schrieb Ken Murchison:
On 02/03/2015 04:50 PM, Marten Gajda wrote:

Am 03.02.2015 um 22:04 schrieb Cyrus Daboo:
I think Ken's idea is that you apply the SKIP after BYMONTH only if the invalid data corresponds to an invalid leap month as opposed to a leap day. In which case the SKIP would not have applied after BYMONTH in your example. But I think a behavior like that is going to be really tricky for implementors to get right and hard to describe really well without having to delve into the gory details of RRULE processing.

Ah, got it.

So, considering the following

Applying SKIP=FORWARD after BYDAY on the following rule

FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD

results in 30 instances in leap years and in non-leap years, since it would expand the week days in Adar I and roll them forward afterwards

Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30 instances in leap years, but 29 instances in non-leap years, since the weekdays would be expanded for Adar instead of Adar I.

It's similar when the month following the leap month has more days than the leap month itself.

In essence, applying SKIP after all BYxxx parts won't change the number of instances (given they don't fall on another instance), but Ken's approach might do that.

Not sure what's preferable in this case.

I'd argue that what this rule is asking for is all days of the leap month, but in non-leap years provide all days of the next month, so 30 and 29 are correct respectively.

I'd also argue that BYMONTHDAY=30/31 should have different results from BYMONTHDAY=-1, in the same way that it does for GREGORIAN:


RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=31
DTSTART:20150131
INSTANCES:20150131,20150301,20150331,20150501,20150531,20150701,20150731,20150831,20151001,20151031,20151201,20151231

RRULE:FREQ=MONTHLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=12;BYMONTHDAY=-1
DTSTART:20150131
INSTANCES:20150131,20150228,20150331,20150430,20150531,20150630,20150731,20150831,20150930,20151031,20151130,20151231


So, my proposal is to tweak the BYxxx rule part processing order in RFC 5545, Section 3.3.10 by inserting SKIP processing in the following way:

BYMONTH
SKIP (for invalid month only)
BYWEEKNO
BYYEARDAY
BYMONTHDAY
SKIP (for invalid day)
BYDAY
BYHOUR
BYMINUTE
BYSECOND
BYSETPOS
COUNT
UNTIL


By main argument here is that BYWEEKNO, BYYEARDAY, BYMONTHDAY should apply to a "real" month in all cases, and not a leap month in non-leap years.

This leads to the following for the Hebrew calendar:

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=30;BYMONTH=5L
DTSTART:20140302
INSTANCES:20140302 (30 Adar I), 20150321 (1 Nisan), 20160310 (30 Adar I), 20170328 (1 Nisan), 20180317 (1 Nisan)

RRULE:FREQ=YEARLY;RSCALE=HEBREW;SKIP=FORWARD;COUNT=5;BYMONTHDAY=-1;BYMONTH=5L
DTSTART:20140302
INSTANCES:20140302 (30 Adar I), 20150320 (29 Adar), 20160310 (30 Adar I), 20170327 (29 Adar), 20180316 (29 Adar)



-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University



-- 
Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391
--------------030503030402090502080507-- From nobody Wed Feb 4 06:34:44 2015 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 D39C21A8987 for ; Wed, 4 Feb 2015 06:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ugi9qVAJBBsj for ; Wed, 4 Feb 2015 06:34:31 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F691A8992 for ; Wed, 4 Feb 2015 06:34:24 -0800 (PST) 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.8/8.14.8) with ESMTP id t14EYJHQ030558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Feb 2015 09:34:20 -0500 Message-ID: <54D22DEB.7020501@andrew.cmu.edu> Date: Wed, 04 Feb 2015 09:34:19 -0500 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: Marten Gajda , Cyrus Daboo , calsify@ietf.org References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> In-Reply-To: <54D224D0.1050309@dmfs.org> Content-Type: multipart/alternative; boundary="------------060706080301010008080309" X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.4.142418 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_2000_2999 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, REFERENCES 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, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.203 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 14:34:35 -0000 This is a multi-part message in MIME format. --------------060706080301010008080309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Marten, On 02/04/2015 08:55 AM, Marten Gajda wrote: > +1 for Ken's proposal. > > I couldn't find it in the latest draft (maybe I just didn't look close > enough), but I think it should be pointed out that in this context > "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't > apply to Feb 30 or similar dates. Actually, for Feb 30, SKIP=FORWARD should yield Mar 1, which is why the draft say "invalid day". Same for April 31. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University --------------060706080301010008080309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hi Marten,


On 02/04/2015 08:55 AM, Marten Gajda wrote:
+1 for Ken's proposal.

I couldn't find it in the latest draft (maybe I just didn't look close enough), but I think it should be pointed out that in this context "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't apply to Feb 30 or similar dates.

Actually, for Feb 30, SKIP=FORWARD should yield Mar 1, which is why the draft say "invalid day".

Same for April 31.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--------------060706080301010008080309-- From nobody Wed Feb 4 06:49:22 2015 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 9D0591A8843 for ; Wed, 4 Feb 2015 06:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iJqh_rLOUule for ; Wed, 4 Feb 2015 06:49:21 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E731A8784 for ; Wed, 4 Feb 2015 06:49:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5BDECADAEE3; Wed, 4 Feb 2015 09:49:17 -0500 (EST) 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 YB6nzWed3xEJ; Wed, 4 Feb 2015 09:49:16 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 25526ADAED6; Wed, 4 Feb 2015 09:49:13 -0500 (EST) Date: Wed, 04 Feb 2015 09:49:07 -0500 From: Cyrus Daboo To: Ken Murchison , Marten Gajda , calsify@ietf.org Message-ID: In-Reply-To: <54D22DEB.7020501@andrew.cmu.edu> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@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=653 Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 14:49:21 -0000 Hi Ken, --On February 4, 2015 at 9:34:19 AM -0500 Ken Murchison wrote: >> +1 for Ken's proposal. >> >> I couldn't find it in the latest draft (maybe I just didn't look close >> enough), but I think it should be pointed out that in this context >> "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't >> apply to Feb 30 or similar dates. > > Actually, for Feb 30, SKIP=FORWARD should yield Mar 1, which is why the > draft say "invalid day". > > Same for April 31. Yes, I think an "invalid" day means either a leap day or a day-of-month value that exceeds the number of days in the current month. -- Cyrus Daboo From nobody Wed Feb 4 07:13:09 2015 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 9FCE41A8A7B for ; Wed, 4 Feb 2015 07:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, 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 RkNgmOV8xUQU for ; Wed, 4 Feb 2015 07:12:51 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503321A8A7D for ; Wed, 4 Feb 2015 07:12:25 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id l15so4337927wiw.0 for ; Wed, 04 Feb 2015 07:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:message-id; bh=CeTLp530PlUxj0CE6sj/ZvUznfW0+orx/eIou6sCuyU=; b=gYnZfTFWGLCcACcmWHiWDdTho69yEUN2AybmCHNgrcA8wDUg+hec2rHSJh5Zs6IpFd hqjPkXDuwT/t5v33/Y7AFdRP7lI8w5U9LzdhW3XcsX8ozjfR15g60C9+tgaJFFLzGskD GwNuDOEwraInfTxTNuCrOSSI2QcBbwCFs1u9IrRQO0EOE/TBkiDAkpDQjPu+5gWG7k8W 5CBiMMxmnh5Uq7nq6W7BG4xxtzUXO/MKFpEb5A4WKgK0gCP8mB29msuNP448s0tQFtRG glLZvKSSgO5ot+Kec8vNyk87zZCyrQGv0rCJ7zLVMV5/4lQmFZtuyQ9iixQtN00i4/Q8 W1aQ== X-Received: by 10.180.35.42 with SMTP id e10mr5339558wij.11.1423062744013; Wed, 04 Feb 2015 07:12:24 -0800 (PST) Received: from smtp.dmfs.org (p4FF0E020.dip0.t-ipconnect.de. [79.240.224.32]) by mx.google.com with ESMTPSA id li10sm3655733wic.10.2015.02.04.07.12.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Feb 2015 07:12:20 -0800 (PST) Sender: Marten Gajda Received: from [10.148.67.12] (unknown [89.204.138.12]) by smtp.dmfs.org (Postfix) with ESMTPSA id A0B05151; Wed, 4 Feb 2015 16:12:18 +0100 (CET) User-Agent: K-9 Mail for Android In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----33NGHRLFN800S6YUIGCN2QRSDIVHLZ" Content-Transfer-Encoding: 8bit From: Marten Gajda Date: Wed, 04 Feb 2015 16:12:15 +0100 To: Cyrus Daboo , Ken Murchison , calsify@ietf.org Message-ID: <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 04 Feb 2015 15:12:54 -0000 ------33NGHRLFN800S6YUIGCN2QRSDIVHLZ Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Oh, interesting. One more reason to make SKIP=OMIT the default, IMHO. Am 4. Februar 2015 15:49:07 MEZ, schrieb Cyrus Daboo : >Hi Ken, > >--On February 4, 2015 at 9:34:19 AM -0500 Ken Murchison > wrote: > >>> +1 for Ken's proposal. >>> >>> I couldn't find it in the latest draft (maybe I just didn't look >close >>> enough), but I think it should be pointed out that in this context >>> "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't >>> apply to Feb 30 or similar dates. >> >> Actually, for Feb 30, SKIP=FORWARD should yield Mar 1, which is why >the >> draft say "invalid day". >> >> Same for April 31. > >Yes, I think an "invalid" day means either a leap day or a day-of-month > >value that exceeds the number of days in the current month. > >-- >Cyrus Daboo -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------33NGHRLFN800S6YUIGCN2QRSDIVHLZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Oh, interesting. One more reason to make SKIP=OMIT the default, IMHO.


Am 4. Februar 2015 15:49:07 MEZ, schrieb Cyrus Daboo <cyrus@daboo.name>:
Hi Ken,

--On February 4, 2015 at 9:34:19 AM -0500 Ken Murchison 
<murch@andrew.cmu.edu> wrote:

 +1 for Ken's proposal.

 I couldn't find it in the latest draft (maybe I just didn't look close
 enough), but I think it should be pointed out that in this context
 "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't
 apply to Feb 30 or similar dates.

 Actually, for Feb 30, SKIP=FORWARD should yield Mar 1, which is why the
 draft say "invalid day".

 Same for April 31.

Yes, I think an "invalid" day means either a leap day or a day-of-month 
value that exceeds the number of days in the current
month.

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------33NGHRLFN800S6YUIGCN2QRSDIVHLZ-- From nobody Thu Feb 5 02:47:44 2015 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 BC6C11A010F for ; Thu, 5 Feb 2015 02:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.112 X-Spam-Level: *** X-Spam-Status: No, score=3.112 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WTorIvJbSazd for ; Thu, 5 Feb 2015 02:47:40 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CFB1A1AD3 for ; Thu, 5 Feb 2015 02:47:39 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id a141so5867274oig.6 for ; Thu, 05 Feb 2015 02:47:39 -0800 (PST) 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=IGqfb8q+wn2R02vkprzS1TCwqNoOWPV6k2K3wywKRxQ=; b=DvfCkpQkC/fTENjoJU3NAxTZEKvwwWzwDNY0bWRNAKVCjUrwsjrIur924gSPKc1GmU 6yjG2IgF3QWploUTyGDPg/L4HhnTrQ/wf4O4QPnLL4+mJ4Fm8hSRWAO6bs56km0/ba4f 50YEr1i+/PExiywrf5EXVzHOZZizKM4e+6N5Y8kHaXTQWjLBEVQn0Ky88H5AzwnMJ6Lf F0+zu95fEwB5y8BrNtYSprn9edVva206CD8pL+QlhwX/3nlzN9OLQUxGYhrcZUm97UC9 ztBRMTVyYMhBY3/fIwxWTOI8/886Zh0Eugve26QvWzFdMcupe+v8JHdavzh8SnIThRRo ZTAg== 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=IGqfb8q+wn2R02vkprzS1TCwqNoOWPV6k2K3wywKRxQ=; b=FvV3S/f1Ru5dGuJcvrlDuFXeJaRVAmcy+4sf/Luaw+ylmmLwZeTRAXY5iIFEtelhZx tjsRrXo/WvndsKySJWcYfFNnKyNjyDPd3cKQqTNi1G8UQ16oV4KM/cfKP7+8Wh1AfoWf 7FN2AzRV4L6A32RIasR/TZxiMKOFSPMvcKL+oIUaXdh2O+efcO67+DjcBvAj1H4MTSKJ TufYpdqWhiNfjzLTirgUsTV6d55WUcudG61Y2DOt9lM1Rvt8K/EA+OFA3wVMSaFkjC2z ZXgqHvzmupaV2CDeVQELLbzSFh9PyLvcm5sX5jZz3LpohVQQUs9Xexy2hsUNZSSDiOcr ktuQ== X-Gm-Message-State: ALoCoQmwbfZF8t/gN5WPirVYTEQ886pucJDnprEsysb0/wfrxO8ecWfc52PaVxNpzEwLNlATvaE6 X-Received: by 10.60.40.7 with SMTP id t7mr1987567oek.2.1423133258982; Thu, 05 Feb 2015 02:47:38 -0800 (PST) MIME-Version: 1.0 References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> From: Gregory Yakushev Date: Thu, 05 Feb 2015 10:47:37 +0000 Message-ID: To: Marten Gajda , Cyrus Daboo , Ken Murchison , calsify@ietf.org Content-Type: multipart/mixed; boundary=089e013cbea45ee766050e55084b Archived-At: Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 10:47:41 -0000 --089e013cbea45ee766050e55084b Content-Type: multipart/alternative; boundary=089e013cbea45ee760050e550849 --089e013cbea45ee760050e550849 Content-Type: text/plain; charset=UTF-8 Funny enough, my understanding of RRULE parsing was incorrect and I made some mistakes with my implementation, because it already follows what Ken suggested. I added all four of the rules from his e-mail (and their expansions) to my rscale_golden.txt (attached) and it passes without any changes. I have no objections to clarifying text about the order of SKIP processing. As mentioned in another thread, I'd prefer to have SKIP=BACKWARD as default to reduce the total amount of text in RRULEs (that is, sum of all RRULEs stored in the world). Length of RRULEs matter from both performance and readability point of view. But SKIP=OMIT is an acceptable compromise if consensus points in this direction. Grisha On Wed Feb 04 2015 at 4:13:01 PM Marten Gajda wrote: > Oh, interesting. One more reason to make SKIP=OMIT the default, IMHO. > > > Am 4. Februar 2015 15:49:07 MEZ, schrieb Cyrus Daboo : > >> Hi Ken, >> >> --On February 4, 2015 at 9:34:19 AM -0500 Ken Murchison >> wrote: >> >> +1 for Ken's proposal. >>>> >>>> I couldn't find it in the latest draft (maybe I just didn't look close >>>> enough), but I think it should be pointed out that in this context >>>> "invalid day" refers to leap days only. I.e. SKIP=FORWARD doesn't >>>> apply to Feb 30 or similar dates. >>>> >>> >>> Actually, for Feb 30, SKIP=FORWARD should yield Mar 1, which is why the >>> draft say "invalid day". >>> >>> Same for April 31. >>> >> >> Yes, I think an "invalid" day means either a leap day or a day-of-month >> value that exceeds the number of days in the current >> month. >> >> > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --089e013cbea45ee760050e550849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Funny enough, my understanding of RRULE parsing was incorr= ect and I made some mistakes with my implementation, because it already fol= lows what Ken suggested. I added all four of the rules from his e-mail (and= their expansions) to my rscale_golden.txt (attached) and it passes without= any changes. I have no objections to clarifying text about the order of SK= IP processing.

As mentioned in another thread, I'd prefer to hav= e SKIP=3DBACKWARD as default to reduce the total amount of text in RRULEs (= that is, sum of all RRULEs stored in the world). Length of RRULEs matter fr= om both performance and readability point of view. But SKIP=3DOMIT is an ac= ceptable compromise if consensus points in this direction.

Grisha

On Wed Feb 04 2015 at 4:= 13:01 PM Marten Gajda <marten@dmfs.or= g> wrote:
Oh, interesting. On= e more reason to make SKIP=3DOMIT the default, IMHO.


Am 4. Februar 2015 15:49:07 MEZ, schrieb= Cyrus Daboo <cyru= s@daboo.name>:
Hi Ken,

--On February 4, 2015 at 9:34:19 AM -0500 Ken Murchison=
 
<murch@an=
drew.cmu.edu> wrote:

 +1 for Ken's proposal.
<=
br> I couldn't find it in the latest draft (maybe I just didn't loo=
k close
 enough), but I think it should be pointed out that in this cont=
ext
 "invalid day" refers to leap days only. I.e. SKIP=3DFORWA=
RD doesn't
 apply to Feb 30 or similar dates.

 A=
ctually, for Feb 30, SKIP=3DFORWARD should yield Mar 1, which is why the draft say "invalid day".

 Same for April 31.

Yes, I think an "invalid" day means either a leap day or=
 a day-of-month 
value that exceeds the number of days in the current
month.

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet= .
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--089e013cbea45ee760050e550849-- --089e013cbea45ee766050e55084b Content-Type: text/plain; charset=US-ASCII; name="rscale_golden.txt" Content-Disposition: attachment; filename="rscale_golden.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 14b59590d5240ef4a92 IyBUaGlzIGlzIGEgZ29sZGVuIHNldCBvZiBSUlVMRSBleHBhbnNpb25zIHVzZWQgdG8gc3luY2hy b25pemUgdmFyaW91cyBpbXBsZW1lbnRhdGlvbnMuCiMgVGhlc2UgcnVsZXMgYXJlIGJhc2VkIG9u IFJGQyA1NTQ1IGFuZCBkcmFmdC1kYWJvby1pY2FsZW5kYXItcnNjYWxlLTA0LgojCiMgSXQgY29u c2lzdHMgb2YgMy1saW5lIGJsb2NrcyBsaWtlIHRoaXM6CiMgICBSUlVMRTpGUkVRPURBSUxZO0NP VU5UPTMKIyAgIERUU1RBUlQ6MjAxNDA1MzAKIyAgIElOU1RBTkNFUzoyMDE0MDUzMCwyMDE0MDUz MSwyMDE0MDYwMQojCiMgTEFTVC1NT0RJRklFRDoyMDE0MDYxOSAodXBkYXRlIEhlYnJldyBsZWFw IG1vbnRoIHRvIHJzY2FsZS0wNCBzcGVjaWZpY2F0aW9uKQoKUlJVTEU6UlNDQUxFPUVUSElPUElD O0ZSRVE9WUVBUkxZO0JZTU9OVEg9MTM7QllNT05USERBWT0tMTtDT1VOVD02CkRUU1RBUlQ6MjAx NDA5MTAKSU5TVEFOQ0VTOjIwMTQwOTEwLDIwMTUwOTExLDIwMTYwOTEwLDIwMTcwOTEwLDIwMTgw OTEwLDIwMTkwOTExCgojIENoaW5lc2UgTmV3IFllYXIKUlJVTEU6UlNDQUxFPUNISU5FU0U7RlJF UT1ZRUFSTFk7VU5USUw9MjAxODAxMDEKRFRTVEFSVDoyMDEzMDIxMApJTlNUQU5DRVM6MjAxMzAy MTAsMjAxNDAxMzEsMjAxNTAyMTksMjAxNjAyMDgsMjAxNzAxMjgKClJSVUxFOlJTQ0FMRT1DSElO RVNFO0ZSRVE9TU9OVEhMWTtDT1VOVD00CkRUU1RBUlQ6MjAxNDA5MjAKSU5TVEFOQ0VTOjIwMTQw OTIwLDIwMTQxMDIwLDIwMTQxMTE5LDIwMTQxMjE4CgpSUlVMRTpSU0NBTEU9SVNMQU1JQy1DSVZJ TDtGUkVRPU1PTlRITFk7Q09VTlQ9NApEVFNUQVJUOjIwMTMxMDI1CklOU1RBTkNFUzoyMDEzMTAy NSwyMDEzMTEyNCwyMDEzMTIyNCwyMDE0MDEyMgoKIyBSYW1hZGFuIChhbHRob3VnaCBub2JvZHkg Y2VsZWJyYXRlcyBpdCB3aXRoIGEgcHJlZGljdGFibGUgY2l2aWwgY2FsZW5kYXIpClJSVUxFOlJT Q0FMRT1JU0xBTUlDLUNJVklMO0ZSRVE9WUVBUkxZO0JZTU9OVEg9OTtDT1VOVD01CkRUU1RBUlQ6 MjAxMzA3MDkKSU5TVEFOQ0VTOjIwMTMwNzA5LDIwMTQwNjI5LDIwMTUwNjE4LDIwMTYwNjA3LDIw MTcwNTI3CgojIEJ1ZGRoYSBiaXJ0aGRheSBpbiBLb3JlYW4gY2FsZW5kYXIKUlJVTEU6UlNDQUxF PURBTkdJO0ZSRVE9REFJTFk7QllNT05USERBWT04O0JZTU9OVEg9NDtVTlRJTD0yMDE2MDEwMQpE VFNUQVJUOjIwMTMxMDI1CklOU1RBTkNFUzoyMDE0MDUwNiwyMDE1MDUyNQoKIyBObyBpbnN0YW5j ZXMgaW4gQ2hpbmVzZSBsZWFwIG1vbnRoClJSVUxFOlJTQ0FMRT1DSElORVNFO0ZSRVE9REFJTFk7 QllNT05USERBWT0xMDtCWU1PTlRIPTk7Q09VTlQ9MwpEVFNUQVJUOjIwMTMxMDI1CklOU1RBTkNF UzoyMDE0MTAwMywyMDE1MTAyMiwyMDE2MTAxMAoKUlJVTEU6UlNDQUxFPUNISU5FU0U7RlJFUT1E QUlMWTtCWU1PTlRIREFZPTEwO0JZTU9OVEg9OUw7U0tJUD1ZRVM7Q09VTlQ9MgpEVFNUQVJUOjIw MTMxMDI1CklOU1RBTkNFUzoyMDE0MTEwMiwyMTA5MTEwMgoKUlJVTEU6RlJFUT1EQUlMWTtSU0NB TEU9Q0hJTkVTRTtTS0lQPVlFUztVTlRJTD0yMTAwMDEwMTtCWU1PTlRIREFZPTEwO0JZTU9OVEg9 NEwKRFRTVEFSVDoyMDEzMTAyNQpJTlNUQU5DRVM6MjAyMDA2MDEsMjA1ODA1MzEsMjA2OTA1MzAs MjA3NzA1MzEsMjA4ODA1MzAsMjA5NjA1MzEKClJSVUxFOlJTQ0FMRT1DSElORVNFO0ZSRVE9REFJ TFk7QllNT05USERBWT0xMDtCWU1PTlRIPTlMO0NPVU5UPTMKRFRTVEFSVDoyMDEzMTAyNQpJTlNU QU5DRVM6MjAxNDExMDIsMjAxNTEwMjIsMjAxNjEwMTAKClJSVUxFOlJTQ0FMRT1DSElORVNFO0ZS RVE9REFJTFk7QllNT05USERBWT0xMDtCWU1PTlRIPTksOUw7Q09VTlQ9NApEVFNUQVJUOjIwMTMx MDI1CklOU1RBTkNFUzoyMDE0MTAwMywyMDE0MTEwMiwyMDE1MTAyMiwyMDE2MTAxMAoKUlJVTEU6 UlNDQUxFPUhFQlJFVztGUkVRPVlFQVJMWTtTS0lQPVlFUztDT1VOVD00CkRUU1RBUlQ6MjAxNDAy MDUKSU5TVEFOQ0VTOjIwMTQwMjA1LDIwMTYwMjE0LDIwMTkwMjEwLDIwMjIwMjA2CgpSUlVMRTpS U0NBTEU9SEVCUkVXO0ZSRVE9WUVBUkxZO1NLSVA9Rk9SV0FSRDtDT1VOVD00CkRUU1RBUlQ6MjAx NDAyMDUKSU5TVEFOQ0VTOjIwMTQwMjA1LDIwMTUwMjI0LDIwMTYwMjE0LDIwMTcwMzAzCgpSUlVM RTpSU0NBTEU9SEVCUkVXO0ZSRVE9WUVBUkxZO0JZTU9OVEg9NUw7QllNT05USERBWT04O1NLSVA9 Rk9SV0FSRDtDT1VOVD01CkRUU1RBUlQ6MjAxNDAyMDgKSU5TVEFOQ0VTOjIwMTQwMjA4LDIwMTUw MjI3LDIwMTYwMjE3LDIwMTcwMzA2LDIwMTgwMjIzCgpSUlVMRTpSU0NBTEU9R1JFR09SSUFOO0ZS RVE9TU9OVEhMWTtDT1VOVD00CkRUU1RBUlQ6MjAxNDAxMzEKSU5TVEFOQ0VTOjIwMTQwMTMxLDIw MTQwMjI4LDIwMTQwMzMxLDIwMTQwNDMwCgpSUlVMRTpSU0NBTEU9R1JFR09SSUFOO0ZSRVE9TU9O VEhMWTtTS0lQPUZPUldBUkQ7Q09VTlQ9NApEVFNUQVJUOjIwMTQwMTMxCklOU1RBTkNFUzoyMDE0 MDEzMSwyMDE0MDMwMSwyMDE0MDMzMSwyMDE0MDUwMQoKUlJVTEU6UlNDQUxFPUdSRUdPUklBTjtG UkVRPVlFQVJMWTtCWU1PTlRIPTI7QllNT05USERBWT0yOCwyOTtTS0lQPUZPUldBUkQ7Q09VTlQ9 NQpEVFNUQVJUOjIwMTUwMjAxCklOU1RBTkNFUzoyMDE1MDIyOCwyMDE1MDMwMSwyMDE2MDIyOCwy MDE2MDIyOSwyMDE3MDIyOAoKUlJVTEU6UlNDQUxFPUdSRUdPUklBTjtGUkVRPU1PTlRITFk7SU5U RVJWQUw9MztTS0lQPUZPUldBUkQ7Q09VTlQ9NApEVFNUQVJUOjIwMTQwMTMxCklOU1RBTkNFUzoy MDE0MDEzMSwyMDE0MDUwMSwyMDE0MDczMSwyMDE0MTAzMQoKUlJVTEU6RlJFUT1NT05USExZO1JT Q0FMRT1HUkVHT1JJQU47U0tJUD1GT1JXQVJEO0NPVU5UPTEyO0JZTU9OVEhEQVk9MzEKRFRTVEFS VDoyMDE1MDEzMQpJTlNUQU5DRVM6MjAxNTAxMzEsMjAxNTAzMDEsMjAxNTAzMzEsMjAxNTA1MDEs MjAxNTA1MzEsMjAxNTA3MDEsMjAxNTA3MzEsMjAxNTA4MzEsMjAxNTEwMDEsMjAxNTEwMzEsMjAx NTEyMDEsMjAxNTEyMzEKClJSVUxFOkZSRVE9TU9OVEhMWTtSU0NBTEU9R1JFR09SSUFOO1NLSVA9 Rk9SV0FSRDtDT1VOVD0xMjtCWU1PTlRIREFZPS0xCkRUU1RBUlQ6MjAxNTAxMzEKSU5TVEFOQ0VT OjIwMTUwMTMxLDIwMTUwMjI4LDIwMTUwMzMxLDIwMTUwNDMwLDIwMTUwNTMxLDIwMTUwNjMwLDIw MTUwNzMxLDIwMTUwODMxLDIwMTUwOTMwLDIwMTUxMDMxLDIwMTUxMTMwLDIwMTUxMjMxCgpSUlVM RTpGUkVRPVlFQVJMWTtSU0NBTEU9SEVCUkVXO1NLSVA9Rk9SV0FSRDtDT1VOVD01O0JZTU9OVEhE QVk9MzA7QllNT05USD01TApEVFNUQVJUOjIwMTQwMzAyCklOU1RBTkNFUzoyMDE0MDMwMiwyMDE1 MDMyMSwyMDE2MDMxMCwyMDE3MDMyOCwyMDE4MDMxNwoKUlJVTEU6RlJFUT1ZRUFSTFk7UlNDQUxF PUhFQlJFVztTS0lQPUZPUldBUkQ7Q09VTlQ9NTtCWU1PTlRIREFZPS0xO0JZTU9OVEg9NUwKRFRT VEFSVDoyMDE0MDMwMgpJTlNUQU5DRVM6MjAxNDAzMDIsMjAxNTAzMjAsMjAxNjAzMTAsMjAxNzAz MjcsMjAxODAzMTY= --089e013cbea45ee766050e55084b-- From nobody Thu Feb 5 07:49:50 2015 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 A79D01A8843 for ; Thu, 5 Feb 2015 07:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, 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 nCGbEHmls3Xt for ; Thu, 5 Feb 2015 07:49:40 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804B11A00E2 for ; Thu, 5 Feb 2015 07:49:40 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id h3so821222qgf.4 for ; Thu, 05 Feb 2015 07:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8mOK2X70qURUFvpWyybOgUv7Y/P0mTUF/dihYEBRWlc=; b=P2a3Ojcyslw/3fO94Hk2Oom61C0P/iToT1TQ5uMFTNC2m10XmUkXeN5awufzMimu84 hxuGLNP4yIO/LH0p173wv6G6rnCWDL55lnrBrjmTSlf0Z9jnRYUg9FxCrKmEFaG7M3vH lSX8wOMVnichndxzISejrKAk7Hzq6NO9aYYFFU52FiPA4gJHfJgA2HUa2JMpdAf5/98e o2n3UQcvEmigyB/h+spbTKg+O7bmGyYfIEmr7HzYNLLagLcE0aDdF5P2G9xtpGIbaIKP HpeLj/fgU2T2hEJgEu9AOToixQG6CwN9n/FB7m3urQY3iLh8WR4mURMPdLbKMHslI3oM LNCg== MIME-Version: 1.0 X-Received: by 10.140.19.78 with SMTP id 72mr9176689qgg.37.1423151379718; Thu, 05 Feb 2015 07:49:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.163 with HTTP; Thu, 5 Feb 2015 07:49:39 -0800 (PST) In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> Date: Thu, 5 Feb 2015 10:49:39 -0500 X-Google-Sender-Auth: 1mq0ME_f5Qjd79j6MAPG68Q0B8Q Message-ID: From: Barry Leiba To: Gregory Yakushev Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 15:49:42 -0000 > As mentioned in another thread, I'd prefer to have SKIP=BACKWARD as default > to reduce the total amount of text in RRULEs (that is, sum of all RRULEs > stored in the world). Length of RRULEs matter from both performance and > readability point of view. But SKIP=OMIT is an acceptable compromise if > consensus points in this direction. And yet I'm still concerned that trying to define SKIP rules outside the context of implementation of a specific calendar is complex and error prone. It remains my contention that the best thing to do (which also keeps the rules short) is to say that how RRULEs that contain RSCALE work without SKIP is dependent upon the calendar specified in RRULE, and that when you implement a particular calendar, you have to know how that calendar works and support it properly. Then we reserve SKIP for exception situations. I do NOT think that we need to accompany this with any list of calendars. Whoever implements a particular calendar needs to know how it works in order to generate the right SKIP values anyway. So why not just say that, and forget about having to include the SKIPs? Barry From nobody Thu Feb 5 08:09:43 2015 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 060081A87A9 for ; Thu, 5 Feb 2015 08:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 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, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 85qoxW4GdB8a for ; Thu, 5 Feb 2015 08:09:31 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE461A88E3 for ; Thu, 5 Feb 2015 08:09:30 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id k15so6464577qaq.9 for ; Thu, 05 Feb 2015 08:09:30 -0800 (PST) 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:cc :content-type; bh=oxp7SKFxA998Zdna6svSOs3dCZzjaKjlyKJzWSwT7W0=; b=chflHPHJAfTrVitVSpEiuIXHt5LPhCtsAHuKC6yddrxHWpCtyjqDAeQdEwttDyuEDW 4if4HpSYcG013TaSWacuLppkslE4+8d5ujktpgSoZNKOIJKsFU2ujIUix0IQxxlEJkMP WLMvwLr7vplHlnA6D4jXcH6ggyLL5CpXdNorPQGbqkBUs0ETjt/+AqKAVWfQHMkgREit 8zFJLy7SJKhrMe4qQAo1GLu9fJUXiM/+MBcB2BmUwk080mEtxXrBurSI7C6VNpFlROB2 7RNE3NxN8SJDkDsZnwWYFQY7ASz71U1HKIeCjwgcX62hja79YVc+t8+RZgFFsoi2tiHQ 103A== 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:cc:content-type; bh=oxp7SKFxA998Zdna6svSOs3dCZzjaKjlyKJzWSwT7W0=; b=WJ9KcdsUa9u4O1DxZOutFD5x0mCfZD6rIQZFEZtz/eDNlCMhjPq3QAweYZ0DMSBzk1 OT70dKfwDZOLFV3M3WcCqXOS2LuLkPHO1DcRCICczjYIMy+reHnmPBsQZd+O5Q3M9jpm xzawLwcIHNjn2SoRnC5c0BU+ovCoidoodql9eFT6+/7aStnTjdBmBRhIK3DksrpA7MVm 2RKcFGb8T5hDnBYdkZEekHuRQZUFr5lFo0HOJmuuKx8g+1i4RjRTCC4Npyw1c78CpncB ghCxeNxagbHL/h7vJcg1ddnMvyuXOOPJSNLKIrwBMsr31L1mWjP0WlD7piqYgi1vkzpB b4NQ== X-Gm-Message-State: ALoCoQno80wMxvZ7OPuKRIni+4ciok1rkEbg0XrOhm778ORAFrDFcFeEP0mJ83LM6UuXuVP0gT9R X-Received: by 10.224.5.131 with SMTP id 3mr9961503qav.36.1423152569997; Thu, 05 Feb 2015 08:09:29 -0800 (PST) MIME-Version: 1.0 References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> From: Gregory Yakushev Date: Thu, 05 Feb 2015 16:09:29 +0000 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b6249fc657f68050e5987c3 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:09:33 -0000 --047d7b6249fc657f68050e5987c3 Content-Type: text/plain; charset=UTF-8 On Thu Feb 05 2015 at 4:49:39 PM Barry Leiba wrote: > > As mentioned in another thread, I'd prefer to have SKIP=BACKWARD as > default > > to reduce the total amount of text in RRULEs (that is, sum of all RRULEs > > stored in the world). Length of RRULEs matter from both performance and > > readability point of view. But SKIP=OMIT is an acceptable compromise if > > consensus points in this direction. > > And yet I'm still concerned that trying to define SKIP rules outside > the context of implementation of a specific calendar is complex and > error prone. It remains my contention that the best thing to do > (which also keeps the rules short) is to say that how RRULEs that > contain RSCALE work without SKIP is dependent upon the calendar > specified in RRULE, and that when you implement a particular calendar, > you have to know how that calendar works and support it properly. > Then we reserve SKIP for exception situations. > > I do NOT think that we need to accompany this with any list of > calendars. Whoever implements a particular calendar needs to know how > it works in order to generate the right SKIP values anyway. So why > not just say that, and forget about having to include the SKIPs? > Because there should be an agreement between all implementation on what SKIP default is applied to a given Calendar. Say, we agree here that SKIP should default to BACKWARD for all calendars except HEBREW, for which it should default to FORWARD. This information needs to be written somewhere and set in stone, so that all implementation apply correct default when expanding RRULEs. Otherwise an implementor without deep knowledge of a particular calendar (its not required if he bases his implementation on ICU for example), can apply a different default. I don't see how can we do without a registry for variable defaults, if we choose this option. > Barry > Grisha --047d7b6249fc657f68050e5987c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu Feb 05 2015 at 4= :49:39 PM Barry Leiba <barryl= eiba@computer.org> wrote:
> As = mentioned in another thread, I'd prefer to have SKIP=3DBACKWARD as defa= ult
> to reduce the total amount of text in RRULEs (that is, sum of all RRUL= Es
> stored in the world). Length of RRULEs matter from both performance an= d
> readability point of view. But SKIP=3DOMIT is an acceptable compromise= if
> consensus points in this direction.

And yet I'm still concerned that trying to define SKIP rules outside the context of implementation of a specific calendar is complex and
error prone.=C2=A0 It remains my contention that the best thing to do
(which also keeps the rules short) is to say that how RRULEs that
contain RSCALE work without SKIP is dependent upon the calendar
specified in RRULE, and that when you implement a particular calendar,
you have to know how that calendar works and support it properly.
Then we reserve SKIP for exception situations.

I do NOT think that we need to accompany this with any list of
calendars.=C2=A0 Whoever implements a particular calendar needs to know how=
it works in order to generate the right SKIP values anyway.=C2=A0 So why not just say that, and forget about having to include the SKIPs?

Because there should be an agreement between all = implementation on what SKIP=C2=A0default=C2=A0is appl= ied to a given Calendar. Say, we agree here that SKIP should default to BAC= KWARD for all calendars except HEBREW, for which it should default to FORWA= RD. This information needs to be written somewhere and set in stone, so tha= t all implementation apply correct default when expanding RRULEs.=C2=A0

Otherwise an implementor without deep knowledg= e of a particular calendar (its not required if he bases his implementation= on ICU for example), can apply a different default. I don't see how ca= n we do without a registry for variable defaults, if we choose this option.=


Barry

Grisha=C2=A0
--047d7b6249fc657f68050e5987c3-- From nobody Thu Feb 5 08:13:33 2015 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 9E32D1A8953 for ; Thu, 5 Feb 2015 08:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 4gzHSU4Dhd-r for ; Thu, 5 Feb 2015 08:13:29 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507011A88E2 for ; Thu, 5 Feb 2015 08:13:29 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so8862271lbj.0 for ; Thu, 05 Feb 2015 08:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U3V6F2KWX1YZl9Mbi6PPpEA3Jru2lpgYneiAIis3Rik=; b=e9AaMoQzu+qzwsHKRXG77Et++Y9ri9aha43I6e/CZ5NA0ygnjgE0yn8ZsLbQpAWwED 73UQ+kFyAUqa3z8TehJzJxyiTzFMvfm3FpTOqNSHj+iJL/aCkuyCVmMxaxAlZW2QQxIg QZij+30h912cCVggcH2WxZHCgbjffY8kU1mMlPZE1pPGHs6OlphpCEdLw4TJS7gwTCDt grpCHrJ+G8/5xmVYtdqTDGaMgn+05H+Mxqg2JFuYex+Vqt0VKjA7SF6fqad/GAKh+Dwa 7168aevs3EnIk0jaiN8Ji7yoXCgOuLG/8XdUwecPbEK9t0BNNRr/4i7iFsdVy2a707BD 3tdA== MIME-Version: 1.0 X-Received: by 10.152.37.138 with SMTP id y10mr4450377laj.88.1423152807764; Thu, 05 Feb 2015 08:13:27 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.225 with HTTP; Thu, 5 Feb 2015 08:13:27 -0800 (PST) In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> Date: Thu, 5 Feb 2015 11:13:27 -0500 X-Google-Sender-Auth: aqpooCXj4zWbdOJusb-Q9sorZjQ Message-ID: From: Barry Leiba To: Gregory Yakushev Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:13:30 -0000 >> I do NOT think that we need to accompany this with any list of >> calendars. Whoever implements a particular calendar needs to know how >> it works in order to generate the right SKIP values anyway. So why >> not just say that, and forget about having to include the SKIPs? > > Because there should be an agreement between all implementation on what SKIP > default is applied to a given Calendar. Say, we agree here that SKIP should > default to BACKWARD for all calendars except HEBREW, for which it should > default to FORWARD. This information needs to be written somewhere and set > in stone, so that all implementation apply correct default when expanding > RRULEs. No, the point isn't that we should agree that SKIP defaults to BACKWARD or FORWARD or BANANA, except for anything. We should agree that the way each calendar behaves in this regard is specific to each calendar, and implementors of a particular calendar need to understand how that calendar works and implement it right. > Otherwise an implementor without deep knowledge of a particular calendar > (its not required if he bases his implementation on ICU for example), can > apply a different default. I don't see how can we do without a registry for > variable defaults, if we choose this option. We do this sort of thing all the time, and it works. Do we get bad implementations sometimes, because someone gets it wrong? Sure. Those usually get fixed. I think that situation is *far* better than having skip rules (perhaps wrong ones, created by the same buggy implementations) imbedded in the iCalendar entries. Barry From nobody Thu Feb 5 08:17:16 2015 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 0F52F1A89B8 for ; Thu, 5 Feb 2015 08:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 0msFTX_ZCwiR for ; Thu, 5 Feb 2015 08:17:11 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E251A8953 for ; Thu, 5 Feb 2015 08:16:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AB4F0AF59F3; Thu, 5 Feb 2015 11:16:41 -0500 (EST) 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 UNAV1pDcB9hZ; Thu, 5 Feb 2015 11:16:41 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 25778AF59E1; Thu, 5 Feb 2015 11:16:37 -0500 (EST) Date: Thu, 05 Feb 2015 11:16:30 -0500 From: Cyrus Daboo To: Barry Leiba , Gregory Yakushev Message-ID: <3BE1022E17B492A5A2887683@caldav.corp.apple.com> In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> 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=1589 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:17:15 -0000 Hi Barry, --On February 5, 2015 at 10:49:39 AM -0500 Barry Leiba wrote: > And yet I'm still concerned that trying to define SKIP rules outside > the context of implementation of a specific calendar is complex and > error prone. It remains my contention that the best thing to do > (which also keeps the rules short) is to say that how RRULEs that > contain RSCALE work without SKIP is dependent upon the calendar > specified in RRULE, and that when you implement a particular calendar, > you have to know how that calendar works and support it properly. > Then we reserve SKIP for exception situations. > > I do NOT think that we need to accompany this with any list of > calendars. Whoever implements a particular calendar needs to know how > it works in order to generate the right SKIP values anyway. So why > not just say that, and forget about having to include the SKIPs? I am not convinced that there is one convention per calendar system that is consistently used. In discussions I have had with others I got the impression that the skip mode was dependent on other factors - e.g. the nature of the event. For example the convention for personal anniversaries may be different than that for "legal" ones. Previously I cited the Gregorian example of someone born on a leap day who prefers to celebrate on the 28th, but legally is not considered to be "of age" until the 1st. The bottom line is conventions for one calendar system can vary from locale to locale and it would be very hard for us to define the basis for that. -- Cyrus Daboo From nobody Thu Feb 5 08:19:46 2015 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 0F7C21A88DD for ; Thu, 5 Feb 2015 08:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 b03aD0bKFC_G for ; Thu, 5 Feb 2015 08:19:43 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721101A88CF for ; Thu, 5 Feb 2015 08:19:43 -0800 (PST) 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.8/8.14.8) with ESMTP id t15GJc2V022081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Feb 2015 11:19:38 -0500 Message-ID: <54D3981A.8060007@andrew.cmu.edu> Date: Thu, 05 Feb 2015 11:19:38 -0500 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: Barry Leiba , Gregory Yakushev References: <68FCD7D11F934509267D5915@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> In-Reply-To: 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: 2015.2.5.161218 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 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, REFERENCES 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, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.203 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:19:45 -0000 On 02/05/2015 11:13 AM, Barry Leiba wrote: >>> I do NOT think that we need to accompany this with any list of >>> calendars. Whoever implements a particular calendar needs to know how >>> it works in order to generate the right SKIP values anyway. So why >>> not just say that, and forget about having to include the SKIPs? >> Because there should be an agreement between all implementation on what SKIP >> default is applied to a given Calendar. Say, we agree here that SKIP should >> default to BACKWARD for all calendars except HEBREW, for which it should >> default to FORWARD. This information needs to be written somewhere and set >> in stone, so that all implementation apply correct default when expanding >> RRULEs. > No, the point isn't that we should agree that SKIP defaults to > BACKWARD or FORWARD or BANANA, except for anything. We should agree > that the way each calendar behaves in this regard is specific to each > calendar, and implementors of a particular calendar need to understand > how that calendar works and implement it right. > >> Otherwise an implementor without deep knowledge of a particular calendar >> (its not required if he bases his implementation on ICU for example), can >> apply a different default. I don't see how can we do without a registry for >> variable defaults, if we choose this option. > We do this sort of thing all the time, and it works. Do we get bad > implementations sometimes, because someone gets it wrong? Sure. > Those usually get fixed. I think that situation is *far* better than > having skip rules (perhaps wrong ones, created by the same buggy > implementations) imbedded in the iCalendar entries. FWIW, the ICU library, which I assume most implementations will use, seems to always skip forward to the next valid date if/when you try to set an invalid one, regardless of calendar. So, If I try to set Feb 29 in a non-leap year it gives me Mar 1. If I try to set 30 Adar I in a non-leap year it gives me 1 Nisan. I could try some more examples using Chinese leap months and Ethiopic leap day. AFAICT, it never skips backwards on its own, I have to do that one layer up. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Thu Feb 5 08:23:22 2015 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 D16AD1A8937 for ; Thu, 5 Feb 2015 08:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 uzpkloDcNWMT for ; Thu, 5 Feb 2015 08:23:20 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6876B1A88A6 for ; Thu, 5 Feb 2015 08:23:20 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so8984332lbv.3 for ; Thu, 05 Feb 2015 08:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4Vi5DPz+DZT0XFqJZ5aq8mWS4NTvGIhZaGL/KTsyBgg=; b=RJuIJ0eEpXNr9/iAm5DmhqwTEMabEtQYTZGzSS/eNWAea7M0cVqCQWMq9PpIFmngiq 5GF/k98fAqItOZqj9wlVbG/EIyfswIjglwOmCUCqhpqVQDO/bWWhnYpB+IjgWDFe6hjB uvX6/43Nx9521Z86GqMn4Lkcs36TnRD1WNjjriu+ol00OoMfVtRDOIDN9CMdka+QuPVi N1W+j86st327ltT8MDO9OUwCZS2TNyy6Rjbq8E6iETFVrJrMgMT0bKcjDVAs3m+mpV5Y EJcOaotWUjJ5kiEqW18F3Hap0Qn4Omeso5a+93vGcmpliXA3jncH5UEHg40DXm5D3wsu SJ1w== MIME-Version: 1.0 X-Received: by 10.152.170.170 with SMTP id an10mr1118339lac.121.1423153398916; Thu, 05 Feb 2015 08:23:18 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.129.97 with HTTP; Thu, 5 Feb 2015 08:23:18 -0800 (PST) In-Reply-To: <3BE1022E17B492A5A2887683@caldav.corp.apple.com> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> <3BE1022E17B492A5A2887683@caldav.corp.apple.com> Date: Thu, 5 Feb 2015 11:23:18 -0500 X-Google-Sender-Auth: Hw4Jyu-ZmykbSIfs25DHrv2DBaE Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:23:22 -0000 >> I do NOT think that we need to accompany this with any list of >> calendars. Whoever implements a particular calendar needs to know how >> it works in order to generate the right SKIP values anyway. So why >> not just say that, and forget about having to include the SKIPs? > > I am not convinced that there is one convention per calendar system that is > consistently used. In discussions I have had with others I got the > impression that the skip mode was dependent on other factors - e.g. the > nature of the event. For example the convention for personal anniversaries > may be different than that for "legal" ones. Previously I cited the > Gregorian example of someone born on a leap day who prefers to celebrate on > the 28th, but legally is not considered to be "of age" until the 1st. > > The bottom line is conventions for one calendar system can vary from locale > to locale and it would be very hard for us to define the basis for that. Ack. But, then, I still don't see how using possibly complicated SKIP controls really works here. If I create a repeating entry, my calendar system tries to figure out what's what and sticks in some set of SKIPs. Maybe it gets them right, and maybe it doesn't. Whatever it does, those are now copied to every other calendar system that I give this vevent to. If it's wrong, it's wrong everywhere. If we rely on the calendar implementations to do the right thing with respect to the particular calendars, then one implementation's bugs don't spread. On the other hand, if "personal" and "legal" differ, we'd have to have some way to convey that this vevent is personal and that one is legal. Oy. I'm not worried about exceptions (personal preferences and the like, though I'm not sure how a calendar implementation would do a UI to let a user control that)... I'm worried about having most things get it right most of the time, and reserving explicit SKIP rules for the exceptions. I really don't see a way out here. b From nobody Thu Feb 5 08:25:47 2015 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 14F661A8937 for ; Thu, 5 Feb 2015 08:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qKtbe1KTvD4x for ; Thu, 5 Feb 2015 08:25:45 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69381A884B for ; Thu, 5 Feb 2015 08:25:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2DA3CAF5D67; Thu, 5 Feb 2015 11:25:45 -0500 (EST) 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 Puqsd4M5ykB8; Thu, 5 Feb 2015 11:25:44 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 99902AF5D5C; Thu, 5 Feb 2015 11:25:42 -0500 (EST) Date: Thu, 05 Feb 2015 11:25:36 -0500 From: Cyrus Daboo To: Ken Murchison , Barry Leiba , Gregory Yakushev Message-ID: <0DA3569C9120E7DAB36D5E94@caldav.corp.apple.com> In-Reply-To: <54D3981A.8060007@andrew.cmu.edu> References: <68FCD7D11F934509267D5915@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> <54D3981A.8060007@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=888 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:25:47 -0000 Hi Ken, --On February 5, 2015 at 11:19:38 AM -0500 Ken Murchison wrote: > FWIW, the ICU library, which I assume most implementations will use, > seems to always skip forward to the next valid date if/when you try to > set an invalid one, regardless of calendar. So, If I try to set Feb 29 > in a non-leap year it gives me Mar 1. If I try to set 30 Adar I in a > non-leap year it gives me 1 Nisan. I could try some more examples using > Chinese leap months and Ethiopic leap day. > > AFAICT, it never skips backwards on its own, I have to do that one layer > up. Right but ICU's approach is a purely "arithmetic" behavior where they just count the extra days and move forward that number. i.e., if you set the ICU date to 30th February in a non-leap year you would get March 2nd. However, our "logicial" skip behavior would give Match 1st. -- Cyrus Daboo From nobody Thu Feb 5 08:29:14 2015 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 2227E1A884B for ; Thu, 5 Feb 2015 08:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ybKqWsRO6IcZ for ; Thu, 5 Feb 2015 08:29:12 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291881A8761 for ; Thu, 5 Feb 2015 08:29:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 74B9EAF5EFD; Thu, 5 Feb 2015 11:29:11 -0500 (EST) 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 JiNuvYIcdqAL; Thu, 5 Feb 2015 11:29:11 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 2FE2CAF5EF0; Thu, 5 Feb 2015 11:29:09 -0500 (EST) Date: Thu, 05 Feb 2015 11:29:04 -0500 From: Cyrus Daboo To: Barry Leiba Message-ID: <9764350C69A3A90809A3CE05@caldav.corp.apple.com> In-Reply-To: References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> <3BE1022E17B492A5A2887683@caldav.corp.apple.com> 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=1254 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:29:13 -0000 Hi Barry, --On February 5, 2015 at 11:23:18 AM -0500 Barry Leiba wrote: > But, then, I still don't see how using possibly complicated SKIP > controls really works here. If I create a repeating entry, my > calendar system tries to figure out what's what and sticks in some set > of SKIPs. Maybe it gets them right, and maybe it doesn't. Whatever > it does, those are now copied to every other calendar system that I > give this vevent to. If it's wrong, it's wrong everywhere. > > If we rely on the calendar implementations to do the right thing with > respect to the particular calendars, then one implementation's bugs > don't spread. But provided the "buggy" data is represented consistently by all clients, users do have a reasonable chance of spotting the mistake and correcting it. On the other hand, if an event looks right on my mobile device, but is interpreted differently on my calendar-aware thermostat (or perhaps more seriously a medical device) I probably have no chance of spotting the error because the device might not expose its "internal" calendar view. So I would much rather the data be interpreted consistently across all devices even if its was not exactly what I wanted. -- Cyrus Daboo From nobody Thu Feb 5 08:31:18 2015 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 992671A89E0 for ; Thu, 5 Feb 2015 08:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DAJpMeGXjWQa for ; Thu, 5 Feb 2015 08:31:16 -0800 (PST) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D711A899F for ; Thu, 5 Feb 2015 08:31:16 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id s11so7215588qcv.5 for ; Thu, 05 Feb 2015 08:31:15 -0800 (PST) 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:cc :content-type; bh=JZuES48f3IwDUVIvcvhKawhH8IEWuDgRxOBEd0ttJr4=; b=V0kJihjyyzjICQf/Ud87T2+FnN9VkKQBvE6Fw51PPcNAIf/RqOqrK+SXt9JLLVpEle qavGvGnXPu2Vb08uYaOXLLxKzcdOh8vNRHcL/0rT/Ze4qiqVKNcqtgYuIHoFEQjMrk2U 5X0qxN74T8dqjfORbspDe2PsJRPzYstWY4RBjzk7qRazUTdjlqYL+LqIfvYdpevIc/A9 KfAO07LZrPTEI68E/tPcizprUxvNC8uX86ffjNbf6gpg69kVH15XVKPQcu1rgRSyNdUk ykFLuZtCQBh/gtMqfa9lxQ9J9apmeGI1Nv0AL9RfkCrAV8GbgUUIkGPzH7RLp5q4CMgn 5yLg== 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:cc:content-type; bh=JZuES48f3IwDUVIvcvhKawhH8IEWuDgRxOBEd0ttJr4=; b=kHmoBuhkYyYiaL6LhUYg795GZ+ZmWExCQYOZwXo5d3MIQ+zgvPmH9gTx/UFjib89M6 8QFyuYfcQI4uQFNQaL1c4vH4TfKUqCLeT1yydvUynxtiE5OhToQKwSk9Eho5mA0RhvlV TsnL91AzHbinnV66eH7vFDgmgnC5K5qKv4osAqovAYEOJKCbvWk1jd2rsOSRCQ/vLUuX wjuSQuxejErzmvKSk6eCrrLvZ5xtm2gydQWCCQeZO1KGz8GHZNvARF3u328OxHD1EKMo 6RYDRJP4gHgft9FjoWO1YvZoF5ywebWU7NSevLAimUBDsetFQ5UBLAt9nmmIGXJGw6S8 y1vw== X-Gm-Message-State: ALoCoQnGg0IdIfIimJ9zqIPbM0wugo9VLr+0/Xe0GQKlxFwK/8iErLOHNoFMoi9XIHXPmC6jRy3K X-Received: by 10.229.68.202 with SMTP id w10mr9996919qci.13.1423153875156; Thu, 05 Feb 2015 08:31:15 -0800 (PST) MIME-Version: 1.0 References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> <3BE1022E17B492A5A2887683@caldav.corp.apple.com> From: Gregory Yakushev Date: Thu, 05 Feb 2015 16:31:14 +0000 Message-ID: To: Barry Leiba , Cyrus Daboo Content-Type: multipart/alternative; boundary=001a11339fa630b475050e59d58e Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:31:17 -0000 --001a11339fa630b475050e59d58e Content-Type: text/plain; charset=UTF-8 On Thu Feb 05 2015 at 5:23:19 PM Barry Leiba wrote: > >> I do NOT think that we need to accompany this with any list of > >> calendars. Whoever implements a particular calendar needs to know how > >> it works in order to generate the right SKIP values anyway. So why > >> not just say that, and forget about having to include the SKIPs? > > > > I am not convinced that there is one convention per calendar system that > is > > consistently used. In discussions I have had with others I got the > > impression that the skip mode was dependent on other factors - e.g. the > > nature of the event. For example the convention for personal > anniversaries > > may be different than that for "legal" ones. Previously I cited the > > Gregorian example of someone born on a leap day who prefers to celebrate > on > > the 28th, but legally is not considered to be "of age" until the 1st. > > > > The bottom line is conventions for one calendar system can vary from > locale > > to locale and it would be very hard for us to define the basis for that. > > Ack. > > But, then, I still don't see how using possibly complicated SKIP > controls really works here. If I create a repeating entry, my > calendar system tries to figure out what's what and sticks in some set > of SKIPs. Maybe it gets them right, and maybe it doesn't. Whatever > it does, those are now copied to every other calendar system that I > give this vevent to. If it's wrong, it's wrong everywhere. > It may be wrong, but for all invitees the event will happen at the same time. The most important aspect of recurring events is that they should be consistent: if I invite you to an event it should show up at the same time for us even if its a wrong time. Otherwise we won't meet at all, and people get really angry about this. In your example, the user (creater) will see when instances happen. And if he is not happy with the implementation - he can always choose a better system. But at least he won't have to blame Google Calendar for getting his event wrong when some invitees using it don't show up. > > If we rely on the calendar implementations to do the right thing with > respect to the particular calendars, then one implementation's bugs > don't spread. > > On the other hand, if "personal" and "legal" differ, we'd have to have > some way to convey that this vevent is personal and that one is legal. > Oy. I'm not worried about exceptions (personal preferences and the > like, though I'm not sure how a calendar implementation would do a UI > to let a user control that)... I'm worried about having most things > get it right most of the time, and reserving explicit SKIP rules for > the exceptions. > > I really don't see a way out here. > > b > --001a11339fa630b475050e59d58e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu Feb 05 2015 at 5= :23:19 PM Barry Leiba <barryl= eiba@computer.org> wrote:
>>= I do NOT think that we need to accompany this with any list of
>> calendars.=C2=A0 Whoever implements a particular calendar needs to= know how
>> it works in order to generate the right SKIP values anyway.=C2=A0 = So why
>> not just say that, and forget about having to include the SKIPs? >
> I am not convinced that there is one convention per calendar system th= at is
> consistently used. In discussions I have had with others I got the
> impression that the skip mode was dependent on other factors - e.g. th= e
> nature of the event. For example the convention for personal anniversa= ries
> may be different than that for "legal" ones. Previously I ci= ted the
> Gregorian example of someone born on a leap day who prefers to celebra= te on
> the 28th, but legally is not considered to be "of age" until= the 1st.
>
> The bottom line is conventions for one calendar system can vary from l= ocale
> to locale and it would be very hard for us to define the basis for tha= t.

Ack.

But, then, I still don't see how using possibly complicated SKIP
controls really works here.=C2=A0 If I create a repeating entry, my
calendar system tries to figure out what's what and sticks in some set<= br> of SKIPs.=C2=A0 Maybe it gets them right, and maybe it doesn't.=C2=A0 W= hatever
it does, those are now copied to every other calendar system that I
give this vevent to.=C2=A0 If it's wrong, it's wrong everywhere.

It may be wrong, but for all invitees the= event will happen at the same time. The most important aspect of recurring= events is that they should be consistent: if I invite you to an event it s= hould show up at the same time for us even if its a wrong time. Otherwise w= e won't meet at all, and people get really angry about this.
=
In your example, the user (creater) will see when instances = happen. And if he is not happy with the implementation - he can always choo= se a better system. But at least he won't have to blame Google Calendar= for getting his event wrong when some invitees using it don't show up.=
=C2=A0

If we rely on the calendar implementations to do the right thing with
respect to the particular calendars, then one implementation's bugs
don't spread.

On the other hand, if "personal" and "legal" differ, we= 'd have to have
some way to convey that this vevent is personal and that one is legal.
Oy.=C2=A0 I'm not worried about exceptions (personal preferences and th= e
like, though I'm not sure how a calendar implementation would do a UI to let a user control that)... I'm worried about having most things
get it right most of the time, and reserving explicit SKIP rules for
the exceptions.

I really don't see a way out here.

b
--001a11339fa630b475050e59d58e-- From nobody Thu Feb 5 08:45:11 2015 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 255AE1A8A01 for ; Thu, 5 Feb 2015 08:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 rjmhLoukumsY for ; Thu, 5 Feb 2015 08:45:03 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8481A8850 for ; Thu, 5 Feb 2015 08:45:01 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so8243184lbi.10 for ; Thu, 05 Feb 2015 08:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Itl7vRQzSF+F4Ir+xWt8Uja5P2ZOR3OVPd7Icwn19rk=; b=EOWIPJxG+qq8pbzwEhi6iDYgpSisllgisd++oAHWfi4aYbgehFM5CWQ8hRsk0w9Mhv EiJff2x1hyprKKT2H8xJzR8umc0Sf/9WAbQhFJlQ5I7BeUAABjWLj9a8/lCA7167A6pO YLSJjVOPiutwMACM7p+2db6qWfVm8m0KE/uvgFnF9hhGAyrHTEkOMF4wbgEvWrFg7NTk ef6Fd71gf0FIjdhotzSz3MjHWxn2VcfxKi2TYgue2XBeT0Gou8bSUpyPi9DgGK/gi4NV YaNtL4V8z0mtDdqU5TZ9gvyVrv7hb/FhQRSZLtsgqD5pQQ15nDVBBU4cyzEc1Nf/ClxL JGbA== MIME-Version: 1.0 X-Received: by 10.152.27.201 with SMTP id v9mr1265606lag.123.1423154700088; Thu, 05 Feb 2015 08:45:00 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.225 with HTTP; Thu, 5 Feb 2015 08:45:00 -0800 (PST) In-Reply-To: <9764350C69A3A90809A3CE05@caldav.corp.apple.com> References: <68FCD7D11F934509267D5915@cyrus.local> <7FF77F2FE3390FFD1149E953@cyrus.local> <54D0E2E9.2030505@andrew.cmu.edu> <99B9DDB4AEFC12755724C5DD@caldav.corp.apple.com> <54D107AC.3050706@andrew.cmu.edu> <2D953326EFEE238B1CCF867E@caldav.corp.apple.com> <54D10C50.20909@andrew.cmu.edu> <54D10FDB.6070001@andrew.cmu.edu> <54D12AAC.7000202@dmfs.org> <54D12E31.4020506@andrew.cmu.edu> <55A07C99191DC58DAAA160D5@caldav.corp.apple.com> <54D1368F.2000501@dmfs.org> <6BD446FBAB897BCD227A82F1@caldav.corp.apple.com> <54D14289.90201@dmfs.org> <54D21CA2.5020807@andrew.cmu.edu> <54D224D0.1050309@dmfs.org> <54D22DEB.7020501@andrew.cmu.edu> <33B390A4-BF1A-4C51-B29F-6F41CB22EC56@dmfs.org> <3BE1022E17B492A5A2887683@caldav.corp.apple.com> <9764350C69A3A90809A3CE05@caldav.corp.apple.com> Date: Thu, 5 Feb 2015 11:45:00 -0500 X-Google-Sender-Auth: xyDSkVm4rPyySN395URjCavuOZc Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Calsify Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03 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, 05 Feb 2015 16:45:07 -0000 >> If we rely on the calendar implementations to do the right thing with >> respect to the particular calendars, then one implementation's bugs >> don't spread. > > But provided the "buggy" data is represented consistently by all clients, > users do have a reasonable chance of spotting the mistake and correcting it. > On the other hand, if an event looks right on my mobile device, but is > interpreted differently on my calendar-aware thermostat (or perhaps more > seriously a medical device) I probably have no chance of spotting the error > because the device might not expose its "internal" calendar view. So I would > much rather the data be interpreted consistently across all devices even if > its was not exactly what I wanted. OK, and Grisha says the same thing in his response. I'm still not happy with the situation, but as it's not clear that we can do better, I'll consider my issue discussed, and let you guys decide what the final settings should be. Thanks for discussing this with me. Barry From nobody Thu Feb 5 08:57:04 2015 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 62E991A07BD for ; Thu, 5 Feb 2015 08:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qBvGY9U5sb3d for ; Thu, 5 Feb 2015 08:57:00 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED7C1A064C for ; Thu, 5 Feb 2015 08:56:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E377CAF6A68; Thu, 5 Feb 2015 11:56:58 -0500 (EST) 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 A5O3KP47C3ZA; Thu, 5 Feb 2015 11:56:58 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A489CAF6A57; Thu, 5 Feb 2015 11:56:57 -0500 (EST) Date: Thu, 05 Feb 2015 11:56:53 -0500 From: Cyrus Daboo To: Calsify Message-ID: 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=5060 Archived-At: Cc: Barry Leiba Subject: [calsify] Proposed resolution to SKIP issue 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, 05 Feb 2015 16:57:02 -0000 Hi, OK, here is what I propose to resolve the SKIP issue. 1) Change to use OMIT instead of the YES value 2) Make OMIT be the default value when SKIP is not present 3) Add a new section describing SPLIT in much more detail. Below is text I have drafted up for the new section: 4.1. Skipping Invalid Dates In every calendar system only certain combinations of day-of-month and month values are valid for a given year. e.g., in the Gregorian calendar system January 31st is valid, but February 31st is not. Similarly, February 29th is valid in a leap year, but invalid in a non-leap year. Other calendar systems can also include leap months (see Section 4.2) which vary from year to year. This poses a problem for recurring events where the frequency of recurrence might give rise to an invalid date. For example, a recurring event that starts on January 31st and is set to repeat monthly will generate invalid dates for months with fewer than 31 days. The iCalendar [RFC5545] specification requires recurrence rule generators to ignore any invalid dates generated when iterating the rule. However, that behavior might be surprising to a calendar user born on a leap day and whose birthday event only appears on their calendar every four years. There are common conventions used by humans to determine what to do in such cases, but those conventions can differ from calendar system to calendar system, as well as within the same calendar system, depending on the nature of the event. Typically, humans will expect the "missing" events to be moved to a earlier or later (valid) date. This specification introduces a new "RRULE" element, "SKIP", for use only when the "RSCALE" element is present. The "SKIP" element allows the calendar user agent to specify new options for handling invalid dates. "SKIP=OMIT": this is the default option and corresponds to the existing iCalendar behavior of simply ignoring the invalid date. "SKIP=BACKWARD": when this option is set, a date with an invalid month is changed to the previous (valid) month. A date with an invalid day-of-month is changed to the previous (valid) day-of- month. "SKIP=FORWARD": when this option is set, a date with an invalid month is changed to the next (valid) month. A date with an invalid day-of-month is changed to the next (valid) day-of-month. Note that for both "BACKWARD" and "FORWARD", if the month is changed and results in an invalid day-of-month, then the skip behavior will be re-applied as per the day-of-month rules, according to the processing order defined below. The month and day-of-month skip behavior is only applied at specific points during the processing of an "RRULE" as determined by the order in which any "BYxxx" elements are processed. The order is as follows (based on the "RRULE" element processing order defined in Section 3.3.10 of [RFC5545]): o BYMONTH o SKIP (for invalid month only) o BYWEEKNO o BYYEARDAY o BYMONTHDAY o SKIP (for invalid day) o BYDAY o BYHOUR o BYMINUTE o BYSECOND o BYSETPOS o COUNT o UNTIL It is often possible to avoid having to deal with invalid dates by determining the real intent of a human user. e.g., a human creating a monthly recurring event that starts on January 31st, likely intends the event to occur on the last day of every month, in which case that could be encoded into an "RRULE" by using the "BYMONTHDAY=-1" element. Only a few types of recurrence patterns are likely to need the use of "SKIP". The following is a list of some situations where it might be needed: 1. The start date of the recurrence is a leap day in the specified calendar system. 2. The start date of the recurrence is in a leap month in the specified calendar system. 3. The start date of the recurrence has a day-of-month value greater than the smallest day-of-month value for any month in any year in the specified calendar system. 4. A "BYMONTHDAY" element in an "RRULE" has a day-of-month value greater than the smallest day-of-month value for any month in any year in the specified calendar system. 5. A "BYMONTH" element in an "RRULE" has a value corresponding to a leap month in the specified calendar system. 6. A combination of "BYMONTHDAY" and "BYMONTH" elements in an "RRULE" have a value corresponding to a leap day in the specified calendar system. 7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater than the smallest number of days in any year in the specified calendar system. 8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater than the smallest number of weeks in any year in the specified calendar system. Examples of using "SKIP" for some common use cases appear in Section 4.3. -- Cyrus Daboo From nobody Thu Feb 5 14:39:43 2015 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 C76DE1A6F0E for ; Thu, 5 Feb 2015 14:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6lIBAa17ToJ7 for ; Thu, 5 Feb 2015 14:39:34 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0361A87B3 for ; Thu, 5 Feb 2015 14:39:30 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id e89so8553037qgf.8 for ; Thu, 05 Feb 2015 14:39:29 -0800 (PST) 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:cc :content-type; bh=WNEwy06xKtPf52aWXVHA748FYy6bZkWtcohOfMD2Tag=; b=Z/gbSH0irYP2NT+HvPxk2+hw8/S7MyH9xhEyeHy6lxE7lr+zKNRTo3BSjl7varnXIx QWE9mr/Fu29ootGipzLZJJEzw5ktXoonbrpaBtJnSpaeUYUWJ8LNDvZaG2n5OMb6KH7e csr4CBCPI22QrhTPpXepRjAuBRCV/+cb/4SN4XwtnWGwmHu4xXkwcr6+l9Q4nofMLcPx TNW3gLlT3DAHlfNCMRLXdrdgSHuRy6cakvwXiMVIkfRa0owCbaeGsPNOWJOwScOt/Niw juzYDrF8pPW4bPPukPaFtZlC2FJ5chR42R6aHNRmnfkk5X8SZlNAdXn5GTzNoy+aUnm+ sNfA== 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:cc:content-type; bh=WNEwy06xKtPf52aWXVHA748FYy6bZkWtcohOfMD2Tag=; b=DIl1+J25qB6wovR7QACmrknC4QKT10O1fHE1F9aZnEUvRS6Ghm68a6aciFYOhHqPYc k3CrRfHtDcSdTlUthPu/RpzX0T0C7LmL26ZhcT0EqKUobKdGAdTY1+d6R/NoOBxBzM6v TATrLzqYjtUCyRIVNUztOL6bO0imUgEfjeKdQFfB7+NXLfqqgBcKamNn5bBUHa4UQK6g xjB+6/mUy0/crnQdsftLqcwqFS5fwQZZkifnXONrPmN0cz1j9t6Z77Hq0QeRpmgKb86+ CH7OxRv2w2M7Nf3vlj2KszjWvcqEZlhzVXsMzxX3Zm0E+VlAmt/sdPErG7PXtz+NpLt5 wK5g== X-Gm-Message-State: ALoCoQkVrrh5VsCtLYXHTyhPTiaaZZNYHvWMtfIuBVGha4dA6pmND7/2/F/alSf/KizD4NAf/JiR X-Received: by 10.224.5.131 with SMTP id 3mr1174372qav.36.1423175969609; Thu, 05 Feb 2015 14:39:29 -0800 (PST) MIME-Version: 1.0 References: From: Gregory Yakushev Date: Thu, 05 Feb 2015 22:39:28 +0000 Message-ID: To: Cyrus Daboo , Calsify Content-Type: multipart/alternative; boundary=047d7b6249fc1f396b050e5efa32 Archived-At: Cc: Barry Leiba Subject: Re: [calsify] Proposed resolution to SKIP issue 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, 05 Feb 2015 22:39:37 -0000 --047d7b6249fc1f396b050e5efa32 Content-Type: text/plain; charset=UTF-8 The explanation is very clear, overall looks good to me. Thanks Cyrus! Small comments below. On Thu Feb 05 2015 at 5:57:06 PM Cyrus Daboo wrote: > Hi, > OK, here is what I propose to resolve the SKIP issue. > > 1) Change to use OMIT instead of the YES value > 2) Make OMIT be the default value when SKIP is not present > 3) Add a new section describing SPLIT in much more detail. > > Below is text I have drafted up for the new section: > > 4.1. Skipping Invalid Dates > > In every calendar system only certain combinations of day-of-month > and month values are valid for a given year. e.g., in the Gregorian > calendar system January 31st is valid, but February 31st is not. > Similarly, February 29th is valid in a leap year, but invalid in a > non-leap year. Other calendar systems can also include leap months > (see Section 4.2) which vary from year to year. This poses a problem > for recurring events where the frequency of recurrence might give > rise to an invalid date. For example, a recurring event that starts > on January 31st and is set to repeat monthly will generate invalid > dates for months with fewer than 31 days. The iCalendar [RFC5545] > specification requires recurrence rule generators to ignore any > invalid dates generated when iterating the rule. However, that > behavior might be surprising to a calendar user born on a leap day > and whose birthday event only appears on their calendar every four > years. There are common conventions used by humans to determine what > to do in such cases, but those conventions can differ from calendar > system to calendar system, as well as within the same calendar > system, depending on the nature of the event. Typically, humans will > expect the "missing" events to be moved to a earlier or later (valid) > date. > > This specification introduces a new "RRULE" element, "SKIP", for use > only when the "RSCALE" element is present. The "SKIP" element allows > the calendar user agent to specify new options for handling invalid > dates. > > "SKIP=OMIT": this is the default option and corresponds to the > existing iCalendar behavior of simply ignoring the invalid date. > > "SKIP=BACKWARD": when this option is set, a date with an invalid > month is changed to the previous (valid) month. A date with an > invalid day-of-month is changed to the previous (valid) day-of- > month. > > "SKIP=FORWARD": when this option is set, a date with an invalid > month is changed to the next (valid) month. A date with an > invalid day-of-month is changed to the next (valid) day-of-month. > A date with an invalid day-of-month is changed to the next day. This may cause MONTH or YEAR to also increment. This behavior may cause two instances to appear in a single month for a MONTHLY rule. > Note that for both "BACKWARD" and "FORWARD", if the month is changed > and results in an invalid day-of-month, then the skip behavior will > be re-applied as per the day-of-month rules, according to the > processing order defined below. > > The month and day-of-month skip behavior is only applied at specific > points during the processing of an "RRULE" as determined by the order > in which any "BYxxx" elements are processed. The order is as follows > (based on the "RRULE" element processing order defined in > Section 3.3.10 of [RFC5545]): > > o BYMONTH > > o SKIP (for invalid month only) > > o BYWEEKNO > > o BYYEARDAY > > o BYMONTHDAY > > o SKIP (for invalid day) > > o BYDAY > > o BYHOUR > > o BYMINUTE > > o BYSECOND > > o BYSETPOS > > o COUNT > > o UNTIL > > It is often possible to avoid having to deal with invalid dates by > determining the real intent of a human user. e.g., a human creating a > monthly recurring event that starts on January 31st, likely intends > the event to occur on the last day of every month, in which case that > could be encoded into an "RRULE" by using the "BYMONTHDAY=-1" > element. > > Only a few types of recurrence patterns are likely to need the use of > "SKIP". The following is a list of some situations where it might be > needed: > I am not sure we need this exhaustive list here, given we already have an examples section. Similarly the spec does not provide an exhaustive list of usecases for other parameters (e.g. BYSETPOS). > > 1. The start date of the recurrence is a leap day in the specified > calendar system. > > 2. The start date of the recurrence is in a leap month in the > specified calendar system. > > 3. The start date of the recurrence has a day-of-month value greater > than the smallest day-of-month value for any month in any year in > the specified calendar system. > > 4. A "BYMONTHDAY" element in an "RRULE" has a day-of-month value > greater than the smallest day-of-month value for any month in any > year in the specified calendar system. > > 5. A "BYMONTH" element in an "RRULE" has a value corresponding to a > leap month in the specified calendar system. > > 6. A combination of "BYMONTHDAY" and "BYMONTH" elements in an > "RRULE" have a value corresponding to a leap day in the specified > calendar system. > > 7. A "BYYEARDAY" element in an "RRULE" has an absolute value greater > than the smallest number of days in any year in the specified > calendar system. > > 8. A "BYWEEKNO" element in an "RRULE" has an absolute value greater > than the smallest number of weeks in any year in the specified > calendar system. > > Examples of using "SKIP" for some common use cases appear in > Section 4.3. > > -- > Cyrus Daboo > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --047d7b6249fc1f396b050e5efa32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The explanation is very clear, overall looks good to me. T= hanks Cyrus!

Small comments below.

On Thu Feb 05 2015 at 5:57:06 PM Cyrus Daboo <cyrus@daboo.name> wrote:
Hi,
OK, here is what I propose to resolve the SKIP issue.

1) Change to use OMIT instead of the YES value
2) Make OMIT be the default value when SKIP is not present
3) Add a new section describing SPLIT in much more detail.

Below is text I have drafted up for the new section:

4.1.=C2=A0 Skipping Invalid Dates

=C2=A0 =C2=A0In every calendar system only certain combinations of day-of-m= onth
=C2=A0 =C2=A0and month values are valid for a given year. e.g., in the Greg= orian
=C2=A0 =C2=A0calendar system January 31st is valid, but February 31st is no= t.
=C2=A0 =C2=A0Similarly, February 29th is valid in a leap year, but invalid = in a
=C2=A0 =C2=A0non-leap year.=C2=A0 Other calendar systems can also include l= eap months
=C2=A0 =C2=A0(see Section 4.2) which vary from year to year.=C2=A0 This pos= es a problem
=C2=A0 =C2=A0for recurring events where the frequency of recurrence might g= ive
=C2=A0 =C2=A0rise to an invalid date.=C2=A0 For example, a recurring event = that starts
=C2=A0 =C2=A0on January 31st and is set to repeat monthly will generate inv= alid
=C2=A0 =C2=A0dates for months with fewer than 31 days.=C2=A0 The iCalendar = [RFC5545]
=C2=A0 =C2=A0specification requires recurrence rule generators to ignore an= y
=C2=A0 =C2=A0invalid dates generated when iterating the rule.=C2=A0 However= , that
=C2=A0 =C2=A0behavior might be surprising to a calendar user born on a leap= day
=C2=A0 =C2=A0and whose birthday event only appears on their calendar every = four
=C2=A0 =C2=A0years.=C2=A0 There are common conventions used by humans to de= termine what
=C2=A0 =C2=A0to do in such cases, but those conventions can differ from cal= endar
=C2=A0 =C2=A0system to calendar system, as well as within the same calendar=
=C2=A0 =C2=A0system, depending on the nature of the event.=C2=A0 Typically,= humans will
=C2=A0 =C2=A0expect the "missing" events to be moved to a earlier= or later (valid)
=C2=A0 =C2=A0date.

=C2=A0 =C2=A0This specification introduces a new "RRULE" element,= "SKIP", for use
=C2=A0 =C2=A0only when the "RSCALE" element is present.=C2=A0 The= "SKIP" element allows
=C2=A0 =C2=A0the calendar user agent to specify new options for handling in= valid
=C2=A0 =C2=A0dates.

=C2=A0 =C2=A0 =C2=A0 "SKIP=3DOMIT": this is the default option an= d corresponds to the
=C2=A0 =C2=A0 =C2=A0 existing iCalendar behavior of simply ignoring the inv= alid date.

=C2=A0 =C2=A0 =C2=A0 "SKIP=3DBACKWARD": when this option is set, = a date with an invalid
=C2=A0 =C2=A0 =C2=A0 month is changed to the previous (valid) month.=C2=A0 = A date with an
=C2=A0 =C2=A0 =C2=A0 invalid day-of-month is changed to the previous (valid= ) day-of-
=C2=A0 =C2=A0 =C2=A0 month.

=C2=A0 =C2=A0 =C2=A0 "SKIP=3DFORWARD": when this option is set, a= date with an invalid
=C2=A0 =C2=A0 =C2=A0 month is changed to the next (valid) month.=C2=A0 A da= te with an
=C2=A0 =C2=A0 =C2=A0 invalid day-of-month is changed to the next (valid) da= y-of-month.

A date with an invalid day-= of-month is changed to the next day. This may cause MONTH or YEAR to also i= ncrement. This behavior may cause two instances to appear in a single month= for a MONTHLY rule.


=C2=A0 =C2=A0Note that for both "BACKWARD" and "FORWARD"= ;, if the month is changed
=C2=A0 =C2=A0and results in an invalid day-of-month, then the skip behavior= will
=C2=A0 =C2=A0be re-applied as per the day-of-month rules, according to the<= br> =C2=A0 =C2=A0processing order defined below.

=C2=A0 =C2=A0The month and day-of-month skip behavior is only applied at sp= ecific
=C2=A0 =C2=A0points during the processing of an "RRULE" as determ= ined by the order
=C2=A0 =C2=A0in which any "BYxxx" elements are processed.=C2=A0 T= he order is as follows
=C2=A0 =C2=A0(based on the "RRULE" element processing order defin= ed in
=C2=A0 =C2=A0Section 3.3.10 of [RFC5545]):

=C2=A0 =C2=A0o=C2=A0 BYMONTH

=C2=A0 =C2=A0o=C2=A0 SKIP (for invalid month only)

=C2=A0 =C2=A0o=C2=A0 BYWEEKNO

=C2=A0 =C2=A0o=C2=A0 BYYEARDAY

=C2=A0 =C2=A0o=C2=A0 BYMONTHDAY

=C2=A0 =C2=A0o=C2=A0 SKIP (for invalid day)

=C2=A0 =C2=A0o=C2=A0 BYDAY

=C2=A0 =C2=A0o=C2=A0 BYHOUR

=C2=A0 =C2=A0o=C2=A0 BYMINUTE

=C2=A0 =C2=A0o=C2=A0 BYSECOND

=C2=A0 =C2=A0o=C2=A0 BYSETPOS

=C2=A0 =C2=A0o=C2=A0 COUNT

=C2=A0 =C2=A0o=C2=A0 UNTIL

=C2=A0 =C2=A0It is often possible to avoid having to deal with invalid date= s by
=C2=A0 =C2=A0determining the real intent of a human user. e.g., a human cre= ating a
=C2=A0 =C2=A0monthly recurring event that starts on January 31st, likely in= tends
=C2=A0 =C2=A0the event to occur on the last day of every month, in which ca= se that
=C2=A0 =C2=A0could be encoded into an "RRULE" by using the "= BYMONTHDAY=3D-1"
=C2=A0 =C2=A0element.

=C2=A0 =C2=A0Only a few types of recurrence patterns are likely to need the= use of
=C2=A0 =C2=A0"SKIP".=C2=A0 The following is a list of some situat= ions where it might be
=C2=A0 =C2=A0needed:

I am not sure we n= eed this exhaustive list here, given we already have an examples section. S= imilarly the spec does not provide an exhaustive list of usecases for other= parameters (e.g. BYSETPOS).
=C2=A0

=C2=A0 =C2=A01.=C2=A0 The start date of the recurrence is a leap day in the= specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0calendar system.

=C2=A0 =C2=A02.=C2=A0 The start date of the recurrence is in a leap month i= n the
=C2=A0 =C2=A0 =C2=A0 =C2=A0specified calendar system.

=C2=A0 =C2=A03.=C2=A0 The start date of the recurrence has a day-of-month v= alue greater
=C2=A0 =C2=A0 =C2=A0 =C2=A0than the smallest day-of-month value for any mon= th in any year in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the specified calendar system.

=C2=A0 =C2=A04.=C2=A0 A "BYMONTHDAY" element in an "RRULE&qu= ot; has a day-of-month value
=C2=A0 =C2=A0 =C2=A0 =C2=A0greater than the smallest day-of-month value for= any month in any
=C2=A0 =C2=A0 =C2=A0 =C2=A0year in the specified calendar system.

=C2=A0 =C2=A05.=C2=A0 A "BYMONTH" element in an "RRULE"= has a value corresponding to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0leap month in the specified calendar system.

=C2=A0 =C2=A06.=C2=A0 A combination of "BYMONTHDAY" and "BYM= ONTH" elements in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0"RRULE" have a value corresponding to = a leap day in the specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0calendar system.

=C2=A0 =C2=A07.=C2=A0 A "BYYEARDAY" element in an "RRULE&quo= t; has an absolute value greater
=C2=A0 =C2=A0 =C2=A0 =C2=A0than the smallest number of days in any year in = the specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0calendar system.

=C2=A0 =C2=A08.=C2=A0 A "BYWEEKNO" element in an "RRULE"= ; has an absolute value greater
=C2=A0 =C2=A0 =C2=A0 =C2=A0than the smallest number of weeks in any year in= the specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0calendar system.

=C2=A0 =C2=A0Examples of using "SKIP" for some common use cases a= ppear in
=C2=A0 =C2=A0Section 4.3.

--
Cyrus Daboo

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--047d7b6249fc1f396b050e5efa32-- From nobody Fri Feb 6 06:16:53 2015 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 5583A1A1AD0 for ; Fri, 6 Feb 2015 06:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 gxEwdBLRka8D for ; Fri, 6 Feb 2015 06:16:48 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741DC1A1AC6 for ; Fri, 6 Feb 2015 06:16:48 -0800 (PST) Received: by lamq1 with SMTP id q1so1379833lam.5 for ; Fri, 06 Feb 2015 06:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=3/K2KDKLFfhl2kE/pg4GkKPsBWbnonFlh4N+72Er9fs=; b=I/dHV6V/I+0o51qDSkzd61DpTVBABVLPQDm6nW499pSgNIGmwZwvhpPsWbdBZJO9zG M3CKRXO/L9lelZT+zb6sxDNRJmb6ciByyIBwELBXiuQnS4fOgrMU14NnFXzXaIOGoJEY /zpeWCa8ld22nKbiIAu3TCnw9FjOSymPUOgrQmXQVHdvWIpr2F6IRl3afPQAU+ffSc2k 7Up8GP0dmxXRtKxj69gnyaGjxq1XXMq/tqb/raRdjr+VAG9UogT5ucMBaJdmZPvQavEH mgXH/IZ6y4HcQOna78bWLQK0FBtsJBlfOT03ldvWrwtbQgqnWpK4rHQpbaoi5iIKsolM 12+A== MIME-Version: 1.0 X-Received: by 10.112.166.73 with SMTP id ze9mr2967481lbb.38.1423232206936; Fri, 06 Feb 2015 06:16:46 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.225 with HTTP; Fri, 6 Feb 2015 06:16:46 -0800 (PST) Date: Fri, 6 Feb 2015 09:16:46 -0500 X-Google-Sender-Auth: jNHNUQA0EuLkLW2JesvdIRFBocA Message-ID: From: Barry Leiba To: "calsify@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [calsify] Errata on CalDAV (RFC 4791) 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, 06 Feb 2015 14:16:50 -0000 Folks... A while ago, Hiroaki Kawai submitted 16 errata reports for RFC 4791: http://www.rfc-editor.org/errata_search.php?rfc=4791 (scroll down to "Reported") Perhaps daunted by the surge, I've not done anything with them yet. I'd like to take care of them. So I need comments on them -- can this august group have a look at the batch and advise me? Thanks, Barry From nobody Fri Feb 6 06:57:52 2015 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 6F3051A1B1C for ; Fri, 6 Feb 2015 06:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gxW1EaoixGk5 for ; Fri, 6 Feb 2015 06:57:47 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392FC1A00A9 for ; Fri, 6 Feb 2015 06:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 787D9B12AC8; Fri, 6 Feb 2015 09:57:46 -0500 (EST) 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 bHjR4e2K99IT; Fri, 6 Feb 2015 09:57:46 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 2D28BB12ABD; Fri, 6 Feb 2015 09:57:44 -0500 (EST) Date: Fri, 06 Feb 2015 09:57:40 -0500 From: Cyrus Daboo To: Barry Leiba , calsify@ietf.org Message-ID: <3074BFF0E72BA3FEEA625300@caldav.corp.apple.com> In-Reply-To: References: 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=932 Archived-At: Subject: Re: [calsify] Errata on CalDAV (RFC 4791) 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, 06 Feb 2015 14:57:50 -0000 Hi Barry, --On February 6, 2015 at 9:16:46 AM -0500 Barry Leiba wrote: > Perhaps daunted by the surge, I've not done anything with them yet. > I'd like to take care of them. So I need comments on them -- can this > august group have a look at the batch and advise me? Errata ID: 4159 - verified Errata ID: 4160 - verified Errata ID: 4161 - verified Errata ID: 4164 - verified Errata ID: 4165 - verified Errata ID: 4166 - verified Errata ID: 4167 - verified Errata ID: 4152 - reject - the query requests the return of an entire resource (including all overridden instances) for any resource that has at least one component overlapping the time range. Errata ID: 4153 - verified Errata ID: 4154 - verified Errata ID: 4155 - verified Errata ID: 4156 - verified Errata ID: 4157 - verified Errata ID: 4158 - verified Errata ID: 4162 - verified Errata ID: 4163 - verified -- Cyrus Daboo From nobody Fri Feb 6 07:36:45 2015 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 7C7E81A1B2C for ; Fri, 6 Feb 2015 07:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 obhVvU8zmxJC for ; Fri, 6 Feb 2015 07:36:34 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4D41A1B3F for ; Fri, 6 Feb 2015 07:36:25 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so18593617lbv.13 for ; Fri, 06 Feb 2015 07:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fq8f5ZZYDZGHtkfHuzzqQlmGRfrHSTN8fOv8dUI/FKM=; b=BpvWk8yECC+3ABS9V92CTWcDyPYX/thRrsz8igCr18RqMPSODHkKsLBfxbzDqjB434 O5AnoFhlNQB7I+gYPF+j6jM9YZGYi+MWHZ8OxiFpWccsXSjXcjlYrotqcW07yLm1BcDl HadZZbY08XXvAks3tImBwtc6A/KzPvDFzxL7CZx5pBlzjtN3x1Zoia0Mjp4qL04jsX98 TVFTuXLOQj5u+sHIe8XMy8ZTcfSz7Lxxv8kQVV73NDz34ZZOldMPTYVhQuOlXGB5WR1y KD+mUB2JK21Hqp/oEumHlCpI+1pwvS9Xah7wmQ5lp3vbOA6JHnmBxOpvkK/90s0ulHT8 mleQ== MIME-Version: 1.0 X-Received: by 10.112.137.196 with SMTP id qk4mr3393458lbb.33.1423236984299; Fri, 06 Feb 2015 07:36:24 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.225 with HTTP; Fri, 6 Feb 2015 07:36:24 -0800 (PST) In-Reply-To: <3074BFF0E72BA3FEEA625300@caldav.corp.apple.com> References: <3074BFF0E72BA3FEEA625300@caldav.corp.apple.com> Date: Fri, 6 Feb 2015 10:36:24 -0500 X-Google-Sender-Auth: meuGovduaAfG-jEFta7iuym5Sjw Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "calsify@ietf.org" Subject: Re: [calsify] Errata on CalDAV (RFC 4791) 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, 06 Feb 2015 15:36:36 -0000 Thanks, Cyrus. I have responded to all of them now. Barry On Fri, Feb 6, 2015 at 9:57 AM, Cyrus Daboo wrote: > Hi Barry, > > --On February 6, 2015 at 9:16:46 AM -0500 Barry Leiba > wrote: > >> Perhaps daunted by the surge, I've not done anything with them yet. >> I'd like to take care of them. So I need comments on them -- can this >> august group have a look at the batch and advise me? > > > Errata ID: 4159 - verified > > Errata ID: 4160 - verified > > Errata ID: 4161 - verified > > Errata ID: 4164 - verified > > Errata ID: 4165 - verified > > Errata ID: 4166 - verified > > Errata ID: 4167 - verified > > Errata ID: 4152 - reject - the query requests the return of an entire > resource (including all overridden instances) for any resource that has at > least one component overlapping the time range. > > Errata ID: 4153 - verified > > Errata ID: 4154 - verified > > Errata ID: 4155 - verified > > Errata ID: 4156 - verified > > Errata ID: 4157 - verified > > Errata ID: 4158 - verified > > Errata ID: 4162 - verified > > Errata ID: 4163 - verified > > > -- > Cyrus Daboo > From nobody Wed Feb 11 09:24:21 2015 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 574AF1A89C7; Wed, 11 Feb 2015 09:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Vk7Ho3PoMyGc; Wed, 11 Feb 2015 09:24:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 076241A1A5E; Wed, 11 Feb 2015 09:24:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211172407.16984.17769.idtracker@ietfa.amsl.com> Date: Wed, 11 Feb 2015 09:24:07 -0800 Archived-At: Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-rscale-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 17:24:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions Working Group of the IETF. Title : Non-Gregorian Recurrence Rules in iCalendar Authors : Cyrus Daboo Gregory Yakushev Filename : draft-ietf-calext-rscale-04.txt Pages : 22 Date : 2015-02-11 Abstract: This document defines extensions to iCalendar (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how CalDAV (RFC 4791) servers and clients can be extended to support these new recurrence rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-rscale/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-calext-rscale-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 11 09:26:06 2015 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 CADF91A1A13 for ; Wed, 11 Feb 2015 09:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fp-tcwrA4QQz for ; Wed, 11 Feb 2015 09:25:52 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60EA1A1A3E for ; Wed, 11 Feb 2015 09:25:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 13739B8689A for ; Wed, 11 Feb 2015 12:25:39 -0500 (EST) 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 eMmYetbR_2nu for ; Wed, 11 Feb 2015 12:25:39 -0500 (EST) Received: from [17.45.162.196] (unknown [17.45.162.196]) by daboo.name (Postfix) with ESMTPSA id 4F428B8688F for ; Wed, 11 Feb 2015 12:25:38 -0500 (EST) Date: Wed, 11 Feb 2015 12:25:35 -0500 From: Cyrus Daboo To: calsify@ietf.org Message-ID: In-Reply-To: <20150211172407.16984.17769.idtracker@ietfa.amsl.com> References: <20150211172407.16984.17769.idtracker@ietfa.amsl.com> 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=190 Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-rscale-04.txt 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, 11 Feb 2015 17:25:58 -0000 Hi folks, I have just posted a new version of the RSCALE draft that addresses the AD and OPSDIR reviews (with suggested corrections as previously discussed on the list). -- Cyrus Daboo From nobody Thu Feb 12 23:12:07 2015 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 13CCB1A1A27 for ; Thu, 12 Feb 2015 23:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 DNG5IFSMDpB0 for ; Thu, 12 Feb 2015 23:11:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id EA4DC1A0AF1 for ; Thu, 12 Feb 2015 23:11:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A77FE180092; Thu, 12 Feb 2015 23:10:57 -0800 (PST) To: bernard.desruisseaux@oracle.com, barryleiba@computer.org, presnick@qti.qualcomm.com, lear@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150213071057.A77FE180092@rfc-editor.org> Date: Thu, 12 Feb 2015 23:10:57 -0800 (PST) Archived-At: Cc: neilj@fastmail.com, calsify@ietf.org, rfc-editor@rfc-editor.org Subject: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 13 Feb 2015 07:12:04 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4271 -------------------------------------- Type: Technical Reported by: Neil Jenkins Section: 3.3.10 Original Text ------------- Recurrence rules may generate recurrence instances with an invalid date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM on a day where the local time is moved forward by an hour at 1:00 AM). Such recurrence instances MUST be ignored and MUST NOT be counted as part of the recurrence set. Corrected Text -------------- Recurrence rules may generate recurrence instances with an invalid date (e.g., February 30). Such recurrence instances MUST be ignored and MUST NOT be counted as part of the recurrence set. Notes ----- The section about ignoring times that don't occur in the timezone of the expansion is contradicted by the later passage (p44): """If the computed local start time of a recurrence instance does not exist, or occurs more than once, for the specified time zone, the time of the recurrence instance is interpreted in the same manner as an explicit DATE-TIME value describing that date and time, as specified in Section 3.3.5.""" And this is the behaviour implemented by major clients such as Calendar.app and Google Calendar. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri Feb 13 12:00:21 2015 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 20AE61A1AEB for ; Fri, 13 Feb 2015 12:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 aOJgtIpduKIR for ; Fri, 13 Feb 2015 12:00:18 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76561A1AAE for ; Fri, 13 Feb 2015 12:00:15 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so16701487lbj.13 for ; Fri, 13 Feb 2015 12:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1HGu55HPehEXaqh/bd5QoaDH5TLGbfgxTD1A9Wtcx/I=; b=z4iPuzWicfE2G8tqoePAUNj930oNl3F/Qt66xuJHWXDZLuHp62uVt+Ronetdjb/ZRR rJekMCR/nRLWEH8cAN0Ulh+6wpBe0m+WK4rb9uDciRCk84s+0KbUgG4u5lPct7Clwscq skRSZJnZr6OOPAeTZVfjD0llOylvg5/wq3ZPJWArzgWjyTyP5C7aPxfGb8G5ajSrgBrY QjuJSywFLGHMgPU/Et4g8yTOOAvhd5x+HbQFUJ5F/x4j1t/+Dk1/nslxjWbDqza2j5r5 qr8uD2xCrJgOoisjyblyYPHofTqeDnUeb0NG5pNQXFQjrdsqMFY3Q6lZGUw0JG+I+uCP /Now== MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr10022898lac.38.1423857613839; Fri, 13 Feb 2015 12:00:13 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Fri, 13 Feb 2015 12:00:13 -0800 (PST) In-Reply-To: <20150213071057.A77FE180092@rfc-editor.org> References: <20150213071057.A77FE180092@rfc-editor.org> Date: Fri, 13 Feb 2015 15:00:13 -0500 X-Google-Sender-Auth: 7lVeT5EK-kIK8ZxWdFMWD0aV0FE Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Pete Resnick , neilj@fastmail.com, "calsify@ietf.org" Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 13 Feb 2015 20:00:20 -0000 This change and explanation does seem right to me. I think this text is there from before we had the 45-minute discussion in some calsify meeting or other about how to handle non-existant-time situations... and this text never got removed. Those who might remember more clearly than I do: is that correct? Barry On Fri, Feb 13, 2015 at 2:10 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4271 > > -------------------------------------- > Type: Technical > Reported by: Neil Jenkins > > Section: 3.3.10 > > Original Text > ------------- > Recurrence rules may generate recurrence instances with an invalid > date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM > on a day where the local time is moved forward by an hour at 1:00 > AM). Such recurrence instances MUST be ignored and MUST NOT be > counted as part of the recurrence set. > > Corrected Text > -------------- > Recurrence rules may generate recurrence instances with an invalid > date (e.g., February 30). Such recurrence instances MUST be ignored > and MUST NOT be counted as part of the recurrence set. > > Notes > ----- > The section about ignoring times that don't occur in the timezone of the expansion is contradicted by the later passage (p44): > > """If the computed local start time of a recurrence instance does not > exist, or occurs more than once, for the specified time zone, the > time of the recurrence instance is interpreted in the same manner > as an explicit DATE-TIME value describing that date and time, as > specified in Section 3.3.5.""" > > And this is the behaviour implemented by major clients such as Calendar.app and Google Calendar. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplification > Area : Applications > Stream : IETF > Verifying Party : IESG > From nobody Fri Feb 13 12:10:27 2015 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 963921A0263 for ; Fri, 13 Feb 2015 12:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RDEi9O99BF3B for ; Fri, 13 Feb 2015 12:10:07 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1511A0118 for ; Fri, 13 Feb 2015 12:09:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AD666BB813D; Fri, 13 Feb 2015 15:09:56 -0500 (EST) 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 5lpAG1wf2GId; Fri, 13 Feb 2015 15:09:56 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 7FE5ABB812D; Fri, 13 Feb 2015 15:09:54 -0500 (EST) Date: Fri, 13 Feb 2015 15:09:50 -0500 From: Cyrus Daboo To: Barry Leiba , RFC Errata System Message-ID: <8A0E525B2C6C9E443AE6A226@caldav.corp.apple.com> In-Reply-To: References: <20150213071057.A77FE180092@rfc-editor.org> 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=584 Archived-At: Cc: Pete Resnick , neilj@fastmail.com, calsify@ietf.org Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 13 Feb 2015 20:10:18 -0000 Hi Barry, --On February 13, 2015 at 3:00:13 PM -0500 Barry Leiba wrote: > This change and explanation does seem right to me. I think this text > is there from before we had the 45-minute discussion in some calsify > meeting or other about how to handle non-existant-time situations... > and this text never got removed. > > Those who might remember more clearly than I do: is that correct? I think that is correct - a non-existent or doubled-up time value should not cause a recurrence instance to be discarded during rule processing. -- Cyrus Daboo From nobody Sat Feb 14 10:01:54 2015 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 3646A1A0063 for ; Sat, 14 Feb 2015 10:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 zSZ8Eqoqpjo2 for ; Sat, 14 Feb 2015 10:01:43 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96E61A00E0 for ; Sat, 14 Feb 2015 10:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4183; q=dns/txt; s=iport; t=1423936904; x=1425146504; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=nBZHT8ZZyr6UUGN79Z56OONmjDaYElkxwVQUq/oRVBQ=; b=mOjdAmn1inqjuNvBvVSdQHchLhtRu7fOLf5MSqiVp0NwLLhzId5LfEjw tSbegPwkauVm0pnk4gD3q9HELek2+FM2xWp+3Hun4wgKa8o9lWIxNy0wb H2mgsP+6AUqMN0i0maql5jrb3kIebz88TpTcFFgKPSa6ODktpx/Slb7Tx 4=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C5BAAwjd9U/xbLJq1BGoNYg12/NIVxAoFQAQEBAQEBfIQNAQEEI1UBEAsYCRYLAgIJAwIBAgFFBgEMAQUCAQGIKQ03vESWcQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLDIE9gzAHgmiBQgWFWYs3gS6GLoEYgwuCKow+IoICDQ+BUT0xARGCMQEBAQ X-IronPort-AV: E=Sophos;i="5.09,577,1418083200"; d="asc'?scan'208";a="345504008" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 14 Feb 2015 18:01:39 +0000 Received: from [10.61.68.215] (ams3-vpn-dhcp1239.cisco.com [10.61.68.215]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1EI1cMp027768; Sat, 14 Feb 2015 18:01:38 GMT Message-ID: <54DF8D82.6000006@cisco.com> Date: Sat, 14 Feb 2015 19:01:38 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba , RFC Errata System References: <20150213071057.A77FE180092@rfc-editor.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PA9dxUfitWtNXaCTiIxPuj1wlgJ3XiVd7" Archived-At: Cc: Pete Resnick , neilj@fastmail.com, "calsify@ietf.org" Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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: Sat, 14 Feb 2015 18:01:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PA9dxUfitWtNXaCTiIxPuj1wlgJ3XiVd7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Something is wrong with this erratum. It could be that there is really a problem with the existing text, but what is proposed simply takes out a quite valid example. Bernard, can you take a look and see if you spot a bug? Eliot On 2/13/15 9:00 PM, Barry Leiba wrote: > This change and explanation does seem right to me. I think this text > is there from before we had the 45-minute discussion in some calsify > meeting or other about how to handle non-existant-time situations... > and this text never got removed. > > Those who might remember more clearly than I do: is that correct? > > Barry > > On Fri, Feb 13, 2015 at 2:10 AM, RFC Errata System > wrote: >> The following errata report has been submitted for RFC5545, >> "Internet Calendaring and Scheduling Core Object Specification (iCalen= dar)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5545&eid=3D4271 >> >> -------------------------------------- >> Type: Technical >> Reported by: Neil Jenkins >> >> Section: 3.3.10 >> >> Original Text >> ------------- >> Recurrence rules may generate recurrence instances with an invalid >> date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM >> on a day where the local time is moved forward by an hour at 1:00 >> AM). Such recurrence instances MUST be ignored and MUST NOT be >> counted as part of the recurrence set. >> >> Corrected Text >> -------------- >> Recurrence rules may generate recurrence instances with an invalid >> date (e.g., February 30). Such recurrence instances MUST be ignored >> and MUST NOT be counted as part of the recurrence set. >> >> Notes >> ----- >> The section about ignoring times that don't occur in the timezone of t= he expansion is contradicted by the later passage (p44): >> >> """If the computed local start time of a recurrence instance does not >> exist, or occurs more than once, for the specified time zone, the >> time of the recurrence instance is interpreted in the same manner >> as an explicit DATE-TIME value describing that date and time, as >> specified in Section 3.3.5.""" >> >> And this is the behaviour implemented by major clients such as Calenda= r.app and Google Calendar. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5545 (draft-ietf-calsify-rfc2445bis-10) >> -------------------------------------- >> Title : Internet Calendaring and Scheduling Core Object = Specification (iCalendar) >> Publication Date : September 2009 >> Author(s) : B. Desruisseaux, Ed. >> Category : PROPOSED STANDARD >> Source : Calendaring and Scheduling Standards Simplificat= ion >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > --PA9dxUfitWtNXaCTiIxPuj1wlgJ3XiVd7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU342DAAoJEIe2a0bZ0nozuvUIANYiNdnJbFPVeBnZkdIh4WQI aFptjLThJhZWkAd29f9LcMaUThvK5mm7bGIO4cYmzmDVwBgc1Jgbd0XfmT5bEkSa 4/d6hYn2tPuK3FrVDWP9KfRE9rNWn6WNZ3bzEBg4gjU8fbUwvAf1udVvULRJRIxr 29P6Dg2S69SIKRKiNeEIxWOGDvO8EwnvpcPMyoQeolz9ZVzDdwsBqFPV1hXPajWN 4eYcVX4cTvJewTB1PTuQGZ283FEaJn8HrSVWS85ty3JM9cuAafi5bXX7/d8l61Ok EUpvp3hy1jqi+WzMwitpqYhKLIKuHYnrd6QxAVa2FtD0CyYnfQ9Q9H5b4UDz7PY= =/sCZ -----END PGP SIGNATURE----- --PA9dxUfitWtNXaCTiIxPuj1wlgJ3XiVd7-- From nobody Tue Feb 17 11:14:56 2015 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 1C3851A906E for ; Tue, 17 Feb 2015 11:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 JhcN1snNvo8d for ; Tue, 17 Feb 2015 11:14:53 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154281A9078 for ; Tue, 17 Feb 2015 11:14:53 -0800 (PST) Received: by labhs14 with SMTP id hs14so37176453lab.1 for ; Tue, 17 Feb 2015 11:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wjdEHjiOZgy8PRNMlmNxvlY/IIxjVFPy3/V+fcJOa74=; b=gcZg171YTZTXu0AkRn4/47MBrdrcXtoB0SbiS3lwnWE3Q1r1+yR5DWeidgrshcCoTL ghqyIVkd31KuQkAEa37DCJZwmg+1zolqqa5De8u6XZc6dt2wrN4njfyT4Gyka87kObCH IXi2i0BitusXH8gDZQTj7Tq98BGHRRtS4/bnaSvMNpwM0FYHNZgGCQsyCNdPLRXLm/wS ZNbXBoA4EBemsccHSQTUIXtLajDuGohvsod9SGlciiVebxXVUTs02/vCnIM2fl2qFz9Z 9AtDBn3TpF2U6L2HDZN+8TQuP5+OxkJMi5K0muUv6TK2T1YSByhDBnBn1O8+vGR6+s8o 8wpw== MIME-Version: 1.0 X-Received: by 10.112.141.228 with SMTP id rr4mr29947804lbb.119.1424200491661; Tue, 17 Feb 2015 11:14:51 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Tue, 17 Feb 2015 11:14:51 -0800 (PST) In-Reply-To: <54DF8D82.6000006@cisco.com> References: <20150213071057.A77FE180092@rfc-editor.org> <54DF8D82.6000006@cisco.com> Date: Tue, 17 Feb 2015 14:14:51 -0500 X-Google-Sender-Auth: JPjmBqAfOr0Ahgcqe2wC5Y3SxTk Message-ID: From: Barry Leiba To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Pete Resnick , "calsify@ietf.org" , neilj@fastmail.com, RFC Errata System Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 17 Feb 2015 19:14:55 -0000 > Something is wrong with this erratum. It could be that there is really > a problem with the existing text, but what is proposed simply takes out > a quite valid example. Bernard, can you take a look and see if you spot > a bug? I've talked with Eliot, who is now sitting next to me, and I've edited the errata report by adding a second paragraph to the corrected text. The second paragraph restores the "nonexistent time" statement and example, and says that it's handled according to Section 3.3.5. Eliot, others, please take a look and see if you think that's good, or whether there's something else that needs to be tweaked (that falls under the errata criteria). Or, if necessary, tell me that the fix is more complicated (I don't think it is), and needs to be held for document update. Barry From nobody Tue Feb 17 11:19:49 2015 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 BE9E21A9067 for ; Tue, 17 Feb 2015 11:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 hvonbYpZk8xp for ; Tue, 17 Feb 2015 11:19:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A3B1A891C for ; Tue, 17 Feb 2015 11:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1900; q=dns/txt; s=iport; t=1424200787; x=1425410387; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=mKYOyBj6vMzs3ZMBIUdp8Ht86heLPhOaRqar57OM9gs=; b=Zd5xPw4MKVEYjDsrRBBSEAbaZuNNKHcDxGNLEmtyeJWU8hZXzhyuac+K 9h03yq9YI0rY7M5TBBxYXqZfDMC3TLj1Fy5uPcOoE/FNHTWCZy1RqwsDC YAFZMAbSQ1sl6t85taABv/18QyG6krs6Zg3U5J1fNjbpTZGaTEpvXdHtV U=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BBBQAAlONU/5FdJa1bgwaEL8VCAoEZQwEBAQEBAXyEDQEBBCNVARALGAkWCwICCQMCAQIBRQYNAQcBAYgruT+XbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLD4E9gzEHgmiBQgEEijqGWIEuhi+BGIMNgiqFd4MJgz4igg+CAB2CdAEBAQ X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="asc'?scan'208";a="124431000" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 17 Feb 2015 19:19:43 +0000 Received: from [10.24.151.108] ([10.24.151.108]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1HJJfWU018203; Tue, 17 Feb 2015 19:19:41 GMT Message-ID: <54E3944E.8050105@cisco.com> Date: Tue, 17 Feb 2015 11:19:42 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Barry Leiba References: <20150213071057.A77FE180092@rfc-editor.org> <54DF8D82.6000006@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aHe1GEvUKGhCgJjDnmGShBU93L2EqCt17" Archived-At: Cc: Pete Resnick , "calsify@ietf.org" , neilj@fastmail.com, RFC Errata System Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 17 Feb 2015 19:19:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aHe1GEvUKGhCgJjDnmGShBU93L2EqCt17 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Barry, I think your proposed change is good. Eliot On 2/17/15 11:14 AM, Barry Leiba wrote: >> Something is wrong with this erratum. It could be that there is reall= y >> a problem with the existing text, but what is proposed simply takes ou= t >> a quite valid example. Bernard, can you take a look and see if you sp= ot >> a bug? > I've talked with Eliot, who is now sitting next to me, and I've edited > the errata report by adding a second paragraph to the corrected text. > The second paragraph restores the "nonexistent time" statement and > example, and says that it's handled according to Section 3.3.5. > > Eliot, others, please take a look and see if you think that's good, or > whether there's something else that needs to be tweaked (that falls > under the errata criteria). Or, if necessary, tell me that the fix is > more complicated (I don't think it is), and needs to be held for > document update. > > Barry > > --aHe1GEvUKGhCgJjDnmGShBU93L2EqCt17 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU45ROAAoJEIe2a0bZ0nozTdsH/0utXR1MQAAbqLo7WziDkMqL yW2rUWsIrJLjRVezXBYjdyiGGpwki0IwiXUsjPK4H+4K7qHHZ0cBQDGOnzynkxOd ZrJxgKyh26yiuFJPMCM5Lc20l73Nc0+BsI4BQsuS+FU+hU5sq1h+ItVqq8SI/hRd h5xHqyWFh/3dKCDZR9hMNe9MaFdX5k7oKdNFxW7f07YnKLpuJz5ZGGQjglYxUuqn UFPsnu2hwNamO1KEX5DRXwdzNbQCVUPH69lJ7jbPM/4wAIFi2lqb6WAe4dzesrrN ddxVdsOI8u8p8sSkOG8xPKYkA2mtXIVHbq/ilG4IqUGAuShFP6Z62MzRy4qmpwA= =IjaZ -----END PGP SIGNATURE----- --aHe1GEvUKGhCgJjDnmGShBU93L2EqCt17-- From nobody Tue Feb 17 12:23:49 2015 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 E69161A1F70 for ; Tue, 17 Feb 2015 12:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2rWkKX0WMRkx for ; Tue, 17 Feb 2015 12:23:45 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE541A1B81 for ; Tue, 17 Feb 2015 12:23:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 269DFC101A5; Tue, 17 Feb 2015 15:23:44 -0500 (EST) 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 NL8ip6D04JSP; Tue, 17 Feb 2015 15:23:43 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id CE05CC10193; Tue, 17 Feb 2015 15:23:41 -0500 (EST) Date: Tue, 17 Feb 2015 15:23:37 -0500 From: Cyrus Daboo To: Eliot Lear , Barry Leiba Message-ID: In-Reply-To: <54E3944E.8050105@cisco.com> References: <20150213071057.A77FE180092@rfc-editor.org> <54DF8D82.6000006@cisco.com> <54E3944E.8050105@cisco.com> 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=153 Archived-At: Cc: Pete Resnick , neilj@fastmail.com, calsify@ietf.org, RFC Errata System Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 17 Feb 2015 20:23:48 -0000 Hi Eliot, --On February 17, 2015 at 11:19:42 AM -0800 Eliot Lear wrote: > I think your proposed change is good. +1 -- Cyrus Daboo From nobody Tue Feb 17 13:18:16 2015 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 18F5F1A1B64 for ; Tue, 17 Feb 2015 13:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 9_vCY4yT0eNb for ; Tue, 17 Feb 2015 13:18:11 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716191A0358 for ; Tue, 17 Feb 2015 13:18:11 -0800 (PST) Received: by lbdu10 with SMTP id u10so7018160lbd.7 for ; Tue, 17 Feb 2015 13:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Pqd4hQBHUSDC4lIOb3nyoH99ohHO2D3jWhwb17uIm44=; b=jaKAmsywie8BY54l4qVePyP5LqjuBrSUzHPPeQLLQudU5V/5BzRaJpbCR2u6e6HobL lRgHAlaMMDf/Nz3J8TyYlV+dp35LOmhOL97GbpOIRRCtW34wTn6DpHnhGy4/GNPA4SOK SKldRCU6rPd4ZYMMu7IAqzehPv72dWcOSK+oIkHT/SQT+pT7KA3cv2oOSVix/eUis0if g0fA/5EkDRsK4eTmITpTC5nVHsoW52HvqpQLKnDm6QgM/obqIig0oJNrTgx2sROWUw/F /UtU42TLRmAk4pEjFlbkWwX3moneJMfEhp88S7cG1W4gJ/LnZqTiq1Ghmvtj6qX8Rvg1 4n2g== MIME-Version: 1.0 X-Received: by 10.152.23.233 with SMTP id p9mr16830175laf.123.1424207889986; Tue, 17 Feb 2015 13:18:09 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Tue, 17 Feb 2015 13:18:09 -0800 (PST) In-Reply-To: References: <20150213071057.A77FE180092@rfc-editor.org> <54DF8D82.6000006@cisco.com> <54E3944E.8050105@cisco.com> Date: Tue, 17 Feb 2015 16:18:09 -0500 X-Google-Sender-Auth: M2-dACmZDhQanbff6VM2uK4wPXQ Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Pete Resnick , neilj@fastmail.com, "calsify@ietf.org" , RFC Errata System Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4271) 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, 17 Feb 2015 21:18:13 -0000 >> I think your proposed change is good. > > +1 Off to mark it "Verified" now... b From nobody Tue Feb 17 13:19:11 2015 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 62BDB1A1B64; Tue, 17 Feb 2015 13:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 QApoHwNQa5_u; Tue, 17 Feb 2015 13:19:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B41F41A0358; Tue, 17 Feb 2015 13:19:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4A3CF182534; Tue, 17 Feb 2015 13:19:04 -0800 (PST) To: neilj@fastmail.com, bernard.desruisseaux@oracle.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150217211904.4A3CF182534@rfc-editor.org> Date: Tue, 17 Feb 2015 13:19:04 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, calsify@ietf.org Subject: [calsify] [Errata Verified] RFC5545 (4271) 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, 17 Feb 2015 21:19:09 -0000 The following errata report has been verified for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4271 -------------------------------------- Status: Verified Type: Technical Reported by: Neil Jenkins Date Reported: 2015-02-12 Verified by: Barry Leiba (IESG) Section: 3.3.10 Original Text ------------- Recurrence rules may generate recurrence instances with an invalid date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM on a day where the local time is moved forward by an hour at 1:00 AM). Such recurrence instances MUST be ignored and MUST NOT be counted as part of the recurrence set. Corrected Text -------------- Recurrence rules may generate recurrence instances with an invalid date (e.g., February 30). Such recurrence instances MUST be ignored and MUST NOT be counted as part of the recurrence set. Recurrence rules may generate recurrence instances with a nonexistent local time ((e.g., 1:30 AM on a day where the local time is moved forward by an hour at 1:00 AM). Such recurrence instances are handled as specified in Section 3.3.5. Notes ----- The section about ignoring times that don't occur in the timezone of the expansion is contradicted by the later passage (p44): """If the computed local start time of a recurrence instance does not exist, or occurs more than once, for the specified time zone, the time of the recurrence instance is interpreted in the same manner as an explicit DATE-TIME value describing that date and time, as specified in Section 3.3.5.""" And this is the behaviour implemented by major clients such as Calendar.app and Google Calendar. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Feb 17 16:53:39 2015 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 1BA431A8A42; Tue, 17 Feb 2015 16:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 BBpPr8HdjJ4e; Tue, 17 Feb 2015 16:53:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4301A1B36; Tue, 17 Feb 2015 16:53:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150218005335.11769.56684.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 16:53:35 -0800 Archived-At: Cc: calsify@ietf.org Subject: [calsify] Last Call: (Non-Gregorian Recurrence Rules in iCalendar) to Proposed Standard X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:53:37 -0000 The IESG has received a request from the Calendaring Extensions WG (calext) to consider the following document: - 'Non-Gregorian Recurrence Rules in iCalendar' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines extensions to iCalendar (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how CalDAV (RFC 4791) servers and clients can be extended to support these new recurrence rules. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-calext-rscale/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-calext-rscale/ballot/ No IPR declarations have been submitted directly on this I-D.