[calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-jscalendar-30: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 22 September 2020 19:31 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C353A0B52; Tue, 22 Sep 2020 12:31:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, daniel.migaultf@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160080310052.2067.3909191521071518854@ietfa.amsl.com>
Date: Tue, 22 Sep 2020 12:31:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/l1JG3rUrn5-xSXt36nflSJ6F5PE>
Subject: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-jscalendar-30: (with DISCUSS and COMMENT)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 19:31:41 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-calext-jscalendar-30: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document; it's generally in good shape even though I do want
to discuss a few specific points.

(1) I'm a bit confused by the indication that we can use linkIds to link to
a vCard representation of a participant or location -- if I understand
correctly that representation would occupy the "description" property of
the linked object, but the "description" is (at least for locations)
supposed to be "human-readable", which is perhaps only debatably an apt
description of a vCard object.

(2) Given the language in Section 1.4.7 about needing to denote on a
per-object basis when Ids have semantic meaning outside of the object in
which they are defined, I think we need a stronger/clearer statement in
Section 4.2.5 that the location Ids have global semantics within a
calendar, Section 4.4.5 that participant Ids have global semantics,
within a calendar, etc.  (My preference would be to reverse the sense of
the language in §1.4.7 rather than add language to each instance of Ids
with global semantics; see COMMENT.)

(3) We may want to discuss the scheduleSequence semantics/usability in the
face of a user/"participant" that has multiple clients.  It seems to me
that there is not much preventing the different clients from sending
(different) responses that use the same sequence number, and I'm also
not sure whether the client is supposed to keep local state on what
sequence number to use next or just to increment any value received from
the server.

(4) I strongly recommend that all the examples not reuse UUIDs for different
things (e.g., I see "2a358cee-6489-4f14-a57f-c104db4dc2f1" as all of:
simple event, location (FRA Airport), location (Math lab room 1),
location (Big Auditorium), and virtualLocation (ChatMe).  The Section
6.9 example at least rises to Discuss-level (IIUC) as inconsistent with
the protocol requirements, since the location id is used for two
different locations in sibling events.

(5) Additionally, the Section 6.3 example seems malformed, since the
"entries" array contains as its second element a key/value pair, not a
(jstask) object.  (Erik noted this as a Comment-level point, it seems,
so this is more a note to myself to confirm that it's fixed than
informing you of the issue.)

(6) Can we briefly discuss the use of the "/" character in time zone
identifiers in §4.7.2?  Specifically, this text:

   o  It MUST start with the "/" character (ASCII decimal 47; also see
      Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion
      of the forward slash character in time zone identifiers).

(a) I see no discussion of the forward slash character in section 3.6 of RFC
7808.

(b) Also, Section 3.2.19 of RFC 5545 seems to basically be saying "there
might one day be one (or more!) global registry for time zones, but we
don't know of one and can't point you to it" ... is this really the
semantics we want to continue to enshrine?


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

If this is "successor to iCalendar", is an Obsoletes: relationship
appropriate?

What is the status of jCal (RFC 7265) now that this work is published?
Should jCal be moved to Historic?

There's a lot of stuff in the section-by-section comments (including
many nits, which hopefully are not too distracting from the substantive
ones); I do want to specifically call out my notes on the media-type
registration's interoperability considerations as noteworthy.  I'd also
request some extra attention be paid to the examples; I have a few
comments (as well as the discuss point) but am not exactly a JSON expert
and there may be other potential issues lurking.

It is perhaps unfortunate that no internationalization directorate
review was requested.

Section 1

   o  The data model should be compatible with the iCalendar data format
      [RFC5545] [RFC7986] and extensions, but the specification should
      add new attributes where the iCalendar format currently lacks
      expressivity, and drop seldom-used, obsolete, or redundant

Should this perhaps be downgraded to "generally compatible", since we go
on to discuss specific areas of incompatibility?

Section 1.3

If we're going to use JMAP as justification for (e.g.) the "A[B]"
notation, should we mention our underlying inspiration as stemming from
JMAP, somewhere?  (I have similar sentiments to the gen-art reviewer,
and apparently did not pay close enough attention to the change when it
happened in JMAP, which was possibly introduced as a result of my
comments on draft-ietf-jmap-core-14...)

Section 1.4.3

   This is a string in [RFC3339] "date-time" format, with the further
   restrictions that any letters MUST be in uppercase, the time

Just to check: this means that in general we expect implementations to
reject as malformed strings that use lowercase 't' or 'z'?

   component MUST be included and the time offset MUST be the character
   "Z".  [...]

(nit) AFAICT including the time component is already required just by
using the "date-time" construction, since the "full-time" part is not
optional.

Section 1.4.4

   A time zone may have a period of discontinuity, for example a change
   from standard time to daylight-savings time.  When converting local
   date-times that fall in the discontinuity to UTC, the offset before
   the transition is used.

Does this mean that there are certain instants in time that are
un-representable in this format in that timezone?  (Presumably UTC could
still be used to represent that absolute time if needed, though that
seems slightly at odds with the general goal of being able to use local
time for local events.)

Section 1.4.5

If we are not going to require that (e.g.) the specified seconds value
is not more than 60, we may want to put in some security considerations
about handling such nominally out-of-range values.

       duration    = "P" (dur-cal [dur-time] / dur-cal / dur-time)

The middle "dur-cal" seems redundant to me.

   1.  Add any week or day components of the duration to the date.

A week is always 7 days, even if a day is not always 24 hours, right?

Section 1.4.7

   Unless otherwise specified, Ids are arbitrary and only have meaning
   within the object where they are being used.  Ids need not be unique

Letting the Id be non-unique across objects seems to be a substantial
divergence from JMAP and the discussion in the document doesn't help me
understand the motivation for that divergence.  (If we said something
along the lines of "JSCalendar's uid is more analogous to the JMAP Id
than the JSCalendar Id is", that would have helped.) What goes wrong if
we try to use the RFC 8620 semantics ("[t]he id of a record is immutable
and assigned by the server.  The id MUST be unique among all records of
the *same type* within the *same account*")?  Or is "the object where
they are being used" intended to refer to the type of the object and not
the specific object itself?  (The guidance from
https://tools.ietf.org/html/rfc8620#section-1.2 on defensive allocation
strategies might be apropos as well.)

I would also appreciate some indication of whether the Id is always
server-assigned, in this section.

Personally, I would rewrite this whole paragraph along the lines of:

% In many places in JSCalendar a JSON map is used where the map keys are
% of type Id and the map values are all the same type of object.  This
% construction has similar semantics to a list of objects, with the
% advantage that it allows for the set of objects in question to be
% named (by the corresponding map key); this, in turn, allows for more
% concise patch objects and, when applicable, for the objects in
% question to be referenced from other calendar objects.  In some cases
% there is no need for references from external objects, so the Ids in
% question only have defined semantics within the specific object in
% which they appear; these cases are noted when they occur.  In all
% cases, however, Ids are server-assigned and immutable.  <Further
% analogy to JMAP could go here, if desired.>

but I recognize that sometimes my editorial ideas are strange, and you
are free to ignore my suggestion entirely -- I won't mind.

Section 1.4.8

The first three items in this list seem semantically equivalent to those
in RFC 8620 for the JMAP PatchObject; would it make sense to reuse the
text verbatim?  (Similarly for the "value associated with each pointer"
text.)

   A PatchObject does not define its own "@type" property.  A "@type"
   property in a patch MUST be handled as any other patched property
   value.

A forward reference for "@type" might be in order (at least, in the
absence of a reference to JMAP as inspiration in the introductory
material).

Section 1.4.9

   By default, time zones in JSCalendar are identified by their names in
   the IANA Time Zone Database [TZDB], and the zone rules of the
   respective zone records apply.

   Implementations MAY embed the definitions of custom time zones in the
   "timeZones" property (see Section 4.7.2).

The wording about "by default" leaves me wondering if the custom time
zones are allowed to override IANA TZDB time zones.

Section 1.4.10

      Keys in the set MUST be one of the following values, or specified
      in the property definition where the Relation object is used, or a
      value registered in the IANA JSCalendar Enum Registry, or a
      vendor-specific value:

(side note) I'd consider reiterating that "vendor-specific values"
require the domain-name-plus-colon prefix, to clarify that there is an
actual restriction in the "MUST".  (Similar language appears elsewhere
in the document, too.)  Also, in other places where we have a similar
requirement (e.g., §4.2.5) we specify the handling for an unrecognized
value, which might be worth doing here as well.

     The value for each key in the set MUST be true.

We have similar language in §4.2.5 describing locationTypes, where we
refer to it as a "map" rather than a "set"; it might be good to use
consistent terminology.

Section 3

   A JSCalendar object is a JSON object, which MUST be valid I-JSON (a
   stricter subset of JSON), as specified in [RFC8259].  Property names
   and values are case-sensitive.

(editorial) The location of "as specified in" binds to I-JSON but the
reference is just for JSON.

Section 3.2

   Considering this, the definition of equivalence and normalization is
   left to client and server implementations and to be negotiated by a
   calendar exchange protocol or defined elsewhere.

Did we consider providing well-written specifications for a few "common
options" that a consuming protocol could select from by reference,
saving applications from needing to duplicate work in each application?

Section 4.1.4

Perhaps it's obvious, but it seems like we're relying on the client to
supply an honest value for the product ID, and the server has no way of
verifying or validating that submission.

   The vendor of the implementation SHOULD ensure that this is a
   globally unique identifier, using some technique such as an FPI
   value, as defined in [ISO.9070.1991].  It MUST only use characters of
   an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]).

[Hmm, normatively referencing iCalendar for allowed characters makes it
hard to obsolete iCalendar as well...inlining the definition in this
document would make it more of a "standalone" document, if that's
desired.]

   For example, it is not to be used to further the understanding of
   non-standard properties, a practice that is knows to cause long-term
   interoperability problems.

nit: s/knows/known/

Section 4.1.5

I think someone else asked about whether a patch that only updates
"updated" without setting "created" is to be considered invalid; it
might be worth reiterating that here.

Section 4.2.5

   A map of location ids to Location objects, representing locations
   associated with the object.

A brief survey of similar usage in this document suggests that we
generally prefer "[map|set] of <type> ids to <Type> objects", but
there's at least one case where we just talk about "map of ids to <Type>
objects"; it would be good to make a pass to ensure consistency.

Section 4.2.6

      This may be a telephone number (represented using the "tel:"
      scheme, e.g., "tel:+1-555-555-555") for a teleconference, a web
      address for online chat, or any custom URI.

nit: one more '5' for a valid country-code 1 phone number.

Section 4.2.10

I don't think I understand why the "http" scheme is used in the example
categories; these feel in some sense more like URI than URL specifically.

Section 4.3.2

   A JSTask recurs by applying the recurrence rules to the "start" date-
   time, if defined, otherwise it recurs by the "due" date-time, if
   defined.  If the task defines neither a "start" nor "due" date-time,
   it MUST NOT define a "recurrenceRules" property.

I think that Phill's secdir review comment about addressing time zones
and daylight savings could be addressed by calling out more explicitly
here that the "start"/"due" times here have an associated time zone, and
that when converting the recurring events into other time zones the time
zone transitions in both the "to" and "from" time zones (if any) need to
be taken into account.

      The calendar system in which this recurrence rule operates, in
      lowercase.  This MUST be either a CLDR-registered calendar system
      name [CLDR], or a vendor-specific value.

I trust that CLDR guarantees that calendar-system names will not be
registered that differ only in case.

   o  bySetPosition: "Int[]" (optional)

      The occurrences within the recurrence interval to include in the
      final results.  Negative values offset from the end of the list of
      occurrences.  The array MUST have at least one entry if included.
      This is the BYSETPOS part from iCalendar.

(side note) huh, a literal reading of the RFC 5545 ABNF seems to limit
the potential indices here to (+/-) 1 to 366, which seems inadvertent.
I'm glad to see that we don't repeat that here!

Section 4.3.2.1

   2.  Each date-time candidate is compared against all of the byX
       properties of the rule except bySetPosition.  If any property in
       the rule does not match the date-time, it is eliminated.  Each

nit: I'd suggest clarifyint that the "it" that is eliminated is the
date-time, not the property in the rule.

       3.  If any valid date produced after applying the skip is already
           a candidate, eliminate the duplicate.  (For example after
           adjusting, 30th February and 31st February would both become
           the same "real" date, so one is eliminated as a duplicate.)

(nit) I can't decide if this should be "one" or "at least one".  I guess
this could have some interaction with step (5) below ("eliminate any
date-times that have already been produced by previous iterations of the
algorithm").

Section 4.3.4

   If the patch object defines the "excluded" property value to be true,
   then the recurring calendar object does not occur at the recurrence
   id date-time (like an EXDATE from iCalendar).  Such a patch object
   MUST NOT patch any other property.

I'd consider specifying which object the "excluded" property value would
be defined in, as opposed to the current state which is a little vague
(it could be anywhere).

   A pointer in the PatchObject MUST be ignored if it starts with one of
   the following prefixes:
   [...]

I'm not sure I understand why prodId is included in this list.  It seems
to preclude indicating that a different product was used to put in an
override than was used to create the initial recurrence.

Also, just to check: it's intentional to allow for
"excludedRecurrenceRules" and "excluded" to be patch-able?

If there is a vendor-specific or future-defined property that should get
similar treatment, how would that fact be communicated to implementors?

Section 4.3.5

   Defines if this object is an overridden, excluded instance of a
   recurring JSCalendar object (see Section 4.3.4).  If this property
   value is true, this calendar object instance MUST be removed from the
   occurrence expansion.  The absence of this property or its default
   value false indicates that this instance MUST be included in the
   occurrence expansion.

nit: I think commas around and an added word for "or the presence of its
default value false" are in order, as the current text seems to parse to
"the absence of its default value false".

Section 4.4.3

   This property MUST NOT affect the information sent to scheduled
   participants; it is only interpreted when the object is shared as
   part of a shared calendar.

(Where is "shared calendar" defined?)

   o  "private": The details of the object are hidden; only the basic
      time and metadata is shared.  The following properties MAY be
      shared, any other properties MUST NOT be shared:

I guess the idea is that if we want to add/remove things from this list
we'll just register a new enum value?

Section 4.4.4

   Represents methods by which participants may submit their RSVP
   response to the organizer of the calendar object.  The keys in the

Given that we don't seem to define a direct analogue for the iCalendar
RSVP parameter (at least, not that mentions that name), it seems that we
are falling back on the "native english" (er, French?) meaning of the
term, in which case it's perhaps debatable about whether "RSVP response"
adds anything over just "response".

   o  "web": Opening this URI in a web browser will provide the user
      with a page where they can submit a reply to the organizer.

Are we in a position where we could mandate the "https" scheme here?

Section 4.4.5

What kind of internal consistency checks do we expect implementations to
do with respect to (e.g.) delegatedTo/delegatedFrom,
memberOf/kind(group), etc.?  What should one do if an inconsistency is
found?

Why do we need both scheduleSequence and scheduleUpdated?

   o  language: "String" (optional)

      The language tag as defined in [RFC5646] that best describes the
      participant's preferred language, if known.

nit: RFC 5646 is BCP 47, and referencing the BCP form is probably
preferred for future compatibility.  (I can't tell on a quick inspection
if the RFC is in fact the preferred reference over an IANA registry, but
trust that you have it right.)

      This can be used to determine whether the participant has sent a
      new RSVP following significant changes to the calendar object, and
      to determine if future responses are responding to a current or
      older view of the data.

[Another case where "RSVP" might be out of place.]

   o  scheduleStatus: "String[]" (optional)

      A list of status codes, as defined in Section 3.8.8.3 of
      [RFC5545], returned from the processing of the most recent
      scheduling message sent to this participant.

[Just noting another place with hard 5545 dependency.]

      Servers MUST only add or change this property when they send a
      scheduling message to the participant.  Clients SHOULD NOT change

Send, but not receive?

Section 4.5.2

      *  offset: "SignedDuration" (mandatory).

         Defines the offset at which to trigger the alert relative to
         the time property defined in the "relativeTo" property of the
         alert.  Negative durations signify alerts before the time
         property, positive durations signify alerts after.

Thank you for specifying this explicitly!

      An "AbsoluteTrigger" object has the following properties:
      [...]
      *  when: "UTCDateTime" (mandatory).

Why can absolute triggers not be in local time even when event start/end
times can be in local time?  (Can alerts be part of recurrence rules?)

      For a recurring calendar object, the "acknowledged" property of
      the parent object MUST be updated, unless the alert is already
      overridden in the "recurrenceOverrides" property.

I'm not 100% sure I understand what the parent/child relationship being
referred to is, here.  My current guess is that there's a main
"recurrence rule" object that's treated as the parent for a given object
(in this case, alert) instance, but that may change as I keep reading...

Also, does this *only* apply to recurring objects, or to any object with
a parent?

Section 4.6.1

Are there ever cases where the burden of carrying around a lot of
localizations in-band with the calendar/objects becomes burdonsome, and
it would be convenient to make localizations remote resources thare are
only retrieved on clients that need them?  (E.g., if a given object is
localized into many different locales.)

   object is set to the language tag.  All pointers for patches MUST end
   with one of the following suffixes; any patch that does not follow
   this MUST be ignored unless otherwise specified in a future RFC:

Any RFC at all (including Independent Stream), or specifically an RFC
that updates this one?

Section 4.7.2

   o  It MUST be a valid "paramtext" value as specified in Section 3.1.
      of [RFC5545].

[another 5545 dependency]

   o  At least one other property in the same JSCalendar object MUST
      reference a time zone using this identifier (i.e., orphaned time
      zones are not allowed).

Will maintaining this invariant become burdensome if a calendar needs to
be "subsetted" (e.g., when redistributing "private" events)?

   A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545]
   and the semantics are as defined there.  A valid time zone MUST

[more 5545 dependence]

   o  validUntil: "UTCDateTime" (optional)

      The TZUNTIL property from iCalendar specified in [RFC7808].

[technically not 5545, but in the same category]

   o  aliases: "String[Boolean]" (optional)

      Maps the TZID-ALIAS-OF properties from iCalendar specified in
      [RFC7808] to a JSON set of aliases.  The set is represented as an
      object, with the keys being the aliases.  The value for each key
      in the set MUST be true.

Is the "alias" property (er, in the natural-language sense of
"property") intended to be transitive, or is there a single primary
timezone that others are aliases of?  (In either case we may want some
more specifics, including error handling.)

   o  offsetTo: "String" (mandatory)
      [...]
   o  offsetFrom: "String" (mandatory)

nit: these are not sorted alphabetically (and are in the opposite order
as RFC 5545); is there a reason not to swap them?

   o  recurrenceOverrides: "LocalDateTime[PatchObject]" (optional)

      Maps the RDATE properties from iCalendar.  The set is represented
      as an object, with the keys being the recurrence dates.  The patch
      object MUST be empty.

I suggest "MUST be the empty JSON object ({})" to distinguish from JSON
null (my initial interpretation), which would not have the desired
semantics.

   o  names: "String[Boolean]" (optional)

      Maps the TZNAME properties from iCalendar to a JSON set.  The set
      is represented as an object, with the keys being the names.  The
      value for each key in the set MUST be true.

I wish there was a more precise definition of "TZNAME properties"
available.  Are these supposed to be the "tznparam" or "text" (or both!)
portions of the RFC 5545 "tzname" construction?

Section 5.1.2

Should we say something about the conceptual "end" of the JSEvent being
at "start" + "duration", or is that too banal?  (We do reference the
"end" in a couple other places.)

Section 5.3

   JSGroup supports the following common JSCalendar properties
   (Section 4):

nit: any chance we could get this list sorted in the order the
properties appear in Section 4?

Section 6.1

(I assume that the January 2018 timestamps reflect approximately when
the example was first written.  It doesn't seem as interesting to have
the examples be "current" to time of publishing as it sometimes does for
other documents that go by.)
It is perhaps surprising to have "updated" and "start" be the same time,
though?

Section 6.10

         "uri": "https://chatme.example.com?id=1234567"

(My sense is that best practices for meeting URLs like this is to
include some amount of randomness in the URL to make it unpredictable.
See also https://www.w3.org/2001/tag/doc/capability-urls/ and
draft-gont-numeric-ids-sec-considerations.)

     "replyTo": {
       "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com"
     },

The local component of the email address is a substring of the UUID that
is this meeting's location id (which itself is reused in several other
places in this document, as previously noted), which is not necessarily
problematic but is perhaps unusual.  I'm more concerned that this is
also the imip "sendTo" for Tom Tool, who is not an owner/chair/etc. of
the meeting, just a regular attendee.  While not forbidden by the spec,
this seems like a highly non-representative example.  I'd suggest making
Tom's "sendTo" be just "tom@foobar.example.com" to match Zoe's.

       "...": ""

Is this empty string actually valid as a participant object?

Section 7

I note that there is not much discussion of internationalization
considerations, and arguably there should be.  This is specifically
relevant for security when it comes to "confusables" in Unicode, though
perhaps the scope for attacks is limited in terms of which JSCalendar
elements are presented to the user.

   Such systems must be careful to authenticate all data they receive to
   prevent them from being subverted.

Authorization checks may also be appropriate in these scenarios,
separately from authentication.

Section 7.3

   Several JSCalendar properties contain URIs as values, and processing
   these properties requires extra care.  Section 7 of [RFC3986]
   discusses security risks related to URIs.

It's generally my preference to specifically call out that there are
inherent considerations with fetching remote resources referenced by
URIs, in addition to referencing RFC 3986's security considerations as
you already do.

Section 7.4

   book contact).  Misclassifications are always possible however, and
   providing a feedback mechanism for users to quickly correct this is
   advised.

Based on real-world experience, I think it's important for the feedback
mechanism to not require sending any traffic to the originator of the
(spam) calendar event/object).
Also, nit: comma before "however" (as well as after).

Section 7.5

   when updating it to avoid unexpected duplication of events.  When the
   UID changes, consumers of the data may not remove the previous
   version of the event if it has a different UID.  This can lead to a

nit: "when the UID changes" seems redundant with "if it has a different
UID".

Section 8

[Just noting that I did not do a particularly thorough cross-referencing
of the various initial registry contents against the document body and
within the related registries.]

Section 8.1

   Interoperability considerations:  This media type provides an
      alternative to iCalendar, jCal and proprietary JSON-based
      calendaring data formats.

This feels like a general statement about the calendaring ecosystem and
not considerations for interoperability specifically within JSCalendar.
I would have expected things more along the lines of "different
applications may use different criteria for determining equivalence of
objects" or "while JSCalendar is designed to avoid ambiguities as much
as possible, when converting objects from other calendar formats to/from
JSCalendar it is possible that differing representations for the same
logical data might arise, or ambiguities in interpretation".

   Fragment identifier considerations:  N/A

I trust it is an explicit decision by the WG to not specify a fragment
identifier structure (e.g., JSON pointer).

Section 8.2

   delay.  It is designed to encourage vendors to document and register
   new properties they add for use cases not covered by the original
   standard, leading to increased interoperability.

nit: maybe s/standard/specification/?

Section 8.2.5

   o  Property Name: The name of the property.  The property name MUST
      NOT already be registered for any of the object types listed in
      the "Property Context" field of this registration.  Other object
      types MAY already have registered a different property with the
      same name.

Is this MAY too strong?  It seems like it would invite confusion if the
same name was used with different semantics in different contexts (so
guidance that this is only expected when the semantics are anlogous
might be appropriate).

Section 10.2

Perhaps "[MIME]" is no longer the best reference tag for the media-types
registry (which is now uncoupled from MIME)?

Since the RFC 4122 UUID construction is RECOMMENDED, that probably makes
it normative.

RFC 5546 needs to be normative since we defer to it for iTIP METHODs.
Likewise RFC 6047 for iMIP, RFC 7529 for several things, and RFC 7808
for several things.