Subject: [Jmap] Mailbox#role vs IMAP SPECIAL-USE

From: Neil Jenkins <[email-masked]>
Date: Mon, 02 Oct 2017 14:05:32 +1100

This is in reference to GitHub issue #62[1].

The role attribute on the Mailbox object in JMAP is equivalent to the
RFC6154[2] SPECIAL-USE flag in IMAP, however there are some semantic
differences so I'd like to solicit some opinions on what to do. Here are
all the differences I can see:
 1. The value is singular in JMAP, but you can have multiple special-use
    attributes on the same mailbox in IMAP.
 2. The value is unique in JMAP (you cannot have two "Sent" mailboxes),
    but duplicates are allowed in IMAP.
 3. The value is immutable in JMAP, but can be modified after mailbox
    creation in IMAP.
In addition, JMAP has two roles that don't exist in SPECIAL-USE:

 * *inbox* (It's a hard-coded name in IMAP so you didn't need an
   attribute).
 * *templates* (Drafts that should be used as the basis for new drafts
   but not themselves modified.)
SPECIAL-USE has two attributes that aren't in JMAP:

 * \All
 * \Flagged

These are both virtual, and aren't necessary in JMAP because
getMessageList allows you to fetch all/flagged across the whole account
without requiring a special mailbox fox it.
So, what to do. Special-use allows servers to enforce the three
differences in semantics that JMAP specifies (singular, unique,
immutable), so one option is to leave the semantics as is, and IMAP
servers can just enforce them over IMAP as well to keep a consistent
view. Alternatively we can relax the restrictions in JMAP, but I think
these are useful properties and I wonder whether there are people
actually making use of the relaxed options at the moment with IMAP?
Regarding the different roles/attributes, there's RFC6154 didn't create
an IANA registry, so it's not extensible without a whole new RFC. I'm
inclined to just include a mapping in an advice to implementors section.
Any other opinions on this?

Cheers,
Neil.

Links:

  1. https://github.com/jmapio/jmap/issues/62
  2. https://tools.ietf.org/html/rfc6154

---

From: Gren Elliot <[email-masked]>
Date: Mon, 2 Oct 2017 06:46:27 -0700

I’m inclined to think there is value in JMAP being more restrictive.  If
IMAP exposes multiple “Sent” mailboxes for instance, the JMAP
implementation could provide an aggregated view of them in a similar way to
how the “all mail” view would be done.  Similarly, if “Sent” and “Drafts”
are on the same IMAP mailbox - JMAP could present 2 views onto the
underlying implementation of this.  There are of course issues (where do
Sent messages end up?) but I don’t think allowing multiple Sent mailboxes
addresses that issue anyway.

Having said this, I’m not aware of any actual instances where this is a
problem - I have seen multiple Sent mailboxes created by different (IMAP
and non-IMAP) clients but I don’t think I’ve seen more than one of them
flagged for special use.

Regards,
Gren Elliot

From: Neil Jenkins <[email-masked]> <[email-masked]>
Reply: Neil Jenkins <[email-masked]> <[email-masked]>
Date: 2 October 2017 at 04:05:38
To: IETF JMAP Mailing List <[email-masked]> <[email-masked]>
Subject:  [Jmap] Mailbox#role vs IMAP SPECIAL-USE

This is in reference to GitHub issue #62
<https://github.com/jmapio/jmap/issues/62>.

The role attribute on the Mailbox object in JMAP is equivalent to the
RFC6154 <https://tools.ietf.org/html/rfc6154> SPECIAL-USE flag in IMAP,
however there are some semantic differences so I'd like to solicit some
opinions on what to do. Here are all the differences I can see:

   - *inbox* (It's a hard-coded name in IMAP so you didn't need an
   attribute).
   - *templates* (Drafts that should be used as the basis for new drafts
   but not themselves modified.)

   - \All
   - \Flagged

These are both virtual, and aren't necessary in JMAP because getMessageList
allows you to fetch all/flagged across the whole account without requiring
a special mailbox fox it.

So, what to do. Special-use allows servers to enforce the three differences
in semantics that JMAP specifies (singular, unique, immutable), so one
option is to leave the semantics as is, and IMAP servers can just enforce
them over IMAP as well to keep a consistent view. Alternatively we can
relax the restrictions in JMAP, but I think these are useful properties and
I wonder whether there are people actually making use of the relaxed
options at the moment with IMAP?

Regarding the different roles/attributes, there's RFC6154 didn't create an
IANA registry, so it's not extensible without a whole new RFC. I'm inclined
to just include a mapping in an advice to implementors section.

Cheers,
Neil.
_______________________________________________
Jmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jmap

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 2 Oct 2017 19:24:28 +0100

Hi Neil,

On 02/10/2017 04:05, Neil Jenkins wrote:
> RFC6154 <https://tools.ietf.org/html/rfc6154> SPECIAL-USE flag in 
> IMAP, however there are some semantic differences so I'd like to 
> solicit some opinions on what to do. Here are all the differences I 
> can see:
>
>  1. The value is singular in JMAP, but you can have multiple
>     special-use attributes on the same mailbox in IMAP.
>  2. The value is unique in JMAP (you cannot have two "Sent"
>     mailboxes), but duplicates are allowed in IMAP.
Just to double check: by immutable you mean that a special use attribute 
is set upon mailbox creation and can't be changed after that?

>   * /inbox/ (It's a hard-coded name in IMAP so you didn't need an
>     attribute).
>   * /templates/ (Drafts that should be used as the basis for new
>     drafts but not themselves modified.)
>
>
> getMessageList allows you to fetch all/flagged across the whole 
> account without requiring a special mailbox fox it.
Agreed, that the last 2 are not needed in JMAP.

> actually making use of the relaxed options at the moment with IMAP?
I think keeping JMAP restrictions is Ok. From my experience writing an 
IMAP client that uses SPECIAL-USE, uniqueness is useful (otherwise I 
have to pick one of the values in the IMAP client). I don't find lack of 
singularity to be an issue, but I can live with it as a restriction. 
Immutability is also Ok, although I am Ok with adding special use to an 
existing mailbox. (Isode's IMAP server would allow for that).

> Regarding the different roles/attributes, there's RFC6154 didn't 
> create an IANA registry, so it's not extensible without a whole new 
> RFC. I'm inclined to just include a mapping in an advice to 
> implementors section.
I think we should create a registry. But this can be done in the EXTRA 
WG, if you don't want to do that in your draft.

> Any other opinions on this?
Best Regards,
Alexey

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 02 Oct 2017 14:34:31 -0400

On Mon, 2 Oct 2017, at 14:24, Alexey Melnikov wrote:
> Just to double check: by immutable you mean that a special use
> attribute is set upon mailbox creation and can't be changed
> after that?

>  servers can just enforce them over IMAP as well to keep a
>  consistent view. Alternatively we can relax the restrictions in
>  JMAP, but I think these are useful properties and I wonder whether
>  there are people actually making use of the relaxed options at the
>  moment with IMAP?
I changed the Cyrus server to only allow a single mailbox with each Special-
use value.
Further more, you can only create them or set those special-use
annotations on mailboxes which are at the top level - this is because
people kept dragging their Archive folder into their Trash or similar
nonsense.  Apparently some clients make this far too easy to do.  Then
other clients would notice that the folder was missing and re-create it
(complete with the use) because select-by-use is not a thing.
Oh yeah - finally, you can't delete a folder with a special-use (though
you can remove the use and THEN delete it)
> have to pick one of the values in the IMAP client). I don't find lack
> of singularity to be an issue, but I can live with it as a
> restriction. Immutability is also Ok, although I am Ok with adding
> special use to an existing mailbox. (Isode's IMAP server would allow
> for that).
Cyrus allows adding the special-use later as well, subject to the above
mentioned restrictions.
>> implementors section.> I think we should create a registry. But this can be done in the EXTRA
I agree that EXTRA is the right place for this.

 Bron.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 02 Oct 2017 18:07:17 -0700

I agree with most of this. One scenario that concerns me:

IMAP servers historically haven't required special use and IMAP clients 
have a tendency to create special use folders without applying the 
annotation. So adding a JMAP server to an existing deployment will make 
the situation worse, unless there's some mechanism to apply the JMAP 
role / IMAP special use to existing folders. I see two options to try to 
resolve this mess:

1. Add a rule that JMAP servers that front-end an IMAP mail store SHOULD 
make a best effort to apply the proper JMAP role to existing IMAP 
folders (with configurable names) for IMAP accounts lacking a given 
special use attribute. That is, if the IMAP account lacks a folder with 
a "Sent" role, the JMAP server should look for folders with likely names 
(e.g., "Sent" or "Sent Messages" or translations of that to other 
languages) and apply the IMAP special use and JMAP role.

2. Punt the problem to the client which means JMAP should allow the 
client to set the role on an existing folder.

I think option 1 better fits the JMAP philosophy (whereas option 2 
better fits the IMAP philosophy).

		- Chris

On 1 Oct 2017, at 20:05, Neil Jenkins wrote:

> account
> create
>   1. 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jmapio_jmap_issues_62&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=CV2ZU50KhbEBSQi35_ZaaIwkkARKDVFZWtsO-hqYVVw&s=AMHURIAQ0LIjdYtFTooTcXUjZnmG7d_zxNyw8CZVI-k&e=
>   2. 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6154&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=CV2ZU50KhbEBSQi35_ZaaIwkkARKDVFZWtsO-hqYVVw&s=qJ6gYTGGIauNkAfaqj1C1OnbrD_noYYTthbljTw7UmQ&e=

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jmap&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=CV2ZU50KhbEBSQi35_ZaaIwkkARKDVFZWtsO-hqYVVw&s=F0m7GhRqFfK8sMHrGEM_N-jYGpIGL3KCBnrLUuYl6PU&e=

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 03 Oct 2017 17:01:21 +1100

On Tue, 3 Oct 2017, at 12:07 PM, Chris Newman wrote:
> 1. Add a rule that JMAP servers that front-end an IMAP mail store
>    SHOULD make a best effort to apply the proper JMAP role to existing
>    IMAP folders (with configurable names) for IMAP accounts lacking a
>    given special use attribute. That is, if the IMAP account lacks a
>    folder with a "Sent" role, the JMAP server should look for folders
>    with likely names (e.g., "Sent" or "Sent Messages" or translations
>    of that to other languages) and apply the IMAP special use and JMAP
>    role.
I think this is a good idea (and can go in server advice), but I also
wonder whether it's worth removing the immutable constraint? This is the
least useful of the three, and there's clearly a use case for adding
special use later, particularly when migrating from existing IMAP
systems but also if new roles are defined later and you happen to have a
mailbox you were already using for this purpose. Servers must be able to
reject changes here of course still (particularly removing or changing
an existing role).
Neil.