Subject: [calsify] Warren Kumari's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 23 Sep 2020 06:29:24 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-calext-jscalendar-30: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for writing this document -- as someone who has written (horrible!)
code to try and generate and parse iCalendar data, this seem like a very useful
effort. Like Eric I'm concerned about the https://xkcd.com/927/  effect, but I
also feel that this standard might be more usable than the existing one(s). I
suspect that it is much too early to think about Obsoleting jCal (although I
must admit I've never run into jCal, so I have no idea if it is actually being
used).

I think that it would be useful to have some more discussions around why / when
PatchObjects should be used - they seem to add significant complexity to the
design, and I'm really not convinced that the complexity outweighs the benefit;
I'm guessing that I'm simply not fully understanding their utility. More
examples would probably help...

Thanks again!
W

---

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

Hi Warren,

> I'm guessing that I'm simply not fully understanding their utility. 

There are two primary benefits:
 1. Significantly reducing file size and duplicated content. For example, if one person is not going to a particular instance of a regularly scheduled event, in iCalendar you would have to duplicate the entire event in the override. In JSCalendar this is a small patch to show the difference.
 2. Better preservation of semantic intent: if a user changes the time of a single occurrence in an event series, only this property is overridden so if you change (for example) the location of the master event, the occurrence will automatically still inherit this.
Cheers,
Neil.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Sep 2020 10:02:00 -0400

Indeed, and I would have found this sort of thing to be useful in many
cases.  Of particular importance is being able to change the
subject/summary for myself, or to add a relevant URI, while still
being able to get event updates such as time/date changes, agendas
added to the description, and such.  At IBM I would frequently get on
some VP's calendar with a meeting invitation that said "Meet with
Barry", which wasn't very useful for me.  But if I made my own copy
that said "Meet with Jane the VP", when it inevitably got rescheduled
because something more important came up for Jane, it would all be a
mess.

In any case, Neil, I think Warren is less interested in your
explaining it to *him* and more interested in seeing some sort of
explanation in the document.  I agree that it would be useful to have
something in the document.

Barry

On Tue, Sep 29, 2020 at 11:46 PM Neil Jenkins <[email-masked]> wrote:
> Significantly reducing file size and duplicated content. For example, if one person is not going to a particular instance of a regularly scheduled event, in iCalendar you would have to duplicate the entire event in the override. In JSCalendar this is a small patch to show the difference.
> Better preservation of semantic intent: if a user changes the time of a single occurrence in an event series, only this property is overridden so if you change (for example) the location of the master event, the occurrence will automatically still inherit this.
>
> Cheers,
> Neil.