Re: [calsify] Feedback on draft-ietf-calext-icalendar-series

Marten Gajda <marten@dmfs.org> Fri, 22 November 2019 10:10 UTC

Return-Path: <marten@dmfs.org>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AD212080E for <calsify@ietfa.amsl.com>; Fri, 22 Nov 2019 02:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dmfs.org
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 rMc4MH4zZQOB for <calsify@ietfa.amsl.com>; Fri, 22 Nov 2019 02:10:52 -0800 (PST)
Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6871202A0 for <calsify@ietf.org>; Fri, 22 Nov 2019 02:10:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20191106; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=l5POVocyMrAtom59aT98iOCk7ONdp+aWK+Kmd2iS3H4=; b=f4ZDJUgHF+TbxCKs0w7IXJBsFq0eyZYyfNw7H41DeExeq/ggeHiuRQtlKbaJPor32UQTvcPvfvjw3 j7NtBrL0/WNdiQIctmDRTY+F8Tm66DwGVSbbcp/sSO9X26awHoOdJyLkoQ0sApzrVAIxyyx3BjIUAm 7X3tp+BkwGtNglDekjYHkF4FxdykO8ol8IedGqEM4+iESUFoRpyBDvwY0xCTQcK71v3zNUzRf9S4ZL N7pokTF3QSh8lTDwmtRh5Rt9avcuasgOuK6x5kENd74SsyJ7I7+tG6HRXs8YSTWjT+nyBrTaiakMdv DJMtc08IT0H2s5NQLCh8I7CwJ+5cDGA==
X-HalOne-Cookie: a56047c99176dde6cb01434c5046a2c984db510f
X-HalOne-ID: 5b936a82-0d10-11ea-b5f1-d0431ea8bb03
Received: from smtp.dmfs.org (unknown [2003:fa:af05:8e00:201:2eff:fe40:2624]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 5b936a82-0d10-11ea-b5f1-d0431ea8bb03; Fri, 22 Nov 2019 10:10:49 +0000 (UTC)
Received: from boss.localdomain (pD95ED904.dip0.t-ipconnect.de [217.94.217.4]) by smtp.dmfs.org (Postfix) with ESMTPSA id 63837136E for <calsify@ietf.org>; Fri, 22 Nov 2019 11:10:49 +0100 (CET)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org> <c6f9e64f-3e0b-4e60-b0fa-de3b2e84945e@dogfood.fastmail.com> <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org> <ee5c3434-fbd6-467c-8c72-acc56801c4b0@dogfood.fastmail.com>
From: Marten Gajda <marten@dmfs.org>
Message-ID: <bd91bec4-5a7a-3e0f-9857-888e350b451a@dmfs.org>
Date: Fri, 22 Nov 2019 11:10:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <ee5c3434-fbd6-467c-8c72-acc56801c4b0@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------58B0794940E0FC67DD544FF9"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/KfrjzyFXMDLqoV3LQL2Ac5uDRLk>
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 10:10:55 -0000

Am 22.11.19 um 10:35 schrieb Neil Jenkins:
> On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:
>>
>> I'm not talking about merely merging the instances of multiple 
>> RRULES. When we have an SRULE, the RRULE property would not be 
>> interpreted by the series and go as-is into the resulting VEVENT.
>>
>
> If that was the intention, I clearly missed that when reading the 
> draft. That seems to me to miss the whole point of this feature, which 
> is to generate individual instances for each occurrence so you can 
> then edit the properties on each one without building up a massive 
> ball of overrides. I do not think you should be able to generate 
> events in a series which themselves contain a recurrence rule.

Right, this probably wasn't the intention, but there is nothing in the 
draft which contradicts this use case either. It doesn't introduce any 
complexity. Series expansion would be agnostic to RRULE. Why would we 
artificially limit the resulting events in their properties?

Just addressing the overrides issue would be too short sighted IMO. This 
draft has the potential to fix many more issues with recurring events. I 
mentioned it before; I'd really like to see a future extension which 
allows to determine occurrences of events based on other calendars. For 
instance, often I sit there and delete instances of a recurring event 
which fall on a holiday or on school holidays. What I want to express is 
"this event occurs every week unless it would overlap an event in this 
calendar of (school) holidays". Often school holidays are not known very 
far in advance and may change every year, so a mechanism which evaluates 
them just a few months in advance would be helpful.

Marten


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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743