(1) The type of RFC requests is Proposed Standard. The title page
currently says "Standards Track".
(2) Document Announcement Writeup
Technical Summary
JMAP-Core specifies a protocol for clients to access JSON-based
data objects efficiently, with support for push and out-of-band
binary data upload/download.
This document was produced in conjunction with
draft-ietf-jmap-mail, which is the first specific set of
objects and access methods built upon the described mechanisms.
Working Group Summary
The initial proposal included an authentication method which was
removed based on feedback from the HTTP and security groups that
it would be controversal, instead JMAP-core just allows for an
authentication layer to be present and restricts itself to the
object transport over that layer.
The object naming and other parts of core underwent significant
revision based on feedback from the group, and it's been in
roughtly the same shape with consensus for the last 6 months as
small consistency fixes were made and feedback from real world
implementation was gathered.
Document Quality
The only known implementations of the latest protocol have been
done by FastMail staff, but there exist multiple implementations
of earlier drafts, and their authors have read the current
drafts - they're just waiting until publication to update to the
latest version. Both client and server implementations are
available as open-source.
The JMAP working group is small, but there have been multiple
people who have read the document carefully - Chris Newman who
is now listed as an author gave particularly detailed reviews.
The authors of the various parts of the FastMail stack that are
now implemented on this spec, and of the two test suites covering
the spec, have also found multiple issues in the last 6 months
which have fed back into the final document.
Multiple email server vendors have indicated their intention to
either add JMAP to their existing servers, or to build new
services on top of the JMAP data model.
Personnel
The Document Shepherd is Bron Gondwana and the Responsible
Area Director is Alexey Melnikov.
(3) The document has had a complete read through of version 10 by the
Document Shepherd, which led to a handful of clarification questions
that made it into verison 11, and idnits fixes for version 12.
I have also implemented most of it and reviewed code from others
implementing other parts.
(4) With a document of this size, there's always a possibility that we
missed something important, but multiple reviewers with long-term experience
in these kinds of protocols have been over the documents, including nit-picky
test writers. I'm confident that it's implementable as specified.
(5) With the removal of authentication, the only review required is from
the HTTP working group. Multiple members of that group attended early JMAP
meetings and were satisfied that JMAP uses HTTP appropriately.
(6) The Area Director has been heavily involved in the working group,
there are no specific concerns with the document that I'm aware of.
(7) Yes, each author listed at any point on both the current and earlier
drafts has been contacted and confirmed that they have no disclosures.
(8) There have been no IPR disclosures filed.
(9) The working group is small, but everyone has spoken. There's have been
no objections to any of the recent changes, and there's full consensus of
the group.
(10) Nobody has threatened any appeals or objections.
(11) IDnits on -12 found only warnings where the tool misdetected
text.
(12) There are no formal review areas required.
(13) All references within this document been identified as
either normative or informative.
(14) There are no normative references awaiting advancement.
(15) There are no downward normative references references.
(16) Publication of this document will not change the status of any
existing RFCs.
(17) The IANA considerations sections requests that two new
registries are created, both of which provide for community
discussion and expert review. The process for future changes
is well described, and both registries fully document their
initial contents.
(18) The two new registries that require expert review are
the "JMAP Capabilities registry" and "JMAP Error Codes registry".
It would be sensible to use the same expert reviewer for both
registries. It would help for the expert to be somebody with
protocol development experience and able to identify mistakes
that limit future possibilities. Email experience would help,
but is not required.
(19) The formal sections are JSON. One of the authors recently
tested all the examples in the document to be parseable, and
most have been copied directly from network dumps out of
working systems using the protocol.