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

[Neil Jenkins]

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. 
 
> 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: 
 1. Reject it: customer complains that our system is broken because it's not accepting showing/accepting invitations; or 
 2. 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. 
 3. Accept it and interpret it as best we can. 
Which one do you think we're going to do? 
 
On Fri, 12 Oct 2018, at 6:16 AM, Hans-Joerg Happel wrote: 
> Just for clarification: By stating that Apple Calendar allows to create such events, (a) the latter refers to events, in which DTSTART is not part of the RRULE. And by describing the Apple Calendar behavior in that case, you say (b) that it will, in such cases, show DTSTART as an instance and also count it. Did I get that correct? 
 
Yes. To be clear again, we never generate events like this at FastMail; our UI is designed to ensure users can only add RRULEs that match the DTSTART. But given that other systems do allow these to be generated, and we have to be able to display these in our calendar, we need to pick a method of interpreting them. Specifying how this should be interpreted is, in my opinion, less likely to lead to incompatibilities between systems. 
 
In the spirit of be strict in what you generate and lax in what you accept, I would suggest something like the following for the spec: 
 
*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.* 
 
Neil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20181011/a1e1a346/attachment.html>