From nobody Sun Nov 2 08:08:04 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 8DC621A8901 for ; Sun, 2 Nov 2014 08:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.594] 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 aBWRXlkWXoFP for ; Sun, 2 Nov 2014 08:07:53 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BF51A88FC for ; Sun, 2 Nov 2014 08:07:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DCADA1E2F7A; Sun, 2 Nov 2014 11:01:26 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKkPS6ns_pDz; Sun, 2 Nov 2014 11:01:26 -0500 (EST) Received: from [17.45.162.246] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 2ADF21E2F6F; Sun, 2 Nov 2014 11:01:25 -0500 (EST) Date: Sun, 02 Nov 2014 11:01:24 -0400 From: Cyrus Daboo To: Donald Eastlake , calsify@ietf.org Message-ID: <972E4A2D3AB9897A35402273@cyrus.local> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1966 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/W0lww8Vt5WgZ18FXjKttMjYBohE Subject: Re: [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: Sun, 02 Nov 2014 16:07:57 -0000 Hi Donald, Thanks for your review - comments below. Changes have been applied to my working copy and I will push out a new version of the draft with those changes later in the week, or once follow-up discussion has concluded. --On October 30, 2014 at 12:04:02 AM -0400 Donald Eastlake wrote: > 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... I think I will just drop "formally" completely. > Section 2: First occurrence of "YYYYMMHH" should prsumably be > "YYYYMMDD". Fixed. > 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? So RFC 5545 "informally" defines monthnum to the range 1..12: monthnum = 1*2DIGIT ;1 to 12 I believe we determined there is never a case where a leap month precedes the first regular month of a year, so 0L is never used, and I don't believe the ICU library has a way to specify that either. Gregory can probably confirm this is the case as he is more familiar with ICU (and maybe Ken since he has also done an implementation). If that is confirmed, then maybe we can add the following text to the "2." list item in Section 4.1: Note, there is never a case of a leap month preceding the first regular month in a year, and consequently this specification provides no way to indicate such a leap 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" '. Fixed. > Section 9: Probably better to say the slightly more general "This > document requires no IANA actions." Fixed. > Appendix A: I think it would be good if it was a little clearer just > which draft version the change sets refer to. Fixed. -- Cyrus Daboo From nobody Sun Nov 2 08:34:26 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A241A9080 for ; Sun, 2 Nov 2014 08:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 hH0inJheWMWZ for ; Sun, 2 Nov 2014 08:34:23 -0800 (PST) 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 B7A971A907F for ; Sun, 2 Nov 2014 08:34:23 -0800 (PST) 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 sA2GYDUh021974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Nov 2014 11:34:14 -0500 Message-ID: <54565D05.1070401@andrew.cmu.edu> Date: Sun, 02 Nov 2014 11:34:13 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cyrus Daboo , Donald Eastlake , calsify@ietf.org References: <972E4A2D3AB9897A35402273@cyrus.local> In-Reply-To: <972E4A2D3AB9897A35402273@cyrus.local> 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.11.2.161819 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_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __INT_PROD_LOC 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.157.39 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/TmIwktB9nY26qqn3sulfKBgmsZQ Subject: Re: [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: Sun, 02 Nov 2014 16:34:25 -0000 On 11/02/2014 10:01 AM, Cyrus Daboo wrote: > Hi Donald, > Thanks for your review - comments below. Changes have been applied to > my working copy and I will push out a new version of the draft with > those changes later in the week, or once follow-up discussion has > concluded. > > --On October 30, 2014 at 12:04:02 AM -0400 Donald Eastlake > wrote: > >> 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? > > So RFC 5545 "informally" defines monthnum to the range 1..12: > > monthnum = 1*2DIGIT ;1 to 12 > > I believe we determined there is never a case where a leap month > precedes the first regular month of a year, so 0L is never used, and I > don't believe the ICU library has a way to specify that either. > Gregory can probably confirm this is the case as he is more familiar > with ICU (and maybe Ken since he has also done an implementation). If > that is confirmed, then maybe we can add the following text to the > "2." list item in Section 4.1: > > Note, there is never a case of a leap month preceding the first > regular > month in a year, and consequently this specification provides no > way to > indicate such a leap month. > As Cyrus indicated, my understanding is that a leap month is never inserted prior to the first month of the year. All of the luini-solar calendars supported by ICU have the leap month inserted after months 2-11, depending on the calendar and year. The insertion point for the Chinese leap month roams between 2-11, and all of the other calendars have the insertion point fixed somewhere between 2-11. If there was to be a leap month prior to the first month of the year, I would imagine that it would be specified as the number of the last month of a non-leap year followed by the "L" suffix (e.g. 12L). -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Mon Nov 3 02:02:04 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 16E6D1A004C for ; Mon, 3 Nov 2014 02:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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.594, 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 hdQbXNyUrOzD for ; Mon, 3 Nov 2014 02:02:01 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB381A0011 for ; Mon, 3 Nov 2014 02:02:01 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id vb8so3808396obc.37 for ; Mon, 03 Nov 2014 02:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=kpCidGKCtjj0y6ljCt6U8sPsFG/ZURjqgwwXOh/AMM4=; b=dYeA7IpiLo0cQttC8qsexom6+2QorWLIxWBhYWltus/80eMiV0/d5y0jQ5oQAczO+2 0FIWtO2RbmOI5mVyk/EvQXQ8lLoiAbz4sfWUgWvPpqOiQqFw2FTA0c3/iRuiurbYQEAw Bb0tpaN6WuxKt+JR979ytQvLs82nkLEkeVgbRRa1itPQyej9xRol32IxtEQr2JGsAu2e nHVfOk8+p1fQlRJ7By8biXRcKvNDbUV42EgXZn4jAXWBaDX7iHfLHZ7w8d3rTB6p09tX hqabnJTW83bRhgslFbxnnOcOQ7whPe0NYH0kegBrXlGBBj1ljw/tBwosYbfhUDro1f0e GJuw== 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=kpCidGKCtjj0y6ljCt6U8sPsFG/ZURjqgwwXOh/AMM4=; b=AjgZH5AAXlh1PX33vxb5QS5YSu8Sxkz+vpiUS2XTxeo88vCHVuK4pJ2ck4SfP0ZImZ IeMChYLPgBA/lK5lUyHDpB5nlIW9gd0eA5Unua4qHf5CeorDx4MPyFYdb+A4MJbrPwVB 4nZNJrcMU+7UGMfyJ/2R7JmTUUP1muiCO5OyNzLA6k134RWdMvpH0SDNQyag6+jpcDDD k66o8kYbpS1x5G3KUxD2xgG0lGcZO7lowrMBFtZeLK+xKWJ8ghqLtol5yjJUPErEUvLq KqV5uwRNTIC2lWVcHo0icShtMsCZC0qboltcZghY3nsdkCEbMLekATwIwhkpCqY1eJrS m3qQ== X-Gm-Message-State: ALoCoQmISmS18dN25wuNaklN4eCHfBHBzjt3iq1Az+YKgDFax/60f7THDRnMpwP1dC6mQYtZ8qfn X-Received: by 10.182.165.36 with SMTP id yv4mr12583678obb.39.1415008920486; Mon, 03 Nov 2014 02:02:00 -0800 (PST) MIME-Version: 1.0 References: <972E4A2D3AB9897A35402273@cyrus.local> <54565D05.1070401@andrew.cmu.edu> From: Gregory Yakushev Date: Mon, 03 Nov 2014 10:02:00 +0000 Message-ID: To: Ken Murchison , Cyrus Daboo , Donald Eastlake , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a11c2fd340f636e0506f170ea Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/AlHcSzHEHxmE7S3DJJUO6ltBUqA Subject: Re: [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: Mon, 03 Nov 2014 10:02:03 -0000 --001a11c2fd340f636e0506f170ea Content-Type: text/plain; charset=UTF-8 On Sun Nov 02 2014 at 5:34:28 PM Ken Murchison wrote: > On 11/02/2014 10:01 AM, Cyrus Daboo wrote: > > Hi Donald, > > Thanks for your review - comments below. Changes have been applied to > > my working copy and I will push out a new version of the draft with > > those changes later in the week, or once follow-up discussion has > > concluded. > > > > --On October 30, 2014 at 12:04:02 AM -0400 Donald Eastlake > > wrote: > > > >> 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? > > > > So RFC 5545 "informally" defines monthnum to the range 1..12: > > > > monthnum = 1*2DIGIT ;1 to 12 > > > > I believe we determined there is never a case where a leap month > > precedes the first regular month of a year, so 0L is never used, and I > > don't believe the ICU library has a way to specify that either. > > Gregory can probably confirm this is the case as he is more familiar > > with ICU (and maybe Ken since he has also done an implementation). If > > that is confirmed, then maybe we can add the following text to the > > "2." list item in Section 4.1: > > > > Note, there is never a case of a leap month preceding the first > > regular > > month in a year, and consequently this specification provides no > > way to > > indicate such a leap month. > > > > > As Cyrus indicated, my understanding is that a leap month is never > inserted prior to the first month of the year. All of the luini-solar > calendars supported by ICU have the leap month inserted after months > 2-11, depending on the calendar and year. The insertion point for the > Chinese leap month roams between 2-11, and all of the other calendars > have the insertion point fixed somewhere between 2-11. If there was to > be a leap month prior to the first month of the year, I would imagine > that it would be specified as the number of the last month of a non-leap > year followed by the "L" suffix (e.g. 12L). > I also confirm Cyrus and Kens points. There are many many calendaring systems in the world, and it is not feasible to cover all of them with this spec. What we aim here is to cover most widely used and best understood systems, those supported by ICU in our case, and these systems cannot have a leap month before the first month. > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify Grisha Software Engineer @ Google --001a11c2fd340f636e0506f170ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun Nov 02 2014 at 5:34:28 PM Ken Mur= chison <murch@andrew.cmu.edu= > wrote:
On 11/02/2014 10:01 AM, Cyrus= Daboo wrote:
> Hi Donald,
> Thanks for your review - comments below. Changes have been applied to<= br> > my working copy and I will push out a new version of the draft with > those changes later in the week, or once follow-up discussion has
> concluded.
>
> --On October 30, 2014 at 12:04:02 AM -0400 Donald Eastlake
> <d3e3e3@gmail= .com> wrote:
>
>> Section 4.1: Would it be correct and worth while for clarity to sa= y
>> that "0L" indicates a leap month before the first regula= r month?
>
> So RFC 5545 "informally" defines monthnum to the range 1..12= :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0monthnum=C2=A0 =C2=A0 =3D 1*2DIGIT=C2=A0 =C2= =A0 =C2=A0 =C2=A0;1 to 12
>
> I believe we determined there is never a case where a leap month
> precedes the first regular month of a year, so 0L is never used, and I=
> don't believe the ICU library has a way to specify that either. > Gregory can probably confirm this is the case as he is more familiar > with ICU (and maybe Ken since he has also done an implementation). If<= br> > that is confirmed, then maybe we can add the following text to the
> "2." list item in Section 4.1:
>
>=C2=A0 =C2=A0 Note, there is never a case of a leap month preceding the= first
> regular
>=C2=A0 =C2=A0 month in a year, and consequently this specification prov= ides no
> way to
>=C2=A0 =C2=A0 indicate such a leap month.
>


As Cyrus indicated, my understanding is that a leap month is never
inserted prior to the first month of the year.=C2=A0 All of the luini-solar=
calendars supported by ICU have the leap month inserted after months
2-11, depending on the calendar and year.=C2=A0 The insertion point for the=
Chinese leap month roams between 2-11, and all of the other calendars
have the insertion point fixed somewhere between 2-11.=C2=A0 If there was t= o
be a leap month prior to the first month of the year, I would imagine
that it would be specified as the number of the last month of a non-leap year followed by the "L" suffix (e.g. 12L).
=
I also confirm Cyrus and Kens points. There are many many ca= lendaring systems in the world, and it is not feasible to cover all of them= with this spec. What we aim here is to cover most widely used and best und= erstood systems, those supported by ICU in our case, and these systems cann= ot have a leap month before the first month.
=C2=A0

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
=
Grisha
Software Engineer @ Google
--001a11c2fd340f636e0506f170ea-- From nobody Mon Nov 3 09:33: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 8BD0C1A1BAC for ; Mon, 3 Nov 2014 09:33:41 -0800 (PST) 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 C2m--PFUKyrE for ; Mon, 3 Nov 2014 09:33:40 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063E11A1B9C for ; Mon, 3 Nov 2014 09:33:39 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id uy5so9497397obc.12 for ; Mon, 03 Nov 2014 09:33:39 -0800 (PST) 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=gdVbKWFnb8Xhda1UhVTZ4/wkGL8Vxxw8g3u9C+JGq4k=; b=bC7FzpoPV0i11HCZSC1ysHbflCxgcXd7pskQW6yrTLGeiz7INlDuBbBs6ciMa6qYp3 W4AtKxkjXEwgv/Rdb2idTIJVIdXw9PGnj/tqxROgTj3etdyPiQaxGQHcHYxt+4zQFVhC C+QDbHkII0ruxqL0BvnFidDJlFfm3fFxSd/FPz0CB4jC+iWFq4ORInnU5EiKYooackl1 SmrAlkHY7e7nY5SFTQu4BwFQVzy9xlMB/4+ELaangEsrtetf2LPq2k6G2UYP2oMUk2l8 fv6HmrUkiKI8o+QzNILINIbk+Op4xD7rLrU7qTiHQ6XN3m2vuW7KamcggSpmYojnVfPK kK1w== X-Received: by 10.182.120.10 with SMTP id ky10mr1353840obb.68.1415036019453; Mon, 03 Nov 2014 09:33:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Mon, 3 Nov 2014 09:33:19 -0800 (PST) In-Reply-To: <972E4A2D3AB9897A35402273@cyrus.local> References: <972E4A2D3AB9897A35402273@cyrus.local> From: Donald Eastlake Date: Mon, 3 Nov 2014 12:33:19 -0500 Message-ID: To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Sfcu6QKobcIGPx6w01lk0A-tsKo Cc: calsify@ietf.org Subject: Re: [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: Mon, 03 Nov 2014 17:33:41 -0000 Hi, Thanks for your responses. I'm happy with them, especially given the observation that should there ever be a leap month before the first regular month in a year it could be denoted as a leap month after the last regular month of the previous year. I'll have to check with my co-Chair but I think that when a draft revised as indicated is uploaded, we can initiate a WG Last Call. Unfortunately, we are in the refractory period before the IETF meeting next week. As a result, draft postings is currently disabled. They should be re-enabled Monday morning next week although sometimes they don't get around to it until later in the day. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Nov 2, 2014 at 10:01 AM, Cyrus Daboo wrote: > Hi Donald, > Thanks for your review - comments below. Changes have been applied to my > working copy and I will push out a new version of the draft with those > changes later in the week, or once follow-up discussion has concluded. > > --On October 30, 2014 at 12:04:02 AM -0400 Donald Eastlake > wrote: > >> 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... > > > I think I will just drop "formally" completely. > >> Section 2: First occurrence of "YYYYMMHH" should prsumably be >> "YYYYMMDD". > > > Fixed. > >> 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? > > > So RFC 5545 "informally" defines monthnum to the range 1..12: > > monthnum = 1*2DIGIT ;1 to 12 > > I believe we determined there is never a case where a leap month precedes > the first regular month of a year, so 0L is never used, and I don't believe > the ICU library has a way to specify that either. Gregory can probably > confirm this is the case as he is more familiar with ICU (and maybe Ken > since he has also done an implementation). If that is confirmed, then maybe > we can add the following text to the "2." list item in Section 4.1: > > Note, there is never a case of a leap month preceding the first regular > month in a year, and consequently this specification provides no way to > indicate such a leap 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" '. > > > Fixed. > >> Section 9: Probably better to say the slightly more general "This >> document requires no IANA actions." > > > Fixed. > >> Appendix A: I think it would be good if it was a little clearer just >> which draft version the change sets refer to. > > > Fixed. > > -- > Cyrus Daboo > From nobody Mon Nov 3 19:36:48 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 68DE71A1BE0 for ; Mon, 3 Nov 2014 19:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.496 X-Spam-Level: X-Spam-Status: No, score=-107.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 iwu3-7AZ4nCx for ; Mon, 3 Nov 2014 19:36:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5194E1A6EE9 for ; Mon, 3 Nov 2014 19:36:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1CDFB18001B; Mon, 3 Nov 2014 19:36:38 -0800 (PST) To: bernard.desruisseaux@oracle.com, barryleiba@computer.org, presnick@qti.qualcomm.com, lear@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141104033638.1CDFB18001B@rfc-editor.org> Date: Mon, 3 Nov 2014 19:36:38 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/cwykx6vxe6Tk-sCiCIEqu62Ijtk Cc: pete@knowledgevault.com, calsify@ietf.org, rfc-editor@rfc-editor.org Subject: [calsify] [Editorial Errata Reported] RFC5545 (4150) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 03:36:45 -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=4150 -------------------------------------- Type: Editorial Reported by: Peter Bachman Section: 10.2 Original Text ------------- [TZDB] Eggert, P. and A.D. Olson, "Sources for Time Zone and Daylight Saving Time Data", July 2009, . Corrected Text -------------- [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", 1987, . Internet Assigned Numbers Authority (IANA) "Time Zone Database" . Notes ----- The twinsun.com version is no longer maintained by the volunteer(s) tz@elsie.nci.nih.gov. The document and the tz database, have been adopted by members of IETF and iana.org. The database itself is public domain. The corrected text matches that of rfc6557 11.1. Normative References [TZDB] http://tools.ietf.org/html/rfc6557 http://www.iana.org/time-zones/repository/tz-link.html http://www.iana.org/time-zones 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 Mon Nov 3 20:09:47 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 7D1881A6EDA for ; Mon, 3 Nov 2014 20:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTdqh4dx4Tyl for ; Mon, 3 Nov 2014 20:09:42 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360511A1C03 for ; Mon, 3 Nov 2014 20:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3712; q=dns/txt; s=iport; t=1415074182; x=1416283782; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=pFK1rDfjAZEW32GIMk50fp9ci7URgW5mfFxyGHc18YI=; b=ZlhTK3p9Clbz4DCOGrFZu0f04HdO5nHfzoEPhd5d1wsSo7co6Xqc6Oxj 2WQBJrsmTqUXx5JMxBiuCP3zjphIlcJZA1eiRwXd8MAZgGCUgACGDDspv zfzAp+nZKCKnmn6gkeEkwyTKOIHG9e+Hr+LNKd2ltmyGrlYa0i8CTEvrB A=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAP9QWFStJssW/2dsb2JhbABCGoNiWIMGwgSJSodNAoE8AQEBAQF9hAMBAQQjVQEQCxgJFgsCAgkDAgECAUUGAQwBBQIBAQWIOA04tXiVDQEBAQEBAQEBAQEBAQEBAQEBAQEBAReNQYNPBwmCboFUBYY1hUGIOYFSaIcYgTE9gxCCd4dvhmyCDoILHC8BE4I3AQEB X-IronPort-AV: E=Sophos;i="5.07,311,1413244800"; d="asc'?scan'208";a="234591690" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 04 Nov 2014 04:09:40 +0000 Received: from [10.61.200.129] ([10.61.200.129]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA449RHZ002190; Tue, 4 Nov 2014 04:09:31 GMT Message-ID: <54585175.3040002@cisco.com> Date: Mon, 03 Nov 2014 20:09:25 -0800 From: Eliot Lear 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: RFC Errata System , bernard.desruisseaux@oracle.com, barryleiba@computer.org, presnick@qti.qualcomm.com References: <20141104033638.1CDFB18001B@rfc-editor.org> In-Reply-To: <20141104033638.1CDFB18001B@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gmmVL0PkcLQWmIh3wi8u1VFmQwOSMRsfi" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/sT2aloOj6HIV2Wop7EH2fP6t6m8 Cc: pete@knowledgevault.com, calsify@ietf.org Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (4150) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 04:09:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gmmVL0PkcLQWmIh3wi8u1VFmQwOSMRsfi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I believe that at the time of release, the link was correct, and so this is not strictly an erratum. That having been said, I don't think it hurts to list the corrected link as an erratum even though strictly speaking it is not necessary for correct implementation. Eliot On 11/3/14, 7:36 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification (iCalend= ar)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5545&eid=3D4150 > > -------------------------------------- > Type: Editorial > Reported by: Peter Bachman > > Section: 10.2 > > Original Text > ------------- > [TZDB] Eggert, P. and A.D. Olson, "Sources for Time > Zone and Daylight Saving Time Data", > July 2009, > . > > Corrected Text > -------------- > [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and > Daylight Saving Time Data", 1987, > . > > Internet Assigned Numbers Authority (IANA) > "Time Zone Database" > . > > Notes > ----- > The twinsun.com version is no longer maintained by the volunteer(s) tz@= elsie.nci.nih.gov. The document and the tz database, have been adopted by= members of IETF and iana.org. The database itself is public domain.=20 > > The corrected text matches that of rfc6557 11.1. Normative References = [TZDB] > > > > http://tools.ietf.org/html/rfc6557 > http://www.iana.org/time-zones/repository/tz-link.html > http://www.iana.org/time-zones > > 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.=20 > > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object S= pecification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplificati= on > Area : Applications > Stream : IETF > Verifying Party : IESG > > > --gmmVL0PkcLQWmIh3wi8u1VFmQwOSMRsfi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUWFF2AAoJEIe2a0bZ0noz8xEIAKzTKQfST9qA1g4z1L+j2q3J iDT/7znF/WDrcTNqG0Joe/KLqbrDBhXO5QCn1ZI2v58wc603XK3WUHd+kHuB4Irj mvmOjzzT6q5Blw9shYZkc21IK2go4RNBmUwjMsVyUsmy4YsiUcKEMqS8Kf1O0Ejs Rgl+YGcRrM4Xq/0e7dqfVViQZ+dM0N9OmzqXxbhmJwrmc6rjbzLoQo91PnaOvIk2 nQiMdGa9AWcqRMJPmV/+Vp9+CjNPj1mhYYf9tOEf2LpoqDU26C3tYnH5WnE8ElFE NN3g+lyydBBWurAKDj7YU4GWE3KUxRAgVlLgxoS4Nbzh0Fzd0PAc1ZnyrxBlyOM= =ya+R -----END PGP SIGNATURE----- --gmmVL0PkcLQWmIh3wi8u1VFmQwOSMRsfi-- From nobody Tue Nov 4 05:08:51 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 C1E541A1B03 for ; Tue, 4 Nov 2014 05:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz-AK8XvFrV1 for ; Tue, 4 Nov 2014 05:08:46 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010: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 74C7C1A00AD for ; Tue, 4 Nov 2014 05:08:46 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id gd6so824412lab.34 for ; Tue, 04 Nov 2014 05:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ewOqhSZiX5EOEft1y6lwunYCugTLQjJ9lJaYU1rD5+k=; b=nIYXIBMvoZTgTQZ+YzAgjrx4uftACUcgq728u0RIQMQHYaCFlWW4hgOpEkF14oiDV3 ifGf/tCJLvYvmzTkGb/O5Bfv2LtvVWJKrCZxlufktTG9ybETRA+7do518/WMpTF2ylLt Yv7NIadT375C1AJlgxEEe52XI3c9V8WGYOewPWggkfYYCCMDNy2MxgbACLHbj4VIQ08c AbLoE2cg8Q9Ys0YehW4Dr9dVePkWLIvXGMAf/ANtRClT97rVgGNI+/LGYbadlznMvle5 y0Fh67p1LBlRCZ3ULjHE4WShbDSYY/K4z5TUly/djQTSqHR8qiGYbkpta6qr6De4p8tP wcSg== MIME-Version: 1.0 X-Received: by 10.112.162.41 with SMTP id xx9mr58608080lbb.21.1415106524480; Tue, 04 Nov 2014 05:08:44 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Tue, 4 Nov 2014 05:08:44 -0800 (PST) In-Reply-To: <54585175.3040002@cisco.com> References: <20141104033638.1CDFB18001B@rfc-editor.org> <54585175.3040002@cisco.com> Date: Tue, 4 Nov 2014 08:08:44 -0500 X-Google-Sender-Auth: 4Mmq6L3nZ4nEW3Rr2qloW1nk8Kk Message-ID: From: Barry Leiba To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/vfPX7VMV6jyghPkR4Wy-zmzkqVE Cc: Pete Resnick , calsify@ietf.org, pete@knowledgevault.com, RFC Errata System Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (4150) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 13:08:48 -0000 > I believe that at the time of release, the link was correct, and so this > is not strictly an erratum. That having been said, I don't think it > hurts to list the corrected link as an erratum even though strictly > speaking it is not necessary for correct implementation. Exactly my thought. I'm inclined to mark this one "Verified", though it actually meets the "Rejected" criteria. Comments from the RFC Editor are welcome, before I do. This is always one of the problems with putting URLs in RFCs, but sometimes we have to do it. I often wonder whether it would make sense to have the actual URLs in metadata, so they can be updated when it's necessary. Barry From nobody Tue Nov 4 12:58:14 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 B2AC51A024C for ; Tue, 4 Nov 2014 12:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 ubdNCaZajUW0 for ; Tue, 4 Nov 2014 12:58:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E71A0107 for ; Tue, 4 Nov 2014 12:58:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 6000) id 3EB50181C98; Tue, 4 Nov 2014 12:58:04 -0800 (PST) Date: Tue, 4 Nov 2014 12:58:04 -0800 From: RFC Editor To: Barry Leiba Message-ID: <20141104205804.GB30903@rfc-editor.org> References: <20141104033638.1CDFB18001B@rfc-editor.org> <54585175.3040002@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/F4ZC2IkndOGALxiZy0uG6Yold94 Cc: Pete Resnick , pete@knowledgevault.com, calsify@ietf.org, RFC Editor Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (4150) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 20:58:13 -0000 Hi Barry and Eliot, As noted, the IANA URL was not valid at the time the document was published, so we don't consider this an erratum. The RFC Editor team discussed this issue -- we would prefer not to see the errata system cluttered in this way (i.e., updating obsolete URLs in references), and recommend that it be rejected with an appropriate note about why the entry has been rejected (perhaps mention RFC 6557?). Please let us know if you would like to discuss this issue further or if you have any questions. Thank you, RFC Editor/sg On Tue, Nov 04, 2014 at 08:08:44AM -0500, Barry Leiba wrote: > > I believe that at the time of release, the link was correct, and so this > > is not strictly an erratum. That having been said, I don't think it > > hurts to list the corrected link as an erratum even though strictly > > speaking it is not necessary for correct implementation. > > Exactly my thought. I'm inclined to mark this one "Verified", though > it actually meets the "Rejected" criteria. Comments from the RFC > Editor are welcome, before I do. > > This is always one of the problems with putting URLs in RFCs, but > sometimes we have to do it. I often wonder whether it would make > sense to have the actual URLs in metadata, so they can be updated when > it's necessary. > > Barry From nobody Tue Nov 4 13:09:10 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 E34601ACF7A for ; Tue, 4 Nov 2014 13:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGp0jYqcFslu for ; Tue, 4 Nov 2014 13:09:07 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E9F1ACF7B for ; Tue, 4 Nov 2014 13:09:06 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u10so3384328lbd.25 for ; Tue, 04 Nov 2014 13:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=er7hJneYguAybq9iE6jr5VO6FrJh10/LlCKiQZejE90=; b=XFhy1dQ0u4IYzdWQ5XahnfqMpGwqyipwFnhRAolZzuKrsM+eN+WgxVMvQOSFSQQNuC e3QAKOXx/RD+2kEjuF4roGwav2T8HvbPzslmc9bUDfbq9cvWbhLK7Fu904Bo7Om4giHm vF954h9pdpGfa22BrhVLJKPm4a4Mjkag+09mbwHzO8Jee1iqgmV5wzFk9QjDVTnl+y32 mZIivnn1RMzMz6KXlRiE8mrDtnnUpbG9ldGuu0Fb4E8bCfiNKhF7qFFnZAAOo3r0Ik1h UOPWCvw8jIqxEI9v0xsoCjHN/wTbDBrYGR7Zs6DkB3s1kZCyuWCX0qB4q14AfeRDemqf VkIQ== MIME-Version: 1.0 X-Received: by 10.112.162.73 with SMTP id xy9mr23873313lbb.94.1415135344903; Tue, 04 Nov 2014 13:09:04 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Tue, 4 Nov 2014 13:09:04 -0800 (PST) In-Reply-To: <20141104205804.GB30903@rfc-editor.org> References: <20141104033638.1CDFB18001B@rfc-editor.org> <54585175.3040002@cisco.com> <20141104205804.GB30903@rfc-editor.org> Date: Tue, 4 Nov 2014 16:09:04 -0500 X-Google-Sender-Auth: EoXJ24UiYRovMyCDVD6EN1FdhTw Message-ID: From: Barry Leiba To: RFC Editor Content-Type: multipart/alternative; boundary=089e0117644f8ad14705070edfbf Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/7wPjFbE_6KwOShxQdYNyjYVo-5Y Cc: "pete@knowledgevault.com" , Pete Resnick , "calsify@ietf.org" Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (4150) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:09:09 -0000 --089e0117644f8ad14705070edfbf Content-Type: text/plain; charset=ISO-8859-1 Ok, Sandy, and thanks for the input. I will reject it with an explanation... and maybe the IESG can discuss with you and Heather on Sunday morning about possible ways to handle these situations. Barry On Tuesday, November 4, 2014, RFC Editor wrote: > Hi Barry and Eliot, > > As noted, the IANA URL was not valid at the time the document was > published, so we don't consider this an erratum. The RFC Editor team > discussed this issue -- we would prefer not to see the errata system > cluttered in this way (i.e., updating obsolete URLs in references), > and recommend that it be rejected with an appropriate note about why > the entry has been rejected (perhaps mention RFC 6557?). > > Please let us know if you would like to discuss this issue further or > if you have any questions. > > Thank you, > RFC Editor/sg > > > > On Tue, Nov 04, 2014 at 08:08:44AM -0500, Barry Leiba wrote: > > > I believe that at the time of release, the link was correct, and so > this > > > is not strictly an erratum. That having been said, I don't think it > > > hurts to list the corrected link as an erratum even though strictly > > > speaking it is not necessary for correct implementation. > > > > Exactly my thought. I'm inclined to mark this one "Verified", though > > it actually meets the "Rejected" criteria. Comments from the RFC > > Editor are welcome, before I do. > > > > This is always one of the problems with putting URLs in RFCs, but > > sometimes we have to do it. I often wonder whether it would make > > sense to have the actual URLs in metadata, so they can be updated when > > it's necessary. > > > > Barry > --089e0117644f8ad14705070edfbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, Sandy, and t= hanks for the input.=A0 I will reject it with an explanation... and maybe t= he IESG can discuss with you and Heather on Sunday morning about possible w= ays to handle these situations.

Barry
On Tuesday, November 4, 2014, RFC Editor <rfc-editor@rfc-editor.org> wrote:
Hi Barry and Eliot,

As noted, the IANA URL was not valid at the time the document was
published, so we don't consider this an erratum.=A0 The RFC Editor team=
discussed this issue -- we would prefer not to see the errata system
cluttered in this way (i.e., updating obsolete URLs in references),
and recommend that it be rejected with an appropriate note about why
the entry has been rejected (perhaps mention RFC 6557?).

Please let us know if you would like to discuss this issue further or
if you have any questions.

Thank you,
RFC Editor/sg



On Tue, Nov 04, 2014 at 08:08:44AM -0500, Barry Leiba wrote:
> > I believe that at the time of release, the link was correct, and = so this
> > is not strictly an erratum.=A0 That having been said, I don't= think it
> > hurts to list the corrected link as an erratum even though strict= ly
> > speaking it is not necessary for correct implementation.
>
> Exactly my thought.=A0 I'm inclined to mark this one "Verifie= d", though
> it actually meets the "Rejected" criteria.=A0 Comments from = the RFC
> Editor are welcome, before I do.
>
> This is always one of the problems with putting URLs in RFCs, but
> sometimes we have to do it.=A0 I often wonder whether it would make > sense to have the actual URLs in metadata, so they can be updated when=
> it's necessary.
>
> Barry
--089e0117644f8ad14705070edfbf-- From nobody Tue Nov 4 13:19:21 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 6F5671A000C; Tue, 4 Nov 2014 13:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.496 X-Spam-Level: X-Spam-Status: No, score=-107.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 8eiXRDE4U7X2; Tue, 4 Nov 2014 13:19:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0621A0007; Tue, 4 Nov 2014 13:19:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A48A1181C6B; Tue, 4 Nov 2014 13:19:06 -0800 (PST) To: pete@knowledgevault.com, bernard.desruisseaux@oracle.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141104211906.A48A1181C6B@rfc-editor.org> Date: Tue, 4 Nov 2014 13:19:06 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/HGQUHqUFWEGUYP6iO7880taOCVg Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, calsify@ietf.org Subject: [calsify] [Errata Rejected] RFC5545 (4150) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:19:15 -0000 The following errata report has been rejected 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=4150 -------------------------------------- Status: Rejected Type: Editorial Reported by: Peter Bachman Date Reported: 2014-11-03 Rejected by: Barry Leiba (IESG) Section: 10.2 Original Text ------------- [TZDB] Eggert, P. and A.D. Olson, "Sources for Time Zone and Daylight Saving Time Data", July 2009, . Corrected Text -------------- [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", 1987, . Internet Assigned Numbers Authority (IANA) "Time Zone Database" . Notes ----- The twinsun.com version is no longer maintained by the volunteer(s) tz@elsie.nci.nih.gov. The document and the tz database, have been adopted by members of IETF and iana.org. The database itself is public domain. The corrected text matches that of rfc6557 11.1. Normative References [TZDB] http://tools.ietf.org/html/rfc6557 http://www.iana.org/time-zones/repository/tz-link.html http://www.iana.org/time-zones --VERIFIER NOTES-- The document was correct at the time it was published, so this report does not meet the formal criteria for errata. That said, Peter is correct that the location of the time zone database has since changed, and readers should look to the new location, as he has specified in this report. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Nov 11 08:04:07 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 6A0E11A8AF3; Tue, 11 Nov 2014 08:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1DKwQpi5atb; Tue, 11 Nov 2014 08:03:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A62C21A8ADC; Tue, 11 Nov 2014 08:03:44 -0800 (PST) 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.7.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141111160344.2446.25960.idtracker@ietfa.amsl.com> Date: Tue, 11 Nov 2014 08:03:44 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/sI_e-xiWvTPJIDZyI9iCIWa9kSY Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-rscale-01.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: Tue, 11 Nov 2014 16:03:53 -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-01.txt Pages : 15 Date : 2014-11-11 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01 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 Mon Nov 17 20:35:53 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 150E01AD05C for ; Mon, 17 Nov 2014 20:35:52 -0800 (PST) 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 JSJfy61R0O0i for ; Mon, 17 Nov 2014 20:35:50 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887911A0079 for ; Mon, 17 Nov 2014 20:35:50 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so5136494obc.11 for ; Mon, 17 Nov 2014 20:35:49 -0800 (PST) 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=3Bupxmu/6S4Y7I+SZCIhYi6ucvzVeINxi222kM6izv4=; b=RFB0qftLD0SfG+vik6YU+YGRO1Nr8jex/kkQEgEbZeTZKSHKkmUm5J0HtO1dhRbd0Q dirIeQ5BhDiGJ+m87P+UOVFrvTeyucltN5HM7vsmRf3NleMx1SCBl7QAWrXsQOngT8UM r3gBxva8+ywfiv0eXzNpw3h4cdP5vvde6754cBfFmwvah0foY/QgFoVPD6YkecMM3m23 lJMHx5XAOGzr2bRj45lE2tGNAFFiiysqqNvqMndaL3hKDiSpRpGOIa2A1rVcQWEflVwi jUB+tKst7i4KrN+gao0YI77wQdMtp/m3bzkPuuVdGrqkQoTZ2DxbJoWkfjasKMRNJWSj tk9g== X-Received: by 10.182.128.38 with SMTP id nl6mr28064105obb.29.1416285349710; Mon, 17 Nov 2014 20:35:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.145.4 with HTTP; Mon, 17 Nov 2014 20:35:29 -0800 (PST) From: Donald Eastlake Date: Mon, 17 Nov 2014 23:35:29 -0500 Message-ID: To: calsify@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/ueSYt4ip_sjKpHO3VrcdnI3_YIw Subject: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 04:35:52 -0000 Hi, This message starts a WG Last Call on the draft below running to two week. If there are any final comments please post by then. Thanks, Donald (CoChair) ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Nov 11, 2014 at 11:03 AM, wrote: > > 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-01.txt > Pages : 15 > Date : 2014-11-11 > > 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-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01 > > > 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 Tue Nov 18 06:55: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 D3A801A066C for ; Tue, 18 Nov 2014 06:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8_b0nBHfAmzz for ; Tue, 18 Nov 2014 06:55:10 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7854B1A0318 for ; Tue, 18 Nov 2014 06:55:10 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTP id C7AEC13D49 for ; Tue, 18 Nov 2014 09:55:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21611.24012.856803.6388@compute03.cs.columbia.edu> Date: Tue, 18 Nov 2014 09:55:08 -0500 To: calsify@ietf.org In-Reply-To: References: X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) From: lennox@cs.columbia.edu Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/PAQL2qcdkMeqW6Yk9bDqQIuvhGg Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 14:55:13 -0000 Reviewing this document, the first thing I notice is that the citation [UNICODE.CLDR] is just a list of names of calendars, with no reference to their actual rules or algorithms or behavior. Is there no reference that can be cited that can give implementors information about what the calendar scales actually mean, other than "Use or duplicate the ICU implementation"? On Monday, November 17 2014, "Donald Eastlake" wrote to "calsify@ietf.org" saying: > Hi, > > This message starts a WG Last Call on the draft below running to two > week. If there are any final comments please post by then. > > Thanks, > Donald (CoChair) > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > On Tue, Nov 11, 2014 at 11:03 AM, wrote: > > > > 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-01.txt > > Pages : 15 > > Date : 2014-11-11 > > > > 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-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01 > > > > > > 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/ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Jonathan Lennox lennox@cs.columbia.edu From nobody Wed Nov 19 04:05:51 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 7472B1A19EE for ; Wed, 19 Nov 2014 04:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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.594, 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 xYwnetVGWjGp for ; Wed, 19 Nov 2014 04:05:44 -0800 (PST) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d: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 510941A0406 for ; Wed, 19 Nov 2014 04:05:43 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id u7so247805qaz.33 for ; Wed, 19 Nov 2014 04:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=SSiSy2le9E2wao5UsxIfT6J8/Msk0W7mXg7po1Hu25s=; b=ekiT+az5KdRZn+wEdEEMvB4C8ETMDq0N59I9D2l9+lnmfRBBlNJAwfr+zHiGcLrpLS jvisfHWdiIuaeCBB+zBQ6EdtRgDZpkTHvzTKeL9k3XbletjQWfbMnSuPkslNRBaiXTb1 zeulPBN5JLaIILLP0ut/wjjiDundRpFM3YQJrtnE5ZJgXjZ3M1Y32nqaEPtr/mkqoZJf VC0HbWyqT5dT42mR2qy/Vt/NXlUgJs7G1Dd+Cyl5OjvVqegqp0sk7COSf+nQj42F+f0u ygMlH2eXGLQ+9/XQX/Mcz2apQwilUQWGaIYdJcOsgzv9LJVwDzohnlXX4xRzMGuLtsHL PB0g== 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=SSiSy2le9E2wao5UsxIfT6J8/Msk0W7mXg7po1Hu25s=; b=hjRJ8vNwZuGMRrIGTv/Jird+7BUO05jtnTjgeYBf9C5UexJbcPME5zKCF0Hg/3a77C 2xHTpc/yIs5blgtKgFHS2LNC/3KTebz9Ka5eummgOfknz93nyvLa52++vdcN44sWuTHG CJ8y2ALkjeBGL+qcPPd05+prSB8PRSwe7GiLPiyiUCfkEKbpKNZO1rkYaDMZ8vOw0b+T NqZQo7vv+7GsHHWWhUkJrhuo3bI5/1mPWm4zNjC2Lb6EBYxGQQthhmhWxYgPCq0KpKEo VHvliVVzJFq/ayiDvIb0E0v+7XPqeOyxjnCT8sThVHG+pdvL818m0EjMzUV6CRYf2SqL hQ/Q== X-Gm-Message-State: ALoCoQkKzvt4pPaxwgsIjW9pY/dklZmjghwMVj3gCnFstVbpF1ecYFgCtV+gZW2BhxqhB+2ovjX2 X-Received: by 10.224.4.133 with SMTP id 5mr48796218qar.37.1416398742165; Wed, 19 Nov 2014 04:05:42 -0800 (PST) MIME-Version: 1.0 References: <21611.24012.856803.6388@compute03.cs.columbia.edu> From: Gregory Yakushev Date: Wed, 19 Nov 2014 12:05:41 +0000 Message-ID: To: lennox@cs.columbia.edu, calsify@ietf.org Content-Type: multipart/alternative; boundary=001a11c22108e341210508350701 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/hy0GODtc1puOp-MyVV-xWzy-lJ8 Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:05:49 -0000 --001a11c22108e341210508350701 Content-Type: text/plain; charset=UTF-8 Yes, this is a big issue. I am not aware of any standards covering calendaring computations, although it would be nice to have them. Standardizing calendaring calculations would be a big project on its own, way outside the scope of this WG, so in absence of such a standard we opted to use ICU as a calendaring calculations provider. The proposal as it stands effectively ties RSCALE to ICU, which is useful at the moment because ICU is maintained and available on a wide range of platforms. If in the future the calculations will be standardized, or there will be a need to recognize calendars not supported by ICU, we can always update the RFC. We also maintain a golden RSCALE expansion set to synchronize our implementations, you can find it here: http://calconnect.org/ioptesting.shtml Maybe its worth mentioning this golden set as an informational reference in the draft. Best Regards Grisha On Tue Nov 18 2014 at 3:55:16 PM wrote: > Reviewing this document, the first thing I notice is that the citation > [UNICODE.CLDR] is just a list of names of calendars, with no reference to > their actual rules or algorithms or behavior. Is there no reference that > can be cited that can give implementors information about what the calendar > scales actually mean, other than "Use or duplicate the ICU implementation"? > > On Monday, November 17 2014, "Donald Eastlake" wrote to "calsify@ietf.org" > saying: > > > Hi, > > > > This message starts a WG Last Call on the draft below running to two > > week. If there are any final comments please post by then. > > > > Thanks, > > Donald (CoChair) > > ============================= > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > > > On Tue, Nov 11, 2014 at 11:03 AM, wrote: > > > > > > 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-01.txt > > > Pages : 15 > > > Date : 2014-11-11 > > > > > > 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-01 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01 > > > > > > > > > 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/ > > > > _______________________________________________ > > calsify mailing list > > calsify@ietf.org > > https://www.ietf.org/mailman/listinfo/calsify > > > > -- > Jonathan Lennox > lennox@cs.columbia.edu > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c22108e341210508350701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, this is a big issue. I am not aware of any standards covering calendar= ing computations, although it would be nice to have them. Standardizing cal= endaring calculations would be a big project on its own, way outside the sc= ope of this WG, so in absence of such a standard we opted to use ICU as a c= alendaring calculations provider.

The proposal as it stands effectiv= ely ties RSCALE to ICU, which is useful at the moment because ICU is mainta= ined and available on a wide range of platforms. If in the future the calcu= lations will be standardized, or there will be a need to recognize calendar= s not supported by ICU, we can always update the RFC.

We also mainta= in a golden RSCALE expansion set to synchronize our implementations, you ca= n find it here:=C2=A0htt= p://calconnect.org/ioptesting.shtml
Maybe its worth mentioning this= golden set as an informational reference in the draft.

Best Regards
Grisha

On Tue Nov 18 2014 at 3:55:16 PM <lennox@cs.columbia.edu> wrote:
Reviewing this document, the first thing I notice is that the= citation
[UNICODE.CLDR] is just a list of names of calendars, with no reference to their actual rules or algorithms or behavior.=C2=A0 Is there no reference t= hat
can be cited that can give implementors information about what the calendar=
scales actually mean, other than "Use or duplicate the ICU implementat= ion"?

On Monday, November 17 2014, "Donald Eastlake" wrote to "calsify@ietf.org&quo= t; saying:

> Hi,
>
> This message starts a WG Last Call on the draft below running to two > week. If there are any final comments please post by then.
>
> Thanks,
> Donald (CoChair)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>=C2=A0 Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
>=C2=A0 155 Beaver Street, Milford, MA 01757 USA
>=C2=A0 d3e3e3@gma= il.com
>
> On Tue, Nov 11, 2014 at 11:03 AM,=C2=A0 <internet-drafts@ietf.org> wrote:=
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s directories.
> >=C2=A0 This draft is a work item of the Calendaring Extensions Wor= king Group of the IETF.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Non-Gregorian Recurrence Rules in iCalendar
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Cyrus Daboo
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Gregory Yakushev
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-calext-rscale-01.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: 15
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2014-11-11
> >
> > Abstract:
> >=C2=A0 =C2=A0 This document defines how non-Gregorian recurrence r= ules can be
> >=C2=A0 =C2=A0 specified and used in iCalendar data, and with CalDA= V 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-rsc= ale-01
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-calext-rscale-01
> >
> >
> > 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/
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org=
> https://www.ietf.org/mailman/listinfo/calsify
>

--
Jonathan Lennox
lennox@cs.colum= bia.edu

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a11c22108e341210508350701-- From nobody Wed Nov 19 05:24:32 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 2F1691A1C05 for ; Wed, 19 Nov 2014 05:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 ejy_umMRM8Zk for ; Wed, 19 Nov 2014 05:24:29 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297F91A1B9B for ; Wed, 19 Nov 2014 05:24:28 -0800 (PST) Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id sAJDOQVO021278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Nov 2014 08:24:27 -0500 Message-ID: <546C9A0A.2050409@andrew.cmu.edu> Date: Wed, 19 Nov 2014 08:24:26 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: calsify@ietf.org References: <21611.24012.856803.6388@compute03.cs.columbia.edu> In-Reply-To: <21611.24012.856803.6388@compute03.cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.19.131520 X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 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, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 33% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Co-IZgQu4DwvaODJ9B2m_v3sZfU Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 13:24:31 -0000 Hi Jonathan, On 11/18/2014 09:55 AM, lennox@cs.columbia.edu wrote: > Reviewing this document, the first thing I notice is that the citation > [UNICODE.CLDR] is just a list of names of calendars, with no reference to > their actual rules or algorithms or behavior. Is there no reference that > can be cited that can give implementors information about what the calendar > scales actually mean, other than "Use or duplicate the ICU implementation"? Would a reference to published text be appropriate? I'm thinking something like: http://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz/dp/0521702380/ That being said, I haven't read this text. I used the ICU library for the RSCALE implementation in libical. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Nov 19 07:32:57 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 F037C1ACD76 for ; Wed, 19 Nov 2014 07:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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.594, 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 UCxDShF_hGZv for ; Wed, 19 Nov 2014 07:32:54 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934351A8AE7 for ; Wed, 19 Nov 2014 07:32:54 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so530845qab.16 for ; Wed, 19 Nov 2014 07:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=XVmTAUayEUgYJHfGXH8wxbOK9DJNTzFWz8w+lVIRwjc=; b=EdFrHMUwgadzjZ6D5gTD6LJbkFYQ2Qrhe3zhJ52mDz2LD8DxaVPm/zKXu/r3QHi6dq gEFsoxvmajaR2RA/HhlWvYjRSR1NXyC4Gst2BlX4q+m9Q4NCGgvd9MuMLiPFeWMirDFr f9wK32RfBIaHMWALP6utiEhpKClfXyCkX9dXZYPT2WJk3LvNhIFqz2/+kCWDcpaWmWTS t9pfJDg9/g32rHIYHaRR5zoZUULb+rWezSMBkQjFY4E/2Xb6CK75K+CWxyq8vCYej6ku Ad7rAsfFq7OEQHbqBOIGwVAkY/SMjE20D8KpjVwfLGLfWTfMTixumlETdMDyuy2HI2yI t30A== 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=XVmTAUayEUgYJHfGXH8wxbOK9DJNTzFWz8w+lVIRwjc=; b=c1BozBbPLgfnEQKn7KKuPOYULD5+N7aABYAOkrMrBiLv62Z31yxzDIP91DguYcqFU0 v74OgTYfqOKQE51ANrRk7YDWQH1zdVEGctYtQPk09OZkvv7ledWrs6I7cB9XoA/ggjgl qo9FNwvuUEjqqv0mIja23I/TcXJ2UmdVgeQ7up5rF5XAcO6zjcivRRgTRwg5Trauk1wp 8jiG3i1QgM4QLOfGwdJukCH+EqaV07mD5a/DWi44CbTYfHUIvXxO7NX2lo/FdPa0iSin jKLI5fFqL+2fsAOsGTYdrAG6N3E/Mw89shOhIWNRDxrBKyWfLWiXE1ZmhlKop8+mrjqp yUvg== X-Gm-Message-State: ALoCoQlKdfQ9raSGebqwMc2Y9HYehXr8zWMJqm/elufA39hP8+rNMVyNIgWQtIUc2pczDVnbglzd X-Received: by 10.140.21.106 with SMTP id 97mr7940763qgk.61.1416411173633; Wed, 19 Nov 2014 07:32:53 -0800 (PST) MIME-Version: 1.0 References: <21611.24012.856803.6388@compute03.cs.columbia.edu> <546C9A0A.2050409@andrew.cmu.edu> From: Gregory Yakushev Date: Wed, 19 Nov 2014 15:32:53 +0000 Message-ID: To: Ken Murchison , calsify@ietf.org Content-Type: multipart/alternative; boundary=001a11c158c4dc6da2050837ec0c Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/T2xfsFil234KSTIHaVhdo84u1Ic Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 15:32:57 -0000 --001a11c158c4dc6da2050837ec0c Content-Type: text/plain; charset=UTF-8 On Wed Nov 19 2014 at 2:24:34 PM Ken Murchison wrote: > Hi Jonathan, > > > On 11/18/2014 09:55 AM, lennox@cs.columbia.edu wrote: > > Reviewing this document, the first thing I notice is that the citation > > [UNICODE.CLDR] is just a list of names of calendars, with no reference to > > their actual rules or algorithms or behavior. Is there no reference that > > can be cited that can give implementors information about what the > calendar > > scales actually mean, other than "Use or duplicate the ICU > implementation"? > > > Would a reference to published text be appropriate? I'm thinking > something like: > http://www.amazon.com/Calendrical-Calculations-Nachum-Dershowitz/dp/ > 0521702380/ This book is really good, but its a more generic scientific literature. It won't tell you the implementation difference between ICU "islamic-umalqura" and "islamic-rgsa" for example. > > > That being said, I haven't read this text. I used the ICU library for > the RSCALE implementation in libical. > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --001a11c158c4dc6da2050837ec0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed Nov 19 2014 at 2:24:34 PM Ken Mur= chison <murch@andrew.cmu.edu= > wrote:
Hi Jonathan,


On 11/18/2014 09:55 AM, lennox@cs.columbia.edu wrote:
> Reviewing this document, the first thing I notice is that the citation=
> [UNICODE.CLDR] is just a list of names of calendars, with no reference= to
> their actual rules or algorithms or behavior.=C2=A0 Is there no refere= nce that
> can be cited that can give implementors information about what the cal= endar
> scales actually mean, other than "Use or duplicate the ICU implem= entation"?


Would a reference to published text be appropriate?=C2=A0 I'm thinking<= br> something like:
http://www.amazon.com/Calendrical= -Calculations-Nachum-Dershowitz/dp/0521702380/

This book is really good, but its a more generic scie= ntific literature. It won't tell you the implementation difference betw= een ICU=C2=A0"islamic-umalqura" and "islamic-rgsa" for = example.

=C2=A0
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--001a11c158c4dc6da2050837ec0c-- From nobody Wed Nov 19 09:25: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 21B9A1AD39E for ; Wed, 19 Nov 2014 09:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 9G_DCTgBAVxz for ; Wed, 19 Nov 2014 09:25:38 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0EA1AD39D for ; Wed, 19 Nov 2014 09:25:38 -0800 (PST) Received: from compute03.cs.columbia.edu (compute03.cs.columbia.edu [128.59.11.33]) by mailbackend.panix.com (Postfix) with ESMTP id DB83A1323A; Wed, 19 Nov 2014 12:25:37 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21612.53905.57790.653250@compute03.cs.columbia.edu> Date: Wed, 19 Nov 2014 12:25:37 -0500 To: Gregory Yakushev In-Reply-To: References: <21611.24012.856803.6388@compute03.cs.columbia.edu> X-Mailer: VM 8.1.0 under 23.3.1 (x86_64-pc-linux-gnu) From: lennox@cs.columbia.edu Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/ds0BVjCXVwjkXr4mP2m_m9Lbudc Cc: calsify@ietf.org Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 17:25:41 -0000 On Wednesday, November 19 2014, "Gregory Yakushev" wrote to "lennox@cs.= columbia.edu, calsify@ietf.org" saying: > Yes, this is a big issue. I am not aware of any standards covering ca= lendaring > computations, although it would be nice to have them. Standardizing c= alendaring > calculations would be a big project on its own, way outside the scope= of this > WG, so in absence of such a standard we opted to use ICU as a calenda= ring > calculations provider. >=20 > The proposal as it stands effectively ties RSCALE to ICU, which is us= eful at > the moment because ICU is maintained and available on a wide range of= > platforms. If in the future the calculations will be standardized, or= there > will be a need to recognize calendars not supported by ICU, we can al= ways > update the RFC. >=20 > We also maintain a golden RSCALE expansion set to synchronize our > implementations, you can find it here:=A0http://calconnect.org/ioptes= ting.shtml > Maybe its worth mentioning this golden set as an informational refere= nce in the > draft. My concern is that some organizations have rules that not only can thei= r products not contain open-source code, but additionally their implement= ors can't even look at open-source code, for fear of inadvertant copyright infringement. This may be excessive paranoia, especially for a license= as lenient as ICU's, but go try arguing with lawyers... That said, the relevant references shouldn't actually have to be a stan= dard, I think. If ICU's public documentation (as opposed to its source code)= has sufficient detail about the different flavors of calendars, then that, alongside a generic reference such as Reingold & Dershowitz, will hopef= ully be sufficient. For that matter, does the CLDR give references beyond just names=3F Th= e XML document that the [UNICODE.CLDR] citation refers to is just a list of n= ames, but hopefully these are expanded or explained somewhere. > Best Regards > Grisha >=20 > On Tue Nov 18 2014 at 3:55:16 PM wrote: >=20 > Reviewing this document, the first thing I notice is that the cit= ation > [UNICODE.CLDR] is just a list of names of calendars, with no refe= rence to > their actual rules or algorithms or behavior.=A0 Is there no refe= rence that > can be cited that can give implementors information about what th= e calendar > scales actually mean, other than "Use or duplicate the ICU implem= entation"=3F >=20 > On Monday, November 17 2014, "Donald Eastlake" wrote to "calsify@= ietf.org" > saying: >=20 > > Hi, > > > > This message starts a WG Last Call on the draft below running t= o two > > week. If there are any final comments please post by then. > > > > Thanks, > > Donald (CoChair) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > >=A0 Donald E. Eastlake 3rd=A0 =A0+1-508-333-2270 (cell) > >=A0 155 Beaver Street, Milford, MA 01757 USA > >=A0 d3e3e3@gmail.com > > > > On Tue, Nov 11, 2014 at 11:03 AM,=A0 = wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-D= rafts > directories. > > >=A0 This draft is a work item of the Calendaring Extensions Wo= rking Group > of the IETF. > > > > > >=A0 =A0 =A0 =A0 =A0Title=A0 =A0 =A0 =A0 =A0 =A0: Non-Gregorian= Recurrence Rules in iCalendar > > >=A0 =A0 =A0 =A0 =A0Authors=A0 =A0 =A0 =A0 =A0: Cyrus Daboo > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gregory= Yakushev > > >=A0 =A0 =A0 =A0 =A0Filename=A0 =A0 =A0 =A0 : draft-ietf-calext= -rscale-01.txt > > >=A0 =A0 =A0 =A0 =A0Pages=A0 =A0 =A0 =A0 =A0 =A0: 15 > > >=A0 =A0 =A0 =A0 =A0Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-11-11 > > > > > > Abstract: > > >=A0 =A0 This document defines how non-Gregorian recurrence rul= es can be > > >=A0 =A0 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-01 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-calext-rscale= -01 > > > > > > > > > Please note that it may take a couple of minutes from the tim= e of > submission > > > until the htmlized version and diff are available at tools.ie= tf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ --=20 Jonathan Lennox lennox@cs.columbia.edu From nobody Wed Nov 19 11:31:07 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 ED2A11A1B77 for ; Wed, 19 Nov 2014 11:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 nBVGSc8Medmv for ; Wed, 19 Nov 2014 11:31:03 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2EB1A6EF3 for ; Wed, 19 Nov 2014 11:31:03 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so6511237wiw.13 for ; Wed, 19 Nov 2014 11:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=JhJVPzng4kCBwPY5ssejVpHEuX+RvSiZvkDJ98xYZRM=; b=rMOoxhBP8l1RDloQZ7B/hLgfLpgOpiBWTp7jSf2BmQwTphaYucr0/BiwMabKxY0RnP 6BDNiGQzKhI/FrJYp8hcFKEiWYJc1lUACiN3YCREZa35SBpEKP1UCYsZDWQrMzlmXOEI 3kgJmuZYxfm44b0Shq/JhrkLS5fuhijGE2gl3EhH4DhJRM+DnJ0lEbSTqILRtHb937LW nQSu7koqLnove8dahZc/7wjMYu2BwDBMYAyeFppZvvRTIUBk9hChL29p1UltzVNAkbPF ceuNswWOzkTvov1HT5jaVdlHPwSUg7iXoxOOADzZlFUZs7XiC6//GKWTSWDJcajKt69K /4YA== X-Received: by 10.194.59.36 with SMTP id w4mr2648690wjq.53.1416425461757; Wed, 19 Nov 2014 11:31:01 -0800 (PST) Received: from smtp.dmfs.org (pD9EA65E1.dip0.t-ipconnect.de. [217.234.101.225]) by mx.google.com with ESMTPSA id bf6sm205441wjb.13.2014.11.19.11.31.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 19 Nov 2014 11:31:00 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (unknown [89.204.137.247]) by smtp.dmfs.org (Postfix) with ESMTPSA id A80EE4E3 for ; Wed, 19 Nov 2014 20:30:57 +0100 (CET) Message-ID: <546CEF71.3070300@dmfs.org> Date: Wed, 19 Nov 2014 20:28:49 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: calsify@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030900050703070507020809" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/Qq5l-QAB1TB9TA5CtmpziUw5G4M Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:31:06 -0000 This is a multi-part message in MIME format. --------------030900050703070507020809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, the current draft doesn't say anything about jCal (RFC 7265, http://tools.ietf.org/html/rfc7265). http://tools.ietf.org/html/rfc7265#section-3.6.10 defines the "byxxx" fields as numbers or arrays of numbers. However, that doesn't work with leap months. I think it its not exactly clear how RRULEs with RSCALE and leap months have to be expressed in jCal. The most obvious solution would be to allow Strings like so: ["rrule", {}, "recur", { "freq": "YEARLY", "rscale": "xxxxxxx", "count": 5, "bymonth": [5, "10L"] } ] But this can result in an array of mixed types. A similar issue exists for xCal. In that case we need an update to the schema. cheers Marten Am 18.11.2014 um 05:35 schrieb Donald Eastlake: > Hi, > > This message starts a WG Last Call on the draft below running to two > week. If there are any final comments please post by then. > > Thanks, > Donald (CoChair) > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > On Tue, Nov 11, 2014 at 11:03 AM, wrote: >> 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-01.txt >> Pages : 15 >> Date : 2014-11-11 >> >> 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-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01 >> >> >> 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/ > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- *Marten Gajda* Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten@dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 --------------030900050703070507020809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

the current draft doesn't say anything about jCal (RFC 7265, http://tools.ietf.org/html/rfc7265).

http://tools.ietf.org/html/rfc7265#section-3.6.10 defines the "byxxx" fields as numbers or arrays of numbers. However, that doesn't work with leap months.

I think it its not exactly clear how RRULEs with RSCALE and leap months have to be expressed in jCal. The most obvious solution would be to allow Strings like so:
["rrule",
    {},
    "recur",
    {
      "freq": "YEARLY",
      "rscale": "xxxxxxx",
      "count": 5,
      "bymonth": [5, "10L"]
    }
   ]
But this can result in an array of mixed types.

A similar issue exists for xCal. In that case we need an update to the schema.

cheers

Marten



Am 18.11.2014 um 05:35 schrieb Donald Eastlake:
Hi,

This message starts a WG Last Call on the draft below running to two
week. If there are any final comments please post by then.

Thanks,
Donald (CoChair)
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Tue, Nov 11, 2014 at 11:03 AM,  <internet-drafts@ietf.org> wrote:

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-01.txt
        Pages           : 15
        Date            : 2014-11-11

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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01


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/

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

--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

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

VAT Reg. No.: DE269072391

--------------030900050703070507020809-- From nobody Wed Nov 19 11:44:26 2014 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4E1A6EFE for ; Wed, 19 Nov 2014 11:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcUQR772NzqB for ; Wed, 19 Nov 2014 11:44:22 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED0E1A6F02 for ; Wed, 19 Nov 2014 11:44:18 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so3099923wiw.3 for ; Wed, 19 Nov 2014 11:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=JMeqO2Bnqiq4vrrT2S2cpMBm/etvFIx/7L6D0PuFdiw=; b=IHQOCJliGP6NOhys+82aouxEPV6mGVhtkIFJQj9d+MrGjI6Ltb9b1i4OXQ7iPHfv0H g8+YDP5Yy5PHDEfbLqXqW0Z2OvYVWDxh8ctmg88Ul9uPbGmBiLR3pRtfe0uZrMKfv1Yy QO+Bd2qX7vFOxgnbZQwThJnPB6MKpD4iKbbIr6a0qkz+DbK8TIxahOkjR1sCUCOkA9xc 9/Kn/iEtouM1rJqVH5qjRnLgtVG2D8kNRvVuR1/T1xAW2FuCz7IFIBwuuPyUvAfHzRj9 rSw3AiJshQujfEPrt86M6fTPFlPNvJG+CgaRhCgwoOjgaDZV3QmnNzDJKZveSd44GH8L t/6Q== X-Received: by 10.180.108.43 with SMTP id hh11mr8513125wib.80.1416426257271; Wed, 19 Nov 2014 11:44:17 -0800 (PST) Received: from oskar.fritz.box (p20030057EA1F4400882E071E32259D6F.dip0.t-ipconnect.de. [2003:57:ea1f:4400:882e:71e:3225:9d6f]) by mx.google.com with ESMTPSA id nd20sm3502921wic.11.2014.11.19.11.44.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Nov 2014 11:44:16 -0800 (PST) Message-ID: <546CF310.3010807@gmail.com> Date: Wed, 19 Nov 2014 20:44:16 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: calsify@ietf.org References: <546CEF71.3070300@dmfs.org> In-Reply-To: <546CEF71.3070300@dmfs.org> Content-Type: multipart/alternative; boundary="------------000300080603030908010308" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/vaRpa1ETGIB_vEefDP1UIHJNHQc Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 19:44:25 -0000 This is a multi-part message in MIME format. --------------000300080603030908010308 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hey Marten, thanks for mentioning this. jCal has multiple notes for other cases mentioning that types should be checked anyway, so I agree the obvious solution makes most sense. iCalendar parsers will have to be upgraded for RSCALE anyway, the same applies to jCal parsers. I'm not sure if the jCal syntax should be mentioned in the RSCALE document or if a separate document should be defined, you probably know better than me how this is usually done in the IETF. Philipp On 11/19/14 8:28 PM, Marten Gajda wrote: > Hi, > > the current draft doesn't say anything about jCal (RFC 7265, > http://tools.ietf.org/html/rfc7265). > > http://tools.ietf.org/html/rfc7265#section-3.6.10 defines the "byxxx" > fields as numbers or arrays of numbers. However, that doesn't work > with leap months. > > I think it its not exactly clear how RRULEs with RSCALE and leap > months have to be expressed in jCal. The most obvious solution would > be to allow Strings like so: > ["rrule", > {}, > "recur", > { > "freq": "YEARLY", > "rscale": "xxxxxxx", > "count": 5, > "bymonth": [5, "10L"] > } > ] > But this can result in an array of mixed types. > > A similar issue exists for xCal. In that case we need an update to the > schema. > > cheers > > Marten > > > > Am 18.11.2014 um 05:35 schrieb Donald Eastlake: >> Hi, >> >> This message starts a WG Last Call on the draft below running to two >> week. If there are any final comments please post by then. >> >> Thanks, >> Donald (CoChair) >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> On Tue, Nov 11, 2014 at 11:03 AM, wrote: >>> 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-01.txt >>> Pages : 15 >>> Date : 2014-11-11 >>> >>> 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-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01 >>> >>> >>> 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/ >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > -- > > *Marten Gajda* > Schandauer Straße 34 > 01309 Dresden > Germany > > tel: +49 177 4427167 > email: marten@dmfs.org > twitter: twitter.com/dmfs_org > > VAT Reg. No.: DE269072391 > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------000300080603030908010308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hey Marten,

thanks for mentioning this. jCal has multiple notes for other cases mentioning that types should be checked anyway, so I agree the obvious solution makes most sense. iCalendar parsers will have to be upgraded for RSCALE anyway, the same applies to jCal parsers.

I'm not sure if the jCal syntax should be mentioned in the RSCALE document or if a separate document should be defined, you probably know better than me how this is usually done in the IETF.

Philipp

On 11/19/14 8:28 PM, Marten Gajda wrote:
Hi,

the current draft doesn't say anything about jCal (RFC 7265, http://tools.ietf.org/html/rfc7265).

http://tools.ietf.org/html/rfc7265#section-3.6.10 defines the "byxxx" fields as numbers or arrays of numbers. However, that doesn't work with leap months.

I think it its not exactly clear how RRULEs with RSCALE and leap months have to be expressed in jCal. The most obvious solution would be to allow Strings like so:
["rrule",
    {},
    "recur",
    {
      "freq": "YEARLY",
      "rscale": "xxxxxxx",
      "count": 5,
      "bymonth": [5, "10L"]
    }
   ]
But this can result in an array of mixed types.

A similar issue exists for xCal. In that case we need an update to the schema.

cheers

Marten



Am 18.11.2014 um 05:35 schrieb Donald Eastlake:
Hi,

This message starts a WG Last Call on the draft below running to two
week. If there are any final comments please post by then.

Thanks,
Donald (CoChair)
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Tue, Nov 11, 2014 at 11:03 AM,  <internet-drafts@ietf.org> wrote:

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-01.txt
        Pages           : 15
        Date            : 2014-11-11

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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-calext-rscale-01


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/

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

--

Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

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

VAT Reg. No.: DE269072391



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

--------------000300080603030908010308-- From nobody Wed Nov 19 12:03: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 A06331A6F45 for ; Wed, 19 Nov 2014 12:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 M0ra0__Ag8N2 for ; Wed, 19 Nov 2014 12:03:28 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1361AD577 for ; Wed, 19 Nov 2014 12:01:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 253483D5B45; Wed, 19 Nov 2014 15:01:52 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uqt4uNzK6iPu; Wed, 19 Nov 2014 15:01:52 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 4B1703D5B39; Wed, 19 Nov 2014 15:01:51 -0500 (EST) Date: Wed, 19 Nov 2014 15:01:47 -0500 From: Cyrus Daboo To: Philipp Kewisch , calsify@ietf.org Message-ID: In-Reply-To: <546CF310.3010807@gmail.com> References: <546CEF71.3070300@dmfs.org> <546CF310.3010807@gmail.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2062 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/BxBl2TUCLWfAoFnP6FeH8YT2jFc Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 20:03:30 -0000 Hi Philipp, --On November 19, 2014 at 8:44:16 PM +0100 Philipp Kewisch wrote: > thanks for mentioning this. jCal has multiple notes for other cases > mentioning that types should be checked anyway, so I agree the obvious > solution makes most sense. iCalendar parsers will have to be upgraded > for RSCALE anyway, the same applies to jCal parsers. > > I'm not sure if the jCal syntax should be mentioned in the RSCALE > document or if a separate document should be defined, you probably know > better than me how this is usually done in the IETF. > When we discussed this before I think we were OK with the RSCALE-unaware jcal parser failing because it should fail regardless if an RSCALE= item is in the RRULE. Perhaps it is worth adding some text specific to jCal and xCal defining the new behavior expected when they do support RSCALE. Something like: X. Use with jCal jCal parsers supporting this specification will need to: 1. Serialize the "RSCALE" element in an "RRULE" property as an "rscale" JSON member in the "rrule" JSON object. The value of the "rscale" JSON member MUST be a boolean. 2. Correctly parse any "rscale" JSON member in an "rrule" JSOB object. 3. Serialize the "bymonth" JSON member in an "rrule" JSON object as a string value, if the equivalent iCalendar value contains the "L" character suffix. "bymonth" JSON members that do not use the "L" suffix continue to be serialized as JSON numbers. 4. Correctly parse any "bymonth" JSON member in an "rrule" JSON object by recognizing either number or string values. 5. Serialize the "SKIP" element in an "RRULE" property as a "skip" JSON member in the "rrule" JSON object. The value of the "skip" JSON member MUST be a string containing lowercased values for the "SKIP" element as defined by this specification. 6. Correctly parse any "skip" JSON member in an "rrule" JSOB object. And I will do an equivalent for xCal, defining new XML elements as needed. I think that should address Marten's comment. -- Cyrus Daboo From nobody Wed Nov 19 12:16:27 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 0C7DA1A6FDF for ; Wed, 19 Nov 2014 12:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, 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 Ku5aUfmsJPfs for ; Wed, 19 Nov 2014 12:16:17 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165E91A6FBB for ; Wed, 19 Nov 2014 12:16:08 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so1776660wgg.35 for ; Wed, 19 Nov 2014 12:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=2r21bMDhglIqIeuybuFTjLt8nZvO9xU2fBegk3M3mPA=; b=zlhpxcgIWrD+hZ0vFatuHiR2UxpSa/eQoTAkmSwVH9+4x8/eKGCNSmZTgBesI2sv2Y 2396Rcn7jXEXo8LjiNFZ37zyo1WxIZFA0x0I4/0Y46QnDSNYAypy6TZsbP8etGXpWuys VjXg8u4nFrX43/cBTWq3tYVkItfKAkMguxey3phScFNhE5WfWsyAua8ojpZ0s9w4OGvN tGjsWGJifv/YSPH6ZKTSITOW94KBa+dMxOmhyR6yYL8i5M0+IlvQj+SwiG6faOenOIZS db+2RRl9hvG912amCIZA3HlL2wqh6Fj7VQtGXn0OZbjDessBDMCvMPiW5cEr0j1jHy38 4FPg== X-Received: by 10.180.98.169 with SMTP id ej9mr8899603wib.1.1416428166825; Wed, 19 Nov 2014 12:16:06 -0800 (PST) Received: from smtp.dmfs.org (pD9EA65E1.dip0.t-ipconnect.de. [217.234.101.225]) by mx.google.com with ESMTPSA id p1sm326563wjy.22.2014.11.19.12.16.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 19 Nov 2014 12:16:05 -0800 (PST) Sender: Marten Gajda Received: from localhost.localdomain (unknown [89.204.137.247]) by smtp.dmfs.org (Postfix) with ESMTPSA id D0338DCA for ; Wed, 19 Nov 2014 21:16:03 +0100 (CET) Message-ID: <546CFA7C.6020702@dmfs.org> Date: Wed, 19 Nov 2014 21:15:56 +0100 From: Marten Gajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: calsify@ietf.org References: <546CEF71.3070300@dmfs.org> <546CF310.3010807@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080904020500000004020507" Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/IMQFMgppl4-Kfxk2-cApbu4JaJc Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 20:16:19 -0000 This is a multi-part message in MIME format. --------------080904020500000004020507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Why would the value of the "rscale" field be boolean? I think it should be a String (i.e. the identifier of the calendar scale). Other than that it sounds good to me. Marten Am 19.11.2014 um 21:01 schrieb Cyrus Daboo: > Hi Philipp, > > --On November 19, 2014 at 8:44:16 PM +0100 Philipp Kewisch > wrote: > >> thanks for mentioning this. jCal has multiple notes for other cases >> mentioning that types should be checked anyway, so I agree the obvious >> solution makes most sense. iCalendar parsers will have to be upgraded >> for RSCALE anyway, the same applies to jCal parsers. >> >> I'm not sure if the jCal syntax should be mentioned in the RSCALE >> document or if a separate document should be defined, you probably know >> better than me how this is usually done in the IETF. >> > > When we discussed this before I think we were OK with the > RSCALE-unaware jcal parser failing because it should fail regardless > if an RSCALE= item is in the RRULE. > > Perhaps it is worth adding some text specific to jCal and xCal > defining the new behavior expected when they do support RSCALE. > Something like: > > X. Use with jCal > > jCal parsers supporting this specification will need to: > > 1. Serialize the "RSCALE" element in an "RRULE" property as an > "rscale" JSON member in the "rrule" JSON object. The value of the > "rscale" JSON member MUST be a boolean. > > 2. Correctly parse any "rscale" JSON member in an "rrule" JSOB object. > > 3. Serialize the "bymonth" JSON member in an "rrule" JSON object as > a string value, if the equivalent iCalendar value contains the "L" > character suffix. "bymonth" JSON members that do not use the "L" > suffix continue to be serialized as JSON numbers. > > 4. Correctly parse any "bymonth" JSON member in an "rrule" JSON > object by recognizing either number or string values. > > 5. Serialize the "SKIP" element in an "RRULE" property as a "skip" > JSON member in the "rrule" JSON object. The value of the "skip" JSON > member MUST be a string containing lowercased values for the "SKIP" > element as defined by this specification. > > 6. Correctly parse any "skip" JSON member in an "rrule" JSOB object. > > > And I will do an equivalent for xCal, defining new XML elements as > needed. I think that should address Marten's comment. > -- *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 --------------080904020500000004020507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Why would the value of the "rscale" field be boolean? I think it should be a String (i.e. the identifier of the calendar scale).

Other than that it sounds good to me.

Marten

Am 19.11.2014 um 21:01 schrieb Cyrus Daboo:
Hi Philipp,

--On November 19, 2014 at 8:44:16 PM +0100 Philipp Kewisch <kewisch@gmail.com> wrote:

thanks for mentioning this. jCal has multiple notes for other cases
mentioning that types should be checked anyway, so I agree the obvious
solution makes most sense. iCalendar parsers will have to be upgraded
for RSCALE anyway, the same applies to jCal parsers.

I'm not sure if the jCal syntax should be mentioned in the RSCALE
document or if a separate document should be defined, you probably know
better than me how this is usually done in the IETF.


When we discussed this before I think we were OK with the RSCALE-unaware jcal parser failing because it should fail regardless if an RSCALE= item is in the RRULE.

Perhaps it is worth adding some text specific to jCal and xCal defining the new behavior expected when they do support RSCALE. Something like:

X. Use with jCal

jCal parsers supporting this specification will need to:

   1. Serialize the "RSCALE" element in an "RRULE" property as an "rscale" JSON member in the "rrule" JSON object. The value of the "rscale" JSON member MUST be a boolean.

   2. Correctly parse any "rscale" JSON member in an "rrule" JSOB object.

   3. Serialize the "bymonth" JSON member in an "rrule" JSON object as a string value, if the equivalent iCalendar value contains the "L" character suffix. "bymonth" JSON members that do not use the "L" suffix continue to be serialized as JSON numbers.

   4. Correctly parse any "bymonth" JSON member in an "rrule" JSON object by recognizing either number or string values.

   5. Serialize the "SKIP" element in an "RRULE" property as a "skip" JSON member in the "rrule" JSON object. The value of the "skip" JSON member MUST be a string containing lowercased values for the "SKIP" element as defined by this specification.

   6. Correctly parse any "skip" JSON member in an "rrule" JSOB object.


And I will do an equivalent for xCal, defining new XML elements as needed. I think that should address Marten's comment.


--

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

--------------080904020500000004020507-- From nobody Wed Nov 19 12:33:37 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 2D5E21A6F92 for ; Wed, 19 Nov 2014 12:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 1AM3l1LTlQE9 for ; Wed, 19 Nov 2014 12:33:34 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F781A1B7D for ; Wed, 19 Nov 2014 12:33:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C5DFD3D66A3; Wed, 19 Nov 2014 15:33:33 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yob_sm8VD0G2; Wed, 19 Nov 2014 15:33:32 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 4BFF33D6698; Wed, 19 Nov 2014 15:33:30 -0500 (EST) Date: Wed, 19 Nov 2014 15:33:27 -0500 From: Cyrus Daboo To: Marten Gajda , calsify@ietf.org Message-ID: <3B482C8E7AAFAD2AEB260AC1@caldav.corp.apple.com> In-Reply-To: <546CFA7C.6020702@dmfs.org> References: <546CEF71.3070300@dmfs.org> <546CF310.3010807@gmail.com> <546CFA7C.6020702@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=354 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/biTWCqb39b2k-R7OqX-cM8j6JFA Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 20:33:36 -0000 Hi Marten, --On November 19, 2014 at 9:15:56 PM +0100 Marten Gajda wrote: > Why would the value of the "rscale" field be boolean? I think it should > be a String (i.e. the identifier of the calendar scale). Sorry, mistake on my part. Yes it needs to be a string value. > Other than that it sounds good to me. OK. -- Cyrus Daboo From nobody Mon Nov 24 12:40: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 CF0A21A9027 for ; Mon, 24 Nov 2014 12:40:14 -0800 (PST) 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 PaTl4aKf68Dd for ; Mon, 24 Nov 2014 12:40:13 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E423E1A902E for ; Mon, 24 Nov 2014 12:40:12 -0800 (PST) Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id sAOKe30B017005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Nov 2014 15:40:03 -0500 Message-ID: <547397A2.2080609@andrew.cmu.edu> Date: Mon, 24 Nov 2014 15:40:02 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Cyrus Daboo , Philipp Kewisch , calsify@ietf.org References: <546CEF71.3070300@dmfs.org> <546CF310.3010807@gmail.com> 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.11.24.202724 X-SMTP-Spam-Clean: 28% ( SXL_IP_DYNAMIC 3, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __INT_PROD_LOC 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 28% X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204 Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/JUPMoeALmDpLda9RlJdNEI15YTw Subject: Re: [calsify] WG Last Call: draft-ietf-calext-rscale-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 20:40:15 -0000 Hi Cyrus, I was just checking my implementation and have a couple of comments and sample output below. On 11/19/2014 03:01 PM, Cyrus Daboo wrote: > Hi Philipp, > > --On November 19, 2014 at 8:44:16 PM +0100 Philipp Kewisch > wrote: > >> thanks for mentioning this. jCal has multiple notes for other cases >> mentioning that types should be checked anyway, so I agree the obvious >> solution makes most sense. iCalendar parsers will have to be upgraded >> for RSCALE anyway, the same applies to jCal parsers. >> >> I'm not sure if the jCal syntax should be mentioned in the RSCALE >> document or if a separate document should be defined, you probably know >> better than me how this is usually done in the IETF. >> > > When we discussed this before I think we were OK with the > RSCALE-unaware jcal parser failing because it should fail regardless > if an RSCALE= item is in the RRULE. > > Perhaps it is worth adding some text specific to jCal and xCal > defining the new behavior expected when they do support RSCALE. > Something like: > > X. Use with jCal > > jCal parsers supporting this specification will need to: > > 1. Serialize the "RSCALE" element in an "RRULE" property as an > "rscale" JSON member in the "rrule" JSON object. The value of the > "rscale" JSON member MUST be a boolean. > > 2. Correctly parse any "rscale" JSON member in an "rrule" JSOB object. In the above to steps, I think "rrule" JSON object should be "recur" JSON object. > > 3. Serialize the "bymonth" JSON member in an "rrule" JSON object as > a string value, if the equivalent iCalendar value contains the "L" > character suffix. "bymonth" JSON members that do not use the "L" > suffix continue to be serialized as JSON numbers. > > 4. Correctly parse any "bymonth" JSON member in an "rrule" JSON > object by recognizing either number or string values. > > 5. Serialize the "SKIP" element in an "RRULE" property as a "skip" > JSON member in the "rrule" JSON object. The value of the "skip" JSON > member MUST be a string containing lowercased values for the "SKIP" > element as defined by this specification. Why lowercased? We preserve case for "freq" and "wkst", and presumably "byday". > > 6. Correctly parse any "skip" JSON member in an "rrule" JSOB object. > > > And I will do an equivalent for xCal, defining new XML elements as > needed. I think that should address Marten's comment. > Does this look correct for an RRULE such as: RRULE:FREQ=YEARLY;RSCALE=CHINESE;SKIP=YES;BYMONTH=6,6L [ "rrule", {}, "recur", { "freq": "YEARLY", "rscale": "CHINESE", "skip": "YES", "bymonth": [ 6, "6L" ] } ], YEARLY CHINESE YES 6 6L -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University