On Sat Oct 04 2014 at 6:39:14 PM Ken Mur= chison <murch@andrew.cmu.edu= > wrote:

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

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

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

That's a good question.=C2=A0 Let's see what the IETF/IAB folks say= .

=C2=A0

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

=C2=A0Grisha

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify

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

Grisha

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

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

cheers

Marten

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

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

VAT Reg. No.: DE269072391

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify

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

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