JMAP News: RFC 8620 Published
The first time that I heard of JMAP was in the technical section of Fastmail’s blog at the end of 2014…
“JMAP is Fastmail’s protocol with the warts removed. We leverage existing standards like HTTP, JSON, and native push channels on platforms which have them – making it easy for developers to work with.”
The protocol that Bron Gondwana, Fastmail’s CEO, is referencing is the client and API that Fastmail had built to support their users and provide a great user experience for their customers. They decided to take this protocol that they had developed and create an open standard.
The current version was submitted for specification in March of 2017, and after 18 revisions, we are pleased to report that the email protocol has finally been accepted. This is good news for two reasons. First, because of what this means for the development of open protocols. And second, because as early adopters of JMAP, we’ve invested a lot of time and development cycles into atmail’s JMAP-based product (atmail suite).
JMAP Specification Published
On 24 July 2019, the Internet Engineering Task Force (IETF) published the core JSON Meta Application Protocol (JMAP) as RFC 8620, marking a major milestone for the messaging industry and the team(s) behind JMAP. The acceptance of this RFC will help ensure that future development of messaging solutions leveraging JMAP will adhere to the same rules.
As defined in RFC 2026:
“In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognisably useful in some or all parts of the Internet.”
The published specification only defines the core mechanism for data synchronisation, as the JMAP specification was split into multiple parts:
While the Mail, Contacts and Calendar portions of the protocol rely on the core, they are different enough and there is a significant use for each of them separately, that splitting the specification at these points makes sense as individual projects. It should also allow each of them to move forward as individual specifications more quickly than if they were all packaged as a single project.
Early JMAP adoption
In 2017, we wrote a piece on how JMAP makes email better and where we thought JMAP fit into the overall user experience of email. At the heart of this conversation is how people consume email today compared to ten (or even five) years ago. With the continued swing towards the use of mobile devices, and the exclusive use of mobile devices for many, this conversation is even more relevant today than it was two years ago.
JMAP helps fix many of the problems with the way clients communicate with email systems today.
- IMAP is a stateful protocol, relying at times on a persistent connection.
- JMAP is stateless. For mobile devices, this means a better experience in less than ideal connectivity.
- IMAP IDLE requires this persistent connection to inform the IMAP client of changes made to the system, and then it only updates you to the changes of the folder you are in.
- JMAP operates on event triggers, both client side and server side, which push data to and from the client and server respectively, based on these events.
- IMAP is often used by traditional email clients for syncing messages on the system, but a separate connection is used for sending messages.
- JMAP provides the ability to both sync and submit messages to the SMTP server. This provides an opportunity to improve the usability of the product by only requiring one form of authentication, so that you don’t have to authenticate to the IMAP server and the SMTP server separately.
These reasons are just a sample of why we started looking at JMAP as a real solution to the problems we saw with email, as well as why we have looked at it for our Contact and Calendar systems as well.
Moving forward
From a big picture perspective, I believe that the email industry needs a better solution for creating an awesome experience for email users and I believe that JMAP can help provide this experience.
The protocols designed for messaging, and specifically email, are dated, and the technology that we use to communicate over these protocols are advancing beyond their reasonable use. This is why so many versions (Gmail, Outlook, Nylas and Context.io to name a few) of a ‘solution’ are available – all built on proprietary APIs.
There is nothing wrong with proprietary software, and these might need to exist for the standardisation of a new protocol to happen. If this is the case, I am glad for it. But with JMAP, we now have a strong foothold on an open protocol that offers a solution, available to everyone, and I am hopeful that the publication of RFC 8620 furthers more solutions provided by JMAP.
JMAP and IETF
To read a quick post about JMAP’s journey through the IETF process and to read Bron Gondwana’s take on how the modern, open email protocol can benefit users, please visit the IETF site here. To watch a quick JMAP overview from Bron, please see the video below.
More Posts
