Subject: Re: [Jmap] Reminder: last call

From: Benoît TELLIER <[email-masked]>
Date: Tue, 6 Nov 2018 15:45:24 +0000

That's a bit of a late remark but I think it would be blocking for our use of JMAP @Linagora...

As far as I remember the way to handle mailbox sharing (Bob gets Alice the right to see his mailbox "teamwork-with-alice") is to let Alice execute requests using Bob account id.

The JMAP client has to pass 2 distinct JMAP method calls (potentially in the same request) then aggregate the results.

Then the client can not rely on the server for relevance/ordering of items (and offset/limits as well).

To get back to our concrete exemple, we do currently execute Email/search on all accessible emails and display (server) aggregated results in a unified infinite list, regardless of which mailbox the message is in (shared or not). I fear that, when switching to an *account implementation of sharing*, we won't be able to propose such a unified view.

Any thoughts regarding this issue?

Cheers,

Benoit Tellier
On Oct 23, 2018 16:18, from [email-masked]

Hi all,

Just a reminder that we're in last call for the JMAP core + mail specs; I've just uploaded new revisions with some minor changes based on the feedback so far. With IETF103 less than 2 weeks away, now would be a great time to do your final review so we can discuss any outstanding items at the meeting before the last call closes on 16th November.

Latest spec links again:

Core: https://tools.ietf.org/html/draft-ietf-jmap-core-09

Mail: https://tools.ietf.org/html/draft-ietf-jmap-mail-09

Cheers,

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 06 Nov 2018 23:37:14 -0500

An account in JMAP is an isolation guarantee. For example, threading happens just for messages within an account, ids need be unique only within an account, state strings are for the set of records within an account etc. 
 
This is important for scalability. Being able to shard accounts easily lets you scale to very large numbers of users across a distributed system much more easily. 
 
So, I think for your use-case there are two options: 
 
1. If Bob and Alice are always going to be part of the same "team", you could make the JMAP account encompass the whole team. Essentially, you would use a single shared account for the team, with each user having different permissions to view a different subset of items within it. This works, although you might have a few weird things like giving different mailboxes the inbox/sent etc. role depending on the user viewing the account. 
 
2. (This is probably the better option). We define an extension for server aggregation of Email/query across multiple accounts. It would return a list of { accountId, emailId } tuples rather than a list of email ids. Some more thought would be required if we wanted to make back-references work to fetch the email objects in the same request. 
 
(Option 3 is of course to just aggregate in the client: you can interleave the results of Email/query to various accounts. But I'm presuming this is not an option for you for some reason.)
 
I'll propose we add this to the agenda for the meeting this afternoon during the agenda bash at the beginning. :) 
 
Cheers, 
Neil.

---

From: Benoît TELLIER <[email-masked]>
Date: Thu, 8 Nov 2018 02:09:17 +0000

Hi Neil,

I will quickly answer this message, that I did not see before I arrived at IETF-103
On Nov 7, 2018 11:37, from [email-masked]

This is not doable as there will be name conflicts (both Bob & Alice have an Inbox mailbox, etc...)

This is what was decided during IETF-103.

The big issue here is that all notion of relevance/sort order is lost as we represent the results only as an Id.

On complex sorts (like text search relevance) the client can not infer this easily. Thus it can not reliably merge the two sorted lists of ids into one.

Cheers,

Neil.

Cheers, Benoit