Re: [Jmap] Submission

[Ted Lemon <[e-mail]>]

On Apr 21, 2017, at 11:02 AM, Ned Freed <[e-mail]> wrote:
> The issue is semantics, not syntax. If your design locks you in to a
> particular set of semantics that cannot be extended - which is what any
> design that fails to allow for capability discovery and attachment of
> arbitrary parameters - you've put yourself in a position where you need
> to continually revise things in order to keep them synchronized as the
> capabilities of the transport infrasture continue to evolve.

Yes, I hear this concern.   I'm saying that it's to be weighed against the benefits of making the JMAP submission protocol primary, rather than nailing it to SMTP submission.   If you nail JMAP submission to SMTP submission, you are excluding any functionality that can't be provided by SMTP submission.   

And as a practical matter, as Arnt said, if SMTP submission continues to be the place where innovation occurs, then this means implementations will have to follow that.   I don't think it's fair to assume that preserving the semantics of SMTP submission in JMAP submission is going to get you to a place of win.

Any JMAP implementation that doesn't use SMTP submission as a backend  is still going to have to track SMTP submission RFCs, or else there will be interop problems.   For such implementations, the need for a JMAP RFC to track relevant new functionality added to SMTP submit is good, not bad.

For the use case you are concerned about, I think it doesn't matter; the point I am making here is just that that is not the only use case we ought to consider.