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

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 18 Nov 2019 20:14:07 +0800

I think this concept is good, but this spec needs a fair bit more work (as noted in the meeting today, this should have been a call for adoption, not WGLC!)

The "series master" is a kind of template; it's not an event itself, it just generates them. It might make more sense therefore to make this a different component, e.g. `VEVENTTEMPLATE`. Clients that don't support the spec should simply ignore them, which is what we want. We can also then reuse standard RRULE etc. properties and don't need to define separate SRULE etc. properties.

I think we should mandate that the server manages generating the instances; that's going to be by far the most useful option and we can clearly define when this should happen in the spec. Changing the template (series master) should not change any generated event that's now in the past; the question is what to do about those in the future. It probably depends on what the change is (what if you change the template SUMMARY? What about adding an RDATE? What about changing the RRULE? Have iTIP messages already been sent out inviting people to the event?). More thought needed here I think.

I was very unclear how the "SPLIT" thing was meant to work in the spec, which is related to the above; I would be interested to know more about what Mike's proposing here.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Tue, 19 Nov 2019 11:12:16 -0500

Thanks Neil

On 11/18/19 07:14, Neil Jenkins wrote:
> I think this concept is good, but this spec needs a fair bit more work 
> (as noted in the meeting today, this should have been a call for 
> adoption, not WGLC!)
>
> The "series master" is a kind of template; it's not an event itself, 
> it just generates them. It might make more sense therefore to make 
> this a different component, e.g. |VEVENTTEMPLATE|. Clients that don't 
> support the spec should simply ignore them, which is what we want. We 
> can also then reuse standard RRULE etc. properties and don't need to 
> define separate SRULE etc. properties.
>
Good idea - I'll work on that.
> I think we should mandate that the server manages generating the 
> instances; that's going to be by far the most useful option and we can 
> clearly define when this should happen in the spec.
That ties the data model in with one or more protocols. I'd prefer to 
leave that to related specs (or sections). However, I can see that with 
say a CalDAV stored series it MUST be the server.
> Changing the template (series master) should not change any generated 
> event that's now in the past; the question is what to do about those 
> in the future. It probably depends on what the change is (what if you 
> change the template SUMMARY? What about adding an RDATE? What about 
> changing the RRULE? Have iTIP messages already been sent out inviting 
> people to the event?). More thought needed here I think.
>
> I was very unclear how the "SPLIT" thing was meant to work in the 
> spec, which is related to the above; I would be interested to know 
> more about what Mike's proposing here.
I'll reread. I want to standardize the split approach from the start so 
we don't have the current recurrence issues. Dangling future overrides 
are always a problem if the rules change - this has been a major problem 
- set up months worth of instances - every one different then chaneg 
from weekly to bi-weekly.
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Marten Gajda <[email-masked]>
Date: Wed, 20 Nov 2019 17:00:03 +0100

Am 19.11.19 um 17:12 schrieb Michael Douglass:
>> I think this concept is good, but this spec needs a fair bit more 
>> work (as noted in the meeting today, this should have been a call for 
>> adoption, not WGLC!)
>>
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. For instance, an 
event recurring every 1st Monday of June for three days or an event 
recurring on eight consecutive days starting every other week.

Marten

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

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

---

From: Marten Gajda <[email-masked]>
Date: Wed, 20 Nov 2019 17:00:03 +0100

Marten

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 22 Nov 2019 11:36:56 +0800

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.

Neil.

---

From: Marten Gajda <[email-masked]>
Date: Fri, 22 Nov 2019 10:29:50 +0100

Am 22.11.19 um 04:36 schrieb Neil Jenkins:
>> 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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 22 Nov 2019 17:35:22 +0800

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.

> Also I want to advice against calling the object VTEMPLATEEVENT. VEVENTSERIES would be a better name

Sure, no objection to that.

Neil.

---

From: Marten Gajda <[email-masked]>
Date: Fri, 22 Nov 2019 11:10:48 +0100

Am 22.11.19 um 10:35 schrieb Neil Jenkins:
>> 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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: Michael Douglass <[email-masked]>
Date: Sun, 24 Nov 2019 12:05:27 -0500

> placeholders I can provide when instantiating the template into a VEVENT.
I was going to suggest the same. The master template approach resolves 
all the issues over whether or not the master is o is not a member of 
the recurrence set.
> email:[email-masked]

---

From: Michael Douglass <[email-masked]>
Date: Sun, 24 Nov 2019 12:18:38 -0500

On 11/22/19 05:10, Marten Gajda wrote:
>> 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.
>
> 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
>
It was not stated explicitly in the draft and i hadn't considered it.

We have 2 choices (I think).

1. We allow the generation of recurrences - in this case we do have to 
duplicate all the recurring properties as the current spec states.

2. We choose to reuse the current recurrence properties which prohibits 
the generation of recurrences.

There's a whole other issue which I've already raised elsewhere: 
multiple RRULEs and SRULES SHOULD be supported. That would deal with 
many cases. For Martens benefit I have come across users generating up 
to 7 identical recurring events to cover a 6 week series and then having 
to keep each one identical as they make changes. A simple multiple rrule 
would have been much easier for them. It's also true that even if it's 
possible to generate a single rule it's often much easier to understand 
(and create) multiple rrules.

On the other hand the issue Marten raises - skip the event if it falls 
on some special date - may be better dealt with by a new relation type.

Series 1 generates a simple set of instances - e.g every Monday.

An exclusion relation points to another series, recurring event or 
single event. All instances of that - now and into the future - exclude 
instances of series 1.

This does require some rules. e.g. series 1 may generate 1 hour 
meetings. the referenced series may generate all day. I think the rule 
is something like the exclusion event masks the instance. So an all day 
blocks completely - an overlap reduces the length of the instance etc.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Nov 2019 10:32:41 +1100

On Mon, 25 Nov 2019, at 04:18, Michael Douglass wrote:
> 2. We choose to reuse the current recurrence properties which prohibits the generation of recurrences. 

I am very much in favour of this option. Keeping the complexity down is important to help adoption (and reduce likelihood of interoperability issues) and make it usable.

> An exclusion relation points to another series, recurring event or single event. All instances of that - now and into the future - exclude instances of series 1.

I am wary that this also adds quite a lot of complexity and I am doubtful it is worth it over just adding EXDATEs to the series master.

Neil.