Re: [ietf-smtp] Fwd: Request to form a new WG: JMAP
John C Klensin <[email protected]> Thu, 10 Nov 2016 09:28:50 -0500
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <E99C5826138657241662E74E@JcK-HP8200> |
--On Wednesday, November 09, 2016 19:57 -0800 Ned Freed <[email protected]> wrote: >> > Which would seem to exclude SUBMIT, unless >> > you're doing SUBMIT with magic folders > >> Most likely, yes. > And as I indicated previously, that's a problem, because magic > folder are a poor means of doing message submission, mostly > because of their lousy error handling. It is also worth noting that magic folders have been repeatedly proposed for IMAP and rejected every time, always for reasons that included the above. If you decide to charter this, please let's be sure that there are built-in mechanisms for adequate review that considers those prior discussions. In principle, I'm not opposed to a carefully-considered decision that reaches a different conclusion, but "carefully-considered" --and not just by advocates of this work -- is key. >From my point of view, we went to the trouble to separate message submission from SMTP for only two important reasons: to make it clear what things a submission server could reasonably do (and be expected to do) that an SMTP relay could not and to permit (and encourage) a better error-handling model among cooperating parties. At least for me, that created a message creation and submission model that was a partnership between the creating MUA and a first-hop server, paralleling what we've often called a "split MUA" model between an IMAP (or POP) server and client at the receiving end. Again, if a different model is really needed --and, so far, I'm not convinced -- those advocating it should be required to demonstrate to the community that they understand all the implications of discarding or bypassing the older one. best, john > But this really isn't the time to get into details. My point > here is that if > you're going to do message submission, you need to get it > right - something > essentially none of the current specifications do - and > that's going to > require an expansion of the model being proposed here. > best, john _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext