[caldeveloper-l] DTSTART that doesn't match RRULE pattern

Thu Oct 11 12:17:12 PDT 2018

Hi,

for discussion, let's define "DTSTART that doesn't match the RRULE
pattern" as "DTSTART-X".

Ken basically proposed the following options:

Option 1: If DTSTART does not match the RRULE, treat it as an instance
but do not count it
Option 2: If DTSTART does not match the RRULE, treat it as an instance
and count it
Option 3: If DTSTART does not match the RRULE, do not treat it as an
instance and hence do not count it

* Out of those, Ken personally favored Option 3
* According to Neil, Apple Calendar (and FastMail) implement Option 2
(see also my separate mail seeking clarification with Neil)

Cyrus basically said: we should disallow that DTSTART does not match the
RRULE by changing to:
'The "DTSTART" property value MUST match the pattern of the recurrence
rule, if specified.'

..which would then yield:

Option 4: DTSTART MUST match RRULE; else undefined (aka invalid iCalendar?)

(Did I get that right? - and if so, what would Option 4 mean for already
existing calendar data in violation of it?)

Regarding the RFC (5545) text, I see three relevant paragraphs:

(P1)  The COUNT rule part defines the number of occurrences at which to
      range-bound the recurrence.  The "DTSTART" property value always
      counts as the first occurrence.

      https://tools.ietf.org/html/rfc5545#section-3.3.10

(P2)  The "DTSTART" property for a "VEVENT" specifies the inclusive
      start of the event.  For recurring events, it also specifies the
      very first instance in the recurrence set.

      https://tools.ietf.org/html/rfc5545#section-3.6.1

(P3) The "DTSTART" property defines the first instance in the recurrence
set.
     The "DTSTART" property value SHOULD be synchronized with the
recurrence rule, if
     specified. The recurrence set generated with a "DTSTART" property
     value not synchronized with the recurrence rule is undefined.

     https://tools.ietf.org/html/rfc5545#section-3.8.5.1
     (This paragraph is actually repeated three times in the RFC -
     section 3.8.5.1. till 3.8.5.3)

In my interpretation, this would boil down to:
* "Option 2" is supported by P1, P2 and P3
* P3 additionally suggest that the case DTSTART-X is undefined (=> hence
invalid iCalendar?)
* One might however argue that P1 and P2 imply that DTSTART *might* be
out of sync with RRULE (i.e., allow DSTART-X), since otherwise stressing
DTSTART is an occurrence would be superfluous (?)

To make things even more complicated, I would assume that many existing
systems use "Option 3" from above (Based on personal experience; I might
look this up somewhere in our test cases or ticket system).

Leaving aside my RFC reflections from above, my personal gut feeling
would opt for "Option 3".

Repeating my corresponding arguments from the Karlsruhe meeting in favor
of Option 3:

A1) Perhaps least error-prone: It seems the most easy way to implement
(e.g., concerning count)
A2) Many implementations might struggle with adapting DTSTART on
changing recurrence days later on (see also extra note below)
A3) Assumed user intent in UIs: Users might click anywhere in the
calendar to launch edit screen (e.g., Monday) in order to create a
recurrence (i.e., every Wednesday) without necessarily indenting to make
Monday an occurrence
A4) Symmetry with "UNTIL" behavior: allow to modify recurrence within
bounded time frame (i.e., "team meeting every TUE until 31st of
December" => will adapt if changed to WED and WED is 31st of December)

Note that (A2) offers a particular semantic challenge, as, under "Option
4", it would require two choices in the aftermath of a change (i.e.,
modifying a recurrence later on):
* In which direct to adapt DTSTART to modified RRULE (forward or backward?)
* If to introduce RDATE for prior DTSTART value
...which feels like some heavyweight user interaction for a certainly
not unusual change case...

If I got all of this correctly, my current summary of things would be:

* There's a sound and clean desired state proposed (Option 4)
* There exist implementations that can considered valid under current
RFC, but would be undefined under Option 4 (= Option 2)
* There are likely to be implementations that can be considered invalid
under both, current RFC and Option 4 (= Option 3)
* For reasons laid out before, Option 3 - imho - would be perhaps the
most natural and least error prone

So honestly, I am a little lost on what to do best, as the current
situation in the wild seems to be tricky already...

Best,
Hans-Joerg

On 11.10.2018 02:54, Neil Jenkins wrote:
> On Thu, 11 Oct 2018, at 6:46 AM, Cyrus Daboo wrote:
>> The intent of that was to effectively deprecate the behavior of
>> DTSTART not 
>> matching the pattern (without making it outright illegal by using a
>> MUST), 
>> with the idea that a future update to 5545 would switch to MUST.
>
> That's lovely in theory, but in practice there are still many clients
> that allow you to create such events. Apple Calendar, to take one
> example. While we can (and do in the FastMail UI) enforce that events
> /we/ create have recurrence rules that match their DTSTART, we still
> have to handle events created in other clients, so for compatibility
> between different clients and calendar systems I think we should
> specify it rather than leave it undefined. The most sensible thing
> would be to choose the behaviour that's currently most prevalent and
> standardise on that.
>
> The FastMail UI currently matches the Apple Calendar behaviour (for
> compatibility with this): the DTSTART is always counted as the first
> occurrence, even if it doesn't match the rule.
>
> Neil.
>
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org

-- 
audriga GmbH
Durlacher Allee 47
76131 Karlsruhe, Germany
Tel: +49 (0) 721 17029 316
Fax: +49 (0) 721 17029 3179

www.twitter.com/audriga
www.audriga.com

Handelsregister: Amtsgericht Mannheim - HRB 713034
Sitz der Gesellschaft: Karlsruhe
Geschäftsführer: Dr. Frank Dengler, Hans-Jörg Happel
USt-ID: DE 279724142

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20181011/f5c19df5/attachment-0001.html>