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

Marten Gajda <marten@dmfs.org> Fri, 22 November 2019 09:29 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 DB10F120288 for <calsify@ietfa.amsl.com>; Fri, 22 Nov 2019 01:29:58 -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 7MjxSGfxcJn6 for <calsify@ietfa.amsl.com>; Fri, 22 Nov 2019 01:29:56 -0800 (PST)
Received: from mailrelay4-1.pub.mailoutpod1-cph3.one.com (mailrelay4-1.pub.mailoutpod1-cph3.one.com [46.30.210.185]) (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 934AC120048 for <calsify@ietf.org>; Fri, 22 Nov 2019 01:29:55 -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=aSgErUX4e/85aYkldVohkXOeO1KEcSxqyHLYblitaUQ=; b=kYc75HUaqfXUt22l3UQG6reRhBTqM7dfGz/kGSGx2/ySgJsntaCSlNwOAk9W79Mtom++ZteXBDQV0 LF6HLryvEVjqdF1EqHshaVZUoalh7l9XY8aVgkTzBtdDa04fXAliaCNECk5l3P2ifLnh2gqZi2DZvF 2rjFJRjfKQojvEwmrPRx7akf5zYO6xSNhjh26j1oOqDV6lJBrKcgqQENCLNgzdRWqkb9BNjMA1K8cx 2Qg6SdhsLHAnqEW5Ktd+YwL+LTsZVpsDA7x9U/T2Q1zXpy3K+8KITiNaq15YdJ2yRkh4LwukfmNSS3 e3PTU2jUv5/zzLHZUXqc5tC5VOItLZg==
X-HalOne-Cookie: 4012d6772cdc8b0e7df4624d67ee86883a432fbd
X-HalOne-ID: a2f73e4d-0d0a-11ea-8288-d0431ea8bb10
Received: from smtp.dmfs.org (unknown [2003:fa:af05:8e00:201:2eff:fe40:2624]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id a2f73e4d-0d0a-11ea-8288-d0431ea8bb10; Fri, 22 Nov 2019 09:29:52 +0000 (UTC)
Received: from boss.localdomain (pD95ED904.dip0.t-ipconnect.de [217.94.217.4]) by smtp.dmfs.org (Postfix) with ESMTPSA id D684C136E for <calsify@ietf.org>; Fri, 22 Nov 2019 10:29:51 +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>
From: Marten Gajda <marten@dmfs.org>
Message-ID: <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>
Date: Fri, 22 Nov 2019 10:29:50 +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: <c6f9e64f-3e0b-4e60-b0fa-de3b2e84945e@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------6D65B140EEE9CF4491F9BC6F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/3AGeHw65AMYNPPJ-dszxeFPfsL8>
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 09:29:59 -0000

Am 22.11.19 um 04:36 schrieb Neil Jenkins:
> On Thu, 21 Nov 2019, at 00:00, Marten Gajda wrote:
>>
>> I like the idea of a separate SRULE. It allows you to declare series 
>> of recurring events. That way you can specify more complex recurrence 
>> patterns which you can't express with a single RRULE.
>>
>
> I'm not sure exactly what you mean by this; do you just mean you can 
> have multiple recurrence rules? Because that's no reason why a 
> VTEMPLATEEVENT can't have multiple RRULE properties. I don't think 
> SRULE was any different to RRULE other than being a different name to 
> differentiate it when sharing a component namespace, which is not 
> required if it's a different component.

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.

Consider this series:

DTSTART:20190611T12:00:00Z
SRULE:FREQ=YEARLY;BYMONTH=6;BYDAY=2MO
RRULE:FREQ=DAILY;COUNT=4

It would result in the following first few VEVENTS

DTSTART:20190611T12:00:00Z
RRULE:FREQ=DAILY;COUNT=4

DTSTART:20200608T12:00:00Z
RRULE:FREQ=DAILY;COUNT=4

DTSTART:20210614T12:00:00Z
RRULE:FREQ=DAILY;COUNT=4

This results in composition of recurrence pattern rather than of the 
union of both recurrence patterns, i.e. you first apply the SRULE and 
then apply the RRULE on every result of the SRULE.

Also I want to advice against calling the object VTEMPLATEEVENT. 
VEVENTSERIES would be a better name because this is not what I would 
expect from a true template. From a template I'd expect to support 
placeholders I can provide when instantiating the template into a VEVENT.

Marten


>
> Neil.
>
> _______________________________________________
> 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