Hi
I'll try to clarify a few of these points.
Message representation
JMAP defines a JSON structure that represents in a consistent and structured way all the information that the vast majority of clients need from an RFC5322 message. The server deals with the complexities of MIME, encoding issues, parsing headers etc. The intention is that the server will still operate with RFC5322 messages for storage and certainly transmission; the JSON representation is not intended to replace RFC5322, just relieve client authors from having to deal with it. Clients can also just fetch the properties they need, reducing bandwidth overhead.
Clients that want to or need to (for example those doing PGP in the client) can still fetch the RFC5322 if needed.
Industry need
A number of proprietary protocols have been popping up as alternatives to IMAP, which all also have their own JSON representation of message objects. Here are a few examples, the latter two being from whole companies that formed just to try to help people not have to deal with IMAP:
In addition, we’re seeing most new mobile email clients proxy everything via their own server rather than talking directly to the user’s mail store. Examples include Mailbox (now defunct), Alto, Outlook and Newton. This is bad for security and privacy, and also bad for the client authors as they have to run server infrastructure in addition to just building their clients.
Despite not only being proprietary but patented (and expensive!), ActiveSync has seen a big increase in adoption, and not just with Microsoft servers, due to its better support for mobile environments and ease of setup (one login for mail receive/send, contacts and calendars).
Protocol vs representation
JMAP is a protocol. It primarily defines a way of syncing data objects in a network-efficient, developer friendly way. Objects are defined to represent mailboxes, threads and messages in a consistent manner. These are encoded as JSON for transmission over HTTPS.
Message submission
There is no justification given for this approach. For eachactivity, there needs to be a clear and solid need documented, basedon actual industry activities or at least industry statements.Besides clarifying /what/ needs doing, it should serve to indicatelikely industry uptake after the work is done.
This is based on industry statements. This is a very common support problem we see here at FastMail, and from our conversations with other mailbox vendors, we don't think this is just us.
Flood control
In IMAP, suppose you have a mailbox with 1,000,000 messages in it selected, and another client expunges the lot. You get * 1 EXPUNGE sent to you 1 million times (and you don't even know how many you are going to receive); the only option is to drop the connection if it gets too much. By flood control, we mean the client can ensure it does not get flooded with data, especially important on low-bandwidth connections like many mobile networks and in developing countries. Reducing data usage is of course vital for saving battery, another key concern for mobile.
Similarly, the server has well defined ways of rate limiting the amount of work the client can ask it to do to ensure it too does not get flooded and either accidentally or deliberately DOSed by client requests.
Why HTTP underneath
The short answer is it’s good enough, widely understood and it’s by far the easiest thing for developers to adopt. There’s support in basically all OSes and programming languages. It’s easy to read and debug.
HTTP doesn’t tend to run into firewall issues, and is so commonly used it has integrations which can help with optimisation (for example, iOS has built-in support for optimising radio usage by batching HTTP calls from different apps where possible, which their mail team have told us they would like to be able to use). This isn’t an innate advantage of HTTP, but rather an advantage of its ubiquity.
Statelessness
The protocol does not make use of any connection persistence to the server. HTTPS may establish this underneath, but the protocol on top is agnostic to it. Each request to the server contains an authorisation token (in the Authorization header) to identify and authenticate the request.
Neil.