[JMAP] Re: JMAP for Calendars comments

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

Hi Neil,

> Apologies for the delay in getting back to this.

No worries, last week I started writing my first I-Ds and realised how much time it takes!


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

That’s perfect, thank 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?

From an ACL perspective in Stalwart, members of a group account are effectively treated as co-owners of that group’s data, in addition to their own personal account data. It’s also possible for a group member to share the group account with non-members. I was trying to model this kind of multi-owner setup within the JMAP Sharing framework, but if JMAP requires each account to have a single owner, I’ll adjust the implementation so that only the main user account is marked as the owner.


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

Great, thanks.

I have one last comment regarding Principal/getAvailability: it would be helpful if each BusyPeriod object also included the accountId when the event property is not null (and the user has access to that account). This would allow clients to map the returned event to its corresponding CalendarEvent object more easily.



Best,
Mauro