Subject: [Jmap] Destroying mailboxes: how this affects messages

From: Neil Jenkins <[email-masked]>
Date: Mon, 04 Sep 2017 14:54:13 +1000

As per #69[1], this needs some discussion. If a mailbox has messages in
it and the client tries to destroy it, what should happen? The spec
currently says this must be rejected with an error, following the
general JMAP philosophy that changes made by the client must be explicit
rather than implicit.
The IMAP model is of course different: the messages in the mailbox would
be implicitly removed from this mailbox, and if not in any other mailbox
they would also be permanently destroyed. This is why I think this model
is dangerous. In a system where messages can belong to multiple
mailboxes, removing a mailbox (deleting a label) makes sense, but you
don't want the message to be destroyed. However, for IMAP compatibility
we require all messages in JMAP to be in at least one mailbox. So if
this was the only mailbox the message was in, the message must also be
either destroyed or automatically added to another mailbox (which I
think is even more problematic). Making it an error requires the client
to deal with this situation first in an appropriate way.
Opinions on the right action here?

Neil.

Links:

  1. https://github.com/jmapio/jmap/issues/69

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Sep 2017 08:41:18 -0400

> Opinions on the right action here?

Have a mailbox called "all" that every message is always in. Or, as you say, make it an error to delete a non-empty mailbox. But I prefer "all" because enforcing that restriction could be incompatible with a label-based inbox paradigm, where we would expect labels to potentially be quite ephemeral.

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 04 Sep 2017 22:47:16 +1000

On Mon, 4 Sep 2017, at 22:41, Ted Lemon wrote:
> On Sep 4, 2017, at 12:54 AM, Neil Jenkins
> <[email-masked]> wrote:>> Opinions on the right action here?
> 
> Have a mailbox called "all" that every message is always in.
> Or, as you> say, make it an error to delete a non-empty mailbox. But I
> prefer "all"> because enforcing that restriction could be incompatible with a
> label-based inbox paradigm, where we would expect labels to
> potentially> be quite ephemeral.

If I was building a client and wanted to allow removing a label, I'd
search for the list of all ids for the messages with that label.  The
client would also say "removing label from <n> messages, as you sure",
and then if you said yes, it would do a setMessages to remove the label
from those messages followed by a setMailboxes to delete the label.
Bron.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 4 Sep 2017 15:49:00 +0100

Ted Lemon writes:
> Or, as you say, make it an error to delete a non-empty mailbox.

Or make it an error to delete a mailbox if that involves actually deleting 
a message. That seems to be the heart of the matter, why not put it like 
that in the spec?

Arnt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Sep 2017 11:50:06 -0400

Because that perpetuates the idea that mailboxes are containers.  And it
still requires the behavior that Bron was describing: the client has to
have a full inventory of the set of messages to which that label has been
applied.

On Sep 4, 2017 10:49, "Arnt Gulbrandsen" <[email-masked]> wrote:

Arnt

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 4 Sep 2017 20:28:22 +0100

Ted Lemon writes:
> Because that perpetuates the idea that mailboxes are 
> containers.

That's not what I intended to suggest. Rather, that (some?) containers are 
going to be visible as mailboxes, most importantly "all mail", and that 
precisely this is the reason to deny delete.

> And it still requires the behavior that Bron was 
> describing: the client has to have a full inventory of the set 
> of messages to which that label has been applied.

That's programmerthink: Corner cases are exciting, let's spend most of the 
text discussing them! ;)

Does JMAP really, really need to specify things like "all mail"? Isn't it 
enough to say that the server shouldn't delete a mailbox if that requires 
actually deleting messages, and that if clients are not urged to try to 
provide this capacity, lest a misclick cost users all their mail because 
the thing the user _wanted_ to click was the line below "all mail".

Arnt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Sep 2017 18:39:34 -0400

Why would deleting the last label that applies to a message have the
semantics that the message should be deleted?

On Sep 4, 2017 3:28 PM, "Arnt Gulbrandsen" <[email-masked]> wrote:

> Ted Lemon writes:
>
>> Because that perpetuates the idea that mailboxes are containers.
>>
>
> And it still requires the behavior that Bron was describing: the client
>> has to have a full inventory of the set of messages to which that label has
>> been applied.
>>
>

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 05 Sep 2017 10:55:02 +1000

> semantics that the message should be deleted?
One of the goals of JMAP, and I think this is important to allow for
migration, is that a server should be able to serve up both an IMAP and
JMAP view of a mail store and these are consistent, so a user might
simultaneously use an IMAP and a JMAP client.
Suppose a message X is in both Foo and Bar. Over IMAP this is exposed as
two different messages, but in JMAP they can be exposed as a single
message in two mailboxes. Deleting the Foo mailbox via IMAP deletes all
the messages in it. In JMAP you would see the Foo mailbox disappear, and
an update to message X that removed the Foo from its list of mailbox
ids. If you now deleted Bar via IMAP, the message would no longer be in
any mailbox so therefore deleted in JMAP as well.
So if we just matched IMAP behaviour, deleting the last "label" would
have the semantics of deleting the message.
I really don't like the idea of mandating an "All mail" mailbox that
every message must belong to. Either you have to expose this via IMAP
(which Gmail does, and it causes all sorts of issues if the IMAP clients
are not specially coded to deal with it as that's not how IMAP is
expected to work), or if you don't expose it via IMAP that means you now
have mail that can only be accessed via JMAP, breaking the goal of
allowing dual use for easier migration.
I think I lean towards the current spec, which simply makes it an error
to try to remove a mailbox that has messages in it, and forces the
client to deal with them first. This is easy to implement, and doesn't
break IMAP compatibility.
Neil.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Sep 2017 21:24:20 -0400

Hm.   I will freely admit that I think IMAP compatibility in the sense of perfectly compatible back-ends is a waste of time, and IMAP as a first-class client is also a bit of a waste.   So that may be why I see this differently.   To my mind, it seems perfectly reasonable to say that the behavior for IMAP clients isn't consistent.   This is what IMAP users are already accustomed to.   I think it's more important to get the semantics of JMAP right than to perfectly mirror IMAP.

I realize that I may be being overly idealistic, but if it were up to me, that would be my preference.   I do not have a problem with the way IMAP works on gmail.   I use it every day—indeed I'm using it to write this message—my mail server is G Suite.

From that perspective, I think that the semantics of an "all mail" mailbox are perfectly acceptable, and meet the mandate to support IMAP for the purposes of migration.   After all, if the experience on IMAP is perfectly fine, but the experience on JMAP is better, that's going to be a minor but still probably significant driver in conversions over time.

> On Sep 4, 2017, at 8:55 PM, Neil Jenkins <[email-masked]> wrote:
> 
>> Why would deleting the last label that applies to a message have the semantics that the message should be deleted?
> 
> One of the goals of JMAP, and I think this is important to allow for migration, is that a server should be able to serve up both an IMAP and JMAP view of a mail store and these are consistent, so a user might simultaneously use an IMAP and a JMAP client.
> 
> Suppose a message X is in both Foo and Bar. Over IMAP this is exposed as two different messages, but in JMAP they can be exposed as a single message in two mailboxes. Deleting the Foo mailbox via IMAP deletes all the messages in it. In JMAP you would see the Foo mailbox disappear, and an update to message X that removed the Foo from its list of mailbox ids. If you now deleted Bar via IMAP, the message would no longer be in any mailbox so therefore deleted in JMAP as well.
> 
> So if we just matched IMAP behaviour, deleting the last "label" would have the semantics of deleting the message.
> 
> I really don't like the idea of mandating an "All mail" mailbox that every message must belong to. Either you have to expose this via IMAP (which Gmail does, and it causes all sorts of issues if the IMAP clients are not specially coded to deal with it as that's not how IMAP is expected to work), or if you don't expose it via IMAP that means you now have mail that can only be accessed via JMAP, breaking the goal of allowing dual use for easier migration.
> 
> I think I lean towards the current spec, which simply makes it an error to try to remove a mailbox that has messages in it, and forces the client to deal with them first. This is easy to implement, and doesn't break IMAP compatibility.
> 
> Neil.

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 12 Sep 2017 20:45:29 -0700

There are a bunch of useful goals I'd want this to address:
* make the behavior explicit
* retain compatibility with an IMAP mail store (within reason), as 
required by the WG charter
* make it easy for clients to use
* don't constrain client model unnecessarily (a mistake made with IMAP 
\Deleted model)

So how about adding "onLastReferenceMoveTo" attribute with a mailbox ID 
value to setMailboxes?

If that attribute is omitted, the destroy mailbox action fails if it 
would leave any message unreferenced (as Arnt suggested). If there's a 
mailbox with "all messages" role, the client can use that if it wants to 
delete a label in that class of message store. Otherwise inbox or trash 
or archive are reasonable options, depending on the client UI.

		- Chris

On 3 Sep 2017, at 21:54, Neil Jenkins wrote:

>   1. 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jmapio_jmap_issues_69&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=RAwHDp1kpF_qCXknEQgF9flzE1a_zDj2fMKZXuWf0OY&s=_8zDKKoAppv1qycFv1Lz0LmKGMX7HyjZ3eWm1Vo1wOE&e=

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

---

From: Neil Jenkins <[email-masked]>
Date: Mon, 18 Sep 2017 11:28:51 +1000

On Wed, 13 Sep 2017, at 01:45 PM, Chris Newman wrote:
> So how about adding "onLastReferenceMoveTo" attribute with a mailbox
> ID value to setMailboxes?
The "special-case"ness of this annoys me slightly, but the functionality
is useful. How does this look to people:
https://github.com/jmapio/jmap/pull/145?
Cheers,
Neil.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Sep 2017 21:33:54 -0400

On Sep 17, 2017, at 9:28 PM, Neil Jenkins <[email-masked]> wrote:
> The "special-case"ness of this annoys me slightly, but the functionality is useful. How does this look to people: https://github.com/jmapio/jmap/pull/145? <https://github.com/jmapio/jmap/pull/145?>
LGTM!