Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP)

[Neil Jenkins <[e-mail]>]

On Thu, 27 Apr 2017, at 02:06 AM, Chris Newman wrote:
> Well, if you believe that and I don't believe that,

Then clearly we need to discover where the divergence in mental models
is occurring.

> * Every server that supports future release and unsend will provide
>   the same interface to the client. No need for the "always empty
>   outbox" alternative server behavior that you'll see with the outbox
>   model.

The server will have to advertise whether it supports scheduled send
regardless of the mechanics underneath. For servers that do not support
scheduled send, I agree that an always-empty outbox mailbox may feel a
little superfluous, however the point is to, as you say, always provide
the same interface to the client regardless. The client will know from
the capabilities that it must always be empty, so will probably hide it
in the sidebar or equivalent navigation mechanism (in fact I expect
clients will probably hide the outbox when empty regardless of scheduled
send support).

> * This does not unnecessarily constrain server implementation, and
>   permits simpler server designs.

I do not believe this to be the case, as I will explain below.

> * This preserves clean mail store and mail queue separation including
>   the security and operational benefits that provides.

This is I think where the confusion lies. The outbox really isn't a mail
queue, and no one is suggesting you merge it with your mail store.

You clearly have existing infrastructure that supports holding scheduled
messages inside your mail queue and possibly cancelling them from that.
You wish to reuse this infrastructure, of course! That's fine. To do so,
when the message is moved to the outbox, you would *also* submit it into
your mail queue. The copy in the outbox would be the representation in
JMAP land, not part of your mail queue. When the message is sent to the
next hop and can no longer be recalled, you then move the JMAP message
from outbox to sent, and remove the `\Draft` keyword.

Other systems may choose to implement it differently, not passing it to
the mail queue until the scheduled time is reached. As has been pointed
out already, many systems such as Gmail, FastMail etc. already have
infrastructure to do this kind of thing since it is also used for
deleting messages that are X days old from the trash, supporting snoozed
mail, etc.

The outbox protocol is agnostic to how you wish to implement this. Your
proposal constrains you to only the option *you* already have
implemented.

> * This makes it clear when the message enters the submission system.
>   There's no confusion as one has with an outbox model where a message
>   in the outbox may be submitted (if it's on the server) or maybe not
>   (if the client is offline when the message moves to the outbox).

This is clearly up to the client to distinguish, but I strongly disagree
this is a confusion. For the user, there is the outbox, which represents
the messages that are yet to be sent. If they open the outbox, I expect
most MUAs would label why they have not yet been sent (e.g. waiting for
internet connection, scheduled for time X).

> * Submission can have semantics fully compatible with existing
>   infrastructure, making this easier/faster to deploy.

As mentioned above, a lot of systems already have infrastructure for "do
action X in folder Y when time Z is reached", or you can alternatively
use your SMTP-queue-scheduled-send to implement the outbox model, so
this is actually *more* compatible with existing infrastructure than
your proposal.

> * The "outbox" model constrains unsend to only work if the message is
>   in the outbox. This model has no such constraint and works the same
>   regardless of where a message that can be "unsent" lives in the
>   infrastructure.

When composing and sending a message, it goes through 2 or 3 states.
These need to be represented in the mail store (and thus the protocol)
so that users can understand what is going on, and what actions are
available to them.

Two of these we (I believe) agree on, since they are from IMAP:

(1) The message is still being composed. It SHOULD be in the
    "drafts" mailbox and MUST have the "\Draft" keyword. This is the
    same as IMAP.
(2) The message has been sent, cannot be recalled. It SHOULD be in the
    "sent" mailbox (although services may provide means for users to ask
    it to go somewhere else, for example we have a few users that prefer
    their sent mail to in the same mailbox as the message they were
    replying to).

The third (new) state is for "scheduled" messages. We have two options
for how this is represented:

1. By its presence in the "outbox". Moving it out is therefore the
   logical thing to unschedule it.

2. By a keyword. This permits it to be in any mailbox, although we would
   probably add an outbox mailbox to our server for holding these
   messages by default. Removing the keyword would probably be a logical
   way to unschedule it. This option is quite a bit less efficient at
   the protocol level, as without a Mailbox object (which has a
   precalculated total count), the client will have to issue a search
   every single time there's a state change to see if there are any
   scheduled messages.

I'm presuming you are not advocating for option (3), which is no
representation in the mail store, since this would be terrible for the
user experience, and your proposal explicitly said "Add a way to
search/select messages in the Sent folder that may be possible to
unsend", which would indicate there must be some kind of state
representing this status.

So however you implement it, you need to trigger some state change on
the JMAP server for each logical step so that clients can represent
this, and update its local model as changes occur. The choice of
representation is mainly down to what will map more easily to how
clients wish to represent the set of scheduled messagese to users.

UX designers seem to have overwhelmingly decided that putting these
scheduled messages in an outbox rather than mixing them in with sent
items or elsewhere is a clearer model for users to understand. I
provided 5 example products in the previous email that do this, but if
that's insufficient I noice we have representatives from Apple, Google
and AOL on this list; perhaps they can ask their respective UI teams to
comment on what they would recommend?

Neil.