On Feb 8, 2017, at 2:26 AM, Yoav Nir <ynir.ietf@xxxxxxxxx> wrote: > That’s good to know. I’m wondering if implementing a generic email client (rather than a specific “gmail” or “live” client) isn’t becoming ever harder. With so many older and newer services, a client has to support pop3, imap, smtp, EWS, ActiveSync, and maybe a few of the others you mentioned. This effort proposes to add yet another one. The protocol and database backend parts of implementing a mail client are only difficult in the sense that ActiveSync is not a standard. IMAP, SMTP and POP protocol implementations are readily available. The problem is not that they are hard to implement. It's that they don't work very well. SMTP works great, don't get me wrong, but IMAP and POP both use the wrong data abstraction, and consequently are very hard to get right, and generally aren't gotten right. So a new protocol that has the data abstraction right is actually a substantial improvement. I don't know if that's the case with JMAP—if it's the same data abstraction as IMAP, it's not worth bothering with, but that's something that at least in theory can be discussed. What JMAP does afford is the opportunity to have an embedded web client that doesn't suck, and a way to escape it if you want something more stateful. Doing IMAP in a web browser is painful. I've seen it done. It wasn't pretty, and the company that did it corkscrewed in and left a crater. So practically speaking, if you want to do email that way, you are already implementing something like JMAP, but you are doing it by yourself, and it's not standard, so your customers are stuck with what you did. Even if the data abstraction is wrong in JMAP, you still get a substantial win from that one improvement.