[calsify] Issues with overrides.

[Michael Douglass <[e-mail]>]

Earlier (8/23) I sent a message outlining an issue I felt we had with 
jscalendar and invites to specific instances of a recurring event.

The full text of a modified form of that is below.

Neil asserted at that time that recurrence ids are only ids and not 
dates. That's not true. CalDAV for one requires that any instance that 
appears or would have appeared in a date range must be returned. It's 
the recurrence id that provides the calculated start date.

The issue is that there's no way of knowing what the timezone of the 
master is if you don't have a master. In iCalendar the tzid is 
associated with the recurrence id - not so in jscalendar.

I ran into this trying to implement the conversion from jscalendar to 
iCalendar in bedework and at the moment have no idea how that can be 
achieved.

If we are going to have widespread adoption of jscalendar we can't be 
making it difficult to convert from one to the other and scheduling has 
to carry on working.

More worrying to me is that there has been no testing and I suspect we 
only have 2-3 implementations. It's quite possible to have a scenario in 
which one UA receives the invite as jscalendar (Thunderbird) passes it 
across to the calendar app (iCal) as iCalendar which then replies in 
iCalendar. In that scenario the recurrence ids would fail to match.


The event starts life inside a calendar system as a recurring event with 
2 overrides - each inviting people and one with timezones shifted. The 
scenario I had in mind is a recurring meeting in New York say, and one 
instance takes place in London and extra people are invited. It’s not 
far fetched and very easy to produce with iCal or thunderbird. For the 
purposes of the example I reduced it to a daily event but I could 
imagine this as a weekly/monthly meeting with the occasional meeting in 
London with extra attendees.

This is what it looks like - sort of.

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Bedework//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20200902T024956Z
DURATION:PT1H
DTSTAMP:20200902T024957Z
DTSTART;TZID=America/New_York:20200522T120000
LAST-MODIFIED:20200902T024957Z
SUMMARY:recurring daily 8 times
UID:6252D6C40A8308BFE25CCDFiinvite-1
RRULE:FREQ=DAILY;COUNT=8
END:VEVENT
BEGIN:VEVENT
RECURRENCE-ID;TZID=America/New_York:20200524T120000
ATTENDEE;RSVP=TRUE:mailto:[e-mail]
ATTENDEE;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[e-mail]
CREATED:20200823T221135Z
DURATION:PT1H
DTSTAMP:20200902T024957Z
DTSTART;TZID=America/New_York:20200524T120000
LAST-MODIFIED:20200902T024957Z
ORGANIZER:mailto:[e-mail]
SUMMARY:Test rid + tzid
UID:6252D6C40A8308BFE25CCDFiinvite-1
END:VEVENT
BEGIN:VEVENT
RECURRENCE-ID;TZID=Europe/London:20200525T170000
ATTENDEE;RSVP=TRUE:mailto:[e-mail]
ATTENDEE;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[e-mail]
CREATED:20200823T221135Z
DURATION:PT1H
DTSTAMP:20200902T024957Z
DTSTART;TZID=Europe/London:20200525T100000
LAST-MODIFIED:20200902T024957Z
ORGANIZER:mailto:[e-mail]
SUMMARY:Test rid + tzid
UID:6252D6C40A8308BFE25CCDFiinvite-1
END:VEVENT
END:VCALENDAR

The 2 overrides are sent out to the attendees. Let’s assume the 
recipient “vbede” can accept jscalendar. I converted the iCalendar to 
jscalendar using bedework and came up with this:

{
   "@type": "jsgroup",
   "prodId": "//Bedework.org//BedeWork V3.13.2//EN",
   "entries": [
     {
       "@type": "jsevent",
       "created": "2020-09-02T02:49:58Z",
       "timeZone": "America/New_York",
       "duration": "PT1H",
       "uid": "6252D6C40A8308BFE25CCDFiinvite-1",
       "start": "2020-05-24T12:00:00",
       "recurrenceId": "2020-05-24T12:00:00",
       "participants": {
         "b1a9dca5-8a60-42e2-ba17-d983bdf3a68d": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "d946d07d-393f-46eb-8b49-9bbbef13f78a": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "replyTo": {
         "imip": "mailto:[e-mail]"
       },
       "title": "Test rid + tzid",
       "freeBusyStatus": "free"
     },
     {
       "@type": "jsevent",
       "created": "2020-09-02T02:49:58Z",
       "duration": "PT1H",
       "uid": "6252D6C40A8308BFE25CCDFiinvite-1",
       "recurrenceId": "2020-05-25T12:00:00",
       "participants": {
         "9a4252d0-b1e5-4a37-bdf5-05e17d7898f9": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "184e6cf2-8288-4b46-812f-e111d773dd65": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "start": "2020-05-25T10:00:00",
       "timeZone": "Europe/London",
       "replyTo": {
         "imip": "mailto:[e-mail]"
       },
       "title": "Test rid + tzid",
       "freeBusyStatus": "free"
     }
   ]
}

The problem here is there’s no tz to associate with the recurrence id so 
we can convert back to valid calendar

This is a problem because if I try to reply with an iCalendar object I 
can’t guarantee that the recurrence id is correct.

So where do I get the TZID from?

Suggesting we add these as vendor properties to deal with this is really 
not good enough. There are easier and more robust ways to fix this.

The easiest way to resolve all these problems is to reassociate the 
timezone with the start date and have a recurrence property of the same 
form. That would fix these issues without vendors being asked to jump 
through hoops just to achieve interoperability.

I think this is a more robust model anyway - the current jscalendar has 
this implicit relationship between the recurrence and the timezone of 
the master. Make it explicit and we’re done.

It’s also more in line with date/time libraries which associate the 
value and the timezone. It means I can manipulate the start date in a 
more natural manner - obtain the UTC time etc.

WIth this we would have the event looking like:

{
   "@type": "jsgroup",
   "prodId": "//Bedework.org//BedeWork V3.13.2//EN",
   "entries": [
     {
       "@type": "jsevent",
       "created": "2020-09-02T02:49:58Z",
      "duration": "PT1H",
       "uid": "6252D6C40A8308BFE25CCDFiinvite-1",
       "start": {
          “value” :“2020-05-24T12:00:00”,
          "timeZone": “America/New_York"
       },
       "recurrenceId": {
          “value” :"2020-05-24T12:00:00",
          "timeZone": “America/New_York"
       },
       "participants": {
         "b1a9dca5-8a60-42e2-ba17-d983bdf3a68d": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "d946d07d-393f-46eb-8b49-9bbbef13f78a": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "replyTo": {
         "imip": "mailto:[e-mail]"
       },
       "title": "Test rid + tzid",
       "freeBusyStatus": "free"
     },
     {
       "@type": "jsevent",
       "created": "2020-09-02T02:49:58Z",
       "duration": "PT1H",
       "uid": "6252D6C40A8308BFE25CCDFiinvite-1",
       "recurrenceId": {
          “value” :"2020-05-25T12:00:00",
          "timeZone": “America/New_York"
       },
       "participants": {
         "9a4252d0-b1e5-4a37-bdf5-05e17d7898f9": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "184e6cf2-8288-4b46-812f-e111d773dd65": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[e-mail]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "start": {
          “value” :"2020-05-25T10:00:00",
          “timeZone": "Europe/London"
       },
       "replyTo": {
         "imip": "mailto:[e-mail]"
       },
       "title": "Test rid + tzid",
       "freeBusyStatus": "free"
     }
   ]
}

which I don’t think is so terrible.

We can argue that iCalendar should have had some different 
representation or should have dropped the timezone like jscalendar but 
it didn’t.

Now we have systems that process these values in an iCalendar centric 
manner and they aren’t going away soon.

We should also make a real effort to involve other vendors in this and 
do some real testing - particularly for scheduling. That testing MUST 
involve a mix of iCalendar and jscalendar otherwise it’s simply not a 
real world scenario.