Subject: [calsify] JSCalendar and EXRULE

From: Michael Douglass <[email-masked]>
Date: Tue, 12 May 2020 16:44:49 -0400

I believe we should support this and I think it's only a minor change to 
the spec.

I didn't agree with the deprecation of EXRULEs - there are a whole bunch 
of cases that are easily handled - just because UIs choose not to 
support it isn't that much of an argument.

Try this article from 2008 for one

https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/

And this would be solved

https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month

My suggestion is to add the "excluded" property to the recurrence rule 
to flag it as an exrule.

   "recurrenceRules" : [{
       "@type" : "RecurrenceRule",

      "excluded": true,

      ...
     }],

---

From: Ken Murchison <[email-masked]>
Date: Tue, 12 May 2020 16:56:20 -0400

I'd also be in favor of adding EXRULEs, but I might name the property 
"exception", since EXRULE is described as Exception Rule in RFC 2445, 
but its not a strong preference.

Hmm.

On 5/12/20 4:44 PM, Michael Douglass wrote:
> I believe we should support this and I think it's only a minor change 
> to the spec.
>
> I didn't agree with the deprecation of EXRULEs - there are a whole 
> bunch of cases that are easily handled - just because UIs choose not 
> to support it isn't that much of an argument.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Michael Douglass <[email-masked]>
Date: Tue, 12 May 2020 21:50:26 -0400

> but its not a strong preference.

I suggested "excluded" because it's already defined for an exdate.

I'd be as happy to see them added as a separate property altogether. I 
guess it's also possible to just have another property altogether 
"exceptionRules" and maybe that's clearer.

>> My suggestion is to add the "excluded" property to the recurrence 
>> rule to flag it as an exrule.
>>
>>   "recurrenceRules" : [{

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 22 May 2020 17:11:22 +1000

On Wed, 13 May 2020, at 11:50, Michael Douglass wrote:
> I guess it's also possible to just have another property altogether 

Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name. I guess this is fine; if you don't support it and receive an object with it set, it's just like if you get multiple recurrence rules and don't support that, or a recurrence property you don't support (e.g. you might not support non-Gregorian recurrences); in any of these cases you would just have to communicate to the user that you don't support expanding the recurrences for this event.

Neil.

---

From: "Robert Stepanek" <[email-masked]>
Date: Fri, 22 May 2020 09:26:16 +0200

On Fri, May 22, 2020, at 9:11 AM, Neil Jenkins wrote:
> Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name. 

In the TC-CALENDAR call of this week we preferred "excludedRecurrenceRules" (or "excludedRules"). We already use "excluded" in recurrenceOverrides for EXDATE, so the naming would be consistent.

Cheers,
Robert

---

From: "Robert Stepanek" <[email-masked]>
Date: Sat, 23 May 2020 11:34:02 +0200

> In the TC-CALENDAR call of this week we preferred "excludedRecurrenceRules" (or "excludedRules"). We already use "excluded" in recurrenceOverrides for EXDATE, so the naming would be consistent.

I'm not sure I got the EXRULE semantics right:

RFC 2245 defines for EXRULE [1]: "The final recurrence set is generated by gathering all of the start date/times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date/times which fall within the union of start date/times generated by any specified "EXRULE" and "EXDATE" properties."

This seems to imply that the DTSTART of a recurrence instance, rather than its RECURRENCE-ID must be considered in relation to EXRULE?

If so, then any time zone differences between overridden recurrence instance start times and EXRULE instances must be considered? Also, is a recurrence instance excluded if its DTSTART falls in the time range of the start and end time of an excluded recurrence instance? Or is only the exact start time relevant?

Thanks,
Robert

[1] https://tools.ietf.org/html/rfc2445#section-4.8.5.2

---

From: Michael Douglass <[email-masked]>
Date: Sat, 23 May 2020 18:44:05 -0400

On 5/23/20 05:34, Robert Stepanek wrote:
>>> Yes, if we do this I think a separate property make much more sense, 
>>> and "exceptionRules" sounds like a reasonable choice for its name.
>>
>> In the TC-CALENDAR call of this week we preferred 
>> "excludedRecurrenceRules" (or "excludedRules"). We already use 
>> "excluded" in recurrenceOverrides for EXDATE, so the naming would be 
>> consistent.
>
> RFC 2245 defines for EXRULE [1]: "The final recurrence set is 
> generated by gathering all of the start date/times generated by any of 
> the specified "RRULE" and "RDATE" properties, and excluding any start 
> date/times which fall within the union of start date/times generated 
> by any specified "EXRULE" and "EXDATE" properties."
>
> This seems to imply that the DTSTART of a recurrence instance, rather 
> than its RECURRENCE-ID must be considered in relation to EXRULE?
>
> If so, then any time zone differences between overridden recurrence 
> instance start times and EXRULE instances must be considered? Also, is 
> a recurrence instance excluded if its DTSTART falls in the time range 
> of the start and end time of an excluded recurrence instance? Or is 
> only the exact start time relevant?

I guess this is another instance of the confusing text around 
recurrences. What we are calculating or excluding are recurrence-ids and 
i think the text might have been better specified that way?

For an instance that isn't overridden the start is the same as the 
recurrence-id.

An override can change the date/time or zone but that's true for RRULE

---

From: "Robert Stepanek" <[email-masked]>
Date: Sun, 24 May 2020 11:14:41 +0200

On Sun, May 24, 2020, at 12:44 AM, Michael Douglass wrote:
> I guess this is another instance of the confusing text around recurrences. What we are calculating or excluding are recurrence-ids and i think the text might have been better specified that way? 

> For an instance that isn't overridden the start is the same as the recurrence-id. 

> An override can change the date/time or zone but that's true for RRULE

OK, so an EXRULE excludes RECURRENCE-ID and RDATE, right?

Cheers,
Robert

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 May 2020 11:42:09 +0200

Hi!

> On 12 May 2020, at 22:44, Michael Douglass <[email-masked]> wrote:
> 
> I believe we should support this and I think it's only a minor change to the spec.
> 
> I didn't agree with the deprecation of EXRULEs - there are a whole bunch of cases that are easily handled - just because UIs choose not to support it isn't that much of an argument.

Before you readd EXRULE or anything like it, it is probably worth understanding why it was removed.  There were several reasons:

Almost nobody (nobody?) in the WG at the time said the they had implemented it.  I believe this is because the UI for EXRULE is not well understood- see below.
Everyone agreed that there was sufficient capability with EXDATE and RRULE.  It wasn’t perfect, but good enough.
There were ambiguities in corner cases regarding DTSTART and the actual recurrence set (I don’t recall the details here- someone might want to check with Bernard, Cyrus, Reinhold, or Jonathan).
We were aiming for a draft standard at the time, and anything not used had to be pulled/deprecated.

To me,  there is a bigger concern: if you readd EXRULE and only some people implement, then you will have inconsistent calendars, and some people will show up to events that aren’t occurring, or worse not attend or schedule events during that time.  And so I would argue that you should have a VERY strong use case and a very strong consensus to do this, and that CalConnect be consulted.

> https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/

This case is handled by EXDATE, albeit not ad infinitum, as RRULE would allow.  And indeed this is how Bernard answered the question back in 2008 when it was asked.  How would you propose the UI be done for the EXRULE case?  I’m not saying that UI is the IETF’s general concern, but there’s no point in adding the function if people can’t reasonably take advantage of it.

> https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month

The example given in StackExchange itself is solved with RRULE as follows.

RRULE:FREQ=MONTHLY;BYDAY=1MO,2MO,3MO,-2MO

That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month.  This creates duplicate recurrences for months with only four Mondays, but RFC 5545 explicitly states that one should delete such duplicates.  I note that Apple doesn’t provide a UI to create this rule, and its display of the rule is a bit… off... but it generates the recurrence set correctly.  Apple’s very minor UI gaffe only serves to reinforce my point about being conservative about adding back capabilities.  It’s hard enough for people to get the existing ones right.

I am not suggesting that you shouldn't add new capabilities, but be careful in doing so.  There really should be good value for real world cases that are not well handled today.  If you really want to go there, let’s see how things work with non-Gregorian calendars where months only recur occasionally ;-)

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 May 2020 12:24:10 +0200

Just to follow up on one point:

>> 
>> And this would be solved
>> 
>> https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month <https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month>
> 
> 
> […]  I note that Apple doesn’t provide a UI to create this rule[…]

And neither does Google but it also handles the recurrence rule correctly when it sees it.

Eliot

---

From: Michael Douglass <[email-masked]>
Date: Sun, 24 May 2020 12:31:33 -0400

On 5/24/20 05:42, Eliot Lear wrote:
> Hi!
>
>> On 12 May 2020, at 22:44, Michael Douglass <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> Before you readd EXRULE or anything like it, it is probably worth 
> understanding why it was removed.  There were several reasons:
>
>  1. Almost nobody (nobody?) in the WG at the time said the they had
>     implemented it.  I believe this is because the UI for EXRULE is
>     not well understood- see below.
>  2. Everyone agreed that there was sufficient capability with EXDATE
>     and RRULE.  It wasn’t perfect, but good enough.
>  3. There were ambiguities in corner cases regarding DTSTART and the
>     actual recurrence set (I don’t recall the details here- someone
>     might want to check with Bernard, Cyrus, Reinhold, or Jonathan).
>  4. We were aiming for a draft standard at the time, and anything not
>     used had to be pulled/deprecated.
>
>
> To me,  there is a bigger concern: if you readd EXRULE and only some 
> people implement, then you will have inconsistent calendars, and some 
> people will show up to events that aren’t occurring, or worse not 
> attend or schedule events during that time.  And so I would argue that 
> you should have a VERY strong use case and a very strong consensus to 
> do this, and that CalConnect be consulted.
>
There are at least 2 aspects to this:

1. Data representation and libraries to handle it

2. How to represent in UIs

On the data representation and handling:

At least some underlying libraries handle multiple rrules and exrules. 
There are many uses for calendar data outside of the corporate meeting 
world - the smart grid for example. If we want standards to be used 
widely they need to be useful.

Then there's the UI implementation.

If we want to make UI's the driver of the standard then we should pretty 
much gut rrule because most don't give you any more than a regularly 
repeating event for a few fixed periods. Your ui might let you enter an 
rrule but do we really expect anything other than a vanishingly small 
number of users to be able to construct a rule?

It is possible to come up with a UI which handles all the complexities 
of recurrence rules - Bedework has one.

My concern is that we confine a data representation to what is perceived 
to be used/useful - additionally the assumption is that the important 
use case is corporate meetings.

> This case is handled by EXDATE, albeit not ad infinitum, as RRULE 
> would allow.  And indeed this is how Bernard answered the question 
> back in 2008 when it was asked.  How would you propose the UI be done 
> for the EXRULE case?  I’m not saying that UI is the IETF’s general 
> concern, but there’s no point in adding the function if people can’t 
> reasonably take advantage of it.
>
>
>>
>> And this would be solved
>>
> That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month. 
>  This creates duplicate recurrences for months with only four Mondays, 
> but RFC 5545 explicitly states that one should delete such duplicates. 
>  I note that Apple doesn’t provide a UI to create this rule, and its 
> display of the rule is a bit… off... but it generates the recurrence 
> set correctly.  Apple’s very minor UI gaffe only serves to reinforce 
> my point about being conservative about adding back capabilities. 
>  It’s hard enough for people to get the existing ones right.

I think this reinforces my point. Or whose UI is going to set the 
standard? Should we remove these capabilities from recurrence rules 
because they are not in a UI?

I would suggest that if we want to provide users with more useful 
recurrence UIs then multiple simple rrules and exrules are probably 
easier to understand - though again not providing the full set of 
possibilities.

>
> I am not suggesting that you shouldn't add new capabilities, but be 
> careful in doing so.  There really should be good value for real world 
> cases that are not well handled today.  If you really want to go 
> there, let’s see how things work with non-Gregorian calendars where 
> months only recur occasionally ;-)
>
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 May 2020 19:31:06 +0200

Hi Doug

To be clear, I am not saying, “Don’t do this.”  The conclusion I draw is that if you do this, before nailing it in the standard you should bake it off to make sure that people can actually use it.  I should have said that in the first message.

Eliot

> On 24 May 2020, at 18:31, Michael Douglass <[email-masked]> wrote:
> 
> 
> 
>>> On 12 May 2020, at 22:44, Michael Douglass <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> At least some underlying libraries handle multiple rrules and exrules. There are many uses for calendar data outside of the corporate meeting world - the smart grid for example. If we want standards to be used widely they need to be useful.
> 
> If we want to make UI's the driver of the standard then we should pretty much gut rrule because most don't give you any more than a regularly repeating event for a few fixed periods. Your ui might let you enter an rrule but do we really expect anything other than a vanishingly small number of users to be able to construct a rule? 
> 
> It is possible to come up with a UI which handles all the complexities of recurrence rules - Bedework has one.
> 
> My concern is that we confine a data representation to what is perceived to be used/useful - additionally the assumption is that the important use case is corporate meetings. 
> 
>> 
>>> 
>>> https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/ <https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/>
>> 
>> 
> I think this reinforces my point. Or whose UI is going to set the standard? Should we remove these capabilities from recurrence rules because they are not in a UI?
> 
> I would suggest that if we want to provide users with more useful recurrence UIs then multiple simple rrules and exrules are probably easier to understand - though again not providing the full set of possibilities.
> 
> 
> 
>>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 May 2020 19:31:52 +0200

I’m sorry- my fingers ran faster than my brain.  I meant Mike of course.

Eliot

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 25 May 2020 13:43:26 -0400

Hi Michael,

--On Tue, 12 May 2020 16:44:49 -0400 Michael Douglass 
<[email-masked]> wrote:

> I didn't agree with the deprecation of EXRULEs - there are a whole bunch of
> cases that are easily handled - just because UIs choose not to support it
> isn't that much of an argument.
>

Before putting EXRULE back in please think carefully about the actual set of 
use cases for recurring exclusions and see if there is a better way to do 
this.

For example, one use case I have: don't have recurring meetings on holidays. 
How would one accomplish that? Well with just EXRULE that means copying a 
set of EXRULEs for every holiday pattern into every recurring event just in 
case they have an instance on a holiday. Clearly that is impractical. What 
other solutions could we come up with? Perhaps we have the idea of an 
"exclusion event" - one specified with an RRULE but marked as forcing an 
exclusion on any recurring or one-off event in the same time slot. Or 
perhaps that could better be done with an availability component (which 
could also then be tied to my regular calendar availability and made to 
auto-decline any invites on holidays). This is definitely a complex 
situation, but maybe there is an elegant solution.

My point here is that I believe there are valid recurring exclusion use 
cases that have never been seriously considered because they would have been 
hard or impossible to do with EXRULEs. So we might be able to do something 
better than EXRULEs for JSCalendar.

-- 
Cyrus Daboo