[JMAP] Re: JMAP for Calendars comments

[Neil Jenkins <[e-mail]>]

Hi Mauro,

>  • *Finding the principal for a calendar address: *As mentioned before, it’s currently not possible to obtain the principal ID for a given calendar address. Allowing `Principal/query` to search by `calendarAddress` would solve this and avoid the need to add a new property to the `Participant` object.
> 

I'm still not quite clear on the use case you have here. The only one I can see (using your scenario) is that you are Wile E. Coyote and want to check the availability of Road Runner so you can invite them to an event, but you only know their alias `[e-mail] and not ``[e-mail]? That … doesn't seem very likely?`

>  • *Discovering a principal’s calendar addresses:*
> 

This is already in the spec <https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-25.html#section-2.1>:

A "urn:ietf:params:jmap:calendars" property is added to the Principal 
"capabilities" object, the value of which is an object with the 
following properties:
[…]

*calendarAddress*: `String
`
If this Principal may be added as a participant to an event, this is the calendarAddress to use to receive iTIP scheduling messages.

>  • *Identifying the main account ID of a principal: *Suppose Road Runner wants to share his personal calendar (or a mailbox) with Wile. He queries for Wile’s `Principal` and sees account IDs “A1” and “A3” listed under the `accounts` property. But how can his client tell which one is Wile’s main account?
> 

Also in the same bit of the spec <https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-25.html#section-2.1>:

A "urn:ietf:params:jmap:calendars" property is added to the Principal 
"capabilities" object, the value of which is an object with the 
following properties:

*accountId*: Id|null

Id of Account with the urn:ietf:params:jmap:calendars capability that contains the calendar   data for this Principal, or null if either (a) there is none (e.g. the Principal is a group just used for permissions management), or (b) the user does not have access to any data in the account (with the exception of free/busy, which is governed by the "mayGetAvailability" property).

>  • Both have the `urn:ietf:params:jmap:principals:owner` capability since he’s a member of both.
> 

This doesn't make sense — A3 is not owned by either Wile E Coyote or Road Runner, it is just shared with both of them. It should either have no owner, or be owned by a Principal representing the team.

> I also have a few additional comments and questions unrelated to the above:
> 
>  • *CalendarEvent/set:* The line *“If 'utcStart' is set, this is translated into a 'start' property using the server's current time zone information”* isn’t entirely clear. I assume it means the event is converted to the calendar’s default time zone?
> 

If the "timeZone" property of the event is null, then yes. If not-null, it should be translated into local time using whatever time zone was set by that property. By "The server's current time zone information" I just meant the current version of the IANA DB it has at the time. I agree this could be clearer.

>  • *Conflicting calendar defaults:* When an event is added to multiple calendars with different default alerts, time zones, etc., how should these preferences be applied?
> 

For alerts, it's the union of all alerts:
*6.1 Default alerts <https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-25.html#section-6.1>*
If the "useDefaultAlerts" property of an event is true, the alerts are 
taken from the "defaultAlertsWithTime" or "defaultAlertsWithoutTime" 
property of all Calendars (see Section 4 <https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-25.html#calendars>) the event is in,

The time zone one is trickier, and is not currently defined in the spec I think. So if you have an event without a time zone, and it's in multiple calendars with different default time zone properties … err, I have no idea what you should do. I think all you can do is pick one, and try to make it stable? Any other suggestions?

>  • *Principal/getAvailability:*
> 
>    • The method requires both a `principalId` and an `accountId`. Could the `accountId` be made optional so the server returns combined availability for all calendars the principal can access?
> 

The accountId here is the account id in which to find the Principal object (just like every other JMAP method — when you're supplying record ids, you need to know the account id in which to look for them). It's *not* the account id in which to look for calendars/events for that principal: you should indeed look at all calendars/accounts the Principal has access to (subject to the includeInAvailability property etc. set on the calendar for that principal).

>  • The rules for relevant events cover shared calendars, but it would help to clarify how to handle personal calendars containing events without participants.

I think this is already covered by:
If the "includeInAvailability" property of the calendar is "attending", 
then the Principal is a participant of the event, and has a 
"participationStatus" of "accepted" or "tentative".

I would expect (by default at least), the user's personal calendars to have includeInAvailability set to "all" (i.e. all events, including those without participants, are considered), while shared/team calendars might have includeInAvailability set to "attending".

>  • It’s unclear what `busyStatus` should be used when `participationStatus` is `needsAction`, `tentative` (and maybe also that `delegated should not be included`).

`"tentative"` — The event status is "tentative" or the Principal's "participationStatus" is "tentative".

That's an "or", so if the event status is tentative, the busyStatus here would be tentative, according to the spec. (Or have I misunderstood your question?)

>  • *Recurrence range matching:* CalDAV treats time ranges differently for `VEVENT` and `VTODO` (RFC 4791 §9.9). Should JMAP for Calendars follow the same behavior for consistency?
> 

I'm not sure I quite follow here. JMAP Calendars does not return todos, only events, so I'm not sure how VTODO is relevant?

>  • *CalendarEvent/query:* The `cannotCalculateOccurrences` error seems to cover general recurrence failures. Would it be useful to define a specific error when a recurrence range expansion is too large?
> 

You mean if it exceeds the *maxExpandedQueryDuration* duration (found in the capabilities)? Yeah, that should maybe have a different error type.

>  • *CalendarEventNotification:* The `changedBy/name` property should probably be nullable, since this information might not be available in iMIP messages from external systems.
> 

Yeah, ok.

>  • *Shared personal calendars:* The specification currently focuses on shared group calendars, which is great, but it might also need to clarify the rules for shared *personal* calendars (for example, how `Principal/getAvailability` should behave in that context).
> 

I'm not quite sure what you're looking for here; if it's not cleared up by the comments above, could you please clarify what's unclear?

Cheers,
Neil.