[JMAP] JMAP for Calendars comments

[Mauro De Gennaro <[e-mail]>]

Hi Neil,

I’m in the process of implementing JMAP for Calendars and while reading through the latest draft (-24), I noted a few small issues and some comments I wanted to share:

First, a few typos and editorial things I spotted:

- Section 4: “initally” should be “initially”.

- Section 1.5.1: “can be can assigned” -> “can be assigned”.

- Section 5.1: it says “four new JSCalendar properties” but only three are defined (mayInviteSelf, mayInviteOthers, hideAttendees).

- Section 5.6.1: the sentence “Splitting an event however is problematic…” may read better as “However, splitting an event is problematic…”.


And here are a few comments and suggestions I wanted to flag as well:

- Section 2.2 (Principal/getAvailability): Returning the full/partial event in the availability response could make responses unnecessarily large (even when using ranges). In addition to this, clients may already have the event cached. It might be better to return only the synthetic ids of the events and let clients fetch the details with a CalendarEvent/get call using a result reference to list/*/eventIds in the Principal/getAvailability response.

- Section 3 (ParticipantIdentity): It’s not clear whether participant identities are associated with each calendar or if they’re account-level objects like email identities. If they are calendar-specific, which permissions apply when viewing or modifying them?

- Default Alerts: It might be worth clarifying that only OffsetTrigger alerts should be used in set requests. AbsoluteTrigger does not make sense for a default alert.

- Permissions (Section 4): I think mayRSVP should be renamed to mayUpdateRSVP, since it refers to the permission to update an RSVP status rather than the permission to RSVP.

- Section 5.11.1 (Filtering): Some filters accept null as an argument. In some cases this makes sense (to indicate absence of a value), but for others like text, before, or after it doesn’t really make sense.

- iCalComponent: Since the iCalComponent property may include unnecessary converted data (like VTIMEZONE components) that most JMAP Calendar clients won’t care about, maybe it’s worth suggesting that such components and properties should not be returned by default unless explicitly requested.


Thanks,
Mauro