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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 24 Sep 2020 02:00:22 -0700

Murray Kucherawy 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:
----------------------------------------------------------------------

I'm late on my reviews this week, and my colleagues have been mighty thorough,
so I'll be blissfully brief.

To assuage some of the IESG's concerns about iCalendar and jCal, could we maybe
include one of those Implementation Status sections?

Nice job on the IANA section here.

[For the IESG] How common is it to have a working group be the point of contact
for a new registry?  What do we normally do if such a working group were to
close?  I scanned RFC 8126 (rather quickly, I admit) and didn't see any
guidance in there about this.

In Section 4.1.4, there's "SHOULD ensure that this is a globally unique
identifier".  Why might an implementation choose not to do so (which SHOULD
allows)?

All of the SHOULDs in 4.5.2 have me asking the same sort of thing: When would
one not do this?   One way out here is to just drop the SHOULDs and say
something like:

CURRENT:

The Relation object SHOULD set the "parent" relation type.

NEW:

The Relation object sets the "parent" relation type.

---

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

Hi Murray,

Thanks for the extra comments.

> identifier".  Why might an implementation choose not to do so (which SHOULD

Good question. I've changed this to a MUST.

> All of the SHOULDs in 4.5.2 have me asking the same sort of thing: When would one not do this?

I have changed several of these to MUST or dropped it altogether. I have left the SHOULDs for when to trigger/dismiss alerts; in theory you may have a context where you would like notifications to be indepenent of your other devices so not dismissed automatically.

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

Cheers,
Neil.