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

[Neil Jenkins <[e-mail]>]

On Mon, 1 May 2017, at 09:53 PM, Chris Newman wrote:
> Here's my guess at the root cause:
> * You're trying to mirror a particular client UI model in the mail
>   store server design.
I'm trying to ensure that the API exposes the data clients need to
present common UI patterns in an efficient way, while also allowing the
most flexibility in server implementation. I think we're both aiming for
the same thing!
> 1. I believe there are four message types involved in this discussion:>   * draft messages
>   * client-side outbox
>   * future release RFC 4865 submitted
>   * other submitted messages

I agree, although I don't think the client-side outbox is particularly
relevant to this discussion, as it should not affect the API design. I'm
sorry I brought this up as it side-tracked the discussion somewhat. My
main point was that many existing systems assign submitted "future
release" messages to a separate mailbox on the *server*, and clients
present them to the user distinctly to those that have been released.
What I misunderstood from your proposal, is that rather than marking
messages that can be recalled/cannot be recalled, you propose a
client just look at the "release date" annotation instead. Although
you also say this:
> Actually, my proposal makes this server design approach
> simpler. There's> just an internal flag in the sent folder to indicate if the
> message has> been passed forward. The mail queue daemon that operates on the mail
> store sent folder, can transfer the message to the next hop MTA and
> set> that flag at the future release time. No need to move the message
> between folders.

So the mail queue daemon *does* perform an action on the message in the
mail store when it is sent? I previously thought you were advocating for
a model where these can be completely separate and so this is not
possible. Could you please clarify?
I think we've got various issues conflated a bit over these discussions,
so I'll clarify what I think are the separate questions:
How, if at all, are "future release" messages (that have yet to be
released) marked over the API? Is there a change in the state when they
are released? I agree this may not correspond exactly with whether a
message can be unsent, especially for internal corporate mail systems,
so a related question is: how, if at all, are messages marked that can
be unsent? (This is potentially a tristate: can (almost) definitely
unsend, can definitely not unsend, may be able to unsend).
I think if we can agree on answers to these questions, the rest will
fall out fairly easily.
> 3. I view "submit" and "unsend" as MTA actions that should not be
> confused or conflated with mail store operations. I'm opposed to
> protocol designs where a message move, delete or flag changes triggers> MTA actions as a side-effect.
> Instead, I propose JMAP have explicit "submit" and "unsend" commands
> that first perform the MTA action but can> also trigger mail store actions (like move message or flag change) if
> the MTA action succeeds.
Yes, this is a perfectly fine approach; I'm not opposed to adding
explicit sendMessages/unsendMessages calls. If the call can optionally
set which mailbox(es)/keywords to set upon successful send, then this is
functionally equivalent.
> My proposal is to have future release sent messages tagged with their> future release date. The MUA can create a virtual folder for future
> release messages with a future date. Whether the server caches a count> for the messages in that virtual folder is a server design
> optimization> choice. If enough clients request that count that it helps server
> scalability to cache that count, then servers will cache that
> count. The> count of future release messages is thus not relevant to the
> issue under> debate.

What's relevant is how this count is exposed over the API. If there
is a mailbox, then the synchronisation of mailbox objects will ensure
the client is "pushed" the count; because count changes are common
and clients need to know them to present the most common UI paradigm
for mail, synchronisation of mailbox counts is optimised for in the
JMAP protocol.
One proposal that might satisfy everyone: an "outbox" or "futurerelease"
mailbox role is added (this is the IMAP SPECIAL-USE representation in
JMAP).  Servers can *optionally* have a mailbox with this role; if it
does, clients SHOULD place future-release messages in here, but like
"sent" *can* put the message in any mailbox(es). Servers that have this
mailbox MUST move messages from this mailbox to the sent mailbox at
future release time (which may just be based upon the future-release
date, or may be actually based on releasing it to the mail queue).
Neil.