Subject: [calsify] Issues with overrides.

From: Michael Douglass <[email-masked]>
Date: Wed, 23 Sep 2020 22:35:53 -0400

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:[email-masked]
ATTENDEE;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[email-masked]
CREATED:20200823T221135Z
DURATION:PT1H
DTSTAMP:20200902T024957Z
DTSTART;TZID=America/New_York:20200524T120000
LAST-MODIFIED:20200902T024957Z
ORGANIZER:mailto:[email-masked]
SUMMARY:Test rid + tzid
UID:6252D6C40A8308BFE25CCDFiinvite-1
END:VEVENT
BEGIN:VEVENT
RECURRENCE-ID;TZID=Europe/London:20200525T170000
ATTENDEE;RSVP=TRUE:mailto:[email-masked]
ATTENDEE;RSVP=TRUE;SCHEDULE-STATUS=1.2:mailto:[email-masked]
CREATED:20200823T221135Z
DURATION:PT1H
DTSTAMP:20200902T024957Z
DTSTART;TZID=Europe/London:20200525T100000
LAST-MODIFIED:20200902T024957Z
ORGANIZER:mailto:[email-masked]
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:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "d946d07d-393f-46eb-8b49-9bbbef13f78a": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "replyTo": {
         "imip": "mailto:[email-masked]"
       },
       "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:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "184e6cf2-8288-4b46-812f-e111d773dd65": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "start": "2020-05-25T10:00:00",
       "timeZone": "Europe/London",
       "replyTo": {
         "imip": "mailto:[email-masked]"
       },
       "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:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "d946d07d-393f-46eb-8b49-9bbbef13f78a": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "replyTo": {
         "imip": "mailto:[email-masked]"
       },
       "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:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true,
             "owner": true
           }
         },
         "184e6cf2-8288-4b46-812f-e111d773dd65": {
           "@type": "Participant",
           "sendTo": {
             "imip": "mailto:[email-masked]"
           },
           "expectReply": true,
           "roles": {
             "attendee": true
           }
         }
       },
       "start": {
          “value” :"2020-05-25T10:00:00",
          “timeZone": "Europe/London"
       },
       "replyTo": {
         "imip": "mailto:[email-masked]"
       },
       "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.

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 30 Sep 2020 13:25:20 +1000

I will copy my stance on this from when Michael and I discussed this privately:

I'm going to presume you sent out an iMIP with both JSCalendar and iCalendar versions (because you don't know what the recipient supports). Here are the scenarios:
 1. The recipient doesn't understand JSCalendar. No problem.
 2. The recipient receives JSCalendar and response with JSCalendar. No problem.
 3. The recipient receives the iCalendar and responds with JSCalendar. OK, a bit weird, but the no problem.
 4. The recipient receives the iCalendar, stores it as JSCalendar then responds with iCalendar. No problem, it can store the recurrence id time zone as a custom property if it likes (and we can define in the JSCalendar-iCalendar translation document exactly how this should be done for interoperability).
 5. The recipient receives the JSCalendar and responds with iCalendar. Again, a bit weird that it would do this, but the client can just use the time zone from the event for the recurrence id in iCalendar (or even omit the time zone) and the server can ignore the time zone on the recurrence id when finding the recurrence on the server (because it MUST be in the master event time zone). This requires a small change on the scheduling server, but if it's going to implement JSCalendar then this is a tiny change in comparison, and likely to increase compatibility in general regardless of JSCalendar.
> 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.

No. The whole point of JSCalendar's construction is to, wherever possible, make it syntactically impossible to produce nonsense such as a recurrence id in a different time zone to the master time zone. I believe changing this would be a significant regression against the goal of making it hard to misuse.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Wed, 30 Sep 2020 23:41:05 -0400

On 9/29/20 23:25, Neil Jenkins wrote:
> I'm going to presume you sent out an iMIP with both JSCalendar and 
> iCalendar versions (because you don't know what the recipient 
> supports). Here are the scenarios:
>
>  4. The recipient receives the iCalendar, stores it as JSCalendar then
>     responds with iCalendar. No problem, it can store the recurrence
>     id time zone as a custom property if it likes (and we can define
>     in the JSCalendar-iCalendar translation document exactly how this
>     should be done for interoperability).
>  5. The recipient receives the JSCalendar and responds with iCalendar.
>     Again, a bit weird that it would do this, but the client can just
>     use the time zone from the event for the recurrence id in
>     iCalendar (or even omit the time zone) and the server can ignore
>     the time zone on the recurrence id when finding the recurrence on
>     the server (because it MUST be in the master event time zone).
>     This requires a small change on the scheduling server, but if it's
>     going to implement JSCalendar then this is a tiny change in
>     comparison, and likely to increase compatibility in general
>     regardless of JSCalendar.
>
Receiving jscalendar and responding in iCalendar is not all that weird. 
I'd have to add extra information to determine what format I received 
and my server may receive jscalendar from a well intentioned user agent 
as in this scenario.

I use thunderbird but not for calendars. I use iCal for that. When I 
receive an imip message it's passed to iCal. The only way we can 
guarantee that will work at the moment is for thunderbird to use 
iCalendar throughout which makes it a bit pointless developing 
jscalendar support.

I'd like to see us move rapidly to implement jscalendar but it all needs 
to work in the meantime.

The current situation is that we have server and library implementations 
built around an iCalendar view of the world. That's not going to change 
all that quickly as you're trying to force a data model change on us.

>> timezone with the start date and have a recurrence property of the 
>> same form.
>
> No. The whole point of JSCalendar's construction is to, wherever 
> possible, make it syntactically impossible to produce nonsense such as 
> a recurrence id in a different time zone to the master time zone. I 
> believe changing this would be a significant regression against the 
> goal of making it hard to misuse.

Not having access to the master time zone more or less guarantees that 
an iCalendar response will be incorrect.

To at least resolve this issue without forcing a rewrite of all the 
libraries and servers we only need a small change to jsCalendar.

The recurrenceId property is only required when an instance is sent 
without the master. If that property includes the timezone we are back 
to having full interoperability

>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify