From nobody Thu Oct 2 10:44:33 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EDC1A8F48 for ; Thu, 2 Oct 2014 10:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rkHtWmzMjtY for ; Thu, 2 Oct 2014 10:44:29 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id DA4DA1A6FBB for ; Thu, 2 Oct 2014 10:44:26 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2BF90B2E1A0 for ; Thu, 2 Oct 2014 13:44:26 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 2235CB2E176 for ; Thu, 2 Oct 2014 13:44:26 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.51]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 13:44:26 -0400 From: "Anganes, Amanda L" To: "Anganes, Amanda L" , "calsify@ietf.org" Thread-Topic: [calsify] Call for WG Adoption: draft-daboo-icalendar-rscale-04 Thread-Index: AQHP3miBuAscpoR8KEy6QNSgB9bl4w== Date: Thu, 2 Oct 2014 17:44:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.146.16.47] Content-Type: multipart/alternative; boundary="_000_D05305C721114aanganesmitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/hCQfvxuW58WbCe-fLjjfHXkSo14 Subject: Re: [calsify] Call for WG Adoption: draft-daboo-icalendar-rscale-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:44:31 -0000 --_000_D05305C721114aanganesmitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Based on the feedback we've received, RSCALE has been adopted by this worki= ng group as an active document. Cheers, Amanda & Donald From: , "Anganes, Amanda L" > Date: Friday, September 12, 2014 at 10:04 AM To: "calsify@ietf.org" > Subject: [calsify] Call for WG Adoption: draft-daboo-icalendar-rscale-04 Hi, This is a call for comments on the adoption of draft-daboo-icalendar-rscale= -04 (RSCALE) as Calendaring Extensions WG drafts. Please comment by Septemb= er 26th. If you have already commented about the adoption of RSCALE in a separate th= read, please resend as a reply to this thread so we can track all of the co= mments in one place. Thanks, Amanda & Donald --_000_D05305C721114aanganesmitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <9877DB3E562AA54383C76EDD565AD56D@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
Hello,

Based on the feedback we've received, RSCALE has been adopted by this = working group as an active document. 

Cheers,

Amanda & Donald

From: <Anganes>, "Angane= s, Amanda L" <aanganes@mitre.= org>
Date: Friday, September 12, 2014 at= 10:04 AM
To: "calsify@ietf.org" <calsify@ietf.org>
Subject: [calsify] Call for WG Adop= tion: draft-daboo-icalendar-rscale-04

Hi,

This is a call for comments on the adoption of draft-daboo-icalen= dar-rscale-04 (RSCALE) as Calendaring Extensions WG drafts. Please comment = by September 26th. 

If you have already commented about the adoption of RSCALE in a separa= te thread, please resend as a reply to this thread so we can track all of t= he comments in one place.

Thanks,

Amanda & Donald

--_000_D05305C721114aanganesmitreorg_-- From nobody Fri Oct 3 06:32:18 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082A51A0AF1 for ; Fri, 3 Oct 2014 06:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVT5GQ8sMCu8 for ; Fri, 3 Oct 2014 06:32:15 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60B31A1A86 for ; Fri, 3 Oct 2014 06:32:06 -0700 (PDT) Received: from [192.168.1.22] (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id s93DW4JI005364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 3 Oct 2014 09:32:05 -0400 Message-ID: <542EA554.1020700@andrew.cmu.edu> Date: Fri, 03 Oct 2014 09:32:04 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.3.132419 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_1099 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_START 0, __SUBJ_ALPHA_START_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.39 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/uzcl6dUaPC61hW0vBL_sVq5DYB4 Subject: [calsify] draft-daboo-icalendar-rscale-04 editorial nits X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:32:17 -0000 Hi All, After another complete re-read, here are a few editorial nits to get us started on draft-ietf-calext-icalendar-rscale-00: Section 3, 2nd last sent: This might be more of a regional thing, but should "later" be "latter" ? Section 3, last sent: Since iCalendar uses ISO weeks, should we say "The number of whole [ISO.8601.2004] weeks in a year is either 52 or 53" ? Section 3: para 3: The two items listed seem more like guidelines, principles, or rules rather than a procedure. Should we change "the following procedure is used" to "the following principles are followed" or "the following rules are used" or some other permutation? Section, 1st sent: "clients and server" -> "clients and servers" Section 11.1, UNICODE.CLDR: Should we use the following URI rather than picking a particular release? http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Sat Oct 4 09:29:01 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3721A00DF for ; Sat, 4 Oct 2014 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_IWWflzvnGU for ; Sat, 4 Oct 2014 09:28:59 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3671A00DD for ; Sat, 4 Oct 2014 09:28:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4DFFBB0F543; Sat, 4 Oct 2014 12:26:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nifYzryT47eb; Sat, 4 Oct 2014 12:26:33 -0400 (EDT) Received: from [192.168.1.232] (94.197.120.241.threembb.co.uk [94.197.120.241]) by daboo.name (Postfix) with ESMTPSA id D68F3B0F538; Sat, 4 Oct 2014 12:26:32 -0400 (EDT) Date: Sat, 04 Oct 2014 17:28:52 +0100 From: Cyrus Daboo To: Ken Murchison , calsify@ietf.org Message-ID: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1745 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/6xSqzX27dkOy8v62WsZ5HoMBB6w Subject: Re: [calsify] draft-daboo-icalendar-rscale-04 editorial nits X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 16:29:00 -0000 Hi Ken, Thanks for your review. I will apply fixes to the WG -00 draft which I am working on now. --On October 3, 2014 at 9:32:04 AM -0400 Ken Murchison wrote: > Section 3, 2nd last sent: This might be more of a regional thing, but > should "later" be "latter" ? Fixed. > Section 3, last sent: Since iCalendar uses ISO weeks, should we say "The > number of whole [ISO.8601.2004] weeks in a year is either 52 or 53" ? Well the ISO things refers to how weeks are numbered not actual weeks in a year - there are always 52 whole weeks in a year (if you start counting from 1st January). I would be willingly to clarify the text with this change: The number of whole weeks in a year is 52 (though the [ISO.8601.2004] week numbering scheme used by iCalendar [RFC5545] can have a numeric count up to 53). > Section 3: para 3: The two items listed seem more like guidelines, > principles, or rules rather than a procedure. Should we change "the > following procedure is used" to "the following principles are followed" > or "the following rules are used" or some other permutation? I will use "principles". > Section, 1st sent: "clients and server" -> "clients and servers" Fixed. > Section 11.1, UNICODE.CLDR: Should we use the following URI rather than > picking a particular release? > http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml I have updated that to the latest release. However, I am not sure about doing what you suggest given that this is a normative reference. I would have thought a "stable" reference is preferred rather than a "moving target". It would be good to get some feedback from the chairs/ADs/RFC-Editor (or anyone else) on that. -- Cyrus Daboo From nobody Sat Oct 4 09:39:08 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD131A00F0 for ; Sat, 4 Oct 2014 09:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTJmxTUwqqVF for ; Sat, 4 Oct 2014 09:39:04 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5B61A00E6 for ; Sat, 4 Oct 2014 09:39:03 -0700 (PDT) Received: from [192.168.1.22] (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id s94GcrMU027077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 4 Oct 2014 12:38:54 -0400 Message-ID: <5430229D.7050300@andrew.cmu.edu> Date: Sat, 04 Oct 2014 12:38:53 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cyrus Daboo , calsify@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.4.163022 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1600_1699 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.39 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/oDJmzOjh2ZrabNBDLyOQ2VRWtcM Subject: Re: [calsify] draft-daboo-icalendar-rscale-04 editorial nits X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 16:39:06 -0000 On 10/04/2014 12:28 PM, Cyrus Daboo wrote: > Hi Ken, > Thanks for your review. I will apply fixes to the WG -00 draft which I > am working on now. > > --On October 3, 2014 at 9:32:04 AM -0400 Ken Murchison > wrote: > > >> Section 3, last sent: Since iCalendar uses ISO weeks, should we say "The >> number of whole [ISO.8601.2004] weeks in a year is either 52 or 53" ? > > Well the ISO things refers to how weeks are numbered not actual weeks > in a year - there are always 52 whole weeks in a year (if you start > counting from 1st January). I would be willingly to clarify the text > with this change: > > The number of whole weeks in a year is 52 (though the [ISO.8601.2004] > week numbering scheme used by iCalendar [RFC5545] can have a numeric > count up to 53). Right, I may have over-analyzed this one. This existing text is probably fine, but let's see if anyone else comments. >> Section 11.1, UNICODE.CLDR: Should we use the following URI rather than >> picking a particular release? >> http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml > > I have updated that to the latest release. However, I am not sure > about doing what you suggest given that this is a normative reference. > I would have thought a "stable" reference is preferred rather than a > "moving target". It would be good to get some feedback from the > chairs/ADs/RFC-Editor (or anyone else) on that. That's a good question. Let's see what the IETF/IAB folks say. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Sat Oct 4 10:34:05 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246D71A00FD; Sat, 4 Oct 2014 10:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t67DrV2pRqU; Sat, 4 Oct 2014 10:19:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFADC1A00FA; Sat, 4 Oct 2014 10:19:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141004171935.28979.96196.idtracker@ietfa.amsl.com> Date: Sat, 04 Oct 2014 10:19:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/E7AFZtDFPlhQWTUkm0rwmLNe-4Q X-Mailman-Approved-At: Sat, 04 Oct 2014 10:34:02 -0700 Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-rscale-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 17:19:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions Working Group of the IETF. Title : Non-Gregorian Recurrence Rules in iCalendar Authors : Cyrus Daboo Gregory Yakushev Filename : draft-ietf-calext-rscale-00.txt Pages : 15 Date : 2014-10-04 Abstract: This document defines how non-Gregorian recurrence rules can be specified and used in iCalendar data, and with CalDAV servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-rscale/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-calext-rscale-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 8 06:24:11 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3554F1A1A42 for ; Wed, 8 Oct 2014 06:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl_AfVltseJo for ; Wed, 8 Oct 2014 06:24:08 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78C51A19F9 for ; Wed, 8 Oct 2014 06:24:07 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so6797133vcb.0 for ; Wed, 08 Oct 2014 06:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=BWZr3tW/Rz4Mfra1JWWDK41EaRLV3GC7WgcG9tkq/EM=; b=X0vnJXrTOUT7HuJh8wTAr4U02FD17UQZ9rG8RjOSNwonCuMMiZneOq/udAE88ZnX9e zE1bYg1nZy2+HacwQUWPFKdzyWKAcu9rpQK3QPMdh3z+TxJn1nA3x1yds3vRkW0Azy4h Eu5M0daLySGKcNCyfCRgoe+jDkKYDKbWopfapVVaah8W0JRdW9U9Zu6lK048eGj8ZnRB lzDeJLmqY1Z8xllVSpvPtIAHSCGFWomckzC0pImnRSH2vLu2T694+IQEAyoeKUM+cgwq ywFGcXneVqbgT2oPce0p0wSjIKIrWFAeMdz5Or3Ywg1wiI5p2zA+7djTyzA8lkFJdqUU z8cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=BWZr3tW/Rz4Mfra1JWWDK41EaRLV3GC7WgcG9tkq/EM=; b=ZHltvEqWOqxgqyjd+AWY5oR5U6Jy1L6thACxcS9g5+Se06i/g4guJa+f3QTSZ6LflF mt126jIBq3OtF/pw8pjQT2WyCiixf5A9031OAfejcKFJ9DUOVjmVZ2v9w9mPcWkEIH/K uNIhxXkI7XhFc6ytVmeiGp9gRVGfqUm7Zlb0x2MMwXYSu+lzqXVt704+SKC9upvsiyjo E4n/Lw6DNypzFS8iBnuC8JmzHTIthixQZnl2zdaRd4GDkcdGH7y+5HxMUCoXCMU3AfYp 6Ing29sk76CAACL4Mco5oHmAi3/aMbUuorFcAyS3dxlbah6MXLhdFmrHaMOFA2JdVl2w G6tw== X-Gm-Message-State: ALoCoQmsX6a7mhAhycaC9atSIAJ1r7rYMpsjSGNtmLu6InM6s4jKLcbxMFNp8hJCJ9MqBT8+DAR8 X-Received: by 10.220.6.7 with SMTP id 7mr10167531vcx.1.1412774642610; Wed, 08 Oct 2014 06:24:02 -0700 (PDT) MIME-Version: 1.0 References: <5430229D.7050300@andrew.cmu.edu> From: Gregory Yakushev Date: Wed, 08 Oct 2014 13:24:01 +0000 Message-ID: To: Ken Murchison , Cyrus Daboo , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a11c3e27eb891d50504e93a4b Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/qZaq8kdq5pyAckEHKr9F8KY0Lps Subject: Re: [calsify] draft-daboo-icalendar-rscale-04 editorial nits X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 13:24:10 -0000 --001a11c3e27eb891d50504e93a4b Content-Type: text/plain; charset=UTF-8 On Sat Oct 04 2014 at 6:39:14 PM Ken Murchison wrote: > On 10/04/2014 12:28 PM, Cyrus Daboo wrote: > > Hi Ken, > > Thanks for your review. I will apply fixes to the WG -00 draft which I > > am working on now. > > > > --On October 3, 2014 at 9:32:04 AM -0400 Ken Murchison > > wrote: > > > > > >> Section 3, last sent: Since iCalendar uses ISO weeks, should we say "The > >> number of whole [ISO.8601.2004] weeks in a year is either 52 or 53" ? > > > > Well the ISO things refers to how weeks are numbered not actual weeks > > in a year - there are always 52 whole weeks in a year (if you start > > counting from 1st January). I would be willingly to clarify the text > > with this change: > > > > The number of whole weeks in a year is 52 (though the [ISO.8601.2004] > > week numbering scheme used by iCalendar [RFC5545] can have a numeric > > count up to 53). > > Right, I may have over-analyzed this one. This existing text is > probably fine, but let's see if anyone else comments. > > > > >> Section 11.1, UNICODE.CLDR: Should we use the following URI rather than > >> picking a particular release? > >> http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml > > > > I have updated that to the latest release. However, I am not sure > > about doing what you suggest given that this is a normative reference. > > I would have thought a "stable" reference is preferred rather than a > > "moving target". It would be good to get some feedback from the > > chairs/ADs/RFC-Editor (or anyone else) on that. > > That's a good question. Let's see what the IETF/IAB folks say. > I don't have a strong opinion on this, but leaning towards a 'moving target' link. We use this reference to point out that the registry is maintained externally, and we make no specific assumptions about its contents in our document. So I don't think there's a strong case for pointing to a specific version in this particular case. Grisha > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c3e27eb891d50504e93a4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat Oct 04 2014 at 6:39:14 PM Ken Mur= chison <murch@andrew.cmu.edu= > wrote:
On 10/04/2014 12:28 PM, Cyrus= Daboo wrote:
> Hi Ken,
> Thanks for your review. I will apply fixes to the WG -00 draft which I=
> am working on now.
>
> --On October 3, 2014 at 9:32:04 AM -0400 Ken Murchison
> <murch@an= drew.cmu.edu> wrote:
>
>
>> Section 3, last sent: Since iCalendar uses ISO weeks, should we sa= y "The
>> number of whole [ISO.8601.2004] weeks in a year is either 52 or 53= " ?
>
> Well the ISO things refers to how weeks are numbered not actual weeks<= br> > in a year - there are always 52 whole weeks in a year (if you start > counting from 1st January). I would be willingly to clarify the text > with this change:
>
>=C2=A0 =C2=A0 The number of whole weeks in a year is 52 (though the [IS= O.8601.2004]
>=C2=A0 =C2=A0 week numbering scheme used by iCalendar [RFC5545] can hav= e a numeric
>=C2=A0 =C2=A0 count up to 53).

Right, I may have over-analyzed this one.=C2=A0 This existing text is
probably fine, but let's see if anyone else comments.



>> Section 11.1, UNICODE.CLDR: Should we use the following URI rather= than
>> picking a particular release?
>> http://www.unicode.org/repos/cld= r/tags/latest/common/bcp47/calendar.xml
>
> I have updated that to the latest release. However, I am not sure
> about doing what you suggest given that this is a normative reference.=
> I would have thought a "stable" reference is preferred rathe= r than a
> "moving target". It would be good to get some feedback from = the
> chairs/ADs/RFC-Editor (or anyone else) on that.

That's a good question.=C2=A0 Let's see what the IETF/IAB folks say= .
=C2=A0
I don't have a strong opinion o= n this, but leaning towards a 'moving target' link. We use this ref= erence to point out that the registry is maintained externally, and we make= no specific assumptions about its contents in our document. So I don't= think there's a strong case for pointing to a specific version in this= particular case.

=C2=A0Grisha


--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a11c3e27eb891d50504e93a4b-- From nobody Wed Oct 8 07:44:24 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A8D1A1B3A for ; Wed, 8 Oct 2014 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXXqzL9dGOIk for ; Wed, 8 Oct 2014 07:44:16 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA121A1B5C for ; Wed, 8 Oct 2014 07:44:15 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so11745360wgh.29 for ; Wed, 08 Oct 2014 07:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=80iTfgKRX1cAnPkDf59gCxQ9eEWsT9xaLeUYsVDzc28=; b=DZVJO+Lab4uHkzXI8V6r9eQ9Gsann5BZ8/qs9C9DNgqv6TKGvHtf4mT34++GZPad6L 9RyE9pSyeLmTZjzD6eWvYdZxkhu0o4AYHS/IbC6kCfrDf7M3O4vdPi5tXrY5f7+6QRl9 wZxN/BNUW+irUSD9bMs2mdeIxahxlRn8VILYaObN4bzllYqSRTZqKOiWnWBR2bxmYYnk 8aLXQB+k/wnIVmL9AbLxf1S4IZOnYfP+f71+BKgBzRLsenBt4lZa+9DSkq2+KpwepAZL eWtSF2LguoALtvUGVpB8870czpzKYs4MSKI0gJ3oAsM1YFXCOVUiNn/oWpV0IvK0oQUm yPmA== X-Received: by 10.180.101.100 with SMTP id ff4mr11508048wib.43.1412779454412; Wed, 08 Oct 2014 07:44:14 -0700 (PDT) Received: from smtp.dmfs.org (pD9EA6D49.dip0.t-ipconnect.de. [217.234.109.73]) by mx.google.com with ESMTPSA id cu9sm352111wjc.3.2014.10.08.07.44.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 08 Oct 2014 07:44:11 -0700 (PDT) Sender: Marten Gajda Received: from localhost.localdomain (linux-4.fritz.box [192.168.2.53]) by smtp.dmfs.org (Postfix) with ESMTPSA id 84AB87ED for ; Wed, 8 Oct 2014 16:44:09 +0200 (CEST) Message-ID: <54354DB9.6050800@dmfs.org> Date: Wed, 08 Oct 2014 16:44:09 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/es01QcF1_PVtGCwQurw0SnsAPwQ Subject: [calsify] RSCALE + Julian Calendars X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:44:21 -0000 Hi all, I just noticed that http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml doesn't seem to define a type for "Julian". Should we trigger the registration process for the Julian calendar scale? According to http://en.wikipedia.org/wiki/Julian_calendar#Eastern_Orthodox_usage there are still a number of churches using Julian calendars. cheers Marten -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 From nobody Wed Oct 8 11:14:34 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4061A7021 for ; Wed, 8 Oct 2014 11:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5PC17FKgwPI for ; Wed, 8 Oct 2014 11:14:30 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623221A01A8 for ; Wed, 8 Oct 2014 11:14:30 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id id10so7113130vcb.6 for ; Wed, 08 Oct 2014 11:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=fPvo9L9v7gEEVWfGzRO+5gktTZZzk6UhJPtlpv4Jn+Y=; b=Y7iQ/w/wmYANAhVP6ScruLZ1Rp+p2g37Kx8BpyBgQg7GEA4S+9E4nKvVJfDGFoH4mM pytldJ8HWQ9x1eIkak9tjFqD8QWw7unpLRYx0pnrK8oA7ygpeF5OIV4N/4xfJswri22F 2pH9LWYecOlU0JOrMZyVECSoJtU2KysyNqiei5yqaQYLJC3f8j+5oUjHEZqTzz9FapOi nAEGbvgnfDWwRT84soRlwolKhpi9PF598gyW2X7VhP2THL9ePkAECCe0h4kXMdPCYpHi bP7l6XXXpBYIVkp9VvFiQmcz9YySPuQO0FLXCLlN5bE00dkszfyB0P3A73zEnV59svcE DBjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=fPvo9L9v7gEEVWfGzRO+5gktTZZzk6UhJPtlpv4Jn+Y=; b=ZpxsDg5TzyncFqGxL5zbIgPpy7z0DQnKwz6EEtjzZ70QihBfQrHagS/pyVUTdo19Vc IzfIMQtSfi5z70pYn0MEeRR2XiclQHfvSQ76lviepPXmRzVu6Dzn5sTsKS+ZFjNYk9qH 00INJwLUUylZNTsmRUsXoYxIFE3YpJn8gq+IEAgy+yciSGtJIcv+uJPiv6A7imf4DckT t33XrVHD3yxfDSmxgcBYcpe+R53MBHUgezVtVe07l9RTf9rCGGyTA7A8UsqkGoMgrn55 8+6L/EvEOCWlaRTPbMGrOPI4gXStomFsachvPApeKCnTyP1neGCg4KHl4ERAK+y5sWtL 2U9g== X-Gm-Message-State: ALoCoQnHYcm7flCQO8L+UfWPqmv4c28q9Wc2PHrisi2GNHnYpaSDqyxff0A4b5U5WTqzHNQJXoUj X-Received: by 10.52.253.39 with SMTP id zx7mr10548764vdc.2.1412792069394; Wed, 08 Oct 2014 11:14:29 -0700 (PDT) MIME-Version: 1.0 References: <54354DB9.6050800@dmfs.org> From: Gregory Yakushev Date: Wed, 08 Oct 2014 18:14:29 +0000 Message-ID: To: Marten Gajda , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a1135f63c7044ae0504ed490c Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/t2tPKUl6JxYdNv1hJPtp94J_D4Y Subject: Re: [calsify] RSCALE + Julian Calendars X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 18:14:32 -0000 --001a1135f63c7044ae0504ed490c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Its better to redirect this question to cldr-users@unicode.org, so Julian gets added to CLDR and gets proper implementation in Unicode libraries (ICU). CalExt WG charter specifically prevents us from developing calendaring systems or calculations: https://datatracker.ietf.org/wg/calext/charter/ Grisha On Wed Oct 08 2014 at 4:44:25 PM Marten Gajda wrote: > Hi all, > > I just noticed that > http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml > doesn't seem to define a type for "Julian". > Should we trigger the registration process for the Julian calendar scale? > According to > http://en.wikipedia.org/wiki/Julian_calendar#Eastern_Orthodox_usage > there are still a number of churches using Julian calendars. > > cheers > > Marten > > -- > Marten Gajda > Schandauer Stra=C3=9Fe 34 > 01309 Dresden > Germany > > tel: +49 177 4427167 > email: marten@dmfs.org > twitter: twitter.com/dmfs_org > > VAT Reg. No.: DE269072391 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a1135f63c7044ae0504ed490c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Its better to redirect this question to cldr-users@unicode.org, so Julian gets added to CLDR and gets pr= oper implementation in Unicode libraries (ICU). CalExt WG charter specifica= lly prevents us from developing calendaring systems or calculations:=C2=A0<= a href=3D"https://datatracker.ietf.org/wg/calext/charter/">https://datatrac= ker.ietf.org/wg/calext/charter/

Grisha

=
On Wed Oct 08 2014 at 4:44:25 PM Marten Gajda &l= t;marten@dmfs.org> wrote:
Hi all,

I just noticed that
http://www.unicode.org/repos/cldr/tags/la= test/common/bcp47/calendar.xml
doesn't seem to define a type for "Julian".
Should we trigger the registration process for the Julian calendar scale? According to
http://en.wikipedia.org/wiki/Julian_calendar#= Eastern_Orthodox_usage
there are still a number of churches using Julian calendars.

cheers

Marten

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

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

VAT Reg. No.: DE269072391

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a1135f63c7044ae0504ed490c-- From nobody Mon Oct 13 08:07:59 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84DC1A031C for ; Mon, 13 Oct 2014 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6_vbyVZzvEa for ; Mon, 13 Oct 2014 08:07:55 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C05A1A0346 for ; Mon, 13 Oct 2014 08:07:44 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id a3so13386657oib.11 for ; Mon, 13 Oct 2014 08:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p7gvYvvPwxN8bIG/bUbzq8dzHhsMRTzhPUZTd5JBiJc=; b=Wc5HRN2kzr7NnAK8B34kXowzWEkg0Sr0JaS2CF/Du6Dd61ApA6iqN6ciLgoQlMF1HL bbcM9ylxR3fv5ErOQEGkZ9ayOMbx2bbpGRXFVi3WH0ytPY4aB59Eg89jhnixTK4UFQbz uuIawYyd29eHZJVSTrrO/bp9x2RL2UOpoN/swO60UOwSa0HIoyHJSCwKoDnqDVCarGih eFghYJu+W3cKpTpp55QVgLwhKQcBXU/EnLvdI4XvnKVTvA05KmPJyNp7XFkSjRkcbmW5 Ic5DL+4nEVM5PwwFDWctfP6FkByk48PN0AQHeFvSg7E1ZRXw6+HqtfPGbZ727dH1+Nxr Oq1g== X-Received: by 10.202.81.67 with SMTP id f64mr2155637oib.73.1413212863797; Mon, 13 Oct 2014 08:07:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Mon, 13 Oct 2014 08:07:23 -0700 (PDT) In-Reply-To: References: <5430229D.7050300@andrew.cmu.edu> From: Donald Eastlake Date: Mon, 13 Oct 2014 11:07:23 -0400 Message-ID: To: Gregory Yakushev Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/7lu9atyvwIc8Rcyc3lO5pDk8-KY Cc: calsify@ietf.org Subject: Re: [calsify] draft-daboo-icalendar-rscale-04 editorial nits X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:07:56 -0000 Hi Guys, On Wed, Oct 8, 2014 at 9:24 AM, Gregory Yakushev wrote: > > > On Sat Oct 04 2014 at 6:39:14 PM Ken Murchison wrote: >> >> On 10/04/2014 12:28 PM, Cyrus Daboo wrote: >> > Hi Ken, >> > Thanks for your review. I will apply fixes to the WG -00 draft which I >> > am working on now. >> > >> > --On October 3, 2014 at 9:32:04 AM -0400 Ken Murchison >> > wrote: >> > >> >... >> >> >> Section 11.1, UNICODE.CLDR: Should we use the following URI rather than >> >> picking a particular release? >> >> http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml >> > >> > I have updated that to the latest release. However, I am not sure >> > about doing what you suggest given that this is a normative reference. >> > I would have thought a "stable" reference is preferred rather than a >> > "moving target". It would be good to get some feedback from the >> > chairs/ADs/RFC-Editor (or anyone else) on that. >> >> That's a good question. Let's see what the IETF/IAB folks say. > > I don't have a strong opinion on this, but leaning towards a 'moving target' > link. We use this reference to point out that the registry is maintained > externally, and we make no specific assumptions about its contents in our > document. So I don't think there's a strong case for pointing to a specific > version in this particular case. That sounds like a moving target link would be OK. I could be misunderstanding something but I wouldn't describe this as just pointing out that a registry is externally maintained. If that were the case, it should be an Informative Reference. Rather it looks to me like a Normative reference to a registry. It is in the nature of registries that they change, mostly as new entries are added but occasionally as old entries are deprecated or an entry is changed to correct errors or whatever. Unless there was a good reason to use a frozen specific version of a registry, I would say that the normal thing it to just refer to the registry as a dynamic data set. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Grisha > >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > From nobody Wed Oct 15 08:49:56 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54911A887D for ; Wed, 15 Oct 2014 08:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS5gaOCyxCJ3 for ; Wed, 15 Oct 2014 08:49:50 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE3D1A8876 for ; Wed, 15 Oct 2014 08:49:49 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so1677689wgg.3 for ; Wed, 15 Oct 2014 08:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zv8kyPLdRdlQnfmO3w3H/8o5x3LfCcwURcekT8+zCrA=; b=ioa/RyNCknRPkpTjgnGchIRBMJpkGOM0GA2YbBW1DYcSKQHw1pl6WLDAKjs7AnXIRg 6Q8ggxBN/JlvKaR66EnEtklmKsNzpf1zV7btJDdsdZ5YRku5YJBqYUlHsXbgFkrxV5n9 R/eiwE6FMJQwvh31nFFmIb4SamshH53Jh6fxfQXm/tbWxI2h9u20DplfzZWgjCmX5rAs I+SgQ9vKFiyFLduWHO9YUJSz+ydlxjZh8n+CGeIjqvB3Tw4mdB7zmcDaZuJi0hq+5+iV V8Pz8Gmfg7mIkdeK6Qs+wVDa8Y5AqhMwcL11tqALJvaeNk8V+s/70GenHPY1dTnNW/0+ kNOw== X-Received: by 10.194.223.101 with SMTP id qt5mr13632453wjc.58.1413388188388; Wed, 15 Oct 2014 08:49:48 -0700 (PDT) Received: from smtp.dmfs.org (pD9EA6F79.dip0.t-ipconnect.de. [217.234.111.121]) by mx.google.com with ESMTPSA id t9sm24299349wjf.41.2014.10.15.08.49.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Oct 2014 08:49:47 -0700 (PDT) Sender: Marten Gajda Received: from localhost.localdomain (unknown [192.168.2.53]) by smtp.dmfs.org (Postfix) with ESMTPSA id EB951370 for ; Wed, 15 Oct 2014 17:49:45 +0200 (CEST) Message-ID: <543E9799.20301@dmfs.org> Date: Wed, 15 Oct 2014 17:49:45 +0200 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: calsify@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/TpNH7_xIHCQ0TwMGQvPa96R9cGY Subject: [calsify] RSCALE + splitting recurrence sets X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:49:54 -0000 Hi all, I've come across a problem with RSCALE that doesn't appear to be trivial to me. You know that it's common procedure to split an event in two when you change "this and all following instances" of a recurring event. However, there seem to be some implications when doing that when RSCALE is present. Here is an example: DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD this event recurs every leap year on the 29th of February and on the 1st of March in non-leap years. (I must admit that I'm not sure how many clients actually include BYMONTH=2 and BYMONTHDAY=29 in the rule) Now consider the users chooses to change the title of the event for the instance on 2014-03-01 and all following instances. Most (if not all) calendar clients would create a new event with the original start date and a truncated recurrence rule like this DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=2 or this DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;UNTIL=20130301 that represents all past instances that didn't change. Then they would update the existing event to start at the first updated instance using the same rule: DTSTART;VALUE=DATE:20140301 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD Which is incorrect! DTSTART;VALUE=DATE:20140229 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD would be incorrect too! The only solution seems to be to specify BYMONTH and BYMONTHDAY like so DTSTART;VALUE=DATE:20140301 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;BYMONTH=2;BYMONTHDAY=29 You can create similar cases with calendar scales that have leap months. However, this kind of conflicts with RFC 5545 (http://tools.ietf.org/html/rfc5545#section-3.8.5.3) which says: > The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if > specified. The recurrence set generated with a "DTSTART" property > value not synchronized with the recurrence rule is undefined. I think the RSCALE specs should mention this case and advise how to deal with it. Maybe in a "best practices for creating RRULEs (when using RSCALE)" section. cheers Marten -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 From nobody Wed Oct 15 09:12:13 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42521A88A8 for ; Wed, 15 Oct 2014 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-h3UuR4rSRm for ; Wed, 15 Oct 2014 09:11:50 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D568D1A8900 for ; Wed, 15 Oct 2014 09:10:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C0F6DC378F2; Wed, 15 Oct 2014 12:09:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZHgtm-Jo_sf; Wed, 15 Oct 2014 12:09:23 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id E6A3CC378E6; Wed, 15 Oct 2014 12:09:22 -0400 (EDT) Date: Wed, 15 Oct 2014 12:09:55 -0400 From: Cyrus Daboo To: Marten Gajda , calsify@ietf.org Message-ID: <0D3D86AFF51FD5ADEDA3D480@caldav.corp.apple.com> In-Reply-To: <543E9799.20301@dmfs.org> References: <543E9799.20301@dmfs.org> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=3546 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/sp1Aj9tXS9LEVKYt9xFk0iJdyAo Subject: Re: [calsify] RSCALE + splitting recurrence sets X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:11:56 -0000 Hi Marten, --On October 15, 2014 at 5:49:45 PM +0200 Marten Gajda wrote: > I've come across a problem with RSCALE that doesn't appear to be trivial > to me. You know that it's common procedure to split an event in two when > you change "this and all following instances" of a recurring event. > However, there seem to be some implications when doing that when RSCALE > is present. > Here is an example: > > DTSTART;VALUE=DATE:20120229 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > > this event recurs every leap year on the 29th of February and on the 1st > of March in non-leap years. (I must admit that I'm not sure how many > clients actually include BYMONTH=2 and BYMONTHDAY=29 in the rule) > > Now consider the users chooses to change the title of the event for the > instance on 2014-03-01 and all following instances. Most (if not all) > calendar clients would create a new event with the original start date > and a truncated recurrence rule like this > > DTSTART;VALUE=DATE:20120229 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=2 > > or this > > DTSTART;VALUE=DATE:20120229 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;UNTIL=20130301 > > that represents all past instances that didn't change. Then they would > update the existing event to start at the first updated instance using > the same rule: > > DTSTART;VALUE=DATE:20140301 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > > Which is incorrect! > > DTSTART;VALUE=DATE:20140229 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > > would be incorrect too! > > The only solution seems to be to specify BYMONTH and BYMONTHDAY like so > > DTSTART;VALUE=DATE:20140301 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;BYMONTH=2;BYMONTHDAY=29 No - a workable alternative for the ongoing event is: DTSTART;VALUE=DATE:20120229 RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD EXDATE;VALUE=DATE:20120229 EXDATE;VALUE=DATE:20130301 i.e., the client has to use a valid yyyy0229 date as the starting point to get the correct skip behviour, but it removes the first 1 - 3 instances that are not needed. > You can create similar cases with calendar scales that have leap months. I haven't thought to hard about that, but I would guess the EXDATE approach would work there too. The only downside is that the number of EXDATEs needed might grow large. (And yes if we still had EXRULE we could have made use of that, but we dumped it when we revised iCalendar in 5545.) > However, this kind of conflicts with RFC 5545 > (http://tools.ietf.org/html/rfc5545#section-3.8.5.3) which says: >> The "DTSTART" property value SHOULD be synchronized with the >> recurrence rule, if specified. The recurrence set generated with >> a "DTSTART" property value not synchronized with the recurrence >> rule is undefined. > I think the RSCALE specs should mention this case and advise how to deal > with it. Maybe in a "best practices for creating RRULEs (when using > RSCALE)" section. Technically this problem exists for the leap day in regular 5545 RRULEs - so it is not specific to RSCALE, but as you note leap months do exacerbate it. However, I am not sure what the scope of such a best practices section would be as there are probably quite a few other issues with RRULEs that people would want described. Perhaps it would be better to leave that for a separate IETF BCP (best common practices) document for iCalendar that could cover not only RRULEs but other problematic areas like time zones. -- Cyrus Daboo From nobody Wed Oct 15 13:20:43 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAA11ACAD8 for ; Wed, 15 Oct 2014 13:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bseKZs8prgq for ; Wed, 15 Oct 2014 13:20:35 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DA61ACC83 for ; Wed, 15 Oct 2014 13:20:20 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hq12so1659787vcb.9 for ; Wed, 15 Oct 2014 13:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=cd0A45dnt+VkKlpt0lT452yt6gxg6nlQOvqVSL9HmRY=; b=RuYtHAcZ7t9GaZIbcgule0SW69kAWeL3KffRbnLwifsVlV+z2mE+KSfCFeYr8n5bMH fiXbXEPWVYl6R3c604niQ5mGgqUJYCi6uPDND6sRBUvkrz51umRrJ2GTFoEZy16g2Cme Wi5ymQIYSPCD1cVHJd18P/WVlx1dSYFQA1T9h2dShFXDJi+w42bEbRpXSM+lPSmgEzka Aia3YCVeDROFHmIm5lQO53gFwds+EX8SsHzCjcA9aOpbYxzC+gsbuztRnyXgpZFcUsWq 702zFtIbu7JrbmIauy+WrO5jSQ4KPgQDokYitlPUwCoaHuyW7+60+33E9bIbIjD+danP Pdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=cd0A45dnt+VkKlpt0lT452yt6gxg6nlQOvqVSL9HmRY=; b=dGYDCE2RFxeGnTrGbhyCHBs7hy1Di8jMSOAQZ1oYNDgE0U247j1QcJ8G6BOkUUcEzU u6YLt6whh4ifeiBcOY3e5t6kg1Y2SwnZ/XX5BjvUmRaU2EN6bq2ZQXHEeqHergLXyXmH TEgxdrHamq6oi+aFZYnYgxCE0GJPJhCjn+RiHN9musAScBuMFvmRvoOpBOVHoBjp76Q0 +Hi5oiIdg0xbh0B2hZcybrGrKsZIbGbb9ww/wXvndBoTecGU6e47PSr/PkhUzEcy2eks B3HbV2LfiVQOZJQ/NRpfwEsF5av6CieLMJfkBj6n31DgktTK5crtohntevuEIbVLO9Nc XArg== X-Gm-Message-State: ALoCoQnE56p22waVAXm+KntGj1iYw8s5KFVaVuJexcaG4Xna+1jGyg4+cJSAB4knXmtPmCPnvb7c X-Received: by 10.220.225.1 with SMTP id iq1mr3753207vcb.71.1413404419319; Wed, 15 Oct 2014 13:20:19 -0700 (PDT) MIME-Version: 1.0 References: <543E9799.20301@dmfs.org> <0D3D86AFF51FD5ADEDA3D480@caldav.corp.apple.com> From: Gregory Yakushev Date: Wed, 15 Oct 2014 20:20:18 +0000 Message-ID: To: Cyrus Daboo , Marten Gajda , calsify@ietf.org Content-Type: multipart/alternative; boundary=089e0115ef54568d5605057bdcf6 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/BgH0E7W7u5c3dRpX4ZtGm4PvjMs Subject: Re: [calsify] RSCALE + splitting recurrence sets X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:20:38 -0000 --089e0115ef54568d5605057bdcf6 Content-Type: text/plain; charset=UTF-8 Yes, recurrence split is a problem, but as Cyrus says its not specific to RSCALE. It is a more generic problem: when we do the split by creating a new recurring event, we also lose event identity. Tail UID will be different, so anything pointing to instances of the head event will no longer work, EXCEPTION-IDs and in-flight invites/responses are lost, it is no longer possible to do changes to the whole series (head+tail) etc. There's a facility in RFC5545 to handle the split gracefully: RANGE=THISANDFUTURE. Internally we already use it for most recurrence splits in Google Calendar, although we translate it into separate recurrences for CalDAV so not to confuse existing clients. I think wider adoption of RANGE=THISANDFUTURE by the industry will be good, although we'd need to nail down some issues (like a split that changes DTSTART or RRULE). This work may fall under CalExt working group charter, but definitely lies outside the scope of the RSCALE draft. Best Regards Grisha On Wed Oct 15 2014 at 6:12:12 PM Cyrus Daboo wrote: > Hi Marten, > > --On October 15, 2014 at 5:49:45 PM +0200 Marten Gajda > wrote: > > > I've come across a problem with RSCALE that doesn't appear to be trivial > > to me. You know that it's common procedure to split an event in two when > > you change "this and all following instances" of a recurring event. > > However, there seem to be some implications when doing that when RSCALE > > is present. > > Here is an example: > > > > DTSTART;VALUE=DATE:20120229 > > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > > > > this event recurs every leap year on the 29th of February and on the 1st > > of March in non-leap years. (I must admit that I'm not sure how many > > clients actually include BYMONTH=2 and BYMONTHDAY=29 in the rule) > > > > Now consider the users chooses to change the title of the event for the > > instance on 2014-03-01 and all following instances. Most (if not all) > > calendar clients would create a new event with the original start date > > and a truncated recurrence rule like this > > > > DTSTART;VALUE=DATE:20120229 > > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;COUNT=2 > > > > or this > > > > DTSTART;VALUE=DATE:20120229 > > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;UNTIL=20130301 > > > > that represents all past instances that didn't change. Then they would > > update the existing event to start at the first updated instance using > > the same rule: > > > > DTSTART;VALUE=DATE:20140301 > > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > > > > Which is incorrect! > > > > DTSTART;VALUE=DATE:20140229 > > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > > > > would be incorrect too! > > > > The only solution seems to be to specify BYMONTH and BYMONTHDAY like so > > > > DTSTART;VALUE=DATE:20140301 > > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD;BYMONTH=2;BYMONTHDAY=29 > > No - a workable alternative for the ongoing event is: > > DTSTART;VALUE=DATE:20120229 > RRULE:FREQ=YEARLY;RSCALE=GREGORIAN;SKIP=FORWARD > EXDATE;VALUE=DATE:20120229 > EXDATE;VALUE=DATE:20130301 > > i.e., the client has to use a valid yyyy0229 date as the starting point to > get the correct skip behviour, but it removes the first 1 - 3 instances > that are not needed. > > > > You can create similar cases with calendar scales that have leap months. > > I haven't thought to hard about that, but I would guess the EXDATE approach > would work there too. The only downside is that the number of EXDATEs > needed might grow large. (And yes if we still had EXRULE we could have made > use of that, but we dumped it when we revised iCalendar in 5545.) > > > However, this kind of conflicts with RFC 5545 > > (http://tools.ietf.org/html/rfc5545#section-3.8.5.3) which says: > >> The "DTSTART" property value SHOULD be synchronized with the > >> recurrence rule, if specified. The recurrence set generated with > >> a "DTSTART" property value not synchronized with the recurrence > >> rule is undefined. > > I think the RSCALE specs should mention this case and advise how to deal > > with it. Maybe in a "best practices for creating RRULEs (when using > > RSCALE)" section. > > Technically this problem exists for the leap day in regular 5545 RRULEs - > so it is not specific to RSCALE, but as you note leap months do exacerbate > it. However, I am not sure what the scope of such a best practices section > would be as there are probably quite a few other issues with RRULEs that > people would want described. Perhaps it would be better to leave that for a > separate IETF BCP (best common practices) document for iCalendar that could > cover not only RRULEs but other problematic areas like time zones. > > -- > Cyrus Daboo > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --089e0115ef54568d5605057bdcf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, recurrence split is a problem, but as Cyrus says its not specific to R= SCALE. It is a more generic problem: when we do the split by creating a new= recurring event, we also lose event identity. Tail UID will be different, = so anything pointing to instances of the head event will no longer work, EX= CEPTION-IDs and in-flight invites/responses are lost, it is no longer possi= ble to do changes to the whole series (head+tail) etc.

There's a facility in RFC5545 to handle the split gracefully:=C2=A0<= span style=3D"color:rgb(0,0,0);font-size:1em;line-height:normal">RANGE=3DTH= ISANDFUTURE. Internally we already use it for most recurrence splits in Goo= gle Calendar, although we translate it into separate recurrences for CalDAV= so not to confuse existing clients. I think wider adoption of RANGE=3DTHIS= ANDFUTURE by the industry will be good, although we'd need to nail down= some issues (like a split that changes DTSTART or RRULE).

This work may fall under CalExt working group charter, but definitely = lies outside the scope of the RSCALE draft.

<= span style=3D"color:rgb(0,0,0);font-size:1em;line-height:normal">Best Regar= ds
Grisha

On Wed Oct 15 = 2014 at 6:12:12 PM Cyrus Daboo <cyru= s@daboo.name> wrote:
Hi Marten,
--On October 15, 2014 at 5:49:45 PM +0200 Marten Gajda <marten@dmfs.org>
wrote:

> I've come across a problem with RSCALE that doesn't appear to = be trivial
> to me. You know that it's common procedure to split an event in tw= o when
> you change "this and all following instances" of a recurring= event.
> However, there seem to be some implications when doing that when RSCAL= E
> is present.
> Here is an example:
>
> DTSTART;VALUE=3DDATE:20120229
> RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD
>
> this event recurs every leap year on the 29th of February and on the 1= st
> of March in non-leap years. (I must admit that I'm not sure how ma= ny
> clients actually include BYMONTH=3D2 and BYMONTHDAY=3D29 in the rule)<= br> >
> Now consider the users chooses to change the title of the event for th= e
> instance on 2014-03-01 and all following instances. Most (if not all)<= br> > calendar clients would create a new event with the original start date=
> and a truncated recurrence rule like this
>
> DTSTART;VALUE=3DDATE:20120229
> RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD;COUNT=3D2=
>
> or this
>
> DTSTART;VALUE=3DDATE:20120229
> RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD;UNTIL=3D<= u>20130301
>
> that represents all past instances that didn't change. Then they w= ould
> update the existing event to start at the first updated instance using=
> the same rule:
>
> DTSTART;VALUE=3DDATE:20140301
> RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD
>
> Which is incorrect!
>
> DTSTART;VALUE=3DDATE:20140229
> RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD
>
> would be incorrect too!
>
> The only solution seems to be to specify BYMONTH and BYMONTHDAY like s= o
>
> DTSTART;VALUE=3DDATE:20140301
> RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD;BY= MONTH=3D2;BYMONTHDAY=3D29

No - a workable alternative for the ongoing event is:

DTSTART;VALUE=3DDATE:20120229
RRULE:FREQ=3DYEARLY;RSCALE=3DGREGORIAN;SKIP=3DFORWARD
EXDATE;VALUE=3DDATE:20120229
EXDATE;VALUE=3DDATE:20130301

i.e., the client has to use a valid yyyy0229 date as the starting point to<= br> get the correct skip behviour, but it removes the first 1 - 3 instances
that are not needed.


> You can create similar cases with calendar scales that have leap month= s.

I haven't thought to hard about that, but I would guess the EXDATE appr= oach
would work there too. The only downside is that the number of EXDATEs
needed might grow large. (And yes if we still had EXRULE we could have made=
use of that, but we dumped it when we revised iCalendar in 5545.)

> However, this kind of conflicts with RFC 5545
> (http://tools.ietf.org/html/rfc5545#section-3.8.5.3) = which says:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The "DTSTART" property value = SHOULD be synchronized with the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 recurrence rule, if specified.=C2=A0 Th= e recurrence set generated with
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 a "DTSTART" property value no= t synchronized with the recurrence
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 rule is undefined.
> I think the RSCALE specs should mention this case and advise how to de= al
> with it. Maybe in a "best practices for creating RRULEs (when usi= ng
> RSCALE)" section.

Technically this problem exists for the leap day in regular 5545 RRULEs - so it is not specific to RSCALE, but as you note leap months do exacerbate<= br> it. However, I am not sure what the scope of such a best practices section<= br> would be as there are probably quite a few other issues with RRULEs that people would want described. Perhaps it would be better to leave that for a=
separate IETF BCP (best common practices) document for iCalendar that could=
cover not only RRULEs but other problematic areas like time zones.

--
Cyrus Daboo

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--089e0115ef54568d5605057bdcf6-- From nobody Mon Oct 27 08:26:06 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC21ACE2D for ; Mon, 27 Oct 2014 08:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtQiuQ_sEQGi for ; Mon, 27 Oct 2014 08:26:03 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636DB1A8897 for ; Mon, 27 Oct 2014 08:26:03 -0700 (PDT) Received: from kens-air.wv.cc.cmu.edu (Kens-Air.wv.cc.cmu.edu [128.237.205.188]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id s9RFQ13A017759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 27 Oct 2014 11:26:02 -0400 Message-ID: <544E640B.60400@andrew.cmu.edu> Date: Mon, 27 Oct 2014 11:26:03 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF Calsify Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.27.151518 X-SMTP-Spam-Clean: 8% ( HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.203 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/QPk2NJgPKXff8WAwcZlFX_WsaHQ Subject: [calsify] Review of draft-ietf-caldav-timezone-ref X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:26:05 -0000 General observation: Having read this document cover to cover a few times, I find it sufficient to implement the documented CalDAV feature on the server-side (which I have done). A few editorial nits: - Sec 1, para 3, sent 1: "resulting missed meetings" -> "resulting in missed meetings" - Sec 3.1.1, sent 1 & 2: "time zone services" -> "time zone data distribution services" - Sec 4, para 1 and items 1 & 2: "time zone services" -> "time zone data distribution services" -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Oct 29 07:49:16 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA341A0161 for ; Wed, 29 Oct 2014 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGjbwz9CooJQ for ; Wed, 29 Oct 2014 07:49:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13C1A0147 for ; Wed, 29 Oct 2014 07:49:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7728E181C96; Wed, 29 Oct 2014 07:48:25 -0700 (PDT) To: bernard.desruisseaux@oracle.com, barryleiba@computer.org, presnick@qti.qualcomm.com, lear@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141029144825.7728E181C96@rfc-editor.org> Date: Wed, 29 Oct 2014 07:48:25 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/JvloQNN3n2EWiAFStyEVaiWaWtA Cc: rfc-editor@rfc-editor.org, kawai@stratosphere.co.jp, calsify@ietf.org Subject: [calsify] [Technical Errata Reported] RFC5545 (4149) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:49:13 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4149 -------------------------------------- Type: Technical Reported by: Hiroaki KAWAI Section: 4 Original Text ------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY ORGANIZER:mailto:jsmith@example.com DTSTART:19980313T141711Z DTEND:19980410T141711Z Corrected Text -------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY UID:19970901T115957Z-76A912@example.com DTSTAMP:19970901T120000Z ORGANIZER:mailto:jsmith@example.com DTSTART:19980313T141711Z DTEND:19980410T141711Z Notes ----- 3.6.4 says fbprop = *( ; ; The following are REQUIRED, ; but MUST NOT occur more than once. ; dtstamp / uid / Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Oct 29 08:24:42 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608C01A01E1 for ; Wed, 29 Oct 2014 08:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELc4tKCVHCrQ for ; Wed, 29 Oct 2014 08:24:33 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE5D1A023E for ; Wed, 29 Oct 2014 08:24:28 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-09v.sys.comcast.net with comcast id 93NU1p0022Qkjl9013QTGd; Wed, 29 Oct 2014 15:24:27 +0000 Received: from THARE ([156.75.186.165]) by resomta-ch2-15v.sys.comcast.net with comcast id 93Q11p00l3aYT8C013Q6c3; Wed, 29 Oct 2014 15:24:25 +0000 From: "Tim Hare" To: "'RFC Errata System'" , , , , References: <20141029144825.7728E181C96@rfc-editor.org> In-Reply-To: <20141029144825.7728E181C96@rfc-editor.org> Date: Wed, 29 Oct 2014 11:23:56 -0400 Message-ID: <039c01cff38c$6a91e130$3fb5a390$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/zh4Qi4izASMDoQSS7c6AZVDtk3AABJvKQ Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414596267; bh=45mKa8h/+i7tmuAgscvoMjkXJUIUNTdAyLXwQRVVzbo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=m454VvsDLeJzhMS5i0kqW1/yG5qj3ch+NCD3LZGblrK08lbltgA7NJQDBJI1Ic/pM w+4PVITOfDCc7dhLRuffderRISn3tzfMWRsB9ub0gvKEB0R5qFSY9iMBLxlUMO4IEl g5i5zJkl5OJOlKfjbkBZiPZHjrySLrP8Aik+9rhTjr0H4S0lWhmSJ8VJy8Qs2z3nrT EDQ1o2mnSzzlxJ9jQOlXJyQlIi6nlyVd13Llkgo+nfxXTVb0r64phpf/uULmoji6zJ D5a3LJZaxkARiN+7/D9IGVnEKxUSzS8wQHAr9rnx1mSK224nt0/ocoyFHJU5rTJGfw YpOtAUkGxQOcw== Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/AwdvBvE-_pw_D9eth63GlRo7nBQ Cc: kawai@stratosphere.co.jp, calsify@ietf.org Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (4149) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:24:36 -0000 ORGANIZER was added to the Corrected Text but is not required, I would submit that it should be: Corrected Text -------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY UID:19970901T115957Z-76A912@example.com DTSTAMP:19970901T120000Z DTSTART:19980313T141711Z DTEND:19980410T141711Z Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Wednesday, October 29, 2014 10:48 AM To: bernard.desruisseaux@oracle.com; barryleiba@computer.org; presnick@qti.qualcomm.com; lear@cisco.com Cc: rfc-editor@rfc-editor.org; kawai@stratosphere.co.jp; calsify@ietf.org Subject: [calsify] [Technical Errata Reported] RFC5545 (4149) The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4149 -------------------------------------- Type: Technical Reported by: Hiroaki KAWAI Section: 4 Original Text ------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY ORGANIZER:mailto:jsmith@example.com DTSTART:19980313T141711Z DTEND:19980410T141711Z Corrected Text -------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY UID:19970901T115957Z-76A912@example.com DTSTAMP:19970901T120000Z ORGANIZER:mailto:jsmith@example.com DTSTART:19980313T141711Z DTEND:19980410T141711Z Notes ----- 3.6.4 says fbprop = *( ; ; The following are REQUIRED, ; but MUST NOT occur more than once. ; dtstamp / uid / Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Wed Oct 29 21:04:30 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC271AD005 for ; Wed, 29 Oct 2014 21:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTWrV7PzfONr for ; Wed, 29 Oct 2014 21:04:26 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC7B1AD007 for ; Wed, 29 Oct 2014 21:04:23 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wm4so3527084obc.6 for ; Wed, 29 Oct 2014 21:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CMAtts5shDqR9wHAZ5G+I4LX9IPUBzf6noud3cX2xdM=; b=ey5Q84Cemz/DLg6UEPQsSN3t1Dmx8C5KjsRCfKBgJFhEleYn3zaV209csbOrNUIRLZ uXuZjNDKgnA+9MwEmmTCZASe85P2ijwqsIinXqSFKlMGjlKJJKmGCBsgL8lBhkV437gi ZccAI2N+lvrOuySqB2MExQ07u7lPfV8Zd/SmWuXlI0otsMeZkkKOTDn1b9yRBpfbAMQn q5wnJ9NjSIaeI4rJSpZziZD2p1DJPLxIB/42YFcxHMpKYmLcEKPio3Wb7yy0W7fmCWlm wnwcqrBiVbNrelEhGmXOk/hSfeR1zLwsbOCNcEpUKwNkqrzwzMLIt1t9kXVwvWzwsuSh /MOA== X-Received: by 10.202.196.72 with SMTP id u69mr11551059oif.21.1414641862891; Wed, 29 Oct 2014 21:04:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Wed, 29 Oct 2014 21:04:02 -0700 (PDT) From: Donald Eastlake Date: Thu, 30 Oct 2014 00:04:02 -0400 Message-ID: To: calsify@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/nv3Gxv1ErVtQhbin6La5jG-z-8U Subject: [calsify] draft-ietf-calext-rscale-00.txt Document Shepherd review X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 04:04:27 -0000 Hi, I have done a document Shepherd review of draft-ietf-calext-rscale-00.txt. Here are a few comments on this draft. Since I'm not that familiar with this area, please tell me if some of these are off base. Section 1: I found "... has never been formally used" to be a little odd. Should it say "... has never been actually used"? I'm not sure what "formal use" means other than including it in the formal syntax... Section 2: First occurrence of "YYYYMMHH" should prsumably be "YYYYMMDD". Section 4.1: Would it be correct and worth while for clarity to say that "0L" indicates a leap month before the first regular month? First line of the last paragraph before the Section 7.1 heading: I think it is 'an "RSCALE" ', as used elsewhere in the draft, not 'a "RSCALE" '. Section 9: Probably better to say the slightly more general "This document requires no IANA actions." Appendix A: I think it would be good if it was a little clearer just which draft version the change sets refer to. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Oct 30 00:54:24 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3B1AD03A; Thu, 30 Oct 2014 00:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7kDzIonsHoX; Thu, 30 Oct 2014 00:54:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC51AD00B; Thu, 30 Oct 2014 00:54:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8BA3D181D17; Thu, 30 Oct 2014 00:53:32 -0700 (PDT) To: kawai@stratosphere.co.jp, bernard.desruisseaux@oracle.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141030075332.8BA3D181D17@rfc-editor.org> Date: Thu, 30 Oct 2014 00:53:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/htsPYpW7tZo7bIlESjdwrJLuAD8 Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, calsify@ietf.org Subject: [calsify] [Errata Verified] RFC5545 (4149) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 07:54:21 -0000 The following errata report has been verified for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5545&eid=4149 -------------------------------------- Status: Verified Type: Technical Reported by: Hiroaki KAWAI Date Reported: 2014-10-29 Verified by: Barry Leiba (IESG) Section: 4 Original Text ------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY ORGANIZER:mailto:jsmith@example.com DTSTART:19980313T141711Z DTEND:19980410T141711Z Corrected Text -------------- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY UID:19970901T115957Z-76A912@example.com DTSTAMP:19970901T120000Z ORGANIZER:mailto:jsmith@example.com DTSTART:19980313T141711Z DTEND:19980410T141711Z Notes ----- 3.6.4 says fbprop = *( ; ; The following are REQUIRED, ; but MUST NOT occur more than once. ; dtstamp / uid / -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG