Re: [Jmap] Submission

[Ned Freed <[e-mail]>]

> On Apr 23, 2017, at 7:13 PM, Ned Freed <[e-mail]> wrote:
> > 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.

> If that's the case, then I don't think there's anything to argue about.   But I've been getting the impression that that's not the case.   I am fully in agreement with the assertion, with which I don't recall anyone disagreeing, that the envelope has to be separate from the message and has to be extensible.

> My concern is with avoiding a requirement that JMAP submit have the same
> _flow_ as SMTP submit.

Huh? Nobody has said that. AFAIK nobody has even hinted at that.

> So I want it to be the case that status can be delivered asynchronously,
> essentially.   I don't mind if it's also possible to deliver it synchronously,
> since that's just a degenerate case of asynchronous.

That's a completely different matter, and in that regard, I'll just make
a few observations:

(0) Synchronous delivery of status is, with the exception of a handful of
    egregiously broken clients, always going to provide the better user
    experience. This has everything to do with how people are wired and
    nothing to do with the technology.

(1) SUBMIT and SMTP both have the ability to deliver status both synchronously
    and asynchronously. We call the latter "DSNs". They have not worked out
    well.

(2) Asynchronous delivery of status information is NOT a degenerate case
    of synchronous delivery. For example, it's entirely possible for a SUBMIT
    server to always return success status codes and issue a DSN later. (In
    fact our SUBMIT server can be set to do exactly this, in order to
    deal with the aforementioned egregiously broken clients.)

(3) The argument that DSNs being in-band rather than an out-of-band mechanism
    is the root cause of all the problems in this area doesn't fly. Out-of-band 
    mechanisms for message status reporting have been tried - the obvious
    example is X.400 - and if anything they've worked less well than
    the in-band approach taken in SMTP. So nobody should assume that the
    definition of such a mechanism will magically lead to glory.

(4) There seems to be an assumption that an alternative asynchronous
    notification mechanism is something  that SUBMIT could not do. If so,
    that's incorrect. In fact I can easily imagine a SUBMIT extension that
    would specify an alternative mechanism for reporting delivery
    success/failures, which the server would then employ instead of
    generating one or more DSNs.

    In fact this would be so trivially easy to implement modulo whatever
    the backwards-pointing notification mechanism is I bet I could do it
    in only and hour or two of coding.

(5) Implementing proper error handling is hard, getting everyone to implement
    it correctly is probably impossible.

(6) There are a host of problems associated with the Outbox/Sent magic folder 
    proposal that have nothing to do with anything being discussed here.

In fact I believe I'm going to coin a new term at this point - the FUSMEHP. I
bet you can geuss what it means.

				Ned