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

From: Robert Stepanek <[email-masked]>
Date: Thu, 28 Sep 2017 10:43:39 +0200

Hi,

over the last year we have been working on JSCalendar, a JSON-based
representation of calendar data as an alternative to iCalendar
(RFC5545).  We already got extensive feedback from the members of
CalConnect  and individual contributors and we'd very much like to get
the discussion started on our proposal at IETF.

There's an increasing amount of proprietary calendar data formats in the
industry, most of them JSON-based. We believe that a new standardised
calendar data representation that meets the requirements of these
applications would help to reduce interoperability issues while
overcoming iCalendar pitfalls and ambiguities.

The current draft version is located at
https://datatracker.ietf.org/doc/draft-jenkins-jscalendar/

Do you have any feedback on this? What would make you use  the new
format, what is it currently missing?

Thanks for your thoughts,
Robert

P.S.: This message got cross-posted to the CALSIFY workgroup.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 Sep 2017 21:58:19 -0400

> format, what is it currently missing?

Given that any practical implementation has to interoperate with iCal,
the barrier to entry is high.  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?  (Coming from the world of SIP,
I've learned that things that are nightmarish for implementors are often
criticial to real-world use of the protocol) Ease of implementation is
nice, but given the need to interoperate with iCal for many years, it
has limited value.  Also, to what degree does the simplicity of
JSCalendar simply push work back into the interface between the
calendaring system and the JSCalendar interface?

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?

Dale