> "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP Not actually true; the protocol does not require HTTP.

> "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP Not actually true; the protocol does not require HTTP. Any bi-directional stream transport will work just as well. > "M" is misleading because this protocol is designed for a lot more than mail. Maybe "Messaging" would have been better. I don't know. Part of the JMAP name is to make it look like IMAP so its easy to see the relationship. J is after I. And so on. But lets not quibble about names. Perhaps its not a great name. It doesn't really matter because products get different, better names. > reinvented HTTP > yet another bloated protocol This is kind of "citation needed" stuff. I'm not saying JMAP is perfect, in concept or in implementation, but we've have a shipping product running on it for a couple of years. Its got runs on the board already, and we're inviting everyone to pick it apart and make it better. > IMAP+SMTP using a stateless protocol would be cool Both IMAP and SMTP are inherently stateful, and that's not the worst of their problems. Why not fix it all properly?