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:
* Gmail[1]
* Outlook[2]
* Nylas[3]
* Context.io[4]
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 each
activity, there needs to be a clear and solid need documented, based
on actual industry activities or at least industry statements.
Besides clarifying /what/ needs doing, it should serve to indicate
likely 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.
Links:
1. https://developers.google.com/gmail/api/v1/reference/
2. https://msdn.microsoft.com/office/office365/APi/mail-rest-operations
3. https://nylas.com/cloud/docs
4. https://context.io/docs/lite