[JMAP] Re: JMAP for Calendars comments

[Neil Jenkins <[e-mail]>]

Apologies for the delay in getting back to this.

On Fri, 10 Oct 2025, at 20:06, Mauro De Gennaro wrote:
> For this use case, I’m thinking from the perspective of a calendar client implementer. For example, suppose the client UI lists all participants in an event, and the user can right-click on a participant to view their availability or share something else (a file node, mailbox, etc.) with them before the meeting. As you said, the client only knows the participant’s alias and display name.
> 
> Currently, the only way for the user to locate the corresponding principal (so they can view availability or share data) is to close that view and perform a manual search by name or by calendar address (if it’s a mailto: URI and happens to match the principal’s email). Allowing Principal/query to search by calendarAddress would let clients automatically map a known calendar address to its principal, when that mapping exists.

OK, I've added:
*2.3. Principal/query extension
*
The following extra optional property is added to the *FilterCondition* object for the *Principal/query* method when the `urn:ietf:params:jmap:principals:availability` capability is used:

*calendarAddress*: String
    The given string is a calendarAddress belonging to the Principal.

Does that work for you?

> Just to clarify the model in Stalwart: when a Principal is a member of a group, they also own the group’s account data in addition to their own.

That's not how that was intended to work. An account can only be owned by a single Principal, so it should either be a group principal representing the group, or no owner (both are allowed). It sounds like you're returning a different owner depending on who's accessing the account? What was the idea behind that?

> It’s also possible for a group to share data with an individual Principal, in which case that Principal does not own the shared data.

Sorry, I don't understand what you're trying to differentiate here. Can you elaborate?

>> 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.
> 
> Ah, so the client must also provide a timeZone property when using utcStart and utcEnd?
> 
> If so, the sentence “If set, the server will convert the UTC date to the event’s current time zone and store the local time” could be clearer. Perhaps it should explicitly state that when creating a new event:
> 
> - the client should provide a timeZone property,
> - if missing, the calendar’s default time zone is used, and
> - if the calendar has no default, then Etc/GMT is assumed.

Yeah, that's reasonable. I've changed it to:
*
*
*If set, the server will convert the UTC date to the event's current time zone and store the local time. If the event does not have a non-null "timeZone" property, the server MUST also set this property (and return it in the created/updated response, as per RFC8620, Section 5.3 <https://www.rfc-editor.org/rfc/rfc8620.html#section-5.3>). The value MUST be the "timeZone" property of the Calendar(s) the event is in if all of them have the same non-null value. Otherwise, the time zone is to be set to "Etc/UTC".*

>>>  • *Conflicting calendar defaults:* When an event is added to multiple calendars with different default alerts, time zones, etc., how should these preferences be applied?
>>> 
>> 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?
> 
> Yes, it’s a tricky case. In my implementation, I choose the most common time zone among the calendars. If there’s no clear majority, I fall back to the time zone from the first calendarId associated with the event.

That sounds fine, I think.

> What are the intended use cases for systems that have multiple accounts containing principals?

It's going to be very rare, but most likely if you were proxying multiple systems into a single JMAP endpoint.

> Could the accountId parameter perhaps be made optional on Principal/* methods to simplify the more common single-directory scenario?

I think it should be mandatory for consistency with the rest of JMAP. (I remember we had a big discussion about whether it should always be optional, defaulting to the primary account for the data type, and we decided to follow the principle of always being explicit, which guards against edge cases like the primary account changing on the server).

>>>  • 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?)
> 
> I was referring to the busyStatus of the BusyPeriod object, which can be confirmed, tentative, or unavailable. My question was which value should be used when the participant’s participationStatus is needsAction (I mistakenly included tentative earlier). It might also be worth clarifying (though perhaps it’s obvious) that when participation is delegated, the participant should be considered available during that time.
> 
> […}
> Please disregard this comment. I had been expecting a direct mapping between participationStatus and busyStatus, but after re-reading the relevant event criteria, I see that it clearly states only events with a participationStatus of "accepted" or "tentative" are included.

Just to clarify, if the calendar's "includeInAvailability" property for the user is "attending", then yes, only events with an accepted or tentative participation status will be included. If the calendar's "includeInAvailability" property is "all", then the event would be included even if the user is not a participant, or their participation status is "needs-action".

> Out of curiosity, what was the reasoning for leaving Tasks out of the spec? The current methods in JMAP Calendars already seem well suited for Tasks with only minor extensions.

To keep the spec simpler and cleaner (and it's long enough already). I expect a Tasks spec would be similar in many ways, but it's a different use case and has slightly different requirements (VJOURNAL gets even more into the weeds).

>>>  • *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.
> 
> Yes, exactly.

OK, I've added a new `expandDurationTooLarge` error type for this.

(Changes will be published when draft submission reopens in a week or so.)

Cheers,
Neil.