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

[Michael Douglass]

I've got to say I agree with Helge (!) and Cyrus

SHOULD should raise alarms every time. It's often an open invitation to 
chaos.

Fix the spec to say exactly what we MUST do and then do the inevitable 
and implement clients and servers that handle all the data created by 
implementors who got it wrong (which is often one or more of us).

That is the kind of thing we document in a best practices document or 
the devguide.

(by the way: the spelling correction offered "tormentors" for 
"implementors")


On 10/11/18 15:30, Helge Hess wrote:
> On 11. Oct 2018, at 21:17, Hans-Joerg Happel <happel at audriga.com> wrote:
>> * According to Neil, Apple Calendar (and FastMail) implement Option 2 (see also my separate mail seeking clarification with Neil)
> The thing to keep in mind is that Apple Calendar does not *intentionally* implement Option 2. It is a bug which needs to be fixed, and I’m sure everyone filed a Radar already (https://radar.apple.com/).
>
>> 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.’
> I agree that this is the only thing which makes sense from standards perspective and should be done.
>
> But the other point is that the RFC already says that clients SHOULD have this behaviour, so current clients SHOULD in no case generate such (and adjust faulty payloads).
>
>> ..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?)
> 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. The latter is very common in the CalDAV space anyways. There are very few clients which support the _whole_ iCalendar spec.
>
> hh
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org