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

[Murray Kucherawy via Datatracker <[e-mail]>]

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.