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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 18 Sep 2020 01:32:39 -0700

Éric Vyncke 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 the work put into this document.

To be honest, after reading the abstract, https://xkcd.com/927/ sprang to my
mind (even after being relieved by the explanations of section 1.1)... Let's
hope that more tools/applications will use this new standard.

Please find below a couple of non-blocking COMMENTs and blocking DISCUSS points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.3  --
Is the wording 'type signature' well accepted in the JSON world ? I would have
expected something like 'type description' 'type grammar'.

-- Section 1.48 --
As I find the 'patchObject' an interesting concept, I wonder whether it should
not also be specified in another document ? (if not yet done of course, then I
wonder why it is defined in this document)

-- Section 4.3 --
Just to write that this section about recurrence was well thought ;-)

-- Section 4.2.2 --
"This MUST be one of the following values, a value registered in the IANA
JSCalendar Enum Registry, or a vendor-specific value:" I find it slightly
confusing as the listed value (free/busy) are also part of the IANA table 5
later in the document. Suggest to use "This MUST be one of the value registered
in the IANA JSCalendar Enum Registry (like the two listed below) or a
vendor-specific value:"

Same applies also to section 4.4.3 and other places (such as 'roles').

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Sep 2020 15:29:07 -0400

Hi, Éric,

> hope that more tools/applications will use this new standard.

:-)

Indeed, we do hope so.

Really, the whole JMAP set of standards is more of an evolution of the
earlier standards into JSON than it is a set of "new" standards.
There are aspects of each piece that are actually new, but it's mostly
that we can use common JSON code for mail, calendar, and contacts,
rather than having IMAP for mail and iCalendar for calendar and vCard
for contacts.  And we do hope that will help, as these three are
generally integrated into common clients.

> Please find below a couple of non-blocking COMMENTs and blocking DISCUSS points.

Just checking here, because you mention DISCUSS but have not balloted
DISCUSS.  Was that a paste-o, or did you mean to include a DISCUSS
ballot that didn't get through?

Barry

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 18 Sep 2020 20:08:14 +0000

Beside the xkcd :-), I would like to apologize for the cut&paste from my 'ballot template'... There is nothing to be discussed IMHO for this document beside my non-blocking comments.

-éric

-----Original Message-----
From: Barry Leiba <[email-masked]>
Date: Friday, 18 September 2020 at 21:29
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, Daniel Migault <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT)

    Hi, Éric,

    :-)

    Indeed, we do hope so.

    Barry

---

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

Hi Éric,

Thanks for your review.

> expected something like 'type description' 'type grammar'.

It's the grammar with which type signatures (or type annotations) are specified. We used the same terminology in the JMAP RFCs (8620 <https://tools.ietf.org/html/rfc8620>/8621 <https://tools.ietf.org/html/rfc8621>) and I haven't heard of anyone being confused by it, so I'm inclined to leave as is.

> not also be specified in another document?

Perhaps, but there are advantages to keeping the specification self contained too, and it's a relatively small definition.

> Just to write that this section about recurrence was well thought ;-)

Thanks!

> in the IANA JSCalendar Enum Registry (like the two listed below) or a

I've changed these from “This MUST be one of the following values, a value registered in the IANA…” to “This MUST be one of the following values, *another* value registered in the IANA…”

I have published a revised draft <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-31> incorporating the IESG feedback.

Cheers,
Neil.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 30 Sep 2020 06:07:38 +0000

Thank you Neil for addressing or replying to all my comments.

Regards

-éric

From: Neil Jenkins <[email-masked]>
Date: Wednesday, 30 September 2020 at 05:35
To: Eric Vyncke <[email-masked]>, iesg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Daniel Migault <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT)

Hi Éric,

Thanks for your review.

-- Section 1.3  --

It's the grammar with which type signatures (or type annotations) are specified. We used the same terminology in the JMAP RFCs (8620<https://tools.ietf.org/html/rfc8620>/8621<https://tools.ietf.org/html/rfc8621>) and I haven't heard of anyone being confused by it, so I'm inclined to leave as is.

-- Section 1.48 --

-- Section 4.3 --

Thanks!

-- Section 4.2.2 --

I've changed these from “This MUST be one of the following values, a value registered in the IANA…” to “This MUST be one of the following values, another value registered in the IANA…”

I have published a revised draft<https://tools.ietf.org/html/draft-ietf-calext-jscalendar-31> incorporating the IESG feedback.

Cheers,
Neil.