Re: [Jmap] Submission

[Ned Freed <[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.

This is a entirely false dichotomy of choices you have going here. Nobody is
proposing "nailing it to SUBMIT". All anyone is saying is that you need to
have a means of specifying the envelope separate from the message and its
headers, and that the envelope needs to be extensible.

Aside from the fact that SUBMIT happens to be a protocol that implements these
semantics (actually with some limitations that probably should be removed in
JMAP), this has nothing to do with using SUBMIT.

If, given this framework or a superset of it, you want you implement mechanisms
that cannot be implemented in SUBMIT, that's an entirely separate discussion,
and I look forward to the specification describing such a mechanism.

The long and short of it is I really don't understand why you persist in
worrying about SUBMIT, but since neither of these fundamental concepts we're
concerned with having in JMAP originated in SUBMIT or even SMTP, maybe it would
help to name them after where they did (AFAIK) originate.

So if I say "IFIP style envelope/message separation" and "X.400-1988
style extensible envelope parameters", does it help?

> 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.

Indeed it does. And without having the right semantics they will do so slowly
and painfully.

> 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.

Again with characterizing this as all about SUBMIT. It isn't.

> 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.

Actually, no, it won't. We've been down this path before with nonextensible
submission APIs of various sorts. It has not gone well.

> For such implementations, the need for a JMAP RFC to track relevant new
> functionality added to SMTP submit is good, not bad.

So rather than having a clean extensible architecture with minimal costs to
use, you're arguing that we should start with a much more limited architecture 
that requires unnnecessary specifications to extend?

This strikes me as fundamentally wrongminded.

> 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.

If you can name a possible use case that is hindered by having an extensible
separate envelope, I'd love to hear what it is and why this is the case.

				Ned