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

[Neil Jenkins <[e-mail]>]

Hi Benjamin,

Many thanks for your detailed review.

> (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, 

I think I can see the cause of the confusion here. The issue is referencing links by id from a Location/Participant. It's confusing then what the "rel" property of the Link is relative to. I think this is a significant enough issue to change to embedding the Link objects in the Participant/Location rather than doing a reference to the id in the event's links property This simplifies it, and makes the "rel" clear. (So for a participant/location, you would probably use a rel="alternative" to link to a vCard, as this is an alternative representation of that object). The "rel=describedby" would be used from the top-level event's links to link to an alternative to the "description" property of the event.

> (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.

Sorry, I don't follow. They don't have global semantics; where did you get that from? Only the UID property must be globally unique, which is not of type Id anyway; for iCalendar compatibility it's just a String. To clarify this, I have rewritten this section to read:

*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 represents an unordered set of objects, with the added advantage that each entry has a name (the corresponding map key). This allows for more concise patching of objects, and, when applicable, for the objects in question to be referenced from other objects within the JSCalendar object. *

*Unless otherwise specified for a particular property, there are no uniqueness constraints on an Id value (other than, of course, the requirement that you cannot have two values with the same key within a single JSON map). For example, two JSEvent objects might use the same Ids in their respective "links" properties. Or within the same JSEvent object the same Id could appear in the "participants" and "alerts" properties. These situations do not imply any semantic connections among the objects.*

*Nevertheless, a UUID is typically a good choice.*

> (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

Correct, this is how iTIP works. These properties are for storing the data needed for the existing iTIP protocol; nothing new. The sequence number is incremented when the organizer makes changes to an event. The changes are sent out to participants. Participants send responses. When a response is received, it is ignored if the sequence number is less than the sequence number of the response currently stored for that participant (as scheduleSequence) or if it's the same but the "updated" date is older than the last response stored for that participant (as scheduleUpdated). Essentially, if the user has multiple clients that aren't in sync then the most recent response will "win" unless it's responding to an older version of the event than a previously received response.

> 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.

The value is only ever incremented by the organizer. Participants respond with the sequence number of the last update from the organiser (i.e. the sequence property of the JSEvent they are responding to).

This is all stuff specified in iTIP and I do not think needs to be, or indeed should be, explained in the JSCalendar document. Specifically, this is a description of how a scheduling protocol works, whereas JSCalendar is a data type to store information.

> (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.

Thanks, I have updated the examples.

> (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.

Indeed. The custom time zones stuff was all written by Robert and he's on holiday at the moment, but I *think* this is just referring to these RFCs for a general discussion on time zone identifiers. Reading through, I don't think either reference is necessary. I have replaced it with the following text, which is the real reason for the requirement:

*To avoid conflict with names in the IANA Time Zone Database it MUST start with the "/" character.*

> (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?

Personally I pushed strongly for not allowing custom time zones and only allowing references to the IANA registry. However, Microsoft are the sole holdouts (that I am aware of) who use their own time zone database rather than the IANA one, and it was considered likely to hinder its eventual adoption everywhere if we did this. (Of course, the flip side is that now everyone has to at least countenance the possibility of custom time zones in code handling JSCalendar, even if it's just to ignore them and treat anything with one as floating time).

> ----------------------------------------------------------------------
> 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?

Probably. How is this done?

> 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?

Sure, done.

> 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...)

We can, but I don't really see how it aids the reader's comprehension to refer them to another document with the same definition?

> 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'?

This would be malformed, yes. Forcing a single representation for any particular date-time (the same reason you can't have trailing zeros) makes equality testing much easier and we've found generally helps reduce bugs.

>    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.

True, I will drop this superfluous statement.

> 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.)

Correct (and yes, you can use UTC to specify something in those times). The alternative would be to store an offset with the date time. At that point you are effectively encoding an absolute time, so might as well use UTC. This also means the dates remain easily compatible with iCalendar, which also does not offer a way to specify the other offset within an overlapping time zone discontinuity.

> 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.

Indeed it is, I've removed it.

>    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?

Yes, I've added an explicit statement to this effect to clarify.

> 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

I don't agree with this statement. JMAP ids must be unique within a very specific context: the `(accountId,Type)` tuple. You may have the same id for another object with a different type within the same account, or of the same type within a different account. (For example, you might just have per account auto increment ids, so id "1" will come up a lot! But it's unique within an account for a particular type.)

> 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.)

It's still different; UIDs need to be globally unique (so if you see the same UID in two different accounts it MUST refer to the same event).

> 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. 

There is no server here. This is a data format. JMAP calendars (currently being drafted <https://tools.ietf.org/html/draft-ietf-jmap-calendars-03>) will provide a JMAP interface to calendar data using the JSCalendar format. This will assign JMAP ids, but this will be a separate property and may be different to the UID (which may not even be a valid JMAP id).

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

As mentioned in response to your second DISCUSS point, I have now rewritten this, and I hope this is now clearer. I remain puzzled as to what server you are referring to.
**
> 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.)

Yes, might as well; I have updated this.

>    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).

Added.

> 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.

This has been rewritten in response to other feedback.

> 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,

I have added a reference to the vendor-specific values section to each of these places.

>      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.

I've changed these all to "map".

> 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?

Not yet. If we did, I think this should be a separate document.

> Section 4.1.4
> 
>    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.]

I've dropped the character restriction here; this was for iCalendar compatibility, but we can define how to escape characters as necessary in the iCalendar-JSCalendar translation document and that simplifies this, which is worth doing.

> 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.

It's technically valid, if pointless. I'm unconvinced that spelling this out specifically is required (a literal reading of the spec does not forbid it, and there are other pointless patches you could make, like overriding a property to the same value).

> 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.

While, as per the spec, a URI is all that's required, a URL that links to documentation would be very useful for people encountering categories.

> 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.

I think this is better in the security considerations; I've added there:

*Events recur in the event's time zone. If the user is in a different time zone, daylight saving transitions may cause an event that normally occurs at, for example, 9am to suddenly shift an hour earlier. This may be used in an attempt to cause a participant to miss an important meeting. User agents must be careful to translate date-times correctly between time zones and may wish to call out unexpected changes in the time of a recurring event.*

> 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.

Done.

> 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).

I've rewritten this to:

*If the patch object defines the "excluded" property of an occurrence to be true, this occurrence is omitted from the final set of recurrences for the calendar object (like an EXDATE from iCalendar).*

>    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.

The intention is that you would update the prodId of the master event while adding the recurrence override. This is because generally a client will have deserialised the whole object into an internal data structure and then reserialised it again; even if it thinks it only changed an override, there's the possibility it actually mangled something else. The prodId is primarily useful for debugging later (if you keep a log of previous versions of an event object for a while) and so you want to know which app wrote a particular version.

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

"excluded" certainly needs to be patchable (that's how you exclude an occurrence, as noted above), however "excludedRecurrenceRules" should have been on the list of disallowed prefixes; I've now added it, thanks.

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

New properties are added to the property registry, which links to a definition. That description may include guidance that this property may not be overridden.

> 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".

Done.

> 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?)

So, this is where we get into the thing of this being a data format, which may be used stand-alone, but may also be used as part of a protocol (e.g. CalDAV or soon JMAP Calendars) which interpret certain properties that have little meaning in isolation. I have rewritten this to try to clarify:

*This property MUST NOT affect the information sent to scheduled participants; it is only interpreted by protocols that share the calendar objects belonging to one user with other users.*

>    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?

Yes.

> 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".

Agreed, I've cut RSVP.

>    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?

I think we can actually, given this is not a property that needs to be backwards compatible (it doesn't have a representation in iCalendar); I've done this.

> 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?

I would expect checks here to be defined in a protocol using JSCalendar rather than in the format itself, because it also relates to permissions and groups.

> Why do we need both scheduleSequence and scheduleUpdated?

With iTIP, the sequence number is incremented by the organizer each time they modify the event. When a participant sends a response to the organizer, the response includes the sequence number of the iTIP message they are replying to, and the current time stamp on their device. The organizer will store both the sequence number and time stamp of the last response they received from a participant. This allows them to choose whether to accept or reject a response in the event that responses arrive out of order: to be accepted, the sequence number of the new response must be higher than the old response (but not higher than the organizer's sequence number!) — this is a response to an update from the organizer — or the same as the old response but with a newer updated time stamp — this is a change of response to an existing invitation.

>    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'm happy to change this reference, but am not sure how to reference the BCP. Do you have a pointer for the correct XML for this?

>       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.]

Changed to response again.

>       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?

I believe that's correct; this is the status of the messages the server has sent.

> 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?

Firstly for compatibility with iCalendar (which only allows UTC), but mainly because no one has expressed a need. Almost all alerts will be relative triggers, which already relative to a local time. AbsoluteTrigger events are (currently, and I expect going forward) almost solely used for snoozing alerts: you dismiss the relative one and create an absolute one for the point in the future it has been snoozed to. This does not require local time support, UTC only is fine. This is extendable should someone come forward with a use case later.

>   (Can alerts be part of recurrence rules?)

You can override the alerts for a specific occurrence with the standard recurrenceOverrides mechanism.

>       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...

I've attempted to clarify:

*For a recurring calendar object, setting the "acknowledged" property MUST NOT add a new override to the "recurrenceOverrides" property. If the alert is not already overridden, the acknowledged property MUST be set on the alert in the master event/task.*

> 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.)

This property is really there for when you explicitly want it in-band. If wanted out of band, you could link to an alternate representation with the links property, but generally the user will have sourced the file from a locale-specific feed in the first place.

>    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?

Independent stream RFCs may document new properties (added to the registry) and may want to allow them to be localized without using one of these suffixes.

>    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)?

If removing private events from a collection, failing to remove a custom time zone that is only used by the private events may leak private information.

>    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?

No, I've swapped 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.

Done.

>    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?

I believe this is just meant to be the text; params are ignored. I have added a clarification.

> 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.)

No harm in making it explicit, done.

> 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?

Sure.

> Section 6.10
> 
>          "uri": "https://chatme.example.com?id=1234567 <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.)

I mean it's not meant to be a real URL, but sure, done.

>      "replyTo": {
>        "imip": "mailto:[e-mail]"
>      },
> 
> 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 "[e-mail]" to match Zoe's.

Sure.

>        "...": ""
> 
> Is this empty string actually valid as a participant object?

No, this is just the saying other entries have been omitted for brevity, as noted at the beginning of the Examples section. It's not necessary here though, so I've just removed it.

> 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.

I'm not sure there's much JSCalendar specific that needs to be documented here, but I've added a short comment to the Spam section:

*Confusable unicode characters may be used to trick a user into trusting a JSCalendar file that appears to come from a known contact but is actually from a similar-looking source controlled by an attacker.*

>    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.

I've added an extra note here.

> 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.

I have added another paragraph to this section:

*Fetching remote resources carries inherent risks. Connections must only be allowed on well known ports, using allowed protocols (generally just HTTP/HTTPS on their default ports). The URL must be resolved externally and not allowed to access internal resources. Connecting to an external source reveals IP (and therefore generally location) information.*

> 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).

I've just cut the word "feedback". The intention of this statement is for the user to correct local classification, certainly not to send remote feedback, which perhaps this implied.

> 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".

Fixed.

> 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".

I have updated this to:

*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. The semantic equivalence of two JSCalendar objects may be determined differently by different applications, for example where URL values differ in case between the two objects.*

>    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).

No, I don't believe anyone had considered this. I think a JSON pointer fragment here makes a lot of sense; I can't see any good reason not to allow it, so I've added this.

> 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/?

Done.

> 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).

I've expanded this to: 

*Other object types MAY already have registered a different property with the same name, however the same name SHOULD only be used when the semantics are analogous.*

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

I've changed this to [MEDIATYPES].

> 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.

Done.

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

Cheers,
Neil.