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

Garry Shutler garry at cronofy.com
Thu Oct 11 01:26:53 PDT 2018


To summarise my read on the two options that seem to be in play:

1. Change SHOULD to MUST - eliminates the undefined behaviour by making it
impossible
2. Define the undefined - allows the current behaviour but defines what
that means based upon the prevailing definitions

My personal preference is for 2 as that's what we've implemented. We
reflect what a user would see on their phone/desktop so our view of
availability matches the persons. For iCalendar events in the undefined
zone this essentially boils down to "what does Calendar.app do?".

For what it's worth, defining the undefined behaviour using SHOULD would
not technically invalidate any implementation, but it would mean there was
a "bless" behaviour people could implement that reflects the prevailing
existing implementations.

-
*Garry Shutler*
CTO & Co-founder, Cronofy
Scheduling Everything for Everyone


On Thu, 11 Oct 2018 at 08:12, Helge Hess <helge.hess at icloud.com> wrote:

> On 11. Oct 2018, at 02:54, Neil Jenkins <neilj at fastmailteam.com> 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.
>
> I really don’t think the idea of a standard is to document bugs in
> software. That DTSTART is an extra RDATE was never ever the intention.
>
> To deal with b0rked software, you already have the User-Agent/PRODID and
> you can switch modes based on that. (IIRR that is already necessary
> necessary to deal with older iCal.app versions.)
>
> As Cyrus says, 5545 clearly states what you as a vendor SHOULD do. And
> that doesn’t say “match the Apple Calendar behaviour” ;-)
>
> hh
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20181011/70f57fb6/attachment-0001.html>


More information about the caldeveloper-l mailing list