[calsify] Benjamin Kaduk's No Objection on draft-ietf-calext-jscalendar-31: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-calext-jscalendar-31: 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:
----------------------------------------------------------------------

Section 1.4.8

   Where "TimeZoneId" is given as a data type, it means a "String" that
   is either a time zone name in the IANA Time Zone Database [TZDB] or a
   custom time zone identifier in the "timeZones" property (see
   Section 4.7.2).

(nit?) I'd suggest 'custom time zone identifier defined in the
"timeZones" property'.

Section 4.7.1

   floating time.  This is either a name from the IANA Time Zone
   Database [TZDB] or the id of a custom time zone from the "timeZones"
   property (Section 4.7.2).  If omitted, this MUST be presumed to be

I think we probably want to say "the TimeZoneID of a custom time zone"
here since there seems to only be a colloquial tie between "id" and that
type.

Section 4.7.2

      Maps the TZNAME properties from iCalendar to a JSON set.  The set
      is represented as an object, with the keys being the names
      (excluding any "tznparam" component from iCalendar).  The value
      for each key in the map MUST be true.

I suggest moving the parenthetical to being offset by a comma -- it's a
normative requirement, not an aside.

Section 6.8

It looks like the change in location Id for the virtualLocation entry
was unintentional, since the localizations property contains a patch
object that still references the old Id.  (This would qualify as a
Discuss-level internal inconsistency but I am confident that the right
thing will happen.)

Section 7

   behavior within a known time window.  It's transmission and storage

nit: s/It's/Its/