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

[Michael Douglass <[e-mail]>]

On 11/22/19 05:10, Marten Gajda wrote:
>
>
> 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
>
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.


>
>> _______________________________________________
>> calsify mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/calsify
> -- 
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: [phone]
> email:[e-mail]
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify