consider using RFC4314 myRights rather than may*

[brong]

"may*": Can we just replace this with a "myrights" per RFC 4314? If you want to drop the rights grouping model of RFC 4314 to be simpler, that's fine with me, but I'd prefer to keep the set of rights the same.

[brong]

Another Chris Newman comment related...

2.3.3. updating mailboxes

myrights (may*) isn't immutable; it's server-generated (possibly based on an IMAP ACL from RFC 4314) so the client can't directly update it. I think it's fine to leave ACLs as an extension to base JMAP but having the equivalent of myrights in the base spec is a good decision.

[neilj]

Alexey notes in #68 that this might be an issue to be mentioned in the JMAP/IMAP co-existence document rather than the JMAP spec itself.

The JMAP ACLs correspond as follows (true iff the given IMAP ACLs are set):

• mayReadItems: lr
• mayAddItems: i
• mayRemoveItems: te
• mayCreateChild: k
• mayRename: x
• mayDelete: x

There's no s/w (allowed to set keywords) because this could lead to a contradictory situation in a system where a message is in two mailboxes, one of which allows keyword changes and the other doesn't. This is instead handled by the more general ability to mark a whole account as isReadOnly: true.

There is no equivalent to p as it's not relevant to JMAP, and no a because we're not covering setting ACLs in this spec; an extra mayAdminister property may be added in a future spec that also covers setting ACLs for different users.

[cjnewman]

I still prefer a "myrights" property with all the IMAP ACL settings, but I suppose I can live with documenting the mapping in this way as long as you don't remove rights.

Removing the s / w is a problem. How does the client know it can successfully set keywords/flags on a message? If the goal of JMAP is to make things easier for a client, there must be a way for a client to determine that. Checking isReadOnly doesn't work because IMAP has finer granularity and we allow JMAP front-ends to IMAP. If you want JMAP to support systems that share one set of keywords/flags across multiple mailboxes (unlike IMAP), that's fine, but that does not eliminate the need for a client to tell if setting flags will succeed. The way to deal with the flags-shared-by-mailboxes-with-different-write-perms is to disallow flag changes if any mailbox with those flags is read-only. It's OK to super-set or group IMAP permissions, but it's not ok to subset them.

The "p" right in IMAP allows submission to a mailbox using a sub-address syntax convention such as userid+mailbox@domain syntax. This behavior is widely deployed by multiple vendors and operators. As JMAP adds submission to the protocol, the "p" right is more relevant to JMAP than it is to IMAP. What might make sense in JMAP is to add a "targetMailbox" property to the submission address object with the semantics it will submit to that mailbox if permissions (and system model) allow and it will fallback to INBOX delivery if they do not allow. That would make the "p" right much better in JMAP than in IMAP (as the client no longer needs to be aware of any addressing convention used in the background -- it can just offer a "submit to mailbox" option when permitted).

[neilj]

The way to deal with the flags-shared-by-mailboxes-with-different-write-perms is to disallow flag changes if any mailbox with those flags is read-only.

OK, that works for me. I suggest mayModifyItems as the mailbox property name? (Which maps to sw from IMAP)? I don't think we need a separate ACL for $Seen, and these ACL property names are all generically useful so I expect to reuse them for JMAP contacts/calendars.

The "p" right in IMAP allows submission to a mailbox using a sub-address syntax convention such as userid+mailbox@domain syntax.

Yes, and this is relevant in terms of setting permissions, but not relevant for telling JMAP clients what permissions they have for accessing a mailbox and its contents.

As JMAP adds submission to the protocol, the "p" right is more relevant to JMAP than it is to IMAP. What might make sense in JMAP is to add a "targetMailbox" property to the submission address object with the semantics it will submit to that mailbox if permissions (and system model) allow and it will fallback to INBOX delivery if they do not allow.

Sorry, I don't think I follow this suggestion. Can you elaborate?

[cjnewman]

I wouldn't object to linking sw in JMAP, but you should understand the consequences. Some implementations of IMAP shared folders have "seen" as a per-user flag and other flags shared by all users; so it's possible to give a user "seen" rights without giving them modification rights to shared flags/keywords that "w" provides. This is common if news groups are exposed via IMAP (multiple IMAP implementations can handle per-user seen but not per-user other flags via .newsrc style mechanisms). If you link the rights, JMAP clients either wouldn't be allowed to set seen flags on shared folders, or the shared flags on shared folders would have to be opened up to a free-for-all by users (think about a user adding a KilroyWasHere flag that other users see on shared folders, and worse). Are you sure you want to do that?

Posting rights was a mediocre attempt to implement an end-user feature in CMU's Andrew Message System: "post to mailbox". The IMAP use of a de-facto addressing scheme that the user "just had to know" meant IMAP clients didn't expose that option. But it's a very useful feature when shared folders are present. Since JMAP has a more client/end-user focus, perhaps we should think about resurrecting that feature properly. To do that, if a user has "maySubmitToMailbox" rights, then the client can advertise a "post to mailbox" command and use the mailboxID directly as a recipient address at JMAP submission time. Then JMAP would route the message to that mailbox using whatever local addressing convention it wanted (without need for the end-user or client to understand the addressing convention). I know you're looking for small/simple features that's a distinguishing selling point of JMAP over IMAP. I think this is one of those.

[neilj]

@cjnewman I was discussing this with @brong and we were wondering whether we should add back an "isUnread" property (and remove $Seen from keywords in JMAP; it would still map to this for IMAP compatibility). This could potentially simplify quite a few things:

• Easier to define separate "s"/"w" rights (one allows you to modify the isUnread property, the other allows you to modify the keywords property).
• Simpler for servers to then check the rights (Cyrus has quite a few code paths where it has to check if the keyword used is $Seen and if so do something different than for other keywords.
• Flipping the boolean makes it more consistent with the unreadThreads/unreadMessages counts on the Mailbox object and matches the concept as it exists in most email clients.

Thoughts?

I'm still dubious regarding the utility of the post-to-mailbox mechanism you're suggesting; how is this different from just copying a message (using the current JMAP copyMessages method) directly into the mailbox if it's already shared with you (and you have the mayAddItems (i) ACL)?

But perhaps you can sell me on the idea in Singapore if you're coming? :)

[brong]

Now that we have patching semantics, it seems sensible to batch all the rights inside a single object, so that if we create an extension to allow ACL management via JMAP later, you can implement SETACL + and SETACL - with patch semantics, but also SETACL raw (=) as a patch that just replaces the toplevel acl object. So:

[ "mailboxes", { "list" : [ { "id" : "...", "name" : "Archive", "myRights" : { "mayReadItems" : true, "mayAddItems" : true, ... }, "role" : "archive", ... }, ... ], }, "tag" ],

[cjnewman]

Making myrights a patchable object sounds good to me. I'm ok with isUnread option for reasons you describe.

An Append/Copy operation to a mailbox is local to the JMAP server; only the people on that server see the changes. A post-to-mailbox operation is interesting when the shared mailbox is one for a mailing list or newsgroup; the post operation implies that it goes to the list submission address rather than just the local view of the list. For a moderated list, a post-to-mailbox operation my not have an immediate response (e.g., until moderation happens), and may result in a rejection (for moderation reasons) even if rights to perform a post are present. Also post-to-mailbox uses the submission API so you get the future release and features like that. The post-to-mailbox semantics allows a site to expose a mailing list as a shared folder and have everything "just work" in a friendly way.