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