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

From: Tim Hare <[email-masked]>
Date: Thu, 2 Nov 2017 00:22:07 -0400

It literally took years to get RFC5545 to the interoperability state 
that it is in now.  I hope, for the sake of interoperability, that you 
are able to further reduce those "pitfalls and ambiguities" - and if you 
do, the PLEASE back-port them to RFC5545.  Not all calendar software 
necessarily needs to read and write JSON .  The "plain text"-based 
RFC5545 has its place as well.

Tim Hare
Interested Bystander, Non-Inc.

On 9/28/2017 4:43 AM, Robert Stepanek wrote:
> 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 DISPATCH workgroup.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 15 Nov 2017 15:02:59 +0800

Hi Tim,

A good example of a "pitfall and ambiguity" in RFC5545 is that events
can contain either a DURATION or a DTEND.  If the event is recurring,
the definition is that the DTEND of each recurrence is calculated by
adding the duration from the master event to the DTSTART of the
recurrence.
This can be ambiguous if the master event starts or ends within a
daylight savings crossover - where the DURATION of the event is
ambiguous based on the DTSTART and DTEND values.  If both DURATION and
DTEND are specified, that is an error - which means semantic cross-key
checking is required to see if a VEVENT  is valid.
In jscalendar there is only duration.  If you need to represent a
different timezone for the end, there's a way to do it, but it means we
don't need to support the DTEND variant just to give somewhere to hang
the end timezone.
Backporting this to RFC5545 would not be possible without completely
replacing 5545, since not allowing DTEND is a big change.
Also, DURATION must be positive in RFC5455 - but if you don't give a
DURATION or a DTEND you create an event with zero length.  In
jscalendar, you can create an event with zero duration and it's
specified how to represent that.

Many of the other parts of jscalendar have been created in cooperation
with efforts to extend 5545 so that the models are compatible.

Regards,

Bron.

On Thu, 2 Nov 2017, at 12:22, Tim Hare wrote:
> that it is in now.  I hope, for the sake of interoperability, that you> are able to further reduce those "pitfalls and ambiguities" -
> and if you> do, the PLEASE back-port them to RFC5545.  Not all calendar software
>> 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
>> _________________________________________________
>> calsify mailing list
>> [email-masked]
> _________________________________________________
> calsify mailing list
> [email-masked]

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]