From ietf-calsify-bounces@osafoundation.org Mon Mar 10 21:03:46 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB1B3A699F for ; Mon, 10 Mar 2008 21:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3O9YC17spvq for ; Mon, 10 Mar 2008 21:03:42 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 6EF523A67B6 for ; Mon, 10 Mar 2008 21:03:26 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 507227FE2D; Mon, 10 Mar 2008 21:01:05 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4C0E67FCD4 for ; Mon, 10 Mar 2008 21:01:04 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9C4A1142228 for ; Mon, 10 Mar 2008 21:01:06 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db1-mA50Myfv for ; Mon, 10 Mar 2008 21:00:59 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 672A1142212 for ; Mon, 10 Mar 2008 21:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 20A223E38BB for ; Tue, 11 Mar 2008 00:00:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZGv8h-E2eq9 for ; Tue, 11 Mar 2008 00:00:53 -0400 (EDT) Received: from dhcp-1790.ietf71.ietf.org (unknown [63.133.180.130]) by daboo.name (Postfix) with ESMTP id 25A3C3E38B4 for ; Tue, 11 Mar 2008 00:00:53 -0400 (EDT) Date: Tue, 11 Mar 2008 00:00:36 -0400 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] Issue 95: text on REQUEST-STATUS X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi, Here is some proposed text to address issue 95 in the tracker. . This text would replace the one line of text currently above the table in section 3.1.6 in 2446bis: 3.6 Status Replies The "REQUEST-STATUS" property is used to convey status information about a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes listed in the table below SHOULD be used. Additional codes MAY be used provided it is known that the recipient's CUA has appropriate knowledge of such codes. This specification allows for multiple "REQUEST-STATUS" properties to be returned in iCalendar components in the appropriate iTIP messages. When multiple "REQUEST-STATUS" properties are present, the following restrictions apply: 1) Within any one component, the "top-level" numeric value of the "short return status code" MUST be the same for all REQUEST-STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a single component. 2) Across all components in the iTIP message, the following applies: a) If any one component would have a 3.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. b) If any one component would have a 5.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. This rule overrides (a) above. c) 2.xx and 4.xx codes can be used in different components provided that each component follows the restriction in (1) above. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 10 21:28:07 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333F028C152 for ; Mon, 10 Mar 2008 21:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tPCAM4O817Y for ; Mon, 10 Mar 2008 21:28:06 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id BF1FA3A68A0 for ; Mon, 10 Mar 2008 21:28:05 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 1F8758092A; Mon, 10 Mar 2008 21:25:45 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 229C37FCD4 for ; Mon, 10 Mar 2008 21:25:44 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 75BC1142212 for ; Mon, 10 Mar 2008 21:25:46 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLGWGOwf+P0w for ; Mon, 10 Mar 2008 21:25:37 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1AF90142228 for ; Mon, 10 Mar 2008 21:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 471C03E3AC9 for ; Tue, 11 Mar 2008 00:25:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJogoO2kp1zn for ; Tue, 11 Mar 2008 00:25:33 -0400 (EDT) Received: from dhcp-1790.ietf71.ietf.org (unknown [63.133.180.130]) by daboo.name (Postfix) with ESMTP id E87FD3E3AC2 for ; Tue, 11 Mar 2008 00:25:32 -0400 (EDT) Date: Tue, 11 Mar 2008 00:25:15 -0400 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] Issue 86 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi, Below is some addition text to partly address issue 86. . This is one piece in the ongoing clarification of SEQUENCE. Another clarification will be done on whether SEQUENCE can be different in components in the same recurrence set. 2.1.4 ... Whilst a change in SEQUENCE number is indicative of a significant change to a previously scheduled item that should be brought to the attention of a calendar user, ATTENDEE CUAs SHOULD NOT rely solely on a change in SEQUENCE as a means of alerting a calendar user to a change. Instead CUAs SHOULD compare the old and new versions of the calendar components and determine the exact nature of the changes and make decisions, possible based on calendar user preferences, as to whether the user needs to be explicitly informed of the change. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Mar 11 07:10:18 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C9528C3C4 for ; Tue, 11 Mar 2008 07:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_34=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kDQ9O2lpRQ5 for ; Tue, 11 Mar 2008 07:10:16 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 4635D3A6903 for ; Tue, 11 Mar 2008 07:10:16 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 15C118043B; Tue, 11 Mar 2008 07:07:56 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E28877F9CC for ; Tue, 11 Mar 2008 07:07:54 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43905142229 for ; Tue, 11 Mar 2008 07:07:57 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-InKHnPVU5N for ; Tue, 11 Mar 2008 07:07:46 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F38614222C for ; Tue, 11 Mar 2008 07:07:46 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id zoAb1Y0031HpZEsA209L00; Tue, 11 Mar 2008 14:06:57 +0000 Received: from THare ([71.203.100.120]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id zq7d1Y00R2brFRz8a00000; Tue, 11 Mar 2008 14:07:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=VE6_KAKKAAAA:8 a=PFsjAnyDAAAA:8 a=ZvXawCQs5LtEqCCsXnoA:9 a=TN2ZvA37RrV3nIcnr4gA:7 a=cWQN3E3hLwxF0SKKEg16RCnfnlkA:4 a=YewFc9KQ5U8A:10 a=XF7b4UCPwd8A:10 From: "Tim Hare" To: "'Cyrus Daboo'" , Subject: RE: [Ietf-calsify] Issue 86 Date: Tue, 11 Mar 2008 10:07:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AciDL/u57xSouai6QYKs2GWUt/J2pQAUCboA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Message-Id: <20080311140746.7F38614222C@laweleka.osafoundation.org> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This doesn't seem right to me, somehow. It seems as though we are somehow specifying how the CUA interacts with the user (whether to be notified or not, etcetera). This, to me, does not belong in iTIP . iTIP should be solely about the exchange of calendaring information between two calendaring tools; adding CUA<->user interaction is really outside the scope of iTIP. As such, it adds un-needed complexity to the document which doesn't advance the goals of simplification and interoperability. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Cyrus Daboo Sent: Tuesday, March 11, 2008 12:25 AM To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Issue 86 Hi, Below is some addition text to partly address issue 86. . This is one piece in the ongoing clarification of SEQUENCE. Another clarification will be done on whether SEQUENCE can be different in components in the same recurrence set. 2.1.4 ... Whilst a change in SEQUENCE number is indicative of a significant change to a previously scheduled item that should be brought to the attention of a calendar user, ATTENDEE CUAs SHOULD NOT rely solely on a change in SEQUENCE as a means of alerting a calendar user to a change. Instead CUAs SHOULD compare the old and new versions of the calendar components and determine the exact nature of the changes and make decisions, possible based on calendar user preferences, as to whether the user needs to be explicitly informed of the change. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Mar 11 07:13:18 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B004128C351 for ; Tue, 11 Mar 2008 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ereXiHOwrCif for ; Tue, 11 Mar 2008 07:13:14 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 2DC2628C434 for ; Tue, 11 Mar 2008 07:13:14 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 0755F7FF4C; Tue, 11 Mar 2008 07:10:54 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A7A807F9CC for ; Tue, 11 Mar 2008 07:10:52 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E4DDE14223E for ; Tue, 11 Mar 2008 07:10:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTIwEWURBKEA for ; Tue, 11 Mar 2008 07:10:48 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21F1F142229 for ; Tue, 11 Mar 2008 07:10:48 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id znnA1Y00G17UAYkAA0AS00; Tue, 11 Mar 2008 14:10:38 +0000 Received: from THare ([71.203.100.120]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id zqAd1Y0082brFRz8Z00000; Tue, 11 Mar 2008 14:10:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=ncHgQnoCPMIA:10 a=VE6_KAKKAAAA:8 a=PFsjAnyDAAAA:8 a=ek_QrCG2vNzMHJXn_HIA:9 a=BnUlCaTvwUbh2tdd_pwA:7 a=tF5R0rsj8GIKtIb__0RJTD2lkh4A:4 a=YewFc9KQ5U8A:10 a=gFYf5DKMwWcA:10 From: "Tim Hare" To: "'Cyrus Daboo'" , Subject: RE: [Ietf-calsify] Issue 95: text on REQUEST-STATUS Date: Tue, 11 Mar 2008 10:10:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AciDLIj6o1zDQzeNS6emPWc3jWiHeQAVMgKA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Message-Id: <20080311141048.21F1F142229@laweleka.osafoundation.org> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org "Additional codes MAY be used provided it is known that the recipient's CUA has appropriate knowledge of such codes." This is not a good thing for interoperability. CUA-specific status codes need to be an X- component (ex: X-MYCAL-REQUEST-STATUS). The only way one end can know for certain the other end "has appropriate knowledge of such codes" is if both are from the same vendor. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Cyrus Daboo Sent: Tuesday, March 11, 2008 12:01 AM To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Issue 95: text on REQUEST-STATUS Hi, Here is some proposed text to address issue 95 in the tracker. . This text would replace the one line of text currently above the table in section 3.1.6 in 2446bis: 3.6 Status Replies The "REQUEST-STATUS" property is used to convey status information about a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes listed in the table below SHOULD be used. Additional codes MAY be used provided it is known that the recipient's CUA has appropriate knowledge of such codes. This specification allows for multiple "REQUEST-STATUS" properties to be returned in iCalendar components in the appropriate iTIP messages. When multiple "REQUEST-STATUS" properties are present, the following restrictions apply: 1) Within any one component, the "top-level" numeric value of the "short return status code" MUST be the same for all REQUEST-STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a single component. 2) Across all components in the iTIP message, the following applies: a) If any one component would have a 3.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. b) If any one component would have a 5.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. This rule overrides (a) above. c) 2.xx and 4.xx codes can be used in different components provided that each component follows the restriction in (1) above. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Mar 14 14:16:00 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877283A6B9A for ; Fri, 14 Mar 2008 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.694 X-Spam-Level: X-Spam-Status: No, score=-3.694 tagged_above=-999 required=5 tests=[AWL=2.905, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGcs2jScJsE5 for ; Fri, 14 Mar 2008 14:15:59 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id EBB753A67B6 for ; Fri, 14 Mar 2008 14:15:58 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 4AE88808A1; Fri, 14 Mar 2008 14:13:41 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 65C2C7FCC0 for ; Fri, 14 Mar 2008 14:13:39 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B710F142230 for ; Fri, 14 Mar 2008 14:13:41 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9N87Q1pgn9u for ; Fri, 14 Mar 2008 14:13:29 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13F58142213 for ; Fri, 14 Mar 2008 14:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DB94B411970 for ; Fri, 14 Mar 2008 17:13:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gUlDw9aGLFr for ; Fri, 14 Mar 2008 17:13:25 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 9EF42411969 for ; Fri, 14 Mar 2008 17:13:24 -0400 (EDT) Date: Fri, 14 Mar 2008 17:13:21 -0400 From: Cyrus Daboo To: Calsify Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] 2445bis problem X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi, I think there is a problem in the recurrence description section 3.3.10 in 2445bis: The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. BYMONTH is special-cased twice with different meaning. It also goes on to state: Furthermore, the BYDAY rule part MUST NOT be specified with a numeric value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part is specified. However, that means the BYWEEKNO description in the earlier statement is bogus! At this point, I have to say I am still slightly confused about all the combinations of BYDAY plus the other BYxxx's. I really think more clarity is needed here - even at this late stage. I am going to try and put together a complete set of examples for all the possible combinations of numeric/non-numeric BYDAY with YEARLY/MONTHLY and other BYxxx rules and see whether all those make sense in terms of the current statements in 2445bis. This might take a while but I think is an important step to verify that we have the description of all these BYxxx's right. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Mar 14 14:27:55 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE873A6A7C for ; Fri, 14 Mar 2008 14:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNR8mtGvu9Sx for ; Fri, 14 Mar 2008 14:27:54 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 1DBF83A68A4 for ; Fri, 14 Mar 2008 14:27:54 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 30FF78058A; Fri, 14 Mar 2008 14:25:31 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3535D7FC1F for ; Fri, 14 Mar 2008 14:25:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 87F81142230 for ; Fri, 14 Mar 2008 14:25:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5ConNe18ods for ; Fri, 14 Mar 2008 14:25:23 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1B6B4142213 for ; Fri, 14 Mar 2008 14:25:22 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2ELPHNd005319 for ; Fri, 14 Mar 2008 22:25:17 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2445bis problem Date: Fri, 14 Mar 2008 22:25:12 +0100 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803142225.12900.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Am Freitag, 14. M=E4rz 2008 schrieb Cyrus Daboo: > It also goes on to state: > > =A0 =A0 Furthermore, the BYDAY rule part MUST NOT be specified with a num= eric > =A0 =A0 value with the FREQ rule part set to YEARLY when the BYWEEKNO rul= e part > =A0 =A0 is specified. Doesn't this make it impossible to recur on yearly on e.g. Wednesday of=20 calendar week 3? Notice that if Jan 1 is a Thursday, that's the second=20 Wednesday of the year, in all other cases it's the third Wednesday... Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Mar 14 14:34:34 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426B63A67E9 for ; Fri, 14 Mar 2008 14:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=2.107, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar+4XyiQSdRl for ; Fri, 14 Mar 2008 14:34:33 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id F1B0C3A6A7C for ; Fri, 14 Mar 2008 14:34:32 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 45A9480B0D; Fri, 14 Mar 2008 14:32:15 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 72CEF80AD8 for ; Fri, 14 Mar 2008 14:32:13 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4374142230 for ; Fri, 14 Mar 2008 14:32:15 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWAfmBiXopLD for ; Fri, 14 Mar 2008 14:32:09 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59732142213 for ; Fri, 14 Mar 2008 14:32:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7A9A7411D4B; Fri, 14 Mar 2008 17:32:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7H6hHEM5Yaw; Fri, 14 Mar 2008 17:32:06 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 4B5BD411D44; Fri, 14 Mar 2008 17:32:05 -0400 (EDT) Date: Fri, 14 Mar 2008 17:32:02 -0400 From: Cyrus Daboo To: Reinhold Kainhofer , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2445bis problem Message-ID: In-Reply-To: <200803142225.12900.reinhold@kainhofer.com> References: <200803142225.12900.reinhold@kainhofer.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Reinhold, --On March 14, 2008 10:25:12 PM +0100 Reinhold Kainhofer=20 wrote: >> =C2=A0 =C2=A0 Furthermore, the BYDAY rule part MUST NOT be specified = with a >> numeric =C2=A0 =C2=A0 value with the FREQ rule part set to YEARLY when = the >> BYWEEKNO rule part =C2=A0 =C2=A0 is specified. > > Doesn't this make it impossible to recur on yearly on e.g. Wednesday of > calendar week 3? Notice that if Jan 1 is a Thursday, that's the second > Wednesday of the year, in all other cases it's the third Wednesday... Isn't that just: RRULE:FREQ=3DYEARLY;BYWEEKNO=3D3;BYDAY=3DWE Are you saying that you might want to only pick the instance if its the 2nd = Wednesday of the year? --=20 Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 06:08:37 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAF728C10A for ; Mon, 17 Mar 2008 06:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pINQdshkIiCg for ; Mon, 17 Mar 2008 06:08:36 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 14D8F28C113 for ; Mon, 17 Mar 2008 06:08:11 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 4DE5080BB4; Mon, 17 Mar 2008 06:05:44 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DEB1080BA4 for ; Mon, 17 Mar 2008 06:05:42 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3AA5E14223F for ; Mon, 17 Mar 2008 06:05:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuxRWjiZuSFL for ; Mon, 17 Mar 2008 06:05:31 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id F11B814223E for ; Mon, 17 Mar 2008 06:05:30 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 5c7c860142b43253ab4884210e773d33 X-Spam-Score-Summary: 2, 0, 0, f9b5a89c6b930cdf, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:355:379:539:540:541:542:543:567:600:601:602:946:960:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2551:2553:2559:2562:2828:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4605:5007:6119:6261:7576:7802:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id for ; Mon, 17 Mar 2008 06:05:28 -0700 Message-ID: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> From: "Nigel Swinson" To: Subject: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 13:05:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This mislaid feedback is still valid, and highlights the same point that Cyrus just raised with proposed text for a fix. ----- Original Message ----- From: "Nigel Swinson" To: Sent: Friday, February 08, 2008 4:14 PM Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt > 3. iCalendar Object Specification > > Section 3.1. defines the content line format; Section 3.2. defines > the property parameter format; Section 3.3. defines the data types > for property values; Section 3.4. defines the iCalendar object > format; Section 3.5. defines the iCalendar property format; Section > 3.6. defines the calendar component format; Section 3.7. defines > - calendar properties; and Sectiopn 3.8. defines calendar component > + calendar properties; and Section 3.8. defines calendar component > properties. > > 3.3.10. Recurrence Rule > > represents the last Monday of the month. The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the month when the BYMONTH rule part is > present, and corresponds to an offset within the year when the > BYWEEKNO or BYMONTH rule parts are present. If an integer > modifier is not present, it means all days of this type within the > > ie: > > The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY > corresponds to: > - an offset within the month > ---when the BYMONTH rule part is present, > - and corresponds to an offset within the year > -- when the BYWEEKNO **or** BYMONTH rule parts are present. > > So if BYMONTH is present, does that mean the offset is within a year or a > month? Both options match. > > I still think it's an non intuative shame that > FREQ=YEARLY;BYDAY=3MO;BYMONTH=11 means the 3rd Monday in November rather > than the 3rd Monday of the year when it falls in November, so I think it has > to be: > > represents the last Monday of the month. The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the month when the BYMONTH rule part is > - present, and corresponds to an offset within the year when the > - BYWEEKNO or BYMONTH rule parts are present. If an integer > + present, and corresponds to an offset within the year otherwise. > + If an integer > modifier is not present, it means all days of this type within the > > Then a trivial one: > > The BYSETPOS rule part specifies a COMMA character (US-ASCII > decimal 44) separated list of values which corresponds to the nth > occurrence within the set of recurrence instances specified by the > rule. BYSETPOS operates on a set of recurrence instances in one > interval of the recurrence rule. For example, in a WEEKLY rule, > - the interval would be one week A set of recurrence instances > + the interval would be one week. A set of recurrence instances > starts at the beginning of the interval defined by the FREQ rule > part. Valid values are 1 to 366 or -366 to -1. It MUST only be > used in conjunction with another BYxxx rule part. For example > "the last work day of the month" could be represented as: > > Cheers > > Nigel > _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 06:08:37 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED0F28C113 for ; Mon, 17 Mar 2008 06:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7gbkBTmUHxy for ; Mon, 17 Mar 2008 06:08:36 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id B596D3A6868 for ; Mon, 17 Mar 2008 06:08:28 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 861E780BF1; Mon, 17 Mar 2008 06:06:11 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A44980BAE for ; Mon, 17 Mar 2008 06:06:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AC14314223D for ; Mon, 17 Mar 2008 06:06:12 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIo0v2BtDh9y for ; Mon, 17 Mar 2008 06:06:00 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1257914223F for ; Mon, 17 Mar 2008 06:06:00 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: ed37adaa6bc7ce960b61355dc7881ce1 X-Spam-Score-Summary: 2, 0, 0, f5fc20912ab48f6a, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:69:355:379:539:540:541:542:543:567:600:601:945:960:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1544:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2379:2393:2551:2553:2559:2562:2693:2828:2893:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4605:5007:6117:6118:6119:6261:7576:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 06:05:56 -0700 Message-ID: <01e301c8882f$b46caa80$6501a8c0@nigelhome> From: "Nigel Swinson" To: Date: Mon, 17 Mar 2008 13:06:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [Ietf-calsify] De-mystifying the limit/expand behaviour of BYXX modifiers X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org > At this point, I have to say I am still slightly confused about all the > combinations of BYDAY plus the other BYxxx's. I really think more clarity > is needed here - even at this late stage. I quite agree Cyrus. I'll try for a third time to pass on my suggestions. ----- Original Message ----- From: "Nigel Swinson" To: Sent: Friday, February 08, 2008 4:15 PM Subject: De-mystifying the limit/expand behaviour of BYXX modifiers Second unanswered point from a mail form 21st September that nobody seemed to receive: Rather than give you lots more text to read, can I just urge you to (re)read the text below and provide opinions. I think recurrence is the most complicated part of iCalendar, and think it's worth crafting the addition of the new table just a little more. - The phrase "special expand" is mentioned nowhere else in the document. I think the concept was better expressed by my suggestion from the 29th May. You merge the "Expand" cells in the Yearly/Monthly columns to illustrate that each creates a set, and when taken together it's the union of the sets. Also even with a numeric modifier on ByDay, it's still the case that Monthly/Yearly + BYDAY will expand, and while it's true that numeric modifiers on ByDay with yearly rules requires attention, I think it's adequately dealt with in the paragraphs above on ByDay. So I'd make it: - BYDAY has some special behaviour depending on the FREQ value and - this is described in separate notes below the table. +----------+--------+--------+-------+-------+------+-------+------+ | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| - +----------+--------+--------+-------+-------+------+-------+------+ + |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | | + +----------+--------+--------+-------+-------+------+-------+ + + |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | | + +----------+--------+--------+-------+-------+------+-------+ + + |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| + +----------+--------+--------+-------+-------+------+-------+ + + |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | | + +----------+--------+--------+-------+-------+------+Expand + + + |BYDAY |Limit |Limit |Limit |Limit |Expand| | | + +----------+--------+--------+-------+-------+------+-------+------+ |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| +----------+--------+--------+-------+-------+------+-------+------+ |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| +----------+--------+--------+-------+-------+------+-------+------+ |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| +----------+--------+--------+-------+-------+------+-------+------+ |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | +----------+--------+--------+-------+-------+------+-------+------+ - Note 1: Limit if BYMONTHDAY is present, otherwise special expand - for MONTHLY. - - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise - special expand for WEEKLY if BYWEEKNO present, otherwise - special expand for MONTHLY if BYMONTH present, otherwise - special expand for YEARLY. + In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY work + together to expand the recurrence set. Each on their own will specify + a range of valid instances, and when used in combination it is the union + of all ranges that create the required recurrence set. So for example + in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1 will + mean the first of every month, so when used together they mean the first of + every month, but only when it's a Monday. It would not mean on the first + of every month and also on every Monday. Likewise in MONTHLY rules, + BYMONTHDAY and BYDAY work together to expand the recurrence set. Nigel _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 06:08:42 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF1A28C113 for ; Mon, 17 Mar 2008 06:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je8tlFemtPfJ for ; Mon, 17 Mar 2008 06:08:34 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 2103228C414 for ; Mon, 17 Mar 2008 06:07:53 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 76F2180B68; Mon, 17 Mar 2008 06:05:35 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 70C6F80B5D for ; Mon, 17 Mar 2008 06:05:33 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C27E014223F for ; Mon, 17 Mar 2008 06:05:35 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLw7Jz7X3C0l for ; Mon, 17 Mar 2008 06:05:26 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4800D14223D for ; Mon, 17 Mar 2008 06:05:26 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: ba22ee18b1fdd63a12cf1ca3b11beb0d X-Spam-Score-Summary: 2, 0, 0, 7509253e80545e6d, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:4:355:379:539:540:541:542:543:567:599:601:945:960:967:973:980:982:988:989:1000:1042:1155:1156:1261:1308:1309:1313:1314:1345:1437:1515:1516:1518:1542:1575:1587:1594:1711:1730:1747:1764:1766:1792:2073:2075:2078:2110:2198:2199:2379:2393:2525:2551:2553:2559:2563:2682:2685:2692:2693:2857:2859:2892:2893:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4427:5007:6119:6261:6506:7281:7398:7576:7679:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,iso-8859-1,iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 06:05:19 -0700 Message-ID: <01ce01c8882f$9e01fcf0$6501a8c0@nigelhome> From: "Nigel Swinson" To: "Cyrus Daboo" References: Subject: Re: [Ietf-calsify] 2445bis problem Date: Mon, 17 Mar 2008 13:05:45 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C9_01C8882F.9CACF440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: Calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. ------=_NextPart_000_01C9_01C8882F.9CACF440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > The numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY corresponds to an offset within the month when the BYMONTH rule > part is present, and corresponds to an offset within the year when the > BYWEEKNO or BYMONTH rule parts are present. > > BYMONTH is special-cased twice with different meaning. > > It also goes on to state: > > Furthermore, the BYDAY rule part MUST NOT be specified with a numeric > value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part > is specified. > > However, that means the BYWEEKNO description in the earlier statement is > bogus! Agreed :o) Irritatingly I made this very point to the list on the 8th Feb this year, but the post got eaten. :o( > At this point, I have to say I am still slightly confused about all the > combinations of BYDAY plus the other BYxxx's. I really think more clarity > is needed here - even at this late stage. I've been lobbying for this for quite some time. Sadly our company wanted to change email addresses from rockliffe.com to mailsite.com and in the change the calsify list software has been silently ignoring may last 5 posts to this list (I would have expected a bounce). I shall re-post them once I've persuaded to listen to me at mailsite.com. Ironically one of the messages it ate was as below: From: "Nigel Swinson" To: Sent: Friday, February 08, 2008 4:14 PM Subject: [Ietf-calsify] working group last call comments for draft-ietf-calsify-rfc2445bis-07.txt] > While reviewing http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08, > I wondered what would happen about recurrence rules, as I'd not seen much > discussion on the list on the topic. Looking in the archive, I notice that > the attached message never made it to the archive, and thus possibly never > made it to any of you. I guess that would partly explain the lack of > response, although I suspect it is largely because recurrence rules are > complex with a lot of corner cases, and it's hard to think about them. This > is the very reason why I am proposing changes, to make that difficult and > error prone area as easy as possible to understand. > > While I attach my message from September, I shall include re-send each open > item as a separate thread, in the hope that folks might respond to at least > one of the three open issues. > > Nigel ------=_NextPart_000_01C9_01C8882F.9CACF440 Content-Type: message/rfc822; name="Re_ [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re_ [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt.eml" From: "Nigel Swinson" To: "CALSIFY Mailinglist" Cc: "Bernard Desruisseaux" , "Eliot Lear" References: <46C033F0.6010203@cisco.com> <46E99A9E.4010906@oracle.com> Subject: Re: [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt Date: Fri, 21 Sep 2007 17:15:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 > Hi Nigel, > > "Not changed for now" meant that I would not do the change > until we have had input from the working group. > > Cheers, > Bernard Ok so there are 3 issues remaining from my feedback, two of which require additional input from the working group to proceed. So could folks please have a read through and comment? I care about the third one the most... > >> 3.3.10. Recurrence Rule > >> > >> The UNTIL rule part defines a DATE or DATE-TIME value which bounds > >> the recurrence rule in an inclusive manner. If the value > >> specified by UNTIL is synchronized with the specified recurrence, > >> this DATE or DATE-TIME becomes the last instance of the > >> recurrence. The value of the UNTIL rule part MUST have the same > >> value type as the "DTSTART" property. Furthermore, if the > >> "DTSTART" property is specified as a date with local time, then > >> the UNTIL rule part MUST also be specified as a date with local > >> time. If the "DTSTART" property is specified as a date with > >> UTC time or a date with local time and time zone reference, then > >> the UNTIL rule part MUST be specified as a date with UTC time. In > >> the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL > >> - rule part MUST always be specified as a date with UTC time. If > >> - specified as a DATE-TIME value, then it MUST be specified in a UTC > >> - time format. If not present, and the COUNT rule part is also not > >> + rule part MUST always be specified as a date with UTC time, > >> with the > >> + "DTSTART" always represented as a date with local time. If the > >> UNTIL > >> + and COUNT rule parts are not >>> present, the "RRULE" is considered to repeat forever. > >> > > > > Substantial. > > Nigel's addition is not substantial. It is repeating what is > already specified in section 4.6.5 "Time Zone Component" of > RFC 2445, that is: > > The mandatory "DTSTART" property gives the effective onset date and > local time for the time zone sub-component definition. "DTSTART" in > this usage MUST be specified as a local DATE-TIME value. > > I'm not convinced we should repeat this information. > > No change done. The existing text has this: ... In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. ....... One of my objectives was to get rid of the second sentence, as I don't think it adds anything, and in the context of the whole paragraph it's confusing to know what the second sentence is even refering to. If this second sentence is to stay could someone please explain what it adds? My second objective was indeed to correlate more fully the relationship between DTSTART and UNTIL as it says in 4.6.5. The start of the paragraph has described this relationship in detail for DTSTART and UNTIL under normal circumstances, but then goes on to talk about the behaviour within the STANDARD/DAYLIGHT components. I think either it should leave all the discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or complete the discussion by saying, as I had suggested, that UNTIL is always date with UTC time and DTSTART is always date with local time. My third objective was to cleanup the language of the last sentence. So please can we have either: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + rule part MUST always be specified as a date with UTC time, with the + "DTSTART" always represented as a date with local time. If the UNTIL + and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. Or: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then - the UNTIL rule part MUST be specified as a date with UTC time. In - the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + the UNTIL rule part MUST be specified as a date with UTC time. + If the UNTIL and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. > >> WRT to the text below I think we should either: > >> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules, > >> - Specify what the "interval" for daily, hourly, minutely, secondly > >> means. > >> - Drop the new text, as I think the example is sufficient illustration. > >> - Change the example to illustrate what obscurity it was that lead to the > >> need for the new text. > >> > >> My vote would be to drop some of the new text to become: > >> > >> The BYSETPOS rule part specifies a COMMA character (US-ASCII > >> decimal 44) separated list of values which corresponds to the nth > >> occurrence within the set of recurrence instances specified by the > >> rule. BYSETPOS operates on a set of recurrence instances in one > >> - interval of the recurrence rule. For a WEEKLY rule, the interval > >> - is one week, for a MONTHLY rule, one month, and for a YEARLY rule, > >> - one year. Valid values are 1 to 366 or -366 to -1. It MUST only > >> + interval of the recurrence rule. > >> + Valid values are 1 to 366 or -366 to -1. It MUST only > >> be used in conjunction with another BYxxx rule part. For example > >> "the last work day of the month" could be represented as: > >> > >> FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 > >> > >> Each BYSETPOS value can include a positive (+n) or negative (-n) > >> integer. If present, this indicates the nth occurrence of the > >> specific occurrence within the set of occurences specified by the > >> rule. > > > > Substantial. > > Not changed. I think this is important, as currently we have it's an inconsistent level of specification, which I think leaves it vague what BYSETPOS means with daily, hourly, minutely, secondly. Could people please comment/vote? > >> The phrase "special expand" is mentioned nowhere else in the document. I > >> think the concept was better expressed by my suggestion from the 29th May. > >> You merge the "Expand" cells in the Yearly/Monthly columns to illustrate > >> that each creates a set, and when taken together it's the union of the sets. > >> Also even with a numeric modifier on ByDay, it's still the case that > >> Monthly/Yearly + BYDAY will expand, and while it's true that numeric > >> modifiers on ByDay with yearly rules requires attention, I think it's > >> adequately dealt with in the paragraphs above on ByDay. So I'd make it: > >> > >> - BYDAY has some special behaviour depending on the FREQ value and > >> - this is described in separate notes below the table. > >> > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> + |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | | > >> + +----------+--------+--------+-------+-------+------+-------+ + > >> + |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | | > >> + +----------+--------+--------+-------+-------+------+-------+ + > >> + |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| > >> + +----------+--------+--------+-------+-------+------+-------+ + > >> + |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | | > >> + +----------+--------+--------+-------+-------+------+Expand + + > >> + |BYDAY |Limit |Limit |Limit |Limit |Expand| | | > >> + +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> > >> - Note 1: Limit if BYMONTHDAY is present, otherwise special expand > >> - for MONTHLY. > >> - > >> - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise > >> - special expand for WEEKLY if BYWEEKNO present, otherwise > >> - special expand for MONTHLY if BYMONTH present, otherwise > >> - special expand for YEARLY. > >> > >> + In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY work > >> + together to expand the recurrence set. Each on their own will specify > >> + a range of valid instances, and when used in combination it is the union > >> + of all ranges that create the required recurrence set. So for example > >> + in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1 will > >> + mean the first of every month, so when used together they mean the first of > >> + every month, but only when it's a Monday. It would not mean on the first > >> + of every month and also on every Monday. Likewise in MONTHLY rules, > >> + BYMONTHDAY and BYDAY work together to expand the recurrence set. > >> > > > > > > Substantial and editorial. The combining of boxes is editorial. > > Not changed for now. > Rather than give you lots more text to read, can I just urge you to (re)read the text above and provide opinions. I think recurrence is the most complicated part of iCalendar, and think it's worth crafting the addition of the new table just a little more. > Nigel: Thanks a lot! You are most welcome. Thanks for processing my feedback :o) Nigel ------=_NextPart_000_01C9_01C8882F.9CACF440 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify ------=_NextPart_000_01C9_01C8882F.9CACF440-- From ietf-calsify-bounces@osafoundation.org Mon Mar 17 06:08:42 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F1F3A6D17 for ; Mon, 17 Mar 2008 06:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+Ts4H4-4VOo for ; Mon, 17 Mar 2008 06:08:36 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 938AC3A6A01 for ; Mon, 17 Mar 2008 06:08:29 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id D3E5E80BCD; Mon, 17 Mar 2008 06:06:02 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F37B80BAE for ; Mon, 17 Mar 2008 06:06:01 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E146E142240 for ; Mon, 17 Mar 2008 06:06:03 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzdRePRBFGJp for ; Mon, 17 Mar 2008 06:05:52 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4A8F14223D for ; Mon, 17 Mar 2008 06:05:52 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 3f9abd001dd017d311c2100fc0c803e4 X-Spam-Score-Summary: 2, 0, 0, 21295486e2bc2226, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:1:2:355:379:476:539:540:541:542:543:567:600:601:602:945:962:967:973:980:983:988:989:1155:1156:1189:1208:1221:1261:1308:1309:1313:1314:1345:1394:1395:1431:1436:1437:1515:1516:1517:1521:1575:1587:1588:1589:1592:1594:1605:1617:1685:1730:1776:1792:2073:2075:2078:2198:2199:2551:2553:2557:2559:2562:2892:3521:3522:3523:3585:3635:3636:3769:3865:3866:3867:3868:3869:3870:3871:3872:3874:4051:4250:4605:4622:5007:6117:6119:6261:7576:7802:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,iso-8859-1,iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id for ; Mon, 17 Mar 2008 06:05:49 -0700 Message-ID: <01df01c8882f$b05610d0$6501a8c0@nigelhome> From: "Nigel Swinson" To: Date: Mon, 17 Mar 2008 13:06:16 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [Ietf-calsify] Fw: Discussion of UNTIL when used with STANDARD and DAYLIGHT sub-components X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1162124562==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============1162124562== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01C8882F.AF2272D0" This is a multi-part message in MIME format. ------=_NextPart_000_01D9_01C8882F.AF2272D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Third attempt at sending: ----- Original Message ----- From: Nigel Swinson To: ietf-calsify@osafoundation.org Sent: Friday, February 08, 2008 4:14 PM Subject: Discussion of UNTIL when used with STANDARD and DAYLIGHT sub-components First point from a mail form 21st September that nobody seemed to receive: > >> 3.3.10. Recurrence Rule > >> > >> The UNTIL rule part defines a DATE or DATE-TIME value which bounds > >> the recurrence rule in an inclusive manner. If the value > >> specified by UNTIL is synchronized with the specified recurrence, > >> this DATE or DATE-TIME becomes the last instance of the > >> recurrence. The value of the UNTIL rule part MUST have the same > >> value type as the "DTSTART" property. Furthermore, if the > >> "DTSTART" property is specified as a date with local time, then > >> the UNTIL rule part MUST also be specified as a date with local > >> time. If the "DTSTART" property is specified as a date with > >> UTC time or a date with local time and time zone reference, then > >> the UNTIL rule part MUST be specified as a date with UTC time. In > >> the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL > >> - rule part MUST always be specified as a date with UTC time. If > >> - specified as a DATE-TIME value, then it MUST be specified in a UTC > >> - time format. If not present, and the COUNT rule part is also not > >> + rule part MUST always be specified as a date with UTC time, > >> with the > >> + "DTSTART" always represented as a date with local time. If the > >> UNTIL > >> + and COUNT rule parts are not >>> present, the "RRULE" is considered to repeat forever. > >> > > > > Substantial. > > Nigel's addition is not substantial. It is repeating what is > already specified in section 4.6.5 "Time Zone Component" of > RFC 2445, that is: > > The mandatory "DTSTART" property gives the effective onset date and > local time for the time zone sub-component definition. "DTSTART" in > this usage MUST be specified as a local DATE-TIME value. > > I'm not convinced we should repeat this information. > > No change done. The existing text has this: ... In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. ....... One of my objectives was to get rid of the second sentence, as I don't think it adds anything, and in the context of the whole paragraph it's confusing to know what the second sentence is even refering to. If this second sentence is to stay could someone please explain what it adds? My second objective was indeed to correlate more fully the relationship between DTSTART and UNTIL as it says in 4.6.5. The start of the paragraph has described this relationship in detail for DTSTART and UNTIL under normal circumstances, but then goes on to talk about the behaviour within the STANDARD/DAYLIGHT components. I think either it should leave all the discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or complete the discussion by saying, as I had suggested, that UNTIL is always date with UTC time and DTSTART is always date with local time. My third objective was to cleanup the language of the last sentence. So please can we have either: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + rule part MUST always be specified as a date with UTC time, with the + "DTSTART" always represented as a date with local time. If the + UNTIL and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. Or: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then - the UNTIL rule part MUST be specified as a date with UTC time. In - the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + the UNTIL rule part MUST be specified as a date with UTC time. + If the UNTIL and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. Nigel ------=_NextPart_000_01D9_01C8882F.AF2272D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Third attempt at sending:
 
----- Original Message -----=20
From: Nigel=20 Swinson
Sent: Friday, February 08, 2008 4:14 PM
Subject: Discussion of UNTIL when used with STANDARD and = DAYLIGHT=20 sub-components

First point from a mail form 21st September that = nobody seemed=20 to receive:

> = >>=20 3.3.10.  Recurrence Rule
> >>
>=20 >>       The UNTIL rule part defines = a DATE=20 or DATE-TIME value which
bounds
>=20 >>       the recurrence rule in an = inclusive=20 manner.  If the value
> = >>      =20 specified by UNTIL is synchronized with the specified = recurrence,
>=20 >>       this DATE or DATE-TIME = becomes the=20 last instance of the
> = >>      =20 recurrence.  The value of the UNTIL rule part MUST have the = same
>=20 >>       value type as the "DTSTART" = property.  Furthermore, if the
>=20 >>       "DTSTART" property is = specified as=20 a date with local time, then
>=20 >>       the UNTIL rule part MUST = also be=20 specified as a date with local
>=20 >>       time.  If the = "DTSTART"=20 property is specified as a date with
>=20 >>       UTC time or a date with = local time=20 and time zone reference, then
>=20 >>       the UNTIL rule part MUST be = specified as a date with UTC time.
In
>=20 >>       the case of the "STANDARD" = and=20 "DAYLIGHT" sub-components the
UNTIL
> >>=20 -      rule part MUST always be specified as a = date=20 with UTC time.  If
> >> -      = specified as a DATE-TIME value, then it MUST be specified in = a
UTC
>=20 >> -      time format.  If not = present, and=20 the COUNT rule part is also
not
> >>=20 +      rule part MUST always be specified as a = date=20 with UTC time,
> >> with the
> >>=20 +      "DTSTART" always represented as a date = with=20 local time.  If the
> >> UNTIL
> >>=20 +      and COUNT rule parts are=20 not
>>>         = =20 present, the "RRULE" is considered to repeat forever.
> = >>
>=20 >
> > Substantial.
>
> Nigel's addition is not=20 substantial.  It is repeating what is
> already specified in = section=20 4.6.5 "Time Zone Component" of
> RFC 2445, that=20 is:
>
>     The mandatory "DTSTART" = property=20 gives the effective onset date and
>     local = time=20 for the time zone sub-component definition. "DTSTART"=20 in
>     this usage MUST be specified as a = local=20 DATE-TIME value.
>
> I'm not convinced we should repeat this = information.
>
> No change done.

The existing text = has=20 this:

      ... =20 In
      the case of the "STANDARD" and = "DAYLIGHT"=20 sub-components the UNTIL
      rule part = MUST always=20 be specified as a date with UTC time.  = If
     =20 specified as a DATE-TIME value, then it MUST be specified in a=20 UTC
      time format. .......

One of = my=20 objectives was to get rid of the second sentence, as I don't think
it = adds=20 anything, and in the context of the whole paragraph it's confusing
to = know=20 what the second sentence is even refering to.  If this = second
sentence=20 is to stay could someone please explain what it adds?

My second = objective=20 was indeed to correlate more fully the relationship
between DTSTART = and UNTIL=20 as it says in 4.6.5.  The start of the paragraph
has described = this=20 relationship in detail for DTSTART and UNTIL under = normal
circumstances, but=20 then goes on to talk about the behaviour within the
STANDARD/DAYLIGHT = components.  I think either it should leave all the
discussion = of it's=20 behaviour within STANDARD/DAYLIGHT to section 4.6.5, or
complete the=20 discussion by saying, as I had suggested, that UNTIL is always
date = with UTC=20 time and DTSTART is always date with local time.

My third = objective was=20 to cleanup the language of the last sentence.

So please can we = have=20 either:

       time.  If the = "DTSTART"=20 property is specified as a date = with
       UTC=20 time or a date with local time and time zone reference,=20 then
       the UNTIL rule part MUST be = specified as a date with UTC time. =20 In
       the case of the "STANDARD" = and=20 "DAYLIGHT" sub-components the = UNTIL
 -     =20 rule part MUST always be specified as a date with UTC time. =20 If
 -      specified as a DATE-TIME = value, then=20 it MUST be specified in a UTC
 -      = time=20 format.  If not present, and the COUNT rule part is also=20 not
 +      rule part MUST always be = specified=20 as a date with UTC time, with = the
 +     =20 "DTSTART" always represented as a date with local time.  If=20 the
+       UNTIL and COUNT rule parts = are=20 not
       present, the "RRULE" is = considered=20 to repeat = forever.

Or:

      =20 time.  If the "DTSTART" property is specified as a date=20 with
       UTC time or a date with = local time=20 and time zone reference, then
-       = the UNTIL=20 rule part MUST be specified as a date with UTC time. =20 In
-       the case of the "STANDARD" = and=20 "DAYLIGHT" sub-components the = UNTIL
-      =20 rule part MUST always be specified as a date with UTC time. =20 If
-       specified as a DATE-TIME = value, then=20 it MUST be specified in a UTC
-       = time=20 format.  If not present, and the COUNT rule part is also=20 not
+       the UNTIL rule part MUST be = specified as a date with UTC = time.
+       If=20 the UNTIL and COUNT rule parts are = not
      =20 present, the "RRULE" is considered to repeat forever.
 
Nigel
------=_NextPart_000_01D9_01C8882F.AF2272D0-- --===============1162124562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============1162124562==-- From ietf-calsify-bounces@osafoundation.org Mon Mar 17 06:14:49 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E0D28C113 for ; Mon, 17 Mar 2008 06:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIMpiXN3Ol6L for ; Mon, 17 Mar 2008 06:14:48 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 479C43A6BDB for ; Mon, 17 Mar 2008 06:14:48 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 2658880BED; Mon, 17 Mar 2008 06:12:31 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E911080BB6 for ; Mon, 17 Mar 2008 06:12:29 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 470BC14223F for ; Mon, 17 Mar 2008 06:12:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQVQ9zTzToF0 for ; Mon, 17 Mar 2008 06:12:21 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9FA9F14223D for ; Mon, 17 Mar 2008 06:12:20 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HDCF4U010149 for ; Mon, 17 Mar 2008 14:12:15 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 14:12:12 +0100 User-Agent: KMail/1.9.6 References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> In-Reply-To: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171412.14523.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 17. März 2008 schrieb Nigel Swinson: > > The numeric value in a BYDAY rule part with the FREQ rule part set to > > YEARLY > > > corresponds to: > > - an offset within the month > > ---when the BYMONTH rule part is present, > > - and corresponds to an offset within the year > > -- when the BYWEEKNO **or** BYMONTH rule parts are present. > > > > So if BYMONTH is present, does that mean the offset is within a year or a > > month?  Both options match. > > > > I still think it's an non intuative shame that > > FREQ=YEARLY;BYDAY=3MO;BYMONTH=11 means the 3rd Monday in November rather > > than the 3rd Monday of the year when it falls in November, so I think it I think it should mean the 3rd monday in November. This becomes clear when you think of BYDAY in the same way as BYSETPOSITION: 1) Apply yearly, so all days in a year match 2) Apply BYMONTH, so only all dates in november match 3) Apply BYDAY, meaning the 3rd monday in the set of currently matching dates (which are just the days in november). 4) Apply all BYHOUR/BYMINUTE/BYSECOND (not present) 5) Take all missing information (i.e. time) from the DTSTART RFC 2445 makes it clear that the recurrence evaluation works on the list of matching date/times and limits or extends it step by step. That's the general algorithm as I understand it. The new elaboration in the RFC simply explains this in a different way. Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH3m4uTqjEwhXvPN0RAiR4AJwPE7UnVQhttq5EQiXkjy9MvIFduwCfRKwG QYvSXgX9DDfKeUTha33HEyk= =7Tvl -----END PGP SIGNATURE----- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 06:47:12 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9313A6D6A for ; Mon, 17 Mar 2008 06:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNGbEZadcMtk for ; Mon, 17 Mar 2008 06:47:11 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id A6AA03A6DA1 for ; Mon, 17 Mar 2008 06:46:07 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 8410480BA2; Mon, 17 Mar 2008 06:43:40 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EB2C680B68 for ; Mon, 17 Mar 2008 06:43:38 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4939514223F for ; Mon, 17 Mar 2008 06:43:41 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-pcs8FLt+-Z for ; Mon, 17 Mar 2008 06:43:27 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0614A14223E for ; Mon, 17 Mar 2008 06:43:26 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 6db77512e9327f6328842c82324ab401 X-Spam-Score-Summary: 2, 0, 0, ebcbd330c835c703, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2551:2553:2559:2562:2828:2892:3027:3740:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4321:4605:5007:6117:6119:6261:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 06:43:23 -0700 Message-ID: <025301c88835$010de070$6501a8c0@nigelhome> From: "Nigel Swinson" To: "Reinhold Kainhofer" References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 13:44:18 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org > > > I still think it's an non intuative shame that > > > FREQ=YEARLY;BYDAY=3MO;BYMONTH=11 means the 3rd Monday in November rather > > > than the 3rd Monday of the year when it falls in November, so I think it > > I think it should mean the 3rd monday in November. This becomes clear when you > think of BYDAY in the same way as BYSETPOSITION: Looking back, I think I meant to illustrate my complaint with: FREQ=YEARLY;BYDAY=MO;BYSETPOS=3;BYMONTH=11 But I think it's the same issue. > 1) Apply yearly, so all days in a year match > 2) Apply BYMONTH, so only all dates in november match > 3) Apply BYDAY, meaning the 3rd monday in the set of currently matching dates > (which are just the days in november). > 4) Apply all BYHOUR/BYMINUTE/BYSECOND (not present) > 5) Take all missing information (i.e. time) from the DTSTART It's step 3 where the intuative step breaks down for me. There's the establishing of the set, and the filtering the set. The only thing the defines the set is the FREQ component. The BYXX components filter the set. See what was defined for BYSETPOS WRT to sets: The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of recurrence instances specified by the * rule. BYSETPOS operates on a set of recurrence instances in one * interval of the recurrence rule. For example, in a WEEKLY rule, * the interval would be one week A set of recurrence instances * starts at the beginning of the interval defined by the FREQ rule part. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example "the last work day of the month" could be represented as: It could just have easily said "For example, in a YEARLY rule, the interval would be one year. A set of recurrence intstances starts at the beginning of the interval defined by the FREQ rule part." ie at the start of the year, irrespective of any BYXX parts. Or with the BYDAY text: Each BYDAY value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of a specific day within the MONTHLY or YEARLY "RRULE". * For example, within a MONTHLY rule, +1MO (or simply 1MO) * represents the first Monday within the month, whereas -1MO * represents the last Monday of the month. The numeric value in a It could just have easily said "For example, within a YEARLY rule, +1MO (or simply 1MO) represents the first Monday within the year, whereas -1MO represents the last Monday of the year.". But then it doesn't say that, instead it goes on to illustrate the special case: BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. If an integer Which of course equally doesn't make sense, see the thread Cyrus just started ;o) I'd have liked 3MO to be a short hand for BYDAY=MO, BYSETPOS = 3, in which case either with a yearly rule would always be the 3rd instance of Monday WRT to the start of the year. I appreciate we can't really change this anyway, as many TZ decls make use of this special case, including some in the standard itself (RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z), so I'm not lobbying we do so, I'm just stating that I think it's a shame, and it results in special cases in an already complicated area of the standard. Nigel _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 07:10:43 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9AB28C3B3 for ; Mon, 17 Mar 2008 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52dgcwuCCsbU for ; Mon, 17 Mar 2008 07:10:41 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id B442F28C3E8 for ; Mon, 17 Mar 2008 07:10:40 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 86E7380BBA; Mon, 17 Mar 2008 07:08:23 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 290DE80BB6 for ; Mon, 17 Mar 2008 07:08:22 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B475142241 for ; Mon, 17 Mar 2008 07:08:24 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7dHjMukp2k9 for ; Mon, 17 Mar 2008 07:08:13 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 607C014223F for ; Mon, 17 Mar 2008 07:08:12 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HE849U000455; Mon, 17 Mar 2008 15:08:04 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: "Nigel Swinson" , ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 15:08:03 +0100 User-Agent: KMail/1.9.6 References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> In-Reply-To: <025301c88835$010de070$6501a8c0@nigelhome> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171508.03917.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 17. März 2008 schrieben Sie: > > 1) Apply yearly, so all days in a year match > > 2) Apply BYMONTH, so only all dates in november match > > 3) Apply BYDAY, meaning the 3rd monday in the set of currently matching > > dates (which are just the days in november). > > 4) Apply all BYHOUR/BYMINUTE/BYSECOND (not present) > > 5) Take all missing information (i.e. time) from the DTSTART > > It's step 3 where the intuative step breaks down for me. There's the > establishing of the set, and the filtering the set. The only thing the > defines the set is the FREQ component. No, each BY* limits/expands the current set; the set is defined by FREQ and all BY* parts. Let's look at the set for 2008: 1) FREQ=YEARLY, set=(Jan1, Jan2, .... Dec31) 2) Filter the set from 1) with BYMONTH, new set=(Nov1, ... Nov30) 3) BYWEEKNO not present, set stays the same 4) BYYEARDAY not present, set stays the same 5) BYMONTHDAY not present, set stays the same 6) Filter the set from 5) with BYDAY=3MO (i.e. the third monday in the currently created set), new set=(Nov17) That's where the order of evaluation is relevant! 7) BYHOUR not present, set stays the same 8) BYMINUTE not present, set stays the same 9) BYSECOND not present, set stays the same 10) BYSETPOS not present, set stays the same (that's the other place where the order of the BY* evaluations is relevant) 11) missing data is taken from the DTSTART (i.e. the time in our case) 11) Apply COUNT and UNTIL (not present), set stays the same (Nov17) So we end up with one recurrence in 2008, namely November 17, 2008, same time as DTSTART. This way, evaluating arbitrarily complex recurrence rules is just as simple as trivial rules. > I'd have liked 3MO to be a short hand for BYDAY=MO, BYSETPOS = 3, in which > case either with a yearly rule would always be the 3rd instance of Monday > WRT to the start of the year. Huh??? BYSETPOS works on the final set after all other BY* rules have been applied. If you have FREQ=YEARLY;BYMONTH=3,6,9; BYMONTHDAY=1; BYSETPOS=2, then you'll get June 1 (At least that was the case with RFC 2445 with the original recurrence rule algorithm, no idea if the reformulation in calsify have messed this up, though). Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH3ntDTqjEwhXvPN0RAsj6AJ4+W9jbL4wK7ZQBHQNZX22evgCTLACfTFId kTDg7Wd/KVSa0BJeEsj+zYU= =/jlc -----END PGP SIGNATURE----- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 08:53:05 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B6E3A6E10 for ; Mon, 17 Mar 2008 08:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G6VzP2ES0d0 for ; Mon, 17 Mar 2008 08:53:02 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 094E23A696D for ; Mon, 17 Mar 2008 08:53:01 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 2239B80BB6; Mon, 17 Mar 2008 08:50:44 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6D85680BA2 for ; Mon, 17 Mar 2008 08:50:42 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF203142240 for ; Mon, 17 Mar 2008 08:50:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGXVZDv+F9yp for ; Mon, 17 Mar 2008 08:50:35 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B7961421FF for ; Mon, 17 Mar 2008 08:50:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7FAA4430709; Mon, 17 Mar 2008 11:50:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsA-oOPYJwey; Mon, 17 Mar 2008 11:50:32 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 0138E430701; Mon, 17 Mar 2008 11:50:30 -0400 (EDT) Date: Mon, 17 Mar 2008 11:50:28 -0400 From: Cyrus Daboo To: Reinhold Kainhofer , ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Message-ID: <1D718510EF6F865AB6A6BB1B@caldav.corp.apple.com> In-Reply-To: <200803171508.03917.reinhold@kainhofer.com> References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> <200803171508.03917.reinhold@kainhofer.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Reinhold, --On March 17, 2008 3:08:03 PM +0100 Reinhold Kainhofer wrote: > No, each BY* limits/expands the current set; the set is defined by FREQ > and all BY* parts. Let's look at the set for 2008: > > 1) FREQ=YEARLY, set=(Jan1, Jan2, .... Dec31) > 2) Filter the set from 1) with BYMONTH, new set=(Nov1, ... Nov30) > 3) BYWEEKNO not present, set stays the same > 4) BYYEARDAY not present, set stays the same > 5) BYMONTHDAY not present, set stays the same > 6) Filter the set from 5) with BYDAY=3MO (i.e. the third monday in the > currently created set), new set=(Nov17) > That's where the order of evaluation is relevant! > 7) BYHOUR not present, set stays the same > 8) BYMINUTE not present, set stays the same > 9) BYSECOND not present, set stays the same > 10) BYSETPOS not present, set stays the same (that's the other place > where the order of the BY* evaluations is relevant) > 11) missing data is taken from the DTSTART (i.e. the time in our case) > 11) Apply COUNT and UNTIL (not present), set stays the same (Nov17) I don't understand how this works! What if there was no BYMONTH and no BYDAY. Then as per step (1), a yearly rule would result in an occurrence on every day of the year! That is clearly wrong. Same problem for YEARLY with BYMONTH and no BYDAY - according to your steps that would be every day in November - again wrong. So I think your steps above only work in the specific case you give. I view the recurrence expansion in the opposite way to your steps above. I would start with the "seed" being DTSTART. Then apply each BYxxx that is present in turn operating on the set from the previous operation. Its hard to explain that in text or even pseudo-code. The table was an attempt to do so but I think it falls slight short in the BYDAY area. Perhaps the best thing I can do is point to the code I did write. I am not claiming this is perfect or the only way to look at this, its just the way that seemed to work for me. So: The generateXXXSet methods there correspond to each column (FREQ values) in the table. Within each generateXXXSet method are conditionals for each BYxxx part corrsponding to the rows in the table. For each BYxxx part there is a byXXXExpand and byXXXLimit method that applies the appropriate logic to a set of date-times passed in, and returns the modified set. The key thing to note is that there are three BYDAY methods byDayExpandYearly, byDayExpandMonthly and byDayExpandWeeky that are used to special case BYDAY. So looking at generateYearlySet, we have: if BYYEARDAY or BYMONTHDAY are present: use byDayLimit else if BYWEEKNO present: use byDayExpandWeekly else if BYMONTH present: use byDayExpandMonthly else: use byDayExpandYearly There is similar logic in generateMonthlySet for BYDAY. This "seed with DTSTART, then Expand/Limit successive sets" approach looks like it covers all cases. So given the above, I think the two notes currently in the 2445bis table should be changed to be more specific about what it means to have a "special expand": Note 1: Limit if BYMONTHDAY is present, otherwise expand days within each month only. Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise if BYWEEKNO is present expands days within each week only, otherwise if BYMONTH is present expand days within each month only, otherwise expand days throughout the year. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 09:24:46 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96013A6868 for ; Mon, 17 Mar 2008 09:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.478 X-Spam-Level: X-Spam-Status: No, score=-4.478 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fisT428-EVTZ for ; Mon, 17 Mar 2008 09:24:41 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 88B4F3A6C1A for ; Mon, 17 Mar 2008 09:24:40 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 25A4380C2E; Mon, 17 Mar 2008 09:22:23 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AA20280BED for ; Mon, 17 Mar 2008 09:22:22 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A159142241 for ; Mon, 17 Mar 2008 09:22:25 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpk1RleOCxXw for ; Mon, 17 Mar 2008 09:22:16 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 310B81421FF for ; Mon, 17 Mar 2008 09:22:16 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: a51f9e03873be97fe0b1b2f1bff26bef X-Spam-Score-Summary: 2, 0, 0, 8affcf387400ba11, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2551:2553:2559:2562:2692:2828:3027:3355:3636:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4605:5007:6117:6119:6261:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigel (nigel.rockliffe.com [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 09:22:13 -0700 Message-ID: <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> From: "Nigel Swinson" To: "Reinhold Kainhofer" References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> <200803171508.03917.reinhold@kainhofer.com> Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 16:22:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org >> I'd have liked 3MO to be a short hand for BYDAY=MO, BYSETPOS = 3, in >> which >> case either with a yearly rule would always be the 3rd instance of Monday >> WRT to the start of the year. > > Huh??? BYSETPOS works on the final set after all other BY* rules have been > applied. I guess this is getting close to the point I was trying to make, and not making a very good job of it, sorry. I agree 3MO should not be the same as BYDAY=MO;BYSETPOS=3 as I understand that BYSETPOS is the last of the BYXX parts to be evaluated, and operates on the collection bound by the sets specified by the FREQ part, but filtered by the previous BYXX rules. But in saying that, 3MO does not mean "3rd monday in the set", that's what BYSETPOS is for, or else it's referring to a different "set", so what does 3MO mean? What I'm trying to say is that I think it would have been better if 3MO had meant, regardless of BYXX rules: weekly/day/hour/second: - 3rd monday of the week/day/hour/second, irrelevant, hence the standard dissalows. freq=monthly - 3rd monday of the month freq=yearly - 3rd monday of the year I think the standard is difficult to interpret WRT to a rule such as: RRULE:FREQ=YEARLY;BYMONTH=2,4;BYDAY=3MO; If we follow your steps, which I agree are appropriate and correct, then when we get to #5 does the 3MO mean we include Mondays for Feb and Apr, or just Apr? - We have to read the special case to realise it's Feb and Apr, not just Apr. - BYSETPOS=3 would be clear, it would be just Feb, which we'd select at step 10. - Equally if we wrote the rule as a MONTHLY rule rather than a YEARLY rule, then it would be fairly easy to interpret as Mondays in Feb and Apr. It's the combination of the 3MO with YEARLY+BYMONTHLY that I think requires unhelpful special casing :o( Lets try one more way to explain my point. The standard says: The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. Surely it would have been clearer to write, easier to implement, and produce better interoperability to reduce the number of clauses to: The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the year. But again, I'm not expecting anything to change in the standard, I think it would break too much code that's out there :o( Nigel _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 09:39:40 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB4D28C510 for ; Mon, 17 Mar 2008 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eR2ZkCqLKb3S for ; Mon, 17 Mar 2008 09:39:39 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id AF01E28C533 for ; Mon, 17 Mar 2008 09:39:02 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 0F8AD80BBB; Mon, 17 Mar 2008 09:36:35 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6B6BE80BAE for ; Mon, 17 Mar 2008 09:36:34 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BEB22142241 for ; Mon, 17 Mar 2008 09:36:36 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMwv9IvLKl47 for ; Mon, 17 Mar 2008 09:36:29 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by laweleka.osafoundation.org (Postfix) with ESMTP id 669081421FF for ; Mon, 17 Mar 2008 09:36:29 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id 58AA429418; Mon, 17 Mar 2008 12:36:26 -0400 (EDT) Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by mailbackend.panix.com (Postfix) with ESMTP id BCA3B112BE; Mon, 17 Mar 2008 12:36:25 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18398.40457.330010.486791@cnr.cs.columbia.edu> Date: Mon, 17 Mar 2008 12:36:25 -0400 To: "Nigel Swinson" Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt In-Reply-To: <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> <200803171508.03917.reinhold@kainhofer.com> <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> X-Mailer: VM 7.19 under Emacs 22.1.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org On Monday, March 17 2008, "Nigel Swinson" wrote to "Reinhold Kainhofer, ietf-calsify@osafoundation.org" saying: > Lets try one more way to explain my point. The standard says: > > The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the month when the BYMONTH rule part is > present, and corresponds to an offset within the year when the > BYWEEKNO or BYMONTH rule parts are present. > > Surely it would have been clearer to write, easier to implement, and produce > better interoperability to reduce the number of clauses to: > > The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the year. > > But again, I'm not expecting anything to change in the standard, I think it > would break too much code that's out there :o( I believe this was the original intent of 2445. However, 2445's example VTIMEZONE (on page 66) contains an RRULE with FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 meaning "the first Sunday in April", and the spec was unclear enough that people implemented following the example instead. Thus the somewhat odd behavior described by 2445bis, which is intended to describe existing practice. -- Jonathan Lennox lennox at cs dot columbia dot edu _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Mar 17 14:20:53 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B243A697E for ; Mon, 17 Mar 2008 14:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vda3Y+8t08A for ; Mon, 17 Mar 2008 14:20:51 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id E3B863A683D for ; Mon, 17 Mar 2008 14:20:50 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 8966880BCD; Mon, 17 Mar 2008 14:18:33 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D933480BAA for ; Mon, 17 Mar 2008 14:18:31 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 38E38142213 for ; Mon, 17 Mar 2008 14:18:34 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c25wIIy3h42U for ; Mon, 17 Mar 2008 14:18:26 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D9BA4142240 for ; Mon, 17 Mar 2008 14:18:23 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HLIAgs001991; Mon, 17 Mar 2008 22:18:11 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: Jonathan Lennox , ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 22:18:01 +0100 User-Agent: KMail/1.9.6 References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> <18398.40457.330010.486791@cnr.cs.columbia.edu> In-Reply-To: <18398.40457.330010.486791@cnr.cs.columbia.edu> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803172218.09700.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 17. März 2008 schrieben Sie: > On Monday, March 17 2008, "Nigel Swinson" wrote to "Reinhold Kainhofer, ietf-calsify@osafoundation.org" saying: > > Lets try one more way to explain my point. The standard says: > > > > The numeric value in a > > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > > to an offset within the month when the BYMONTH rule part is > > present, and corresponds to an offset within the year when the > > BYWEEKNO or BYMONTH rule parts are present. > > > > Surely it would have been clearer to write, easier to implement, and > > produce better interoperability to reduce the number of clauses to: > > > > The numeric value in a > > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > > to an offset within the year. > > > > But again, I'm not expecting anything to change in the standard, I think > > it would break too much code that's out there :o( > > I believe this was the original intent of 2445. Really? Given that **all** VTIMEZONES I have seen (even those in the RFC!) use YEARLY together with BYDAY and BYMONTH, I find this hard to believe... Even the implementations from Lotus and Microsoft (the first draft of RFC 2445 came from Microsoft (!!) while reimplementing Outlook/OE and was merged with the Versit vCalendar draft, see http://www.imc.org/ietf-calendar/archive1/msg00192.html) use this, and the two editors of RFC 2445 were from Lotus and Micosoft, so I doubt that this was just a collective error made simultaneously by all implementations at that time... Anyway, I took a look at the ietf-calendar archives from 1996-1999 when RFC 2445 was written and discussed and there are some quite interesting postings by the RFC authors, some of which contradict what was "clarified" in calsify: Apparently, RDATE befor the DTSTART were not meant to be allowed: http://www.imc.org/ietf-calendar/archive1/msg02220.html About the order of the BY* rule parts (clearly indicating the step-by-step application): http://www.imc.org/ietf-calendar/archive1/msg02221.html That the DTSTART does not have to be part of the RRULE (e.g. an event recurring every monday can have a DTSTART on Tuesday; Also compare the example on page 120 of the original RFC 120; Notice that Frank is the editor of RFC 2445 and Vinod worked for Lotus, where the other editor worked, too): http://www.imc.org/ietf-calendar/archive1/msg02224.html http://www.imc.org/ietf-calendar/archive1/msg02230.html (Tread started at http://www.imc.org/ietf-calendar/archive1/msg02197.html) Also: http://www.imc.org/ietf-calendar/archive1/msg01429.html Unfortunately, none of the postings from 1996 to 1999 explain in more detail how the RRULE is supposed to be evaluated exactly :( And apparently the archives of the old (pre-1996) mailing list from cst.ca are not available any more... Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH3uARTqjEwhXvPN0RAt+1AKCDZV9hk4On5glQfEc+1tszVBtSHQCfUyB5 FWJs209B0eCmJo3t+dkNNMM= =D5J1 -----END PGP SIGNATURE----- _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Mar 20 08:57:39 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B93A28C302 for ; Thu, 20 Mar 2008 08:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPZqeKAVx4mS for ; Thu, 20 Mar 2008 08:57:35 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id CC2413A6D74 for ; Thu, 20 Mar 2008 08:57:34 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 5B00E80490; Thu, 20 Mar 2008 08:55:16 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0B1F5800F5 for ; Thu, 20 Mar 2008 08:55:15 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4DEB4142242 for ; Thu, 20 Mar 2008 08:55:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7k5wSk4Pj3x for ; Thu, 20 Mar 2008 08:55:06 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3624F14223D for ; Thu, 20 Mar 2008 08:55:05 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2KFsx2C018853 for ; Thu, 20 Mar 2008 15:54:59 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JY100G01D08A900@fe-emea-10.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-calsify@osafoundation.org; Thu, 20 Mar 2008 15:54:59 +0000 (GMT) Received: from [129.150.116.188] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JY100CIUDJLEJD0@fe-emea-10.sun.com> for ietf-calsify@osafoundation.org; Thu, 20 Mar 2008 15:54:58 +0000 (GMT) Date: Thu, 20 Mar 2008 16:59:29 +0100 From: Arnaud Quillaud To: "ietf-calsify@osafoundation.org" Message-id: <47E289E1.1040508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.12 (X11/20080227) Subject: [Ietf-calsify] SMS alarm X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Probably too late but I thought I'd send this comment anyway... A *lot* of our customers are using server triggered SMS based alarms when currently only: "AUDIO" / "DISPLAY" / "EMAIL" / iana-token / x-name are allowed. I have found only one email related to SMS based alarms on the calsify mailing list (http://lists.osafoundation.org/pipermail/ietf-calsify/2006-September/001173.html). It simply suggest the possibility to add more action values. Now, instead of having to register new actions (and their associated set of properties), couldn't we extend the definition of "EMAIL" alarms to all forms of electronic messages ? In an EMAIL alarm, the address is already stored in an ATTENDEE property so its value can be any RFC3986 compliant URI. This means that in theory, we could directly use: * IM uris (http://tools.ietf.org/html/rfc3860) * SMS uris (http://tools.ietf.org/html/draft-wilde-sms-uri) or any other form of electronic message with a known uri definition. More comments: Unless I'm mistaken, allowing vendors to register new action values is not enough since http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.6.6 limits what you can put in an alarm component: alarmc = "BEGIN" ":" "VALARM" CRLF (audioprop / dispprop / emailprop) "END" ":" "VALARM" CRLF so maybe the x-prop / iana-prop should be removed from audioprop/dispprop/emailprop and added at the alarmc definition level, or an otherprop should be added whose definition should be part of the iana registry for new actions. Finally, http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.6.6 mentions that: << It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. >> when from my experience, EMAIL is always ignored by CUAs and often handled by the CS. Arnaud Q _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Mar 21 17:49:22 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1E73A6A64 for ; Fri, 21 Mar 2008 17:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.106 X-Spam-Level: X-Spam-Status: No, score=-4.106 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjUkYVChVjcs for ; Fri, 21 Mar 2008 17:49:21 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 32F803A6BDB for ; Fri, 21 Mar 2008 17:48:52 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 2671680B7E; Fri, 21 Mar 2008 17:46:31 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CEF2D80B2B for ; Fri, 21 Mar 2008 17:46:29 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2435314223D for ; Fri, 21 Mar 2008 17:46:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMad8JPVbcrS for ; Fri, 21 Mar 2008 17:46:25 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91B2A142229 for ; Fri, 21 Mar 2008 17:46:25 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: a7ca93b3ee66240d29f9f25162e5ce2a X-Spam-Score-Summary: 2, 0, 0, b08df9d9c386c93d, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:2703, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,windows-1252,windows-1252 Received: from nigelhome (unverified [10.42.40.209]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id for ; Fri, 21 Mar 2008 17:46:08 -0700 Message-ID: <002601c88bb6$1eee1f90$6501a8c0@nigelhome> From: "Nigel Swinson" To: Date: Sat, 22 Mar 2008 00:46:07 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [Ietf-calsify] \t disallowed in "text" value type but allowed in root "value" type X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1899675743==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============1899675743== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C88BB6.1DB355A0" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C88BB6.1DB355A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Perhaps I'm reading this incorrectly, but I think the grammer says that \t (0x09) isn't allowed in a text value: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.3.11 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) ; Folded according to description above ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") ; \\ encodes \, \N or \n encodes newline ; \; encodes ;, \, encodes , TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B / %x5D-7E / NON-US-ASCII ; Any character except CTLs not needed by the current ; character set, DQUOTE, ";", ":", "\", ","Was this a mistake, or a deliberate choice? It seem especially wierd given that \t is allowed in a "value", and I thought the whole intention of the "text" value type was to allow more characters to be in a value than what "value" allowed. http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.1 contentline = name *(";" param ) ":" value CRLF value = *VALUE-CHAR VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII ; Any textual characterI think it is a mistake, one that might be easy to rectify should there be a V09?Nigel ------=_NextPart_000_0022_01C88BB6.1DB355A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Perhaps I'm reading this incorrectly, but I think the grammer says = that \t=20 (0x09) isn't allowed in a text value:
 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#se= ction-3.3.11
        text       =3D *(TSAFE-CHAR / ":" / DQUOTE / =
ESCAPED-CHAR)
           ; Folded according to description above

        ESCAPED-CHAR =3D ("\\" / "\;" / "\," / "\N" / "\n")
           ; \\ encodes \, \N or \n encodes newline
           ; \; encodes ;, \, encodes ,

        TSAFE-CHAR =3D %x20-21 / %x23-2B / %x2D-39 / %x3C-5B /
                     %x5D-7E / NON-US-ASCII
           ; Any character except CTLs not needed by the current
           ; character set, DQUOTE, ";", ":", "\", ","
Was this a mistake, or a deliberate choice?  It seem = especially wierd=20 given that \t is allowed in a "value", and I thought the whole intention = of the=20 "text" value type was to allow more characters to be in a value than = what=20 "value" allowed.
 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#secti= on-3.1
      contentline   =3D name *(";" param ) ":" value =
CRLF
 
      value         =3D *VALUE-CHAR

      VALUE-CHAR    =3D WSP / %x21-7E / NON-US-ASCII
      ; Any textual character
I think it is a mistake, one =
that might be easy to rectify should there be a =
V09?
Nigel
------=_NextPart_000_0022_01C88BB6.1DB355A0-- --===============1899675743== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============1899675743==-- From ietf-calsify-bounces@osafoundation.org Tue Mar 25 13:36:04 2008 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572F53A6C1C for ; Tue, 25 Mar 2008 13:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL1UHkPGkHmJ for ; Tue, 25 Mar 2008 13:36:03 -0700 (PDT) Received: from leilani.osafoundation.org (unknown [IPv6:2001:4f8:3:ba:230:48ff:fe43:1456]) by core3.amsl.com (Postfix) with ESMTP id 2A77028C0EC for ; Tue, 25 Mar 2008 13:36:02 -0700 (PDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id EB1E680A1A; Tue, 25 Mar 2008 13:33:41 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 480D57F9CC for ; Tue, 25 Mar 2008 13:33:41 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B154B142201 for ; Tue, 25 Mar 2008 13:33:43 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr+kIHfctpuM for ; Tue, 25 Mar 2008 13:33:36 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B7E9D1421FB for ; Tue, 25 Mar 2008 13:33:36 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.106]) by redwood.morsemedia.net with esmtpa (Exim 4.68) (envelope-from ) id 1JeFpv-0007QZ-9j; Tue, 25 Mar 2008 13:33:35 -0700 Message-ID: <47E9619A.8000401@calconnect.org> Date: Tue, 25 Mar 2008 13:33:30 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ietf-calsify list X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] Registration is now open for CalConnect XII: Roundtable XII and IOP Test Events, June 2-6, 2008 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0950550770==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============0950550770== Content-Type: multipart/alternative; boundary="------------010804080906080108090501" This is a multi-part message in MIME format. --------------010804080906080108090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit /This message is being sent to the IETF calendaring-related lists. My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists. Dave Thewlis./ *CalConnect Roundtable XII and Interoperability Test Events Registration is now open* Registration is now open for CalConnect Roundtable XII and the associated CalConnect Interoperability Test Events, June 2-6, 2008, hosted by the University of Wisconsin, Madison, in Madison, Wisconsin. Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable12.shtml The CalConnect Interoperability Test Event will occur from Monday morning the 2nd (starting at 08:30) through noon Wednesday the 4th; the Roundtable from noon Wednesday the 4th through 13:00 Friday the 6th. Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you. Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well. Information on observer status and registration is also linked from the above page. Registration for both member representatives and observer representatives is $350 for the Roundtable through May 15, and $395 thereafter. Observer registration for the IOP test event is also $350. If you have any questions please contact me, and we hope to see you in June. Best Regards, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------010804080906080108090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This message is being sent to the IETF calendaring-related lists.  My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists.  Dave Thewlis.

CalConnect Roundtable XII and Interoperability Test Events Registration is now open

Registration is now open for CalConnect Roundtable XII and the associated CalConnect Interoperability Test Events, June 2-6, 2008, hosted by the University of Wisconsin, Madison, in Madison, Wisconsin.  Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable12.shtml

The CalConnect Interoperability Test Event will occur from Monday morning the 2nd (starting at 08:30) through noon Wednesday the 4th; the Roundtable from noon Wednesday the 4th through 13:00 Friday the 6th. 

Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you.  Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well.  Information on observer status and registration is also linked from the above page.

Registration for both member representatives and observer representatives is $350 for the Roundtable through May 15, and $395 thereafter.  Observer registration for the IOP test event is also $350.

If you have any questions please contact me, and we hope to see you in June.

Best Regards,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------010804080906080108090501-- --===============0950550770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============0950550770==-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 480D57F9CC for ; Tue, 25 Mar 2008 13:33:41 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B154B142201 for ; Tue, 25 Mar 2008 13:33:43 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-50 required=4 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr+kIHfctpuM for ; Tue, 25 Mar 2008 13:33:36 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B7E9D1421FB for ; Tue, 25 Mar 2008 13:33:36 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.106]) by redwood.morsemedia.net with esmtpa (Exim 4.68) (envelope-from ) id 1JeFpv-0007QZ-9j; Tue, 25 Mar 2008 13:33:35 -0700 Message-ID: <47E9619A.8000401@calconnect.org> Date: Tue, 25 Mar 2008 13:33:30 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ietf-calsify list Content-Type: multipart/alternative; boundary="------------010804080906080108090501" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] Registration is now open for CalConnect XII: Roundtable XII and IOP Test Events, June 2-6, 2008 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 20:33:41 -0000 This is a multi-part message in MIME format. --------------010804080906080108090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit /This message is being sent to the IETF calendaring-related lists. My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists. Dave Thewlis./ *CalConnect Roundtable XII and Interoperability Test Events Registration is now open* Registration is now open for CalConnect Roundtable XII and the associated CalConnect Interoperability Test Events, June 2-6, 2008, hosted by the University of Wisconsin, Madison, in Madison, Wisconsin. Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable12.shtml The CalConnect Interoperability Test Event will occur from Monday morning the 2nd (starting at 08:30) through noon Wednesday the 4th; the Roundtable from noon Wednesday the 4th through 13:00 Friday the 6th. Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you. Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well. Information on observer status and registration is also linked from the above page. Registration for both member representatives and observer representatives is $350 for the Roundtable through May 15, and $395 thereafter. Observer registration for the IOP test event is also $350. If you have any questions please contact me, and we hope to see you in June. Best Regards, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------010804080906080108090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This message is being sent to the IETF calendaring-related lists.  My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists.  Dave Thewlis.

CalConnect Roundtable XII and Interoperability Test Events Registration is now open

Registration is now open for CalConnect Roundtable XII and the associated CalConnect Interoperability Test Events, June 2-6, 2008, hosted by the University of Wisconsin, Madison, in Madison, Wisconsin.  Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable12.shtml

The CalConnect Interoperability Test Event will occur from Monday morning the 2nd (starting at 08:30) through noon Wednesday the 4th; the Roundtable from noon Wednesday the 4th through 13:00 Friday the 6th. 

Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you.  Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well.  Information on observer status and registration is also linked from the above page.

Registration for both member representatives and observer representatives is $350 for the Roundtable through May 15, and $395 thereafter.  Observer registration for the IOP test event is also $350.

If you have any questions please contact me, and we hope to see you in June.

Best Regards,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------010804080906080108090501-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CEF2D80B2B for ; Fri, 21 Mar 2008 17:46:29 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2435314223D for ; Fri, 21 Mar 2008 17:46:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-50 required=4 tests=[AWL=-0.741, BAYES_05=-1.11, HTML_50_60=0.134, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMad8JPVbcrS for ; Fri, 21 Mar 2008 17:46:25 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91B2A142229 for ; Fri, 21 Mar 2008 17:46:25 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: a7ca93b3ee66240d29f9f25162e5ce2a X-Spam-Score-Summary: 2, 0, 0, b08df9d9c386c93d, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:2703, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,windows-1252,windows-1252 Received: from nigelhome (unverified [10.42.40.209]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id for ; Fri, 21 Mar 2008 17:46:08 -0700 Message-ID: <002601c88bb6$1eee1f90$6501a8c0@nigelhome> From: "Nigel Swinson" To: Date: Sat, 22 Mar 2008 00:46:07 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C88BB6.1DB355A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [Ietf-calsify] \t disallowed in "text" value type but allowed in root "value" type X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2008 00:46:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C88BB6.1DB355A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Perhaps I'm reading this incorrectly, but I think the grammer says that \t (0x09) isn't allowed in a text value: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.3.11 text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) ; Folded according to description above ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") ; \\ encodes \, \N or \n encodes newline ; \; encodes ;, \, encodes , TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B / %x5D-7E / NON-US-ASCII ; Any character except CTLs not needed by the current ; character set, DQUOTE, ";", ":", "\", ","Was this a mistake, or a deliberate choice? It seem especially wierd given that \t is allowed in a "value", and I thought the whole intention of the "text" value type was to allow more characters to be in a value than what "value" allowed. http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.1 contentline = name *(";" param ) ":" value CRLF value = *VALUE-CHAR VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII ; Any textual characterI think it is a mistake, one that might be easy to rectify should there be a V09?Nigel ------=_NextPart_000_0022_01C88BB6.1DB355A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Perhaps I'm reading this incorrectly, but I think the grammer says = that \t=20 (0x09) isn't allowed in a text value:
 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#se= ction-3.3.11
        text       =3D *(TSAFE-CHAR / ":" / DQUOTE / =
ESCAPED-CHAR)
           ; Folded according to description above

        ESCAPED-CHAR =3D ("\\" / "\;" / "\," / "\N" / "\n")
           ; \\ encodes \, \N or \n encodes newline
           ; \; encodes ;, \, encodes ,

        TSAFE-CHAR =3D %x20-21 / %x23-2B / %x2D-39 / %x3C-5B /
                     %x5D-7E / NON-US-ASCII
           ; Any character except CTLs not needed by the current
           ; character set, DQUOTE, ";", ":", "\", ","
Was this a mistake, or a deliberate choice?  It seem = especially wierd=20 given that \t is allowed in a "value", and I thought the whole intention = of the=20 "text" value type was to allow more characters to be in a value than = what=20 "value" allowed.
 
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#secti= on-3.1
      contentline   =3D name *(";" param ) ":" value =
CRLF
 
      value         =3D *VALUE-CHAR

      VALUE-CHAR    =3D WSP / %x21-7E / NON-US-ASCII
      ; Any textual character
I think it is a mistake, one =
that might be easy to rectify should there be a =
V09?
Nigel
------=_NextPart_000_0022_01C88BB6.1DB355A0-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0B1F5800F5 for ; Thu, 20 Mar 2008 08:55:15 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4DEB4142242 for ; Thu, 20 Mar 2008 08:55:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-50 required=4 tests=[AWL=0.948, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7k5wSk4Pj3x for ; Thu, 20 Mar 2008 08:55:06 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3624F14223D for ; Thu, 20 Mar 2008 08:55:05 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2KFsx2C018853 for ; Thu, 20 Mar 2008 15:54:59 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JY100G01D08A900@fe-emea-10.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-calsify@osafoundation.org; Thu, 20 Mar 2008 15:54:59 +0000 (GMT) Received: from [129.150.116.188] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JY100CIUDJLEJD0@fe-emea-10.sun.com> for ietf-calsify@osafoundation.org; Thu, 20 Mar 2008 15:54:58 +0000 (GMT) Date: Thu, 20 Mar 2008 16:59:29 +0100 From: Arnaud Quillaud Sender: Arnaud.Quillaud@Sun.COM To: "ietf-calsify@osafoundation.org" Message-id: <47E289E1.1040508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.12 (X11/20080227) Subject: [Ietf-calsify] SMS alarm X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 15:55:15 -0000 Probably too late but I thought I'd send this comment anyway... A *lot* of our customers are using server triggered SMS based alarms when currently only: "AUDIO" / "DISPLAY" / "EMAIL" / iana-token / x-name are allowed. I have found only one email related to SMS based alarms on the calsify mailing list (http://lists.osafoundation.org/pipermail/ietf-calsify/2006-September/001173.html). It simply suggest the possibility to add more action values. Now, instead of having to register new actions (and their associated set of properties), couldn't we extend the definition of "EMAIL" alarms to all forms of electronic messages ? In an EMAIL alarm, the address is already stored in an ATTENDEE property so its value can be any RFC3986 compliant URI. This means that in theory, we could directly use: * IM uris (http://tools.ietf.org/html/rfc3860) * SMS uris (http://tools.ietf.org/html/draft-wilde-sms-uri) or any other form of electronic message with a known uri definition. More comments: Unless I'm mistaken, allowing vendors to register new action values is not enough since http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.6.6 limits what you can put in an alarm component: alarmc = "BEGIN" ":" "VALARM" CRLF (audioprop / dispprop / emailprop) "END" ":" "VALARM" CRLF so maybe the x-prop / iana-prop should be removed from audioprop/dispprop/emailprop and added at the alarmc definition level, or an otherprop should be added whose definition should be part of the iana registry for new actions. Finally, http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.6.6 mentions that: << It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. >> when from my experience, EMAIL is always ignored by CUAs and often handled by the CS. Arnaud Q Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D933480BAA for ; Mon, 17 Mar 2008 14:18:31 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 38E38142213 for ; Mon, 17 Mar 2008 14:18:34 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-50 required=4 tests=[AWL=1.111, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c25wIIy3h42U for ; Mon, 17 Mar 2008 14:18:26 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D9BA4142240 for ; Mon, 17 Mar 2008 14:18:23 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HLIAgs001991; Mon, 17 Mar 2008 22:18:11 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: Jonathan Lennox , ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 22:18:01 +0100 User-Agent: KMail/1.9.6 References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> <18398.40457.330010.486791@cnr.cs.columbia.edu> In-Reply-To: <18398.40457.330010.486791@cnr.cs.columbia.edu> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803172218.09700.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 21:18:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 17. März 2008 schrieben Sie: > On Monday, March 17 2008, "Nigel Swinson" wrote to "Reinhold Kainhofer, ietf-calsify@osafoundation.org" saying: > > Lets try one more way to explain my point. The standard says: > > > > The numeric value in a > > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > > to an offset within the month when the BYMONTH rule part is > > present, and corresponds to an offset within the year when the > > BYWEEKNO or BYMONTH rule parts are present. > > > > Surely it would have been clearer to write, easier to implement, and > > produce better interoperability to reduce the number of clauses to: > > > > The numeric value in a > > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > > to an offset within the year. > > > > But again, I'm not expecting anything to change in the standard, I think > > it would break too much code that's out there :o( > > I believe this was the original intent of 2445. Really? Given that **all** VTIMEZONES I have seen (even those in the RFC!) use YEARLY together with BYDAY and BYMONTH, I find this hard to believe... Even the implementations from Lotus and Microsoft (the first draft of RFC 2445 came from Microsoft (!!) while reimplementing Outlook/OE and was merged with the Versit vCalendar draft, see http://www.imc.org/ietf-calendar/archive1/msg00192.html) use this, and the two editors of RFC 2445 were from Lotus and Micosoft, so I doubt that this was just a collective error made simultaneously by all implementations at that time... Anyway, I took a look at the ietf-calendar archives from 1996-1999 when RFC 2445 was written and discussed and there are some quite interesting postings by the RFC authors, some of which contradict what was "clarified" in calsify: Apparently, RDATE befor the DTSTART were not meant to be allowed: http://www.imc.org/ietf-calendar/archive1/msg02220.html About the order of the BY* rule parts (clearly indicating the step-by-step application): http://www.imc.org/ietf-calendar/archive1/msg02221.html That the DTSTART does not have to be part of the RRULE (e.g. an event recurring every monday can have a DTSTART on Tuesday; Also compare the example on page 120 of the original RFC 120; Notice that Frank is the editor of RFC 2445 and Vinod worked for Lotus, where the other editor worked, too): http://www.imc.org/ietf-calendar/archive1/msg02224.html http://www.imc.org/ietf-calendar/archive1/msg02230.html (Tread started at http://www.imc.org/ietf-calendar/archive1/msg02197.html) Also: http://www.imc.org/ietf-calendar/archive1/msg01429.html Unfortunately, none of the postings from 1996 to 1999 explain in more detail how the RRULE is supposed to be evaluated exactly :( And apparently the archives of the old (pre-1996) mailing list from cst.ca are not available any more... Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH3uARTqjEwhXvPN0RAt+1AKCDZV9hk4On5glQfEc+1tszVBtSHQCfUyB5 FWJs209B0eCmJo3t+dkNNMM= =D5J1 -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6B6BE80BAE for ; Mon, 17 Mar 2008 09:36:34 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BEB22142241 for ; Mon, 17 Mar 2008 09:36:36 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-50 required=4 tests=[AWL=0.591, BAYES_00=-2.599, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=1.384] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMwv9IvLKl47 for ; Mon, 17 Mar 2008 09:36:29 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by laweleka.osafoundation.org (Postfix) with ESMTP id 669081421FF for ; Mon, 17 Mar 2008 09:36:29 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by mail1.panix.com (Postfix) with ESMTP id 58AA429418; Mon, 17 Mar 2008 12:36:26 -0400 (EDT) Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by mailbackend.panix.com (Postfix) with ESMTP id BCA3B112BE; Mon, 17 Mar 2008 12:36:25 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18398.40457.330010.486791@cnr.cs.columbia.edu> Date: Mon, 17 Mar 2008 12:36:25 -0400 To: "Nigel Swinson" Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt In-Reply-To: <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> <200803171508.03917.reinhold@kainhofer.com> <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> X-Mailer: VM 7.19 under Emacs 22.1.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 16:36:34 -0000 On Monday, March 17 2008, "Nigel Swinson" wrote to "Reinhold Kainhofer, ietf-calsify@osafoundation.org" saying: > Lets try one more way to explain my point. The standard says: > > The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the month when the BYMONTH rule part is > present, and corresponds to an offset within the year when the > BYWEEKNO or BYMONTH rule parts are present. > > Surely it would have been clearer to write, easier to implement, and produce > better interoperability to reduce the number of clauses to: > > The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the year. > > But again, I'm not expecting anything to change in the standard, I think it > would break too much code that's out there :o( I believe this was the original intent of 2445. However, 2445's example VTIMEZONE (on page 66) contains an RRULE with FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 meaning "the first Sunday in April", and the spec was unclear enough that people implemented following the example instead. Thus the somewhat odd behavior described by 2445bis, which is intended to describe existing practice. -- Jonathan Lennox lennox at cs dot columbia dot edu Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AA20280BED for ; Mon, 17 Mar 2008 09:22:22 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A159142241 for ; Mon, 17 Mar 2008 09:22:25 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-50 required=4 tests=[AWL=0.083, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpk1RleOCxXw for ; Mon, 17 Mar 2008 09:22:16 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 310B81421FF for ; Mon, 17 Mar 2008 09:22:16 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: a51f9e03873be97fe0b1b2f1bff26bef X-Spam-Score-Summary: 2, 0, 0, 8affcf387400ba11, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2551:2553:2559:2562:2692:2828:3027:3355:3636:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4605:5007:6117:6119:6261:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigel (nigel.rockliffe.com [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 09:22:13 -0700 Message-ID: <003a01c8884b$0eab2100$6e2c2a0a@rockliffe.com> From: "Nigel Swinson" To: "Reinhold Kainhofer" References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> <200803171508.03917.reinhold@kainhofer.com> Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 16:22:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 16:22:22 -0000 >> I'd have liked 3MO to be a short hand for BYDAY=MO, BYSETPOS = 3, in >> which >> case either with a yearly rule would always be the 3rd instance of Monday >> WRT to the start of the year. > > Huh??? BYSETPOS works on the final set after all other BY* rules have been > applied. I guess this is getting close to the point I was trying to make, and not making a very good job of it, sorry. I agree 3MO should not be the same as BYDAY=MO;BYSETPOS=3 as I understand that BYSETPOS is the last of the BYXX parts to be evaluated, and operates on the collection bound by the sets specified by the FREQ part, but filtered by the previous BYXX rules. But in saying that, 3MO does not mean "3rd monday in the set", that's what BYSETPOS is for, or else it's referring to a different "set", so what does 3MO mean? What I'm trying to say is that I think it would have been better if 3MO had meant, regardless of BYXX rules: weekly/day/hour/second: - 3rd monday of the week/day/hour/second, irrelevant, hence the standard dissalows. freq=monthly - 3rd monday of the month freq=yearly - 3rd monday of the year I think the standard is difficult to interpret WRT to a rule such as: RRULE:FREQ=YEARLY;BYMONTH=2,4;BYDAY=3MO; If we follow your steps, which I agree are appropriate and correct, then when we get to #5 does the 3MO mean we include Mondays for Feb and Apr, or just Apr? - We have to read the special case to realise it's Feb and Apr, not just Apr. - BYSETPOS=3 would be clear, it would be just Feb, which we'd select at step 10. - Equally if we wrote the rule as a MONTHLY rule rather than a YEARLY rule, then it would be fairly easy to interpret as Mondays in Feb and Apr. It's the combination of the 3MO with YEARLY+BYMONTHLY that I think requires unhelpful special casing :o( Lets try one more way to explain my point. The standard says: The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. Surely it would have been clearer to write, easier to implement, and produce better interoperability to reduce the number of clauses to: The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the year. But again, I'm not expecting anything to change in the standard, I think it would break too much code that's out there :o( Nigel Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6D85680BA2 for ; Mon, 17 Mar 2008 08:50:42 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF203142240 for ; Mon, 17 Mar 2008 08:50:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-50 required=4 tests=[AWL=0.081, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGXVZDv+F9yp for ; Mon, 17 Mar 2008 08:50:35 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B7961421FF for ; Mon, 17 Mar 2008 08:50:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7FAA4430709; Mon, 17 Mar 2008 11:50:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsA-oOPYJwey; Mon, 17 Mar 2008 11:50:32 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 0138E430701; Mon, 17 Mar 2008 11:50:30 -0400 (EDT) Date: Mon, 17 Mar 2008 11:50:28 -0400 From: Cyrus Daboo To: Reinhold Kainhofer , ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Message-ID: <1D718510EF6F865AB6A6BB1B@caldav.corp.apple.com> In-Reply-To: <200803171508.03917.reinhold@kainhofer.com> References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> <200803171508.03917.reinhold@kainhofer.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 15:50:42 -0000 Hi Reinhold, --On March 17, 2008 3:08:03 PM +0100 Reinhold Kainhofer wrote: > No, each BY* limits/expands the current set; the set is defined by FREQ > and all BY* parts. Let's look at the set for 2008: > > 1) FREQ=YEARLY, set=(Jan1, Jan2, .... Dec31) > 2) Filter the set from 1) with BYMONTH, new set=(Nov1, ... Nov30) > 3) BYWEEKNO not present, set stays the same > 4) BYYEARDAY not present, set stays the same > 5) BYMONTHDAY not present, set stays the same > 6) Filter the set from 5) with BYDAY=3MO (i.e. the third monday in the > currently created set), new set=(Nov17) > That's where the order of evaluation is relevant! > 7) BYHOUR not present, set stays the same > 8) BYMINUTE not present, set stays the same > 9) BYSECOND not present, set stays the same > 10) BYSETPOS not present, set stays the same (that's the other place > where the order of the BY* evaluations is relevant) > 11) missing data is taken from the DTSTART (i.e. the time in our case) > 11) Apply COUNT and UNTIL (not present), set stays the same (Nov17) I don't understand how this works! What if there was no BYMONTH and no BYDAY. Then as per step (1), a yearly rule would result in an occurrence on every day of the year! That is clearly wrong. Same problem for YEARLY with BYMONTH and no BYDAY - according to your steps that would be every day in November - again wrong. So I think your steps above only work in the specific case you give. I view the recurrence expansion in the opposite way to your steps above. I would start with the "seed" being DTSTART. Then apply each BYxxx that is present in turn operating on the set from the previous operation. Its hard to explain that in text or even pseudo-code. The table was an attempt to do so but I think it falls slight short in the BYDAY area. Perhaps the best thing I can do is point to the code I did write. I am not claiming this is perfect or the only way to look at this, its just the way that seemed to work for me. So: The generateXXXSet methods there correspond to each column (FREQ values) in the table. Within each generateXXXSet method are conditionals for each BYxxx part corrsponding to the rows in the table. For each BYxxx part there is a byXXXExpand and byXXXLimit method that applies the appropriate logic to a set of date-times passed in, and returns the modified set. The key thing to note is that there are three BYDAY methods byDayExpandYearly, byDayExpandMonthly and byDayExpandWeeky that are used to special case BYDAY. So looking at generateYearlySet, we have: if BYYEARDAY or BYMONTHDAY are present: use byDayLimit else if BYWEEKNO present: use byDayExpandWeekly else if BYMONTH present: use byDayExpandMonthly else: use byDayExpandYearly There is similar logic in generateMonthlySet for BYDAY. This "seed with DTSTART, then Expand/Limit successive sets" approach looks like it covers all cases. So given the above, I think the two notes currently in the 2445bis table should be changed to be more specific about what it means to have a "special expand": Note 1: Limit if BYMONTHDAY is present, otherwise expand days within each month only. Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise if BYWEEKNO is present expands days within each week only, otherwise if BYMONTH is present expand days within each month only, otherwise expand days throughout the year. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 290DE80BB6 for ; Mon, 17 Mar 2008 07:08:22 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B475142241 for ; Mon, 17 Mar 2008 07:08:24 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-50 required=4 tests=[AWL=1.125, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7dHjMukp2k9 for ; Mon, 17 Mar 2008 07:08:13 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 607C014223F for ; Mon, 17 Mar 2008 07:08:12 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HE849U000455; Mon, 17 Mar 2008 15:08:04 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: "Nigel Swinson" , ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 15:08:03 +0100 User-Agent: KMail/1.9.6 References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> <025301c88835$010de070$6501a8c0@nigelhome> In-Reply-To: <025301c88835$010de070$6501a8c0@nigelhome> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171508.03917.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 14:08:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 17. März 2008 schrieben Sie: > > 1) Apply yearly, so all days in a year match > > 2) Apply BYMONTH, so only all dates in november match > > 3) Apply BYDAY, meaning the 3rd monday in the set of currently matching > > dates (which are just the days in november). > > 4) Apply all BYHOUR/BYMINUTE/BYSECOND (not present) > > 5) Take all missing information (i.e. time) from the DTSTART > > It's step 3 where the intuative step breaks down for me. There's the > establishing of the set, and the filtering the set. The only thing the > defines the set is the FREQ component. No, each BY* limits/expands the current set; the set is defined by FREQ and all BY* parts. Let's look at the set for 2008: 1) FREQ=YEARLY, set=(Jan1, Jan2, .... Dec31) 2) Filter the set from 1) with BYMONTH, new set=(Nov1, ... Nov30) 3) BYWEEKNO not present, set stays the same 4) BYYEARDAY not present, set stays the same 5) BYMONTHDAY not present, set stays the same 6) Filter the set from 5) with BYDAY=3MO (i.e. the third monday in the currently created set), new set=(Nov17) That's where the order of evaluation is relevant! 7) BYHOUR not present, set stays the same 8) BYMINUTE not present, set stays the same 9) BYSECOND not present, set stays the same 10) BYSETPOS not present, set stays the same (that's the other place where the order of the BY* evaluations is relevant) 11) missing data is taken from the DTSTART (i.e. the time in our case) 11) Apply COUNT and UNTIL (not present), set stays the same (Nov17) So we end up with one recurrence in 2008, namely November 17, 2008, same time as DTSTART. This way, evaluating arbitrarily complex recurrence rules is just as simple as trivial rules. > I'd have liked 3MO to be a short hand for BYDAY=MO, BYSETPOS = 3, in which > case either with a yearly rule would always be the 3rd instance of Monday > WRT to the start of the year. Huh??? BYSETPOS works on the final set after all other BY* rules have been applied. If you have FREQ=YEARLY;BYMONTH=3,6,9; BYMONTHDAY=1; BYSETPOS=2, then you'll get June 1 (At least that was the case with RFC 2445 with the original recurrence rule algorithm, no idea if the reformulation in calsify have messed this up, though). Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH3ntDTqjEwhXvPN0RAsj6AJ4+W9jbL4wK7ZQBHQNZX22evgCTLACfTFId kTDg7Wd/KVSa0BJeEsj+zYU= =/jlc -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EB2C680B68 for ; Mon, 17 Mar 2008 06:43:38 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4939514223F for ; Mon, 17 Mar 2008 06:43:41 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-50 required=4 tests=[AWL=0.091, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-pcs8FLt+-Z for ; Mon, 17 Mar 2008 06:43:27 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0614A14223E for ; Mon, 17 Mar 2008 06:43:26 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 6db77512e9327f6328842c82324ab401 X-Spam-Score-Summary: 2, 0, 0, ebcbd330c835c703, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2551:2553:2559:2562:2828:2892:3027:3740:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4321:4605:5007:6117:6119:6261:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 06:43:23 -0700 Message-ID: <025301c88835$010de070$6501a8c0@nigelhome> From: "Nigel Swinson" To: "Reinhold Kainhofer" References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> <200803171412.14523.reinhold@kainhofer.com> Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 13:44:18 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 13:43:39 -0000 > > > I still think it's an non intuative shame that > > > FREQ=YEARLY;BYDAY=3MO;BYMONTH=11 means the 3rd Monday in November rather > > > than the 3rd Monday of the year when it falls in November, so I think it > > I think it should mean the 3rd monday in November. This becomes clear when you > think of BYDAY in the same way as BYSETPOSITION: Looking back, I think I meant to illustrate my complaint with: FREQ=YEARLY;BYDAY=MO;BYSETPOS=3;BYMONTH=11 But I think it's the same issue. > 1) Apply yearly, so all days in a year match > 2) Apply BYMONTH, so only all dates in november match > 3) Apply BYDAY, meaning the 3rd monday in the set of currently matching dates > (which are just the days in november). > 4) Apply all BYHOUR/BYMINUTE/BYSECOND (not present) > 5) Take all missing information (i.e. time) from the DTSTART It's step 3 where the intuative step breaks down for me. There's the establishing of the set, and the filtering the set. The only thing the defines the set is the FREQ component. The BYXX components filter the set. See what was defined for BYSETPOS WRT to sets: The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of recurrence instances specified by the * rule. BYSETPOS operates on a set of recurrence instances in one * interval of the recurrence rule. For example, in a WEEKLY rule, * the interval would be one week A set of recurrence instances * starts at the beginning of the interval defined by the FREQ rule part. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example "the last work day of the month" could be represented as: It could just have easily said "For example, in a YEARLY rule, the interval would be one year. A set of recurrence intstances starts at the beginning of the interval defined by the FREQ rule part." ie at the start of the year, irrespective of any BYXX parts. Or with the BYDAY text: Each BYDAY value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of a specific day within the MONTHLY or YEARLY "RRULE". * For example, within a MONTHLY rule, +1MO (or simply 1MO) * represents the first Monday within the month, whereas -1MO * represents the last Monday of the month. The numeric value in a It could just have easily said "For example, within a YEARLY rule, +1MO (or simply 1MO) represents the first Monday within the year, whereas -1MO represents the last Monday of the year.". But then it doesn't say that, instead it goes on to illustrate the special case: BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. If an integer Which of course equally doesn't make sense, see the thread Cyrus just started ;o) I'd have liked 3MO to be a short hand for BYDAY=MO, BYSETPOS = 3, in which case either with a yearly rule would always be the 3rd instance of Monday WRT to the start of the year. I appreciate we can't really change this anyway, as many TZ decls make use of this special case, including some in the standard itself (RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z), so I'm not lobbying we do so, I'm just stating that I think it's a shame, and it results in special cases in an already complicated area of the standard. Nigel Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E911080BB6 for ; Mon, 17 Mar 2008 06:12:29 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 470BC14223F for ; Mon, 17 Mar 2008 06:12:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-50 required=4 tests=[AWL=1.140, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQVQ9zTzToF0 for ; Mon, 17 Mar 2008 06:12:21 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9FA9F14223D for ; Mon, 17 Mar 2008 06:12:20 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HDCF4U010149 for ; Mon, 17 Mar 2008 14:12:15 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 14:12:12 +0100 User-Agent: KMail/1.9.6 References: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> In-Reply-To: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803171412.14523.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 13:12:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 17. März 2008 schrieb Nigel Swinson: > > The numeric value in a BYDAY rule part with the FREQ rule part set to > > YEARLY > > > corresponds to: > > - an offset within the month > > ---when the BYMONTH rule part is present, > > - and corresponds to an offset within the year > > -- when the BYWEEKNO **or** BYMONTH rule parts are present. > > > > So if BYMONTH is present, does that mean the offset is within a year or a > > month?  Both options match. > > > > I still think it's an non intuative shame that > > FREQ=YEARLY;BYDAY=3MO;BYMONTH=11 means the 3rd Monday in November rather > > than the 3rd Monday of the year when it falls in November, so I think it I think it should mean the 3rd monday in November. This becomes clear when you think of BYDAY in the same way as BYSETPOSITION: 1) Apply yearly, so all days in a year match 2) Apply BYMONTH, so only all dates in november match 3) Apply BYDAY, meaning the 3rd monday in the set of currently matching dates (which are just the days in november). 4) Apply all BYHOUR/BYMINUTE/BYSECOND (not present) 5) Take all missing information (i.e. time) from the DTSTART RFC 2445 makes it clear that the recurrence evaluation works on the list of matching date/times and limits or extends it step by step. That's the general algorithm as I understand it. The new elaboration in the RFC simply explains this in a different way. Cheers, Reinhold - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH3m4uTqjEwhXvPN0RAiR4AJwPE7UnVQhttq5EQiXkjy9MvIFduwCfRKwG QYvSXgX9DDfKeUTha33HEyk= =7Tvl -----END PGP SIGNATURE----- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A44980BAE for ; Mon, 17 Mar 2008 06:06:10 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AC14314223D for ; Mon, 17 Mar 2008 06:06:12 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-50 required=4 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIo0v2BtDh9y for ; Mon, 17 Mar 2008 06:06:00 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1257914223F for ; Mon, 17 Mar 2008 06:06:00 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: ed37adaa6bc7ce960b61355dc7881ce1 X-Spam-Score-Summary: 2, 0, 0, f5fc20912ab48f6a, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:69:355:379:539:540:541:542:543:567:600:601:945:960:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1544:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2379:2393:2551:2553:2559:2562:2693:2828:2893:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4605:5007:6117:6118:6119:6261:7576:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 06:05:56 -0700 Message-ID: <01e301c8882f$b46caa80$6501a8c0@nigelhome> From: "Nigel Swinson" To: Date: Mon, 17 Mar 2008 13:06:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [Ietf-calsify] De-mystifying the limit/expand behaviour of BYXX modifiers X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 13:06:10 -0000 > At this point, I have to say I am still slightly confused about all the > combinations of BYDAY plus the other BYxxx's. I really think more clarity > is needed here - even at this late stage. I quite agree Cyrus. I'll try for a third time to pass on my suggestions. ----- Original Message ----- From: "Nigel Swinson" To: Sent: Friday, February 08, 2008 4:15 PM Subject: De-mystifying the limit/expand behaviour of BYXX modifiers Second unanswered point from a mail form 21st September that nobody seemed to receive: Rather than give you lots more text to read, can I just urge you to (re)read the text below and provide opinions. I think recurrence is the most complicated part of iCalendar, and think it's worth crafting the addition of the new table just a little more. - The phrase "special expand" is mentioned nowhere else in the document. I think the concept was better expressed by my suggestion from the 29th May. You merge the "Expand" cells in the Yearly/Monthly columns to illustrate that each creates a set, and when taken together it's the union of the sets. Also even with a numeric modifier on ByDay, it's still the case that Monthly/Yearly + BYDAY will expand, and while it's true that numeric modifiers on ByDay with yearly rules requires attention, I think it's adequately dealt with in the paragraphs above on ByDay. So I'd make it: - BYDAY has some special behaviour depending on the FREQ value and - this is described in separate notes below the table. +----------+--------+--------+-------+-------+------+-------+------+ | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| - +----------+--------+--------+-------+-------+------+-------+------+ + |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | | + +----------+--------+--------+-------+-------+------+-------+ + + |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | | + +----------+--------+--------+-------+-------+------+-------+ + + |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| + +----------+--------+--------+-------+-------+------+-------+ + + |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | | + +----------+--------+--------+-------+-------+------+Expand + + + |BYDAY |Limit |Limit |Limit |Limit |Expand| | | + +----------+--------+--------+-------+-------+------+-------+------+ |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| +----------+--------+--------+-------+-------+------+-------+------+ |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| +----------+--------+--------+-------+-------+------+-------+------+ |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| +----------+--------+--------+-------+-------+------+-------+------+ |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | +----------+--------+--------+-------+-------+------+-------+------+ - Note 1: Limit if BYMONTHDAY is present, otherwise special expand - for MONTHLY. - - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise - special expand for WEEKLY if BYWEEKNO present, otherwise - special expand for MONTHLY if BYMONTH present, otherwise - special expand for YEARLY. + In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY work + together to expand the recurrence set. Each on their own will specify + a range of valid instances, and when used in combination it is the union + of all ranges that create the required recurrence set. So for example + in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1 will + mean the first of every month, so when used together they mean the first of + every month, but only when it's a Monday. It would not mean on the first + of every month and also on every Monday. Likewise in MONTHLY rules, + BYMONTHDAY and BYDAY work together to expand the recurrence set. Nigel Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F37B80BAE for ; Mon, 17 Mar 2008 06:06:01 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E146E142240 for ; Mon, 17 Mar 2008 06:06:03 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-50 required=4 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_40_50=0.496, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzdRePRBFGJp for ; Mon, 17 Mar 2008 06:05:52 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4A8F14223D for ; Mon, 17 Mar 2008 06:05:52 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 3f9abd001dd017d311c2100fc0c803e4 X-Spam-Score-Summary: 2, 0, 0, 21295486e2bc2226, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:1:2:355:379:476:539:540:541:542:543:567:600:601:602:945:962:967:973:980:983:988:989:1155:1156:1189:1208:1221:1261:1308:1309:1313:1314:1345:1394:1395:1431:1436:1437:1515:1516:1517:1521:1575:1587:1588:1589:1592:1594:1605:1617:1685:1730:1776:1792:2073:2075:2078:2198:2199:2551:2553:2557:2559:2562:2892:3521:3522:3523:3585:3635:3636:3769:3865:3866:3867:3868:3869:3870:3871:3872:3874:4051:4250:4605:4622:5007:6117:6119:6261:7576:7802:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,iso-8859-1,iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id for ; Mon, 17 Mar 2008 06:05:49 -0700 Message-ID: <01df01c8882f$b05610d0$6501a8c0@nigelhome> From: "Nigel Swinson" To: Date: Mon, 17 Mar 2008 13:06:16 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01C8882F.AF2272D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [Ietf-calsify] Fw: Discussion of UNTIL when used with STANDARD and DAYLIGHT sub-components X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 13:06:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01D9_01C8882F.AF2272D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Third attempt at sending: ----- Original Message ----- From: Nigel Swinson To: ietf-calsify@osafoundation.org Sent: Friday, February 08, 2008 4:14 PM Subject: Discussion of UNTIL when used with STANDARD and DAYLIGHT sub-components First point from a mail form 21st September that nobody seemed to receive: > >> 3.3.10. Recurrence Rule > >> > >> The UNTIL rule part defines a DATE or DATE-TIME value which bounds > >> the recurrence rule in an inclusive manner. If the value > >> specified by UNTIL is synchronized with the specified recurrence, > >> this DATE or DATE-TIME becomes the last instance of the > >> recurrence. The value of the UNTIL rule part MUST have the same > >> value type as the "DTSTART" property. Furthermore, if the > >> "DTSTART" property is specified as a date with local time, then > >> the UNTIL rule part MUST also be specified as a date with local > >> time. If the "DTSTART" property is specified as a date with > >> UTC time or a date with local time and time zone reference, then > >> the UNTIL rule part MUST be specified as a date with UTC time. In > >> the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL > >> - rule part MUST always be specified as a date with UTC time. If > >> - specified as a DATE-TIME value, then it MUST be specified in a UTC > >> - time format. If not present, and the COUNT rule part is also not > >> + rule part MUST always be specified as a date with UTC time, > >> with the > >> + "DTSTART" always represented as a date with local time. If the > >> UNTIL > >> + and COUNT rule parts are not >>> present, the "RRULE" is considered to repeat forever. > >> > > > > Substantial. > > Nigel's addition is not substantial. It is repeating what is > already specified in section 4.6.5 "Time Zone Component" of > RFC 2445, that is: > > The mandatory "DTSTART" property gives the effective onset date and > local time for the time zone sub-component definition. "DTSTART" in > this usage MUST be specified as a local DATE-TIME value. > > I'm not convinced we should repeat this information. > > No change done. The existing text has this: ... In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. ....... One of my objectives was to get rid of the second sentence, as I don't think it adds anything, and in the context of the whole paragraph it's confusing to know what the second sentence is even refering to. If this second sentence is to stay could someone please explain what it adds? My second objective was indeed to correlate more fully the relationship between DTSTART and UNTIL as it says in 4.6.5. The start of the paragraph has described this relationship in detail for DTSTART and UNTIL under normal circumstances, but then goes on to talk about the behaviour within the STANDARD/DAYLIGHT components. I think either it should leave all the discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or complete the discussion by saying, as I had suggested, that UNTIL is always date with UTC time and DTSTART is always date with local time. My third objective was to cleanup the language of the last sentence. So please can we have either: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + rule part MUST always be specified as a date with UTC time, with the + "DTSTART" always represented as a date with local time. If the + UNTIL and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. Or: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then - the UNTIL rule part MUST be specified as a date with UTC time. In - the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + the UNTIL rule part MUST be specified as a date with UTC time. + If the UNTIL and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. Nigel ------=_NextPart_000_01D9_01C8882F.AF2272D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Third attempt at sending:
 
----- Original Message -----=20
From: Nigel=20 Swinson
Sent: Friday, February 08, 2008 4:14 PM
Subject: Discussion of UNTIL when used with STANDARD and = DAYLIGHT=20 sub-components

First point from a mail form 21st September that = nobody seemed=20 to receive:

> = >>=20 3.3.10.  Recurrence Rule
> >>
>=20 >>       The UNTIL rule part defines = a DATE=20 or DATE-TIME value which
bounds
>=20 >>       the recurrence rule in an = inclusive=20 manner.  If the value
> = >>      =20 specified by UNTIL is synchronized with the specified = recurrence,
>=20 >>       this DATE or DATE-TIME = becomes the=20 last instance of the
> = >>      =20 recurrence.  The value of the UNTIL rule part MUST have the = same
>=20 >>       value type as the "DTSTART" = property.  Furthermore, if the
>=20 >>       "DTSTART" property is = specified as=20 a date with local time, then
>=20 >>       the UNTIL rule part MUST = also be=20 specified as a date with local
>=20 >>       time.  If the = "DTSTART"=20 property is specified as a date with
>=20 >>       UTC time or a date with = local time=20 and time zone reference, then
>=20 >>       the UNTIL rule part MUST be = specified as a date with UTC time.
In
>=20 >>       the case of the "STANDARD" = and=20 "DAYLIGHT" sub-components the
UNTIL
> >>=20 -      rule part MUST always be specified as a = date=20 with UTC time.  If
> >> -      = specified as a DATE-TIME value, then it MUST be specified in = a
UTC
>=20 >> -      time format.  If not = present, and=20 the COUNT rule part is also
not
> >>=20 +      rule part MUST always be specified as a = date=20 with UTC time,
> >> with the
> >>=20 +      "DTSTART" always represented as a date = with=20 local time.  If the
> >> UNTIL
> >>=20 +      and COUNT rule parts are=20 not
>>>         = =20 present, the "RRULE" is considered to repeat forever.
> = >>
>=20 >
> > Substantial.
>
> Nigel's addition is not=20 substantial.  It is repeating what is
> already specified in = section=20 4.6.5 "Time Zone Component" of
> RFC 2445, that=20 is:
>
>     The mandatory "DTSTART" = property=20 gives the effective onset date and
>     local = time=20 for the time zone sub-component definition. "DTSTART"=20 in
>     this usage MUST be specified as a = local=20 DATE-TIME value.
>
> I'm not convinced we should repeat this = information.
>
> No change done.

The existing text = has=20 this:

      ... =20 In
      the case of the "STANDARD" and = "DAYLIGHT"=20 sub-components the UNTIL
      rule part = MUST always=20 be specified as a date with UTC time.  = If
     =20 specified as a DATE-TIME value, then it MUST be specified in a=20 UTC
      time format. .......

One of = my=20 objectives was to get rid of the second sentence, as I don't think
it = adds=20 anything, and in the context of the whole paragraph it's confusing
to = know=20 what the second sentence is even refering to.  If this = second
sentence=20 is to stay could someone please explain what it adds?

My second = objective=20 was indeed to correlate more fully the relationship
between DTSTART = and UNTIL=20 as it says in 4.6.5.  The start of the paragraph
has described = this=20 relationship in detail for DTSTART and UNTIL under = normal
circumstances, but=20 then goes on to talk about the behaviour within the
STANDARD/DAYLIGHT = components.  I think either it should leave all the
discussion = of it's=20 behaviour within STANDARD/DAYLIGHT to section 4.6.5, or
complete the=20 discussion by saying, as I had suggested, that UNTIL is always
date = with UTC=20 time and DTSTART is always date with local time.

My third = objective was=20 to cleanup the language of the last sentence.

So please can we = have=20 either:

       time.  If the = "DTSTART"=20 property is specified as a date = with
       UTC=20 time or a date with local time and time zone reference,=20 then
       the UNTIL rule part MUST be = specified as a date with UTC time. =20 In
       the case of the "STANDARD" = and=20 "DAYLIGHT" sub-components the = UNTIL
 -     =20 rule part MUST always be specified as a date with UTC time. =20 If
 -      specified as a DATE-TIME = value, then=20 it MUST be specified in a UTC
 -      = time=20 format.  If not present, and the COUNT rule part is also=20 not
 +      rule part MUST always be = specified=20 as a date with UTC time, with = the
 +     =20 "DTSTART" always represented as a date with local time.  If=20 the
+       UNTIL and COUNT rule parts = are=20 not
       present, the "RRULE" is = considered=20 to repeat = forever.

Or:

      =20 time.  If the "DTSTART" property is specified as a date=20 with
       UTC time or a date with = local time=20 and time zone reference, then
-       = the UNTIL=20 rule part MUST be specified as a date with UTC time. =20 In
-       the case of the "STANDARD" = and=20 "DAYLIGHT" sub-components the = UNTIL
-      =20 rule part MUST always be specified as a date with UTC time. =20 If
-       specified as a DATE-TIME = value, then=20 it MUST be specified in a UTC
-       = time=20 format.  If not present, and the COUNT rule part is also=20 not
+       the UNTIL rule part MUST be = specified as a date with UTC = time.
+       If=20 the UNTIL and COUNT rule parts are = not
      =20 present, the "RRULE" is considered to repeat forever.
 
Nigel
------=_NextPart_000_01D9_01C8882F.AF2272D0-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DEB1080BA4 for ; Mon, 17 Mar 2008 06:05:42 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3AA5E14223F for ; Mon, 17 Mar 2008 06:05:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-50 required=4 tests=[AWL=0.094, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuxRWjiZuSFL for ; Mon, 17 Mar 2008 06:05:31 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id F11B814223E for ; Mon, 17 Mar 2008 06:05:30 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 5c7c860142b43253ab4884210e773d33 X-Spam-Score-Summary: 2, 0, 0, f9b5a89c6b930cdf, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:355:379:539:540:541:542:543:567:600:601:602:946:960:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2551:2553:2559:2562:2828:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4605:5007:6119:6261:7576:7802:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id for ; Mon, 17 Mar 2008 06:05:28 -0700 Message-ID: <01d401c8882f$a3ab92b0$6501a8c0@nigelhome> From: "Nigel Swinson" To: Subject: Fw: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt Date: Mon, 17 Mar 2008 13:05:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 13:05:43 -0000 This mislaid feedback is still valid, and highlights the same point that Cyrus just raised with proposed text for a fix. ----- Original Message ----- From: "Nigel Swinson" To: Sent: Friday, February 08, 2008 4:14 PM Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-08.txt > 3. iCalendar Object Specification > > Section 3.1. defines the content line format; Section 3.2. defines > the property parameter format; Section 3.3. defines the data types > for property values; Section 3.4. defines the iCalendar object > format; Section 3.5. defines the iCalendar property format; Section > 3.6. defines the calendar component format; Section 3.7. defines > - calendar properties; and Sectiopn 3.8. defines calendar component > + calendar properties; and Section 3.8. defines calendar component > properties. > > 3.3.10. Recurrence Rule > > represents the last Monday of the month. The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the month when the BYMONTH rule part is > present, and corresponds to an offset within the year when the > BYWEEKNO or BYMONTH rule parts are present. If an integer > modifier is not present, it means all days of this type within the > > ie: > > The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY > corresponds to: > - an offset within the month > ---when the BYMONTH rule part is present, > - and corresponds to an offset within the year > -- when the BYWEEKNO **or** BYMONTH rule parts are present. > > So if BYMONTH is present, does that mean the offset is within a year or a > month? Both options match. > > I still think it's an non intuative shame that > FREQ=YEARLY;BYDAY=3MO;BYMONTH=11 means the 3rd Monday in November rather > than the 3rd Monday of the year when it falls in November, so I think it has > to be: > > represents the last Monday of the month. The numeric value in a > BYDAY rule part with the FREQ rule part set to YEARLY corresponds > to an offset within the month when the BYMONTH rule part is > - present, and corresponds to an offset within the year when the > - BYWEEKNO or BYMONTH rule parts are present. If an integer > + present, and corresponds to an offset within the year otherwise. > + If an integer > modifier is not present, it means all days of this type within the > > Then a trivial one: > > The BYSETPOS rule part specifies a COMMA character (US-ASCII > decimal 44) separated list of values which corresponds to the nth > occurrence within the set of recurrence instances specified by the > rule. BYSETPOS operates on a set of recurrence instances in one > interval of the recurrence rule. For example, in a WEEKLY rule, > - the interval would be one week A set of recurrence instances > + the interval would be one week. A set of recurrence instances > starts at the beginning of the interval defined by the FREQ rule > part. Valid values are 1 to 366 or -366 to -1. It MUST only be > used in conjunction with another BYxxx rule part. For example > "the last work day of the month" could be represented as: > > Cheers > > Nigel > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 70C6F80B5D for ; Mon, 17 Mar 2008 06:05:33 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C27E014223F for ; Mon, 17 Mar 2008 06:05:35 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-50 required=4 tests=[AWL=0.107, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLw7Jz7X3C0l for ; Mon, 17 Mar 2008 06:05:26 -0700 (PDT) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4800D14223D for ; Mon, 17 Mar 2008 06:05:26 -0700 (PDT) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: ba22ee18b1fdd63a12cf1ca3b11beb0d X-Spam-Score-Summary: 2, 0, 0, 7509253e80545e6d, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, , RULES_HIT:4:355:379:539:540:541:542:543:567:599:601:945:960:967:973:980:982:988:989:1000:1042:1155:1156:1261:1308:1309:1313:1314:1345:1437:1515:1516:1518:1542:1575:1587:1594:1711:1730:1747:1764:1766:1792:2073:2075:2078:2110:2198:2199:2379:2393:2525:2551:2553:2559:2563:2682:2685:2692:2693:2857:2859:2892:2893:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4250:4427:5007:6119:6261:6506:7281:7398:7576:7679:7875:7903, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1,iso-8859-1,iso-8859-1,iso-8859-1 Received: from nigelhome (unverified [10.42.40.203]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id ; Mon, 17 Mar 2008 06:05:19 -0700 Message-ID: <01ce01c8882f$9e01fcf0$6501a8c0@nigelhome> From: "Nigel Swinson" To: "Cyrus Daboo" References: Subject: Re: [Ietf-calsify] 2445bis problem Date: Mon, 17 Mar 2008 13:05:45 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C9_01C8882F.9CACF440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: Calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 13:05:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01C9_01C8882F.9CACF440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > The numeric value in a BYDAY rule part with the FREQ rule part set to > YEARLY corresponds to an offset within the month when the BYMONTH rule > part is present, and corresponds to an offset within the year when the > BYWEEKNO or BYMONTH rule parts are present. > > BYMONTH is special-cased twice with different meaning. > > It also goes on to state: > > Furthermore, the BYDAY rule part MUST NOT be specified with a numeric > value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part > is specified. > > However, that means the BYWEEKNO description in the earlier statement is > bogus! Agreed :o) Irritatingly I made this very point to the list on the 8th Feb this year, but the post got eaten. :o( > At this point, I have to say I am still slightly confused about all the > combinations of BYDAY plus the other BYxxx's. I really think more clarity > is needed here - even at this late stage. I've been lobbying for this for quite some time. Sadly our company wanted to change email addresses from rockliffe.com to mailsite.com and in the change the calsify list software has been silently ignoring may last 5 posts to this list (I would have expected a bounce). I shall re-post them once I've persuaded to listen to me at mailsite.com. Ironically one of the messages it ate was as below: From: "Nigel Swinson" To: Sent: Friday, February 08, 2008 4:14 PM Subject: [Ietf-calsify] working group last call comments for draft-ietf-calsify-rfc2445bis-07.txt] > While reviewing http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08, > I wondered what would happen about recurrence rules, as I'd not seen much > discussion on the list on the topic. Looking in the archive, I notice that > the attached message never made it to the archive, and thus possibly never > made it to any of you. I guess that would partly explain the lack of > response, although I suspect it is largely because recurrence rules are > complex with a lot of corner cases, and it's hard to think about them. This > is the very reason why I am proposing changes, to make that difficult and > error prone area as easy as possible to understand. > > While I attach my message from September, I shall include re-send each open > item as a separate thread, in the hope that folks might respond to at least > one of the three open issues. > > Nigel ------=_NextPart_000_01C9_01C8882F.9CACF440 Content-Type: message/rfc822; name="Re_ [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re_ [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt.eml" From: "Nigel Swinson" To: "CALSIFY Mailinglist" Cc: "Bernard Desruisseaux" , "Eliot Lear" References: <46C033F0.6010203@cisco.com> <46E99A9E.4010906@oracle.com> Subject: Re: [Ietf-calsify] working group last call commentsfor draft-ietf-calsify-rfc2445bis-07.txt Date: Fri, 21 Sep 2007 17:15:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 > Hi Nigel, > > "Not changed for now" meant that I would not do the change > until we have had input from the working group. > > Cheers, > Bernard Ok so there are 3 issues remaining from my feedback, two of which require additional input from the working group to proceed. So could folks please have a read through and comment? I care about the third one the most... > >> 3.3.10. Recurrence Rule > >> > >> The UNTIL rule part defines a DATE or DATE-TIME value which bounds > >> the recurrence rule in an inclusive manner. If the value > >> specified by UNTIL is synchronized with the specified recurrence, > >> this DATE or DATE-TIME becomes the last instance of the > >> recurrence. The value of the UNTIL rule part MUST have the same > >> value type as the "DTSTART" property. Furthermore, if the > >> "DTSTART" property is specified as a date with local time, then > >> the UNTIL rule part MUST also be specified as a date with local > >> time. If the "DTSTART" property is specified as a date with > >> UTC time or a date with local time and time zone reference, then > >> the UNTIL rule part MUST be specified as a date with UTC time. In > >> the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL > >> - rule part MUST always be specified as a date with UTC time. If > >> - specified as a DATE-TIME value, then it MUST be specified in a UTC > >> - time format. If not present, and the COUNT rule part is also not > >> + rule part MUST always be specified as a date with UTC time, > >> with the > >> + "DTSTART" always represented as a date with local time. If the > >> UNTIL > >> + and COUNT rule parts are not >>> present, the "RRULE" is considered to repeat forever. > >> > > > > Substantial. > > Nigel's addition is not substantial. It is repeating what is > already specified in section 4.6.5 "Time Zone Component" of > RFC 2445, that is: > > The mandatory "DTSTART" property gives the effective onset date and > local time for the time zone sub-component definition. "DTSTART" in > this usage MUST be specified as a local DATE-TIME value. > > I'm not convinced we should repeat this information. > > No change done. The existing text has this: ... In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL rule part MUST always be specified as a date with UTC time. If specified as a DATE-TIME value, then it MUST be specified in a UTC time format. ....... One of my objectives was to get rid of the second sentence, as I don't think it adds anything, and in the context of the whole paragraph it's confusing to know what the second sentence is even refering to. If this second sentence is to stay could someone please explain what it adds? My second objective was indeed to correlate more fully the relationship between DTSTART and UNTIL as it says in 4.6.5. The start of the paragraph has described this relationship in detail for DTSTART and UNTIL under normal circumstances, but then goes on to talk about the behaviour within the STANDARD/DAYLIGHT components. I think either it should leave all the discussion of it's behaviour within STANDARD/DAYLIGHT to section 4.6.5, or complete the discussion by saying, as I had suggested, that UNTIL is always date with UTC time and DTSTART is always date with local time. My third objective was to cleanup the language of the last sentence. So please can we have either: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then the UNTIL rule part MUST be specified as a date with UTC time. In the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + rule part MUST always be specified as a date with UTC time, with the + "DTSTART" always represented as a date with local time. If the UNTIL + and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. Or: time. If the "DTSTART" property is specified as a date with UTC time or a date with local time and time zone reference, then - the UNTIL rule part MUST be specified as a date with UTC time. In - the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not + the UNTIL rule part MUST be specified as a date with UTC time. + If the UNTIL and COUNT rule parts are not present, the "RRULE" is considered to repeat forever. > >> WRT to the text below I think we should either: > >> - Say BYSETPOS is only valid with Weekly, Monthly, Yearly rules, > >> - Specify what the "interval" for daily, hourly, minutely, secondly > >> means. > >> - Drop the new text, as I think the example is sufficient illustration. > >> - Change the example to illustrate what obscurity it was that lead to the > >> need for the new text. > >> > >> My vote would be to drop some of the new text to become: > >> > >> The BYSETPOS rule part specifies a COMMA character (US-ASCII > >> decimal 44) separated list of values which corresponds to the nth > >> occurrence within the set of recurrence instances specified by the > >> rule. BYSETPOS operates on a set of recurrence instances in one > >> - interval of the recurrence rule. For a WEEKLY rule, the interval > >> - is one week, for a MONTHLY rule, one month, and for a YEARLY rule, > >> - one year. Valid values are 1 to 366 or -366 to -1. It MUST only > >> + interval of the recurrence rule. > >> + Valid values are 1 to 366 or -366 to -1. It MUST only > >> be used in conjunction with another BYxxx rule part. For example > >> "the last work day of the month" could be represented as: > >> > >> FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 > >> > >> Each BYSETPOS value can include a positive (+n) or negative (-n) > >> integer. If present, this indicates the nth occurrence of the > >> specific occurrence within the set of occurences specified by the > >> rule. > > > > Substantial. > > Not changed. I think this is important, as currently we have it's an inconsistent level of specification, which I think leaves it vague what BYSETPOS means with daily, hourly, minutely, secondly. Could people please comment/vote? > >> The phrase "special expand" is mentioned nowhere else in the document. I > >> think the concept was better expressed by my suggestion from the 29th May. > >> You merge the "Expand" cells in the Yearly/Monthly columns to illustrate > >> that each creates a set, and when taken together it's the union of the sets. > >> Also even with a numeric modifier on ByDay, it's still the case that > >> Monthly/Yearly + BYDAY will expand, and while it's true that numeric > >> modifiers on ByDay with yearly rules requires attention, I think it's > >> adequately dealt with in the paragraphs above on ByDay. So I'd make it: > >> > >> - BYDAY has some special behaviour depending on the FREQ value and > >> - this is described in separate notes below the table. > >> > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| > >> - +----------+--------+--------+-------+-------+------+-------+------+ > >> + |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit | | > >> + +----------+--------+--------+-------+-------+------+-------+ + > >> + |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A | | > >> + +----------+--------+--------+-------+-------+------+-------+ + > >> + |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| > >> + +----------+--------+--------+-------+-------+------+-------+ + > >> + |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A | | | > >> + +----------+--------+--------+-------+-------+------+Expand + + > >> + |BYDAY |Limit |Limit |Limit |Limit |Expand| | | > >> + +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand| > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> |BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit | > >> +----------+--------+--------+-------+-------+------+-------+------+ > >> > >> - Note 1: Limit if BYMONTHDAY is present, otherwise special expand > >> - for MONTHLY. > >> - > >> - Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise > >> - special expand for WEEKLY if BYWEEKNO present, otherwise > >> - special expand for MONTHLY if BYMONTH present, otherwise > >> - special expand for YEARLY. > >> > >> + In YEARLY rules, BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY work > >> + together to expand the recurrence set. Each on their own will specify > >> + a range of valid instances, and when used in combination it is the union > >> + of all ranges that create the required recurrence set. So for example > >> + in a YEARLY rule BYDAY=MO will mean every Monday, and BYMONTHDAY=1 will > >> + mean the first of every month, so when used together they mean the first of > >> + every month, but only when it's a Monday. It would not mean on the first > >> + of every month and also on every Monday. Likewise in MONTHLY rules, > >> + BYMONTHDAY and BYDAY work together to expand the recurrence set. > >> > > > > > > Substantial and editorial. The combining of boxes is editorial. > > Not changed for now. > Rather than give you lots more text to read, can I just urge you to (re)read the text above and provide opinions. I think recurrence is the most complicated part of iCalendar, and think it's worth crafting the addition of the new table just a little more. > Nigel: Thanks a lot! You are most welcome. Thanks for processing my feedback :o) Nigel ------=_NextPart_000_01C9_01C8882F.9CACF440-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 72CEF80AD8 for ; Fri, 14 Mar 2008 14:32:13 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C4374142230 for ; Fri, 14 Mar 2008 14:32:15 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-50 required=4 tests=[AWL=0.081, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWAfmBiXopLD for ; Fri, 14 Mar 2008 14:32:09 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59732142213 for ; Fri, 14 Mar 2008 14:32:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7A9A7411D4B; Fri, 14 Mar 2008 17:32:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7H6hHEM5Yaw; Fri, 14 Mar 2008 17:32:06 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 4B5BD411D44; Fri, 14 Mar 2008 17:32:05 -0400 (EDT) Date: Fri, 14 Mar 2008 17:32:02 -0400 From: Cyrus Daboo To: Reinhold Kainhofer , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2445bis problem Message-ID: In-Reply-To: <200803142225.12900.reinhold@kainhofer.com> References: <200803142225.12900.reinhold@kainhofer.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 21:32:13 -0000 Hi Reinhold, --On March 14, 2008 10:25:12 PM +0100 Reinhold Kainhofer=20 wrote: >> =C2=A0 =C2=A0 Furthermore, the BYDAY rule part MUST NOT be specified = with a >> numeric =C2=A0 =C2=A0 value with the FREQ rule part set to YEARLY when = the >> BYWEEKNO rule part =C2=A0 =C2=A0 is specified. > > Doesn't this make it impossible to recur on yearly on e.g. Wednesday of > calendar week 3? Notice that if Jan 1 is a Thursday, that's the second > Wednesday of the year, in all other cases it's the third Wednesday... Isn't that just: RRULE:FREQ=3DYEARLY;BYWEEKNO=3D3;BYDAY=3DWE Are you saying that you might want to only pick the instance if its the 2nd = Wednesday of the year? --=20 Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3535D7FC1F for ; Fri, 14 Mar 2008 14:25:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 87F81142230 for ; Fri, 14 Mar 2008 14:25:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-50 required=4 tests=[AWL=1.154, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5ConNe18ods for ; Fri, 14 Mar 2008 14:25:23 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1B6B4142213 for ; Fri, 14 Mar 2008 14:25:22 -0700 (PDT) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2ELPHNd005319 for ; Fri, 14 Mar 2008 22:25:17 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2445bis problem Date: Fri, 14 Mar 2008 22:25:12 +0100 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803142225.12900.reinhold@kainhofer.com> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 21:25:30 -0000 Am Freitag, 14. M=E4rz 2008 schrieb Cyrus Daboo: > It also goes on to state: > > =A0 =A0 Furthermore, the BYDAY rule part MUST NOT be specified with a num= eric > =A0 =A0 value with the FREQ rule part set to YEARLY when the BYWEEKNO rul= e part > =A0 =A0 is specified. Doesn't this make it impossible to recur on yearly on e.g. Wednesday of=20 calendar week 3? Notice that if Jan 1 is a Thursday, that's the second=20 Wednesday of the year, in all other cases it's the third Wednesday... Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 65C2C7FCC0 for ; Fri, 14 Mar 2008 14:13:39 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B710F142230 for ; Fri, 14 Mar 2008 14:13:41 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-50 required=4 tests=[AWL=0.082, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9N87Q1pgn9u for ; Fri, 14 Mar 2008 14:13:29 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13F58142213 for ; Fri, 14 Mar 2008 14:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DB94B411970 for ; Fri, 14 Mar 2008 17:13:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gUlDw9aGLFr for ; Fri, 14 Mar 2008 17:13:25 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 9EF42411969 for ; Fri, 14 Mar 2008 17:13:24 -0400 (EDT) Date: Fri, 14 Mar 2008 17:13:21 -0400 From: Cyrus Daboo To: Calsify Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] 2445bis problem X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 21:13:39 -0000 Hi, I think there is a problem in the recurrence description section 3.3.10 in 2445bis: The numeric value in a BYDAY rule part with the FREQ rule part set to YEARLY corresponds to an offset within the month when the BYMONTH rule part is present, and corresponds to an offset within the year when the BYWEEKNO or BYMONTH rule parts are present. BYMONTH is special-cased twice with different meaning. It also goes on to state: Furthermore, the BYDAY rule part MUST NOT be specified with a numeric value with the FREQ rule part set to YEARLY when the BYWEEKNO rule part is specified. However, that means the BYWEEKNO description in the earlier statement is bogus! At this point, I have to say I am still slightly confused about all the combinations of BYDAY plus the other BYxxx's. I really think more clarity is needed here - even at this late stage. I am going to try and put together a complete set of examples for all the possible combinations of numeric/non-numeric BYDAY with YEARLY/MONTHLY and other BYxxx rules and see whether all those make sense in terms of the current statements in 2445bis. This might take a while but I think is an important step to verify that we have the description of all these BYxxx's right. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A7A807F9CC for ; Tue, 11 Mar 2008 07:10:52 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E4DDE14223E for ; Tue, 11 Mar 2008 07:10:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-50 required=4 tests=[AWL=-0.209, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTIwEWURBKEA for ; Tue, 11 Mar 2008 07:10:48 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21F1F142229 for ; Tue, 11 Mar 2008 07:10:48 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id znnA1Y00G17UAYkAA0AS00; Tue, 11 Mar 2008 14:10:38 +0000 Received: from THare ([71.203.100.120]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id zqAd1Y0082brFRz8Z00000; Tue, 11 Mar 2008 14:10:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=ncHgQnoCPMIA:10 a=VE6_KAKKAAAA:8 a=PFsjAnyDAAAA:8 a=ek_QrCG2vNzMHJXn_HIA:9 a=BnUlCaTvwUbh2tdd_pwA:7 a=tF5R0rsj8GIKtIb__0RJTD2lkh4A:4 a=YewFc9KQ5U8A:10 a=gFYf5DKMwWcA:10 From: "Tim Hare" To: "'Cyrus Daboo'" , Subject: RE: [Ietf-calsify] Issue 95: text on REQUEST-STATUS Date: Tue, 11 Mar 2008 10:10:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AciDLIj6o1zDQzeNS6emPWc3jWiHeQAVMgKA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Message-Id: <20080311141048.21F1F142229@laweleka.osafoundation.org> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 14:10:52 -0000 "Additional codes MAY be used provided it is known that the recipient's CUA has appropriate knowledge of such codes." This is not a good thing for interoperability. CUA-specific status codes need to be an X- component (ex: X-MYCAL-REQUEST-STATUS). The only way one end can know for certain the other end "has appropriate knowledge of such codes" is if both are from the same vendor. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Cyrus Daboo Sent: Tuesday, March 11, 2008 12:01 AM To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Issue 95: text on REQUEST-STATUS Hi, Here is some proposed text to address issue 95 in the tracker. . This text would replace the one line of text currently above the table in section 3.1.6 in 2446bis: 3.6 Status Replies The "REQUEST-STATUS" property is used to convey status information about a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes listed in the table below SHOULD be used. Additional codes MAY be used provided it is known that the recipient's CUA has appropriate knowledge of such codes. This specification allows for multiple "REQUEST-STATUS" properties to be returned in iCalendar components in the appropriate iTIP messages. When multiple "REQUEST-STATUS" properties are present, the following restrictions apply: 1) Within any one component, the "top-level" numeric value of the "short return status code" MUST be the same for all REQUEST-STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a single component. 2) Across all components in the iTIP message, the following applies: a) If any one component would have a 3.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. b) If any one component would have a 5.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. This rule overrides (a) above. c) 2.xx and 4.xx codes can be used in different components provided that each component follows the restriction in (1) above. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E28877F9CC for ; Tue, 11 Mar 2008 07:07:54 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43905142229 for ; Tue, 11 Mar 2008 07:07:57 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-50 required=4 tests=[AWL=0.699, BAYES_00=-2.599, MSGID_FROM_MTA_ID=1.393, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-InKHnPVU5N for ; Tue, 11 Mar 2008 07:07:46 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F38614222C for ; Tue, 11 Mar 2008 07:07:46 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id zoAb1Y0031HpZEsA209L00; Tue, 11 Mar 2008 14:06:57 +0000 Received: from THare ([71.203.100.120]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id zq7d1Y00R2brFRz8a00000; Tue, 11 Mar 2008 14:07:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=VE6_KAKKAAAA:8 a=PFsjAnyDAAAA:8 a=ZvXawCQs5LtEqCCsXnoA:9 a=TN2ZvA37RrV3nIcnr4gA:7 a=cWQN3E3hLwxF0SKKEg16RCnfnlkA:4 a=YewFc9KQ5U8A:10 a=XF7b4UCPwd8A:10 From: "Tim Hare" To: "'Cyrus Daboo'" , Subject: RE: [Ietf-calsify] Issue 86 Date: Tue, 11 Mar 2008 10:07:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AciDL/u57xSouai6QYKs2GWUt/J2pQAUCboA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Message-Id: <20080311140746.7F38614222C@laweleka.osafoundation.org> X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 14:07:55 -0000 This doesn't seem right to me, somehow. It seems as though we are somehow specifying how the CUA interacts with the user (whether to be notified or not, etcetera). This, to me, does not belong in iTIP . iTIP should be solely about the exchange of calendaring information between two calendaring tools; adding CUA<->user interaction is really outside the scope of iTIP. As such, it adds un-needed complexity to the document which doesn't advance the goals of simplification and interoperability. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Cyrus Daboo Sent: Tuesday, March 11, 2008 12:25 AM To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Issue 86 Hi, Below is some addition text to partly address issue 86. . This is one piece in the ongoing clarification of SEQUENCE. Another clarification will be done on whether SEQUENCE can be different in components in the same recurrence set. 2.1.4 ... Whilst a change in SEQUENCE number is indicative of a significant change to a previously scheduled item that should be brought to the attention of a calendar user, ATTENDEE CUAs SHOULD NOT rely solely on a change in SEQUENCE as a means of alerting a calendar user to a change. Instead CUAs SHOULD compare the old and new versions of the calendar components and determine the exact nature of the changes and make decisions, possible based on calendar user preferences, as to whether the user needs to be explicitly informed of the change. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 229C37FCD4 for ; Mon, 10 Mar 2008 21:25:44 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 75BC1142212 for ; Mon, 10 Mar 2008 21:25:46 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLGWGOwf+P0w for ; Mon, 10 Mar 2008 21:25:37 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1AF90142228 for ; Mon, 10 Mar 2008 21:25:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 471C03E3AC9 for ; Tue, 11 Mar 2008 00:25:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJogoO2kp1zn for ; Tue, 11 Mar 2008 00:25:33 -0400 (EDT) Received: from dhcp-1790.ietf71.ietf.org (unknown [63.133.180.130]) by daboo.name (Postfix) with ESMTP id E87FD3E3AC2 for ; Tue, 11 Mar 2008 00:25:32 -0400 (EDT) Date: Tue, 11 Mar 2008 00:25:15 -0400 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] Issue 86 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 04:25:44 -0000 Hi, Below is some addition text to partly address issue 86. . This is one piece in the ongoing clarification of SEQUENCE. Another clarification will be done on whether SEQUENCE can be different in components in the same recurrence set. 2.1.4 ... Whilst a change in SEQUENCE number is indicative of a significant change to a previously scheduled item that should be brought to the attention of a calendar user, ATTENDEE CUAs SHOULD NOT rely solely on a change in SEQUENCE as a means of alerting a calendar user to a change. Instead CUAs SHOULD compare the old and new versions of the calendar components and determine the exact nature of the changes and make decisions, possible based on calendar user preferences, as to whether the user needs to be explicitly informed of the change. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4C0E67FCD4 for ; Mon, 10 Mar 2008 21:01:04 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9C4A1142228 for ; Mon, 10 Mar 2008 21:01:06 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db1-mA50Myfv for ; Mon, 10 Mar 2008 21:00:59 -0700 (PDT) Received: from daboo.name (unknown [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 672A1142212 for ; Mon, 10 Mar 2008 21:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 20A223E38BB for ; Tue, 11 Mar 2008 00:00:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZGv8h-E2eq9 for ; Tue, 11 Mar 2008 00:00:53 -0400 (EDT) Received: from dhcp-1790.ietf71.ietf.org (unknown [63.133.180.130]) by daboo.name (Postfix) with ESMTP id 25A3C3E38B4 for ; Tue, 11 Mar 2008 00:00:53 -0400 (EDT) Date: Tue, 11 Mar 2008 00:00:36 -0400 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Ietf-calsify] Issue 95: text on REQUEST-STATUS X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2008 04:01:04 -0000 Hi, Here is some proposed text to address issue 95 in the tracker. . This text would replace the one line of text currently above the table in section 3.1.6 in 2446bis: 3.6 Status Replies The "REQUEST-STATUS" property is used to convey status information about a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes listed in the table below SHOULD be used. Additional codes MAY be used provided it is known that the recipient's CUA has appropriate knowledge of such codes. This specification allows for multiple "REQUEST-STATUS" properties to be returned in iCalendar components in the appropriate iTIP messages. When multiple "REQUEST-STATUS" properties are present, the following restrictions apply: 1) Within any one component, the "top-level" numeric value of the "short return status code" MUST be the same for all REQUEST-STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a single component. 2) Across all components in the iTIP message, the following applies: a) If any one component would have a 3.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. b) If any one component would have a 5.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. This rule overrides (a) above. c) 2.xx and 4.xx codes can be used in different components provided that each component follows the restriction in (1) above. -- Cyrus Daboo