Re: [Jmap] Submission

[Ned Freed <[e-mail]>]

> On Apr 20, 2017, at 11:06 PM, Ned Freed <[e-mail]> wrote:
> > More generally, the only difference between a JMAP capability tied to, say,
> > a magic header and a SUBMIT extension is syntax. But if you specify things
> > in a way that makes it difficult to map from one to the other, you'll pay
> > the price for that as long as either protocols continue to evolve - and that's
> > going to be a long time.

> I think the distinction comes from whether you actually think that the SMTP
> submission protocol is always going to be what's behind a message submitted via
> JMAP. If you think that, then it's going to look really weird to not just
> replicate that exact paradigm with the JMAP submission process.

I don't think that at all and I doubt anyone else does either, so this 
distinction seems completely irrelevant to me.

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.

None of this is in any way specific to SUBMIT or SMTP.

> However, it's not at all clear to me that that makes any general sense.   I'm
> sure it makes sense in some implementations, but if we were to go that route,
> we would essentially be nailing JMAP to SMTP submission.   There's some value
> to doing this in that it avoids reinventing the wheel, but there is also
> damage, in that the SMTP submission paradigm really isn't particularly
> congruent to the general paradigm of JMAP.

The message transport process is precisely defined as a series of steps that
begin with submission and end with delivery. Nothing in that process says
that SUBMIT has to be used for submission - and it frequently isn't in
practice - but in order to be compatible with the current transport
infrastructure submission does have to occur and where it occurs has to be
well defined.

> The point is that whichever choice we make, we are going to pay a price for
> it.   It's worth asking what that price is, and also asking what the advantages
> are to the choices we have, and then deciding on that basis.   The fact that we
> would pay a price for not replicating SMTP submission can definitely be taken
> as a given.

I'm afraid that's really not the point at all. There are always costs on
both sides of a decision; my point is that the costs on one side of this
decision are significant and ongong, whereas on the other, not so much.

				Ned