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

["Chris Newman" <[e-mail]>]

On 25 Apr 2017, at 22:41, Bron Gondwana wrote:
>> I really want a fourth option for server implementation:
>>
>> 4. The mail store and mail queue are completely separate. The mail 
>> queue
>> daemon never accesses the mail store. The set of actions JMAP 
>> performs
>> on objects in the mail queue is limited to only those that are 
>> strictly
>> necessary to achieve a useful goal (envelope extensions like future
>> release at submission time, unsend for messages still in local queue,
>> and status feedback tagging on sent messages).
>
> You appear to be proposing one of:
>
> a) there is no support for delayed sending or undo
> b) the user has no visibility or control of queued messages after 
> submitting them
> c) the user can control queued messages, but needs to use a different 
> protocol than JMAP to do it
> d) a new object type for queued messages needs to be defined in JMAP, 
> with operations that allow achieving the above useful goals.
>
> If (d), are you willing to write up the object definitions and client 
> advice for how they would be used, so they can be tested?

I'll describe a model that achieves my goal (which is to provide the 
desired future release & unsend functionality without requiring the 
server to implement a storage model with combined mail store and mail 
queue semantics). I don't want to get bogged down in specification 
details yet.

Here's one way to accomplish my goal:

1. Get rid of the server-side outbox. We only have a drafts folder and a 
sent folder.

2. Add a submission command with envelope (same structure as SMTP 
envelope but JSON syntax and quoting). We pass this command a reference 
to a draft message in the drafts folder, and if the submission succeeds, 
the message is moved to the sent folder with the envelope as an 
annotation. The envelope can include the already-standard future release 
extension.

3. Add an unsend command which takes a reference to a message in the 
sent folder. If the unsend succeeds, the message can be moved back to 
the drafts folder as part of this action. How the server correlates a 
message in the sent folder with a message in the mail queue is an 
implementation detail; the spec need not specify that detail in order to 
provide the functionality with this model.

4. Add a way to search/select messages in the Sent folder that may be 
possible to unsend.

This model has a lot of advantages over the outbox model:

* 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.
* This does not unnecessarily constrain server implementation, and 
permits simpler server designs.
* This preserves clean mail store and mail queue separation including 
the security and operational benefits that provides.
* 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).
* Submission can have semantics fully compatible with existing 
infrastructure, making this easier/faster to deploy.
* 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.

		- Chris