Last week, the Internet Engineering Task Force (IETF) published JSON Meta Application Protocol (JMAP) as RFC 8260, now marked as “Proposed Standard”. The protocol is authored by Neil Jenkins, Director and UX Architect at Fastmail and Chris Newman, Principle Engineer at Oracle.
Today we're proud to announce a big victory for email tools 5+ years in the making. #JMAP, authored by @neilj of Fastmail and Chris Newman of @Oracle, has been published as RFC 8260 by @IETF. Read about the technology: https://t.co/lAVDTiyigP See the spec: https://t.co/rtwi7oxZ2Z
— Fastmail (@Fastmail) July 19, 2019
What is JSON Meta Application Protocol (JMAP)?
Fastmail started working on JMAP in 2014 as an internal development project. It is an internet protocol that handles the submission and synchronization of emails, contacts, and calendars between a client and a server providing a consistent interface to different data types. It is developed to be a possible successor to IMAP and a potential replacement for the CardDAV and CalDAV standards.
Why is it needed?
According to the developers, the current standards for email protocols, that is IMAP and SMTP, for client-server communication are outdated and complicated. They are not well-suited for modern mobile networks and high-latency scenarios. These limitations in current standards have led to stagnation in the development of new good email clients.
Many have also started coming up with proprietary alternatives like Gmail, Outlook, Nylas, and Context.io. Another drawback is that many mobile email clients proxy everything via their own server instead of talking directly to the user’s mail store, for example, Outlook and Newton. This is not only bad for client authors who have to run server infrastructure in addition to just building their clients, but also raises security and privacy concerns.
Here’s a video by FastMail explaining the purpose behind JMAP:
How JMAP solves the limitations in current standards?
JMAP is designed to be easier for developers to work with and enable efficient use of network resources. Here are some of its properties that address the limitations in current standards:
- Stateless: It does not require a persistent connection, which fits best for mobile environments.
- Immutable Ids: It is more like NFS or filesystems with inodes rather than a name-based hierarchy, which makes renaming easy to detect and cheap to sync.
- Batchable API calls: It batches multiple API calls in a single request to the server resulting in reduced round trips and better battery life for mobile users.
- Provides flood control: The client can put limits on how much data the server is allowed to send. For instance, the command will return a ‘tooManyChanges’ error on exceeding the client’s limit, rather than returning a million * 1 EXPUNGED lines as can happen in IMAP.
- No custom parser required: Support for JSON, a well understood and widely supported encoding format, makes it easier for developers to get started.
- A backward compatible data model: Its data model is backward compatible with both IMAP folders and Gmail-style labels.
Fastmail is already using JMAP in production for its Fastmail and Topicbox products. It is also seeing some adoption in organizations like the Apache Software Foundation, who added experimental support for JMAP in its free mail server Apache in version 3.0.
Many developers are happy about this announcement. A user on Hacker News said, “JMAP client and the protocol impresses a lot. Just 1 to a few calls, you can re-sync entire emails state in all folders. With IMAP need to select each folder to inspect its state. Moreover, just a few IMAP servers support fast synchronization extensions like QRESYNC or CONDSTORE.”
However, its use of JSON did spark some debate on Hacker News. “JSON is an incredibly inefficient format for shareable data: it is annoying to write, unsafe to parse and it even comes with a lot of overhead (colons, quotes, brackets and the like). I’d prefer s-expressions,” a user commented.