Re: [Jmap] Submission

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

On 19 Apr 2017, at 12:36, Ted Lemon wrote:
> On Apr 19, 2017, at 3:29 PM, Chris Newman <[e-mail]> 
> wrote:
>> When deploying a large mail service it's important to keep the 
>> submission mail queues (which have management/monitoring issues) 
>> functionally separate from the mail store (which has very different 
>> management/monitoring issues). If the JMAP design requires a mail 
>> queue to be present on the JMAP server or present in the mail store, 
>> that is an unacceptable protocol design error as it hinders the 
>> manageability of large deployments.
>
> Isn't this just an implementation detail?   IOW, how is it different 
> to have a different protocol for queuing messages, versus having 
> different handling for a mailbox with a specific name?

Not at all. Protocols can either be architecture neutral or impose an 
architecture on the system. An example where IMAP imposed an 
architecture on the system is the \Deleted flag and EXPUNGE command. 
This requires a server mail store to have a concept of deleted messages 
within a folder; something that doesn't fit well if the mail store had a 
"trash folder" model. And while it's possible to implement a virtual 
trash folder in a mail client using the \Deleted+EXPUNGE model so this 
wasn't a UI-constraining protocol design error, it turns out that 
clients didn't do that and decided to ignore the IMAP base spec 
semantics and impose the trash folder model on IMAP servers. That 
interoperates badly without correct implementation of RFC 6154 on all 
clients. So that's an example of a protocol design error imposing 
architectural constraints that resulted in real world problems.

To clarify my point, I think having an "outbox" with combined mail store 
and mail queue semantics as a mandatory architectural element of JMAP is 
a protocol design error because it breaks functional separation. And 
that violation of functional separation is particularly problematic in 
larger deployments where mail stores and mail queues each add management 
and monitoring complexity and require different designs and storage 
models to scale effectively.

JMAP needs to have a submission action that has semantics matching the 
IETF Submission standard. It's fine for that command to pull data from 
the mail store as part of the submission action (as RFC 4468 does). But 
the JMAP protocol needs to allow implementations where mail queue and 
mail store semantics are separate.

		- Chris