Re: [calsify] Updated JSCalendar draft version 07

["Neil Jenkins" <[e-mail]>]

On Thu, 20 Sep 2018, at 7:55 PM, Robert Stepanek wrote: 
> *Main changes*  
>  * Replaced the `web` replyTo property with `other`. The iCalendar spec allows arbitrary CAL-ADDRESS values for attendees and organizer. While running our implementation of the latest JSCalendar spec draft on production data, we ran into such calendar objects. JSCalendar needs to be able to handle these non-mailto, non-HTTPs URIs. 
>  * The `email` property of the Participant object became optional (for the same reasons as the previous bullet point).  
 
That's fine.
 
>  * The id of a Participant object in the `participants` property now must be a valid URI. 
 
I don't like this because it's different to how these kind of set-of-items properties (e.g. locations, alerts) work in two imporant ways: 
 * It means the id has semantic value. 
 * It means the id has different allowed character restrictions compared to these other objects. 
 
I suggest that instead we add a new `sendTo` property on the participant object, with a value in the same format as the `replyTo` JSEvent property. This has a number of advantages: 
 * The ids for the participants can have the same restrictions as elsewhere and, like elsewhere do not have semantic meaning. 
 * The email property (for contacting the person) can be defined separated from the imip-email (for sending updates to the event). In the future, you could create an event that sends an iMIP message to the user's email. The RSVP however could update the `sendTo` property to either give a different email, or even add a separate protocol option (like `replyTo` it can include multiple options, so the organiser can then choose whichever they support). This allows you to then potentially bypass email for future updates (which is nice because most systems avoid sending iMIP updates for attendee status changes to avoid flooding the user's inbox, but if the organiser knew it was directly updating the calendar they could send all the updates and keep everyone in sync). 
 
>  * The `replyTo` URI Template replaced the `email` variable with a `participantId` variable. The allowed level for the URI template now is 2 (instead of previously 1) to support URI-encoding of the participant id. 
 
This can then be level 1 again (so only simpler substitution required) with the above change.
  
> *Open points* 
>  * The current spec requires durations to be calculated in UTC. The iCalendar specification requires durations to be calculated in the calendar object time-zone. No consensus has been found on the mailing list, yet. I suggest to redefine durations to be calculated in the event time-zone.  
 
Yes, I think this is probably the best way forward, if nothing else for iCalendar compatibility. It also gives more flexibility, in that a client can define an event as 24h duration to ignore DST shifts, or 1 day if they really want to include them. (All day events are always in floating time, so this makes no difference to them of course). 
 
Neil.