[JMAP] Re: JMAP for Calendars comments

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

Hi Neil,

Thanks for the fixes! Please find below my replies plus some new comments,

>> Now, suppose Jane sees mailto:john.do <http://john.do/>[e-mail] <http://example.com/> listed as a participant in an event and wants to query John’s availability using Principal/getAvailability. How can Jane determine which principal ID is associated with that address, given that it’s defined as a ParticipantIdentity under John’s account? The Principal/query method does not currently allow querying by calendar address and Principal objects can contain just one email, so how should a client resolve that mapping?
> 
> Interesting, I see where you're coming from now with all this. A few thoughts:
> It would have to be a policy decision for the server over whether users are allowed to resolve the owner of the alias; as mentioned earlier, some people consider them private.
> The most common scenario (by far) is for the organiser to be checking availability, and they would not have this problem (because you go the other way → find the principals you want to schedule with, check their availability, then get the address to invite from the Principal).
> If we did want to support this, my feeling is the best way would be to add an optional principalId property to the Participant <https://www.ietf.org/archive/id/draft-ietf-calext-jscalendarbis-09.html#name-participants> object, which the server would automatically add if it could resolve which Principal this participant corresponded to, and its policy gave user permission to see this. Do others think this is worth adding?

What do you think about instead extending Principal/query to support searching by calendarAddress? That might cover the same use case without introducing new properties on Participant.
While looking into this, I ran into a few related issues. Let me try to explain using a simple example with ACME, Inc.:

Wile E. Coyote:

accountId: A1

principalId: P1 (email address: [e-mail])

participant identities: [e-mail], [e-mail]

Road Runner:

accountId: A2

principalId: P2 (email address: [e-mail])

participant identities: [e-mail], [e-mail]

“Corporate” group, which contains a shared calendar:

accountId: A3

shared with: A1, A2

From this setup, a few questions and gaps become apparent:

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.

Discovering a principal’s calendar addresses: If Wile wants to invite Road Runner to an event stored in the Corporate shared calendar, he might run a Principal/query for “Road Runner” and obtain the principal details, but the Principal object only lists an email address, not calendar addresses.
I think that if a user is available for scheduling, at least one calendarAddress should be included in the Principalobject. Otherwise, there’s no reliable way to search for other users to invite to a shared calendar.

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? Both have the urn:ietf:params:jmap:principals:owner capability since he’s a member of both. I checked whether the isPersonal flag could be used for this but it serves a different purpose.



To summarize, we currently lack a way to:

Obtain the principalId associated with a calendarAddress (needed to fetch availability).

Obtain the calendarAddress values for a Principal (needed to invite users to events).

Identify the “main” accountId for a Principal (needed when sharing data).


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?

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

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? Otherwise, clients have to issue multiple queries and merge the results locally, which seems counter to JMAP’s low-bandwidth design goals.

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

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

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?

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?

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

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 nearly finished implementing JMAP for Calendars and JMAP for Sharing, so these will likely be my final round of comments.



Thanks,
Mauro