Subject: Re: [dispatch] Feedback requested: draft-jenkins-jscalendar

From: Robert Stepanek <[email-masked]>
Date: Mon, 02 Oct 2017 14:17:37 +0200

On Fri, Sep 29, 2017, at 03:58, Dale R. Worley wrote:
> To what degree is this addressing actual
> failures of iCal (e.g., where iCal is ambiguous) and to what degree is
> it just *simpler* for the implementor? 

Two common pitfalls in iCalendar are embedded, custom timezones as well
as time-span definitions that overlap daylight-savings time boundaries.
JSCalendar addresses this by restricting timezones to the common IANA
timezone definitions and requiring time-spans to be expressed by
durations. In both cases, iCalendar per spec wasn't ambiguous, but in
practice has shown to confuse many implementations about the intent of
the calendar object creator.

> to what degree does the simplicity of
> JSCalendar simply push work back into the interface between the
> calendaring system and the JSCalendar interface?

Moving away from iCalendar format to JSON makes it actually simpler on
both client and server implementations to handle the wire format.
Feature-wise there isn't additional effort due to the data model, it's
very much in line with iCalendar.

> I suspect that in practice, semantic upward-compatibility from iCal will
> be important. 
> You mention in section 1 item 3, "a conversion between
> the data formats is not guaranteed to be completed without losing
> semantic meaning".  What exactly are the incompatibilities?

In Cyrus IMAPd, we store calendar objects in iCalendar format on disk
and serve them in JSCalendar format; compatibility with iCalendar is
important to us. I also know of other vendors who implemented a draft
version of JSCalendar to serve both formats with success. We take the
liberty to be incompatible with iCalendar where it benefits users and
allows richer semantics.

Notable differences are the ability to define multiple owners for an
event (versus a single ORGANIZER in iCalendar), the ability to localize
all text properties (versus a single allowed SUMMARY in iCalendar), the
ability to relate participants with locations and multi-location events
(e.g. a meeting that has participants attending by video, audio and
on-premises vs. a single LOCATION property in iCalendar). Probably we'll
also propose to allow rich-text descriptions similar to HTML email
bodies (versus plain-text only DESCRIPTION in iCalendar), but that's
undecided, yet.

Cheers,
Robert