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

[Helge Hess]

On Oct 12, 2018, at 12:33 AM, Neil Jenkins <neilj at fastmailteam.com> wrote:
> On Thu, 11 Oct 2018, at 6:12 PM, Helge Hess wrote:
>> I really don’t think the idea of a standard is to document bugs in software.
> 
> No. It's to ensure that different implementations are compatible with each other. Undefined behaviour leads to incompatibility, therefore it is a problem with the spec.

It is not *undefined*. It explicitly specifies the intended behavior everyone should follow. That is the issue with the MUST, it doesn’t really change anything, you will still have clients send you something wrong and the implementor has to deal with the crap.


>> The conclusion is wrong. If a server sees an entity which doesn’t match the spec he can either by picky and reject it straight away, OR, rewrite the item to match the spec.
> 
> Meanwhile, in the real world if one of our customers receives an iMIP invitation with a DTSTART that doesn't match the RRULE, we can:
> 	• Reject it: customer complains that our system is broken because it's not accepting showing/accepting invitations; or
> 	• Rewrite it: customer complains that our system is broken because it does not show the event on the same days the organiser sees it on.
> 	• Accept it and interpret it as best we can.
> Which one do you think we're going to do?

In the real world you detect that the invitation was sent by a b0rked client (PRODID) and rewrite it to the expected behavior for the RFC you want to support. If the DTSTART doesn’t match, that presumably means adjusting the DTSTART and adding an RDATE for the extra event.
(It is work, but you have to do this anyways as there are always bugs and legacy clients.)

And yes, it is better if the people 20 years ago would have specified those things more clearly, but it is a complicated matter and hard to get right from the start.

I also warn against the “real world” argument, that is just going nowhere. It is precisely the reason to have standards and specifically not a moving target. The “real world” changes with every macOS release (not anymore because it seems no one cares anymore, but it used to).


> Calendar agents MUST NOT create events with an RRULE that does not match the DTSTART. If it receives such an event, the DTSTART MUST be interpreted as the first instance of the rule expansion, and included in any COUNT.

This is not a bad wording, but I would rather propose the thing above. The goal being to adjust the entity to the standard, not the other way around.

hh