Skip to main content

Shepherd writeup

(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.


  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

(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.