Skip to main content

The JSON Meta Application Protocol (JMAP)
draft-ietf-jmap-core-17

Revision differences

Document history

Date Rev. By Action
2019-07-16
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-06-10
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-05-20
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-04-03
17 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-04-03
17 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2019-03-28
17 (System) IANA Action state changed to Waiting on Authors
2019-03-25
17 (System) RFC Editor state changed to EDIT
2019-03-25
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-03-25
17 (System) Announcement was received by RFC Editor
2019-03-23
17 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-03-23
17 Amy Vezza IESG has approved the document
2019-03-23
17 Amy Vezza Closed "Approve" ballot
2019-03-23
17 Amy Vezza Ballot approval text was generated
2019-03-23
17 Alexey Melnikov IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-03-23
17 Mirja Kühlewind
[Ballot comment]
Thanks for considering my discuss!

Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)!

----------------------------
Old comment (for the …
[Ballot comment]
Thanks for considering my discuss!

Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)!

----------------------------
Old comment (for the record):
----------------------------
One question regarding sec 9.4.1.:
How long should IANA wait for comments before the registration is performed?
2019-03-23
17 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2019-03-20
17 Cindy Morgan New version available: draft-ietf-jmap-core-17.txt
2019-03-20
17 (System) Secretariat manually posting. Approvals already received
2019-03-20
17 Cindy Morgan Uploaded new revision
2019-03-08
16 Benjamin Kaduk [Ballot comment]
Thank you for addressing my DISCUSS (and COMMENT!) points!
2019-03-08
16 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-03-07
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-03-07
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-03-07
16 Neil Jenkins New version available: draft-ietf-jmap-core-16.txt
2019-03-07
16 (System) New version approved
2019-03-07
16 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2019-03-07
16 Neil Jenkins Uploaded new revision
2019-03-07
15 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2019-03-07
15 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-03-07
15 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-03-06
15 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from No Record
2019-03-06
15 Eric Rescorla [Ballot comment]
Thank you for addressing my DISCUSS
2019-03-06
15 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Record from Discuss
2019-03-06
15 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-03-05
15 Ben Campbell [Ballot comment]
Thank you for addressing my comments on version 14.
2019-03-05
15 Ben Campbell Ballot comment text updated for Ben Campbell
2019-03-04
15 Alissa Cooper
[Ballot comment]
Thank you for addressing my DISCUSS questions. Original COMMENT is below.

= Section 1.1 =

Please use the RFC 8174 boilerplate instead of …
[Ballot comment]
Thank you for addressing my DISCUSS questions. Original COMMENT is below.

= Section 1.1 =

Please use the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

= Section 2=

s/To avoid conflict, the identifiers for these MUST be a URL with a domain owned by the vendor./To avoid conflict, an identifier for a vendor-specific extension MUST be a URL with a domain owned by the vendor./

= Section 8 =

Depending on the outcome of the discussion related to the DISCUSS point above, I think it would be appropriate to describe or even normatively require client ID construction such that client IDs are opaque and can change over time at the client's choosing.
2019-03-04
15 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2019-03-02
15 Alexey Melnikov Telechat date has been changed to 2019-03-07 from 2019-02-21
2019-03-01
15 Benjamin Kaduk
[Ballot discuss]
Trimming down for things fixed in the -15...

Section 5.3

  Some records may hold references to other records (foreign keys).
  That …
[Ballot discuss]
Trimming down for things fixed in the -15...

Section 5.3

  Some records may hold references to other records (foreign keys).
  That reference may be set (via create or update) in the same request
  as the referenced record is created.  To do this, the client refers
  to the new record using its creation id prefixed with a "#".  The
  order of the method calls in the request by the client MUST be such
  that the record being referenced is created in the same or an earlier
  call.  The server thus never has to look ahead.  Instead, while

I think this means you need to specify what order the server does the
create, update, and destroy lists in -- that is, that all creates are
done before all updates, etc..

Section 7.1

  o  *changed*: "Id[TypeState]" A map of _account id_ to an object
      encoding the state of data types that have changed for that
      account since the last StateChange object was pushed, for each of

I don't see how these semantics provide the properties stated in Section
7, "[i]t doesn't matter if some push events are dropped before they
reach the client; it will still get all changes next time it syncs."  In
particular, if the client misses a state change for the CalendarEvent
type, and then no other changes that affect CalendarEvents occur, the
client will remain unaware of the changes to CalendarEvents, even if
other push notifications for other types come in.  Am I misunderstanding
one or more of the behavior or stated guarantees?

Section 7.2

  o  *keys*: "Object|null" (immutable) Client-generated encryption
      keys.  If supplied the server MUST use them as specified in
      [RFC8291] to encrypt all data sent to the push subscription.  The
      object MUST have the following properties:

      *  *p256dh*: the P-256 ECDH Diffie-Hellman public key as described
        in [RFC8291], encoded in URL-safe Base64 representation as

What's the crypto agility story for these web push encryption keys?
(See BCP 201.)

Also, when these expirations fire (e.g., for Basic Authentication
credentials), we need a normative requirement to actually destroy the
private credentials; there's a lot going on here so maybe I missed it,
but I don't think I saw one.
2019-03-01
15 Benjamin Kaduk Ballot discuss text updated for Benjamin Kaduk
2019-03-01
15 Adam Roach [Ballot comment]
Thanks for addressing my discuss and comment points.
2019-03-01
15 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2019-02-28
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-28
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-02-28
15 Neil Jenkins New version available: draft-ietf-jmap-core-15.txt
2019-02-28
15 (System) New version approved
2019-02-28
15 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2019-02-28
15 Neil Jenkins Uploaded new revision
2019-02-25
14 Adam Roach
[Ballot discuss]
[After consultation with a security AD, I have removed one of my three
DISCUSS items, as I now believe it pertains more broadly …
[Ballot discuss]
[After consultation with a security AD, I have removed one of my three
DISCUSS items, as I now believe it pertains more broadly to the use
of .well-known and is not specific to this document]

Thanks to the authors for a well-laid-out and easy-to-read document. Thanks also
to everyone who contributed to the completion of this work. I have three
DISCUSS-level items, and a handful of other suggestions that are largely
editorial

---------------------------------------------------------------------------

§7.3:

>  The client may add a query parameter called "types", with the value
...
>  The client may add a query parameter called "closeafter" with value
...
>  The client may add a query parameter called "ping", with a positive

This form of specification of URI parameters is not allowed -- it contravenes
the basic thesis of BCP 190; section 2.4 of which stipulates:

>  Applications MUST NOT directly specify the syntax of queries, as this
>  can cause operational difficulties for deployments that do not
>  support a particular form of a query.
...
>  Extensions MUST NOT constrain the format or semantics of queries.

Given that the base resource used to bootstrap the JMAP infrastructure already
uses URI templates, it seems that they would be a good candidate for specifying
a means of adding these parameters in a way that respects the basic principle
that URI design ownership belongs to the domain administrator.

---------------------------------------------------------------------------

The reference for Server-Sent events normatively points to the WHATWG HTML
spec, which changes on a continuing basis. I don't think we've really worked
out the mechanics of citing this kind of reference normatively; and JMAP takes
the especially dangerous step of citing a specific *section* of the document,
which may well change at arbitrary and potentially frequent intervals. There
is, in fact, no guarantee that the cited "text/event-stream" mechanism will
continue to exist in future versions of the WHATWG document (cf. the
element).

In this particular case, I think we want to reference
https://www.w3.org/TR/eventsource/ instead.
2019-02-25
14 Adam Roach Ballot discuss text updated for Adam Roach
2019-02-21
14 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2019-02-21
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-02-21
14 Mirja Kühlewind
[Ballot discuss]
Sorry, I earlier forgot one point I would like to quickly discuss:

The jmap service name registration only requests registration for tcp while …
[Ballot discuss]
Sorry, I earlier forgot one point I would like to quickly discuss:

The jmap service name registration only requests registration for tcp while H/3 could be used as well which will work over udp. Maybe it would be more future-proof to also add an entry for udp?

Further, there is a note that says that this registration will change an existing entry. Please note that for removing the existing entry, IANA might still need to contact the original assignee to ask for approval. However, this is just a processing issue and shouldn't lead to a real problem.

And finally a comment related to my above note about H/3, the document talks two times about "keeping the TCP connection open". To be future proof, I would maybe recommend to change the wording to "keeping the transport connection open".
2019-02-21
14 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Objection
2019-02-21
14 Mirja Kühlewind
[Ballot comment]
Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)!

One question regarding sec 9.4.1.:
How long should IANA wait …
[Ballot comment]
Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)!

One question regarding sec 9.4.1.:
How long should IANA wait for comments before the registration is performed?
2019-02-21
14 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-02-20
14 Adam Roach
[Ballot discuss]
Thanks to the authors for a well-laid-out and easy-to-read document. Thanks also
to everyone who contributed to the completion of this work. I …
[Ballot discuss]
Thanks to the authors for a well-laid-out and easy-to-read document. Thanks also
to everyone who contributed to the completion of this work. I have three
DISCUSS-level items, and a handful of other suggestions that are largely
editorial

---------------------------------------------------------------------------

§7.3:

>  The client may add a query parameter called "types", with the value
...
>  The client may add a query parameter called "closeafter" with value
...
>  The client may add a query parameter called "ping", with a positive

This form of specification of URI parameters is not allowed -- it contravenes
the basic thesis of BCP 190; section 2.4 of which stipulates:

>  Applications MUST NOT directly specify the syntax of queries, as this
>  can cause operational difficulties for deployments that do not
>  support a particular form of a query.
...
>  Extensions MUST NOT constrain the format or semantics of queries.

Given that the base resource used to bootstrap the JMAP infrastructure already
uses URI templates, it seems that they would be a good candidate for specifying
a means of adding these parameters in a way that respects the basic principle
that URI design ownership belongs to the domain administrator.

---------------------------------------------------------------------------

§8.3:

>  If this is not feasible, servers MUST ensure this path cannot be
>  controlled by an attacker, as again it may be used to steal
>  credentials.

This seems problematic, as it would need to be honored by *all* web servers
everywhere on the entire Internet to be effective. One cannot really presume
that all website operators will be aware of JMAP. I think the only really
sensible thing to do here is to forbid clients from using "/.well-known/jmap" on
a server until they have received some external positive indication that the
server supports JMAP (via SRV or some other mechanism).

---------------------------------------------------------------------------

The reference for Server-Sent events normatively points to the WHATWG HTML
spec, which changes on a continuing basis. I don't think we've really worked
out the mechanics of citing this kind of reference normatively; and JMAP takes
the especially dangerous step of citing a specific *section* of the document,
which may well change at arbitrary and potentially frequent intervals. There
is, in fact, no guarantee that the cited "text/event-stream" mechanism will
continue to exist in future versions of the WHATWG document (cf. the
element).

In this particular case, I think we want to reference
https://www.w3.org/TR/eventsource/ instead.
2019-02-20
14 Adam Roach Ballot discuss text updated for Adam Roach
2019-02-20
14 Adam Roach
[Ballot discuss]
Thanks to the authors for a well-laid-out and easy-to-read document. Thanks also
to everyone who contributed to the completion of this work. I …
[Ballot discuss]
Thanks to the authors for a well-laid-out and easy-to-read document. Thanks also
to everyone who contributed to the completion of this work. I have three
DISCUSS-level items, and a handful of other suggestions that are largely
editorial

---------------------------------------------------------------------------

§7.3:

>  The client may add a query parameter called "types", with the value
...
>  The client may add a query parameter called "closeafter" with value
...
>  The client may add a query parameter called "ping", with a positive

This form of specification of URI parameters is not allowed -- it contravenes
the basic thesis of BCP 190, section 2.4 of which stipulates:

>  Applications MUST NOT directly specify the syntax of queries, as this
>  can cause operational difficulties for deployments that do not
>  support a particular form of a query.
...
>  Extensions MUST NOT constrain the format or semantics of queries.

Given that the base resource used to bootstrap the JMAP infrastructure already
uses URI templates, it seems that they would be a good candidate for specifying
a means of adding these parameters in a way that respects the basic principle
that URI design ownership belongs to the domain administrator.

---------------------------------------------------------------------------

§8.3:

>  If this is not feasible, servers MUST ensure this path cannot be
>  controlled by an attacker, as again it may be used to steal
>  credentials.

This seems problematic, as it would need to be honored by *all* web servers
everywhere on the entire Internet to be effective. One cannot really presume
that all website operators will be aware of JMAP. I think the only really
sensible thing to do here is to forbid clients from using "/.well-known/jmap" on
a server until they have received some external positive indication that the
server supports JMAP (via SRV or some other mechanism).

---------------------------------------------------------------------------

The reference for Server-Sent events normatively points to the WHATWG HTML
spec, which changes on a continuing basis. I don't think we've really worked
out the mechanics of citing this kind of reference normatively; and JMAP takes
the especially dangerous step of citing a specific *section* of the document,
which may well change at arbitrary and potentially frequent intervals. There
is, in fact, no guarantee that the cited "text/event-stream" mechanism will
continue to exist in future versions of the WHATWG document (cf. the
element).

In this particular case, I think we want to reference
https://www.w3.org/TR/eventsource/ instead.
2019-02-20
14 Adam Roach
[Ballot comment]
§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  …
[Ballot comment]
§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§1.2:

>  Where "Id" is given as a datatype, it means a "String" of at least 1
>  and maximum 255 octets in size, and MUST only contain characters from
>  the "URL and Filename safe" Base 64 Alphabet, as defined in section 5
>  of [RFC4648].  This is the ASCII alphanumeric characters ("A-Za-
>  z0-9"), hyphen ("-"), and underscore ("_").

This is unclear as to whether "=" is allowed. It is included in the RFC 4648
"URL and Filename safe" alphabet, but not mentioned in this document's
reiteration of that alphabet's definition. If the intention is to exclude "=",
please say so explicitly.

---------------------------------------------------------------------------

§1.2 says:

>  All record ids are assigned by the server, and are immutable.

...in which no exceptions are allowed.

§1.6.3 says:

>  The id of a record is immutable, and normally assigned by the server.

...where "normally" indicates that there will be exceptions. These say different
things. Please change the inaccurate one to match the accurate one.

---------------------------------------------------------------------------

§2.1:

>      "accounts": {
>        "13824": {
>          "name": "john@example.com",
>          "isPersonal": true,
>          "isReadOnly": false,
>          "hasDataFor": [
>            "urn:ietf:params:jmap:mail",
>            "urn:ietf:params:jmap:contacts"
>          ]
>        },

Section 1.2 offers the advice:

>  In particular, it is wise to avoid:
>
...
>
>  o  Ids starting with digits
>
>  o  Ids that contain only digits

It seems that the examples should conform to the document's advice --
implementors often pay more attention to examples than even normative text, much
less non-normative advice.

---------------------------------------------------------------------------

§3.2:

>    3.  A "String" *client id*: an arbitrary string from the client to
>        be echoed back with the responses emitted by that method call

I think the document wants to say a bit more about the scope of uniqueness for
this client ID. Also, the name is a bit confusing, as "Client ID" is most easily
interpreted as "an identifier that identifies a client." This appears to be more
of a "Method ID."

---------------------------------------------------------------------------

§5.7:

>  o  *keywords*: "String[Boolean]" (default: ) A set of keywords that

I think you're missing something after "default:" inside the parentheses.

As an aside -- and I know this is just an example, but people are likely to
follow it when designing things riding on top of JMAP -- I was initially a bit
confused about why this is "String[Boolean]" rather than "String[]",
especially since the only valid value appears to be "true". Is this to allow
for smaller patch operations? If so, text explaining this design decision
would probably be good.

---------------------------------------------------------------------------

§7.1.1:

>  It can wait until the call completes and
>  then compare if the new state string after the /set is the same as
>  was pushed in the StateChange object; if so, it does not need to
>  waste a request asking for changes it already knows.

I think this phrasing may oversimplify things a bit. For example:

- my current cached notion of state is "A"
- I send a /set operation
- I get a "StateChange" that indicates that the new state is "C"
- I get a response to the /set operation indicating that the state has changed
  from "B" to "C"

The new state after the /set is the same as was pushed in the StateChange
object; however, I'm still missing state that resulted in the change from "A" to
"B".

I think the language in this example needs to be updated to be more precise
about when such requests can be omitted.

---------------------------------------------------------------------------

§7.3:

>  When a new connection is made to the event-source endpoint, a
>  client following the server-sent events specification will send a
>  Last-Event-ID HTTP header

Nit: "...HTTP header field..."
2019-02-20
14 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2019-02-20
14 Benjamin Kaduk
[Ballot discuss]
There's a lot here, and I was not reading in the best of environments,
so it's quite possible that I am just confused …
[Ballot discuss]
There's a lot here, and I was not reading in the best of environments,
so it's quite possible that I am just confused or missed something while
reading.  On the whole, this document is well-written and gives me a
good picture of how things work.  That said, there are still some places
where it looks like we may need to have some discussions...

This document (twice) has a MUST requirement for HTTP over TLS, which
seems to exclude any future usage of HTTP/3 over QUIC.  (It's also
probably not needed to repeat the normative requirement in two places; I
noted both in the COMMENT section.)

Section 1.6.2 asserts that "all data belong to a single account".  And
yet, we seem to have PushSubscription objects in Sections 7.2.1 and
7.2.2 that disclaim any relationship to an account, which seems
internally inconsistent.  It's also unclear to me from the text in the
latter sections what mechanism is used to determine whether a given
request is authorized to see a given PushSubscription object.  Is it
supposed to be based on the authentication credentials to the API
service directly, or a user abstraction, or something else?

Section 5.3

  Some records may hold references to other records (foreign keys).
  That reference may be set (via create or update) in the same request
  as the referenced record is created.  To do this, the client refers
  to the new record using its creation id prefixed with a "#".  The
  order of the method calls in the request by the client MUST be such
  that the record being referenced is created in the same or an earlier
  call.  The server thus never has to look ahead.  Instead, while

I think this means you need to specify what order the server does the
create, update, and destroy lists in -- that is, that all creates are
done before all updates, etc..

Section 5.5

The Unicode Collation Algorithm (
is not listed in the IANA collation registry for internet application
protocols; since the session object limits the collationAlgorithms to
those in the registry, at present, it is not permitted to use that
collation algorithm.  It would seem that this document should stimulate
the registration of that collation algorithm in some fashion (whether by
explicitly doing so in its IANA Considerations or otherwise).

Section 7.1

  o  *changed*: "Id[TypeState]" A map of _account id_ to an object
      encoding the state of data types that have changed for that
      account since the last StateChange object was pushed, for each of

I don't see how these semantics provide the properties stated in Section
7, "[i]t doesn't matter if some push events are dropped before they
reach the client; it will still get all changes next time it syncs."  In
particular, if the client misses a state change for the CalendarEvent
type, and then no other changes that affect CalendarEvents occur, the
client will remain unaware of the changes to CalendarEvents, even if
other push notifications for other types come in.  Am I misunderstanding
one or more of the behavior or stated guarantees?

Section 7.2

  As a push subscription causes the JMAP server to make a number of
  requests to a previously unknown endpoint, it can be used as a vector
  for launching a denial of service attack.  To prevent this, when a
  subscription is created the JMAP server immediately sends a
  PushVerification object to that URL (see section 7.2.2).  The JMAP
  server MUST NOT make any further requests to the URL until the client
  receives the push and updates the subscription with the correct
  verification code.

I think the JMAP server also needs to rate-limit even the initial
PushVerification generation, per-user(?), in order to close the DoS
and annoyance-vector risks.

  o  *keys*: "Object|null" (immutable) Client-generated encryption
      keys.  If supplied the server MUST use them as specified in
      [RFC8291] to encrypt all data sent to the push subscription.  The
      object MUST have the following properties:

      *  *p256dh*: the P-256 ECDH Diffie-Hellman public key as described
        in [RFC8291], encoded in URL-safe Base64 representation as

What's the crypto agility story for these web push encryption keys?
(See BCP 201.)

Also, when these expirations fire (e.g., for Basic Authentication
credentials), we need a normative requirement to actually destroy the
private credentials; there's a lot going on here so maybe I missed it,
but I don't think I saw one.
2019-02-20
14 Benjamin Kaduk
[Ballot comment]
I also have a big pile of mostly editorial comments.

Section 1.1

"Type signatures" sounds a lot like a "JSON Schema".  But we …
[Ballot comment]
I also have a big pile of mostly editorial comments.

Section 1.1

"Type signatures" sounds a lot like a "JSON Schema".  But we can work
with what we have, no doubt :)

  o  "String[A]" - A JSON object where the keys are all "String"s, and
      the values are of type "A".

To avoid confusion about whether String is the only possible map key
type (vs., e.g., Id), maybe "A[B]" notation is more appropriate?

Section 1.2

Do we want to give any guidance about when it is (not) advisable to use
very short identifiers (even the 1-2 character case could be
noteworthy)?  (I don't know what that guidance would be, so "no" is a
perfectly fine answer!)

W.r.t "NIL", that is the specifc 3-character identifier, right?  Or do
we need to worry about having it embedded as part of a larger string?

(I don't see how prefixing every ID with an alphabetical character
avoids the "NIL" case, unless 'N' is disallowed from being that
character.)

Section 1.3

My math degree obliges me to note that, per trichotomy, zero is not a
positive integer.

Section 1.6.1

nit: perhaps a "user object", or some broader rewrite like "in this
document, the keyword 'user' is used to refer to [...]" -- the current
text feels like it's dehumanizing, well, humans.

Section 1.6.2

nit re. "All data belong to a single account": I assume this is "each datum
has a map to its respective account", not "the entire set of data in the
system is associated with a single privileged account", as that would
make the account distinction rather useless.

Section 1.7

A "MUST" requirement for TLS would seem likely to disallow HTTP/3
(QUIC).

Does "MUST confirm with the HTTP Authentication framework" preclude
other authentication schemes?  The RFC 7235 framework has some warts,
and in many webapp settings there are plausible reasons to prefer
app-layer authentication schemes.  I guess that JMAP as being an
API-driven model may have a more natural mapping to the 7235 framework,
and I do note the remarks in the shepherd writeup that an authentication
scheme was removed from a previous version of this document.  So mostly
I'm just asking if we are intending to force the 7235 framework to be
the one and only authentication scheme for JMAP.  (Who knows, maybe this
will drive adoption of new HTTP Authentication Schemes or prompt renewed
interest in their development?)

  Clients MUST understand and be able to handle standard HTTP status
  codes appropriately.

(Is there a precise definition for "standard HTTP status codes"?)

  An authenticated client can fetch the JMAP Session object with
  details about the data and capabilities the server can provide as

nit: maybe this is "a JAMP session object" with the indefinite article?

Section 2

  o  *username*: "String" The username associated with the given
      credentials.

This seems to implicitly require that all credentialed entities have
user accounts, denying the possibility for some shared-credential or
machine-credential models.  Is this intended?

  o  *state*: "String" A string representing the state of this object
      on the server.  If the value of any other property on the session
      object changes, this string will change.  The current value is
      also returned on the API Response object (see section 3.3),
      allowing clients to quickly determine if the session information
      has changed (e.g. an account has been added or removed) and so
      they need to refetch the object.

As written this sounds like a serialized version of the full object
(without the 'state' field, of course, to avoid recursion), but I
suspect this is intended to be more like a generation number or hash or
serialized state, as a short lookup key.  Greater clarity would be
welcome.
(Same comment for all other "state" fields in the document.)
In particular, the /changes endpoints seem to place fairly strict bounds
on the generation/tracking of *state*.

Section 3.2

  o  *using*: "String[]" The set of capabilities the client wishes to
      use.  The client MAY include capability identifiers even if the
      method calls it makes do not utilise those capabilities.  The
      server advertises the set of specifications it supports in the
      JMAP Session object, as keys on the _capabilities_ property.

Are the "capability identifiers" the same as or different from the
"specifications [the server] supports"?

Was there much discussion of short Strings as method names vs. URIs?

Is the "client id" something that could also be called a "request ID"?
(I note that RFC 7252 calls a similar thing a "token" but has some text
wishing they called it a "request ID".)

The 'prefixed with a "#"' laguage seems like it has some potential for
confusion; is it better to write this like "the first character of the
creation ID MUST be octothorpe ('#')"?
I'm also still a bit unclear at this point about how the client tells
the server which entry in the createdIds map to update when which action
completes, but hopefully there is more later.
AFAICT having finished reading the doc, these can only be created by
explicit client action via a "create" array (or equivalent), where the
array keys are the "creation id"s since the client has to use some
handle before the server has assigned them.  It should be possible to
add a very brief note to that effect here.

Given the later usage in Section 3.3, I would consider splitting the
*Invocation* definition into a subsection.

Section 3.3

(editorial) If the second element of the Invocation tuple is literally
"arguments for the method", do we really have enough rope to make
response objects like this (unless we limit ourselves to conceptually
"in/out" arguments with no pure-output functionality)?

Section 3.5

I expect that deployment will see differences of opinion as to which
checks fall under "syntactically valid", but it's unclear whether we
need to attempt to forestall such debate.

Section 3.5.1

  o  "urn:ietf:params:jmap:error:notRequest" The request parsed as JSON
      but did not match the structure of the Request object.

"the Request object" makes me think of "the thing the client stuck in
the field named "Request", which is probably not the intent.  Perhaps
the key phrase is "type signature"?

Section 3.5.1.1

Since there is special handling for "urn:ietf:params:jmap:error:limit",
do we want an example to show that?

Section 3.5.2

  With the exception of "serverPartialFail", the externally-visible
  state of the server MUST NOT have changed if an error is returned at
  the method level.

nit: You don't say where in the type signature "serverPartialFail" is
supposed to be in order to trigger the special handling.

  "invalidArguments": One of the arguments is of the wrong type or
  otherwise invalid, or a required argument is missing.  A
  "description" property MAY be present to help debug with an
  explanation of what the problem was.  This is a non-localised string,
  and is not intended to be shown directly to end users.

It seems almost certain that it *will* be shown directly to end users,
intent or not.  But disavowing localization is probably sufficient for
now.
(et seq.)

  Further general errors MAY be defined in future RFCs.  Should a
  client receive an error type it does not understand, it MUST treat it
  the same as the "serverFail" type.

Does this imply that "serverPartialFail" is unique in its ability to
partially modify state?

Section 3.6

(Same comment about '"prefixes with "#"' as above.)

                                    If an argument object contains the
  same argument name in normal and referenced form (e.g. "foo" and
  "#foo"), the method MUST return an "invalidArguments" error.

This "same argument name in normal and referenced form" applies even in
arbitrarily nested objects, right?  It seems like this could potentially
be expensive and/or difficult to enforce.

Section 4

I'm trying to consider whether there is any sort of canonicalization or
un-escaping behavior that a server might perform on method inputs so
that the response would be almost but not exactly the same as the
request.  (Such behavior could perhaps be used for fingerprinting an
implementation.)  I can't think of any, though.

Section 5.1

  o  *ids*: "Id[]|null" The ids of the Foo objects to return.  If
      "null" then *all* records of the data type are returned, if this
      is supported for that data type.

Maybe note that the "maxObjectsInGet" capability limit might kick in
here for the "null" case?

  o  *properties*: "String[]|null" If supplied, only the properties
      listed in the array are returned for each Foo object.  If "null",
      all properties of the object are returned.  The id property of the
      object is *always* returned, even if not explicitly requested.  If
      an invalid property is requested, the call MUST be rejected with
      an "invalidArguments" error.

Because we're constrained to a single type here, there's no way for only
some (but not all) of the objects to have any given property, right?

Section 5.3

  o  *ifInState*: "String|null" This is a state string as returned by
      the _Foo/get_ method.  If supplied, the string must match the

So, just to double-check, this applies to the state of all objects of
the type in question (for the account)?  It might be worth reiterating,
since we frequently see this sort of check against the current state at
a per-object granularity, in other systems.

Do the "creation id"s in the "create" array include leading "#"?

Section 5.4

  o  *destroyFromIfInState*: "String|null" This argument is passed on
      as the "ifInState" argument to the implicit _Foo/set_ call, if
      made at the end of this request.

This is "the Implicit _Foo/set_ call that effectuates the destruction of
the original", right?

  o  *created*: "Id[Foo]|null" A map of the creation id to an object
      containing any properties of the copied Foo object that are set by
      the server (such as the _id_ in most object types).  This argument
      is "null" if no Foo objects were successfully copied.

Maybe note that the id property will also likely differ from the one
that was passed in in the create array, since the ids in question are
from different accounts?

Section 5.6

  o  *upToId*: "Id|null" The last (highest-index) id the client
      currently has cached from the query results.  When there are a

Just to double-check: semantically this is an object identifier, but the
ordering we care about for the "up to" part is the ordering in the query
results?

  o  *removed*: "Id[]" The _id_ for every foo that was in the query
      results in the old state and is not in the results in the new
      state.  If the server cannot calculate this exactly, the server
      MAY return extra foos in addition that may have been in the old
      results but are not in the new results.  If the sort and filter
      are both only on immutable properties and an _upToId_ is supplied
      and exists in the results, any ids that were removed but have a
      higher index than _upToId_ SHOULD be omitted.  If the _filter_ or
      _sort_ includes a mutable property, the server MUST include all
      foos in the current results for which this property MAY have
      changed.

I'm having a hard time understanding this "MAY have changed" text
(which, for one, shouldn't be using 2119 language).  Taking note that
this is the "removed" list, this text seems to be saying that I include
in the "removed" list any object that *is* in the current query results,
but which may have had a property change since the previous state.  So
we end up having to do a "remove + add" for this sort of property
change, is that right?

We may need more detail on the "splices in" operation, with respect to
the indices in the "added" array reflecting the final state, and the
local cached indices needing to be updated on the fly during the
splicing operation in order to get things inserted in the proper places.

Section 5.8

  2.  It must resolve back-references to previous method results that
      were processed on a different server.  This is a relatively
      simple syntactic substitution, described in section 3.6.

Relatively simple, yes, but does require properly parsing the JSON
(right?).

Section 6.3

Why does Blob/copy use 'blobIds' instead of 'create' like generic /copy?

  o  *fromAccountId*: "Id" The id of the account emails were copied
      from.

  o  *accountId*: "Id" The id of the account emails were copied to.

I assme the "emails" are copy/paste bugs.

Section 7.2

  o  *deviceClientId*: "String" (immutable) An id that uniquely
      identifies the client + device it is running on.  The purpose of
      this is to allow clients to identify which PushSubscription
      objects they created even if they lose their local state, so they
      can revoke or update them.  This string MUST be different on
      different devices, and be different from other vendors.  It SHOULD

What's the first vendor that's the basis for comparison?

      be easy to re-generate, not depend on persisted state.  A secure
      hash that includes both a device id and vendor id is one way this
      could be achieved.

Easy to re-generate by whom?
How does the client get the deviceClientId value the first time?

  The POST request MUST have a content type of "application/json" and
  contain the UTF-8 JSON encoded object as the body.  The request MUST

(editorial) Are we back to what the JMAP server sends to the notification URL?

  The push subscription is tied to the credentials used to authenticate
  the API request that created it.  Should these credentials expire or
  be revoked, the push subscription MUST be destroyed by the JMAP
  server.

How is the JMAP server expected to learn about credential expiry or
revocation?

  When these credentials have their own expiry (i.e. it is a session
  with a timeout), the server SHOULD NOT set or bound the expiry time

(editorial) A session where?

Section 7.2.1

I would suggest a section reference to "follows the common /get
semantics from Section 5.1, with the exceptions that [...]" to more
clearly incorporate by reference the existing text.

What nature of authorization checking is done for these get requests?

Section 7.2.2

(Same comment about invariants.)

Section 7.2.3

Given that all of these times are going to be in the past for all
readers, do we want to say something about what time the client is
performing these operations at?

Section 8.1

Again, this (duplicated!) MUST for TLS prevents future  HTTP/3 QUIC
usage.

Also, please reference RFC 7525.

Section 8.2

Please recommend against Basic.  SCRAM is probably a tolerable default
suggestion; some of the other options that have nicer-looking crypto
properties are also not widely deployed, IIUC.

Also, the concept of what a "user's regular password" is seems a bit
underspecified.

Section 8.3

DNS SRV-based autodiscovery seems the only type of autodiscovery
available that is susceptible to the attack described here; you should
probably just state that explicitly.

Section 8.4

While true, 8529's security considerations are pretty sparse; we could
say more here about not overscanning, limiting string length, being
strict about tokenization, etc.

Section 8.7

  and JMAP server the client MUST specify encryption keys when
  establishing the PushSubscription and ignore any push notification
  received that is not encrypted and signed with those keys.

There's no signing in RFC 8291; there is, however, a separate
authentication secret.

Section 8.8

I would be surprised if the propsects for traffic analysis were limited
to just push.  Even regular accesses may still be susceptible to traffic
analysis.

Section 9.4.3

You probably should document that recourse for non-response after 30
days is to request action from the IESG.
2019-02-20
14 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-02-20
14 Ben Campbell
[Ballot comment]
Thanks for the huge amount of work this involved.

I support Alissa's discuss point concerning device ids. Otherwise, I have a few minor …
[Ballot comment]
Thanks for the huge amount of work this involved.

I support Alissa's discuss point concerning device ids. Otherwise, I have a few minor comments:

§1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

§1.6.2:
- 2nd paragraph:  I think this means that any given piece of data belongs to one account. But it could be read (nonsensically) to mean that one account owns all the data.

§1.6.3: "The id of a record is immutable, and normally assigned by the server.":  This seems to conflict with section 1. 2, which says all record lDs are assigned by the server. (I take "normally" to mean "most of the time, but sometimes not"

§1.7: "Support for common HTTP mechanisms such as redirection
and caching are assumed.":  I'm not sure what this means. Are they *required* to be supported?

§2:
- "If the specification
includes new object type definitions, the server MUST include
it in the _hasDataFor_ array if, and only if, the user may use
those data types with this account."
This would be more clear in the form of "MUST include... and MUST NOT..."

- "Servers MAY advertise vendor-specific JMAP
extensions, as described in section 1.7. To avoid conflict, the
identifiers for these MUST be a URL with a domain owned by the
vendor."
I think the cross reference should be to section 1.8. Also, the MUST is redundant to normative text in that section.

§5:
- "Not all types may have all methods. ": Is that the same as saying some types may not have all methods?  (It could be read to say not all types are allowed to have all methods.)
2019-02-20
14 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2019-02-20
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-02-20
14 Alissa Cooper
[Ballot discuss]
= Section 7.2 =

There is something I'm not understanding about this:

*deviceClientId*: "String" (immutable) An id that uniquely
      identifies …
[Ballot discuss]
= Section 7.2 =

There is something I'm not understanding about this:

*deviceClientId*: "String" (immutable) An id that uniquely
      identifies the client + device it is running on.  The purpose of
      this is to allow clients to identify which PushSubscription
      objects they created even if they lose their local state, so they
      can revoke or update them.  This string MUST be different on
      different devices, and be different from other vendors.  It SHOULD
      be easy to re-generate, not depend on persisted state.  A secure
      hash that includes both a device id and vendor id is one way this
      could be achieved.
   
I don't understand why device ID needs to be incorporated in order to achieve uniqueness here. Really it seems like what is needed is a unique ID per client, full stop. Even if you have the unlikely scenario of two clients running on the same device from the same vendor (say, one for mail and one for calendar), you would still want to support the ability for each client independently to be able to recover its push subscriptions, right? Some JMAP servers may have device IDs for other reasons anyway, but setting this up this way seems like it opens the door for clients to unnecessarily share device IDs with JMAP servers in other cases.

Related to this, I don't understand the "SHOULD ... not depend on persisted state." Why? I presume it would be straightforward to produce a unique client ID that did not have the device ID embedded if this requirement were not there.
2019-02-20
14 Alissa Cooper
[Ballot comment]
= Section 1.1 =

Please use the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

= Section 2=

s/To avoid conflict, the …
[Ballot comment]
= Section 1.1 =

Please use the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

= Section 2=

s/To avoid conflict, the identifiers for these MUST be a URL with a domain owned by the vendor./To avoid conflict, an identifier for a vendor-specific extension MUST be a URL with a domain owned by the vendor./

= Section 8 =

Depending on the outcome of the discussion related to the DISCUSS point above, I think it would be appropriate to describe or even normatively require client ID construction such that client IDs are opaque and can change over time at the client's choosing.
2019-02-20
14 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2019-02-20
14 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-02-20
14 Warren Kumari [Ballot comment]
"Trusting AD"
2019-02-20
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-02-19
14 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-02-19
14 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-02-18
14 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2019-02-16
14 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4155


I believe I have found a security issue, noted below. In addition, I
have noted a …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4155


I believe I have found a security issue, noted below. In addition, I
have noted a potential interop issue.

DETAIL
S 2.
>            "urn:ietf:params:jmap:contacts", while the second account would
>            just have the last of these.  Attempts to use the methods
>            defined in a specification with one of the accounts that does
>            not contain those data types are rejected with an
>            _accountNotSupportedByMethod_ error (see section 3.5.2: method-
>            level errors).

What happens if this changes after the user has logged in. So, for
instance, I log in and am told that account X has contacts, but later
calendars get added. Do requests have to fail?


S 7.2.2.
>      o  *pushSubscriptionId*: "String" The id of the push subscription
>        that was created.

>      o  *verificationCode*: "String" The verification code to add to the
>        push subscription.  This MUST contain sufficient entropy to avoid
>        the client being able to brute force guess the code.

This doesn't actually guarantee permission. Consider the case where
the client provides a push URL for some sort of open server upload
endpoint. The client could then read the verification code off that
endpoint and confirm the push subscription. Off the top of my head,
requiring the push endpoint to respond in-band with a function of the
code would be better.
2019-02-16
14 Eric Rescorla
[Ballot comment]
S 1.2.
>      the "URL and Filename safe" Base 64 Alphabet, as defined in section 5
>      of [ …
[Ballot comment]
S 1.2.
>      the "URL and Filename safe" Base 64 Alphabet, as defined in section 5
>      of [RFC4648].  This is the ASCII alphanumeric characters ("A-Za-
>      z0-9"), hyphen ("-"), and underscore ("_").

>      These characters are safe to use in almost any context (e.g.,
>      filesystems, URIs, IMAP atoms).  For maximum safety, servers should

SHOULD?


S 1.7.

>  1.7.  The JMAP API model

>      JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download
>      resources.  Implementations MUST support HTTP/1.1, and MAY support
>      later versions.  All HTTP requests MUST use [RFC8446] TLS (HTTPS)

You need to cite 2818 here too.


S 1.7.

>  1.7.  The JMAP API model

>      JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download
>      resources.  Implementations MUST support HTTP/1.1, and MAY support
>      later versions.  All HTTP requests MUST use [RFC8446] TLS (HTTPS)

At this point, do you think it should be SHOULD for H2


S 1.7.
>      and caching are assumed.

>      All HTTP requests MUST be authenticated.  Servers MUST conform with
>      the [RFC7235] HTTP Authentication framework to reject requests that
>      fail authentication and inform the client of available authentication
>      schemes.

This seems pretty restrictive. I read it as forbidding TLS client auth
and/or PAKEs.


S 2.
>            something like "urn:ietf:params:jmap:mail",
>            "urn:ietf:params:jmap:calendars",
>            "urn:ietf:params:jmap:contacts", while the second account would
>            just have the last of these.  Attempts to use the methods
>            defined in a specification with one of the accounts that does
>            not contain those data types are rejected with an

Is this a MUST-level statement or something else?



S 2.
>      o  *downloadUrl*: "String" The URL endpoint to use when downloading
>        files, in [RFC6570] URI Template (level 1) format.  The URL MUST
>        contain variables called "accountId", "blobId", "type" and "name".
>        The use of these variables is described in section 6.2.  Due to
>        potential encoding issues with slashes in content types, it is
>        recommended to put the "type" variable in the query section of the

Should this be RECOMMENDED?


S 3.2.

>        3.  A "String" *client id*: an arbitrary string from the client to
>            be echoed back with the responses emitted by that method call
>            (a method may return 1 or more responses, as it may make
>            implicit calls to other methods; all responses initiated by
>            this method call get the same client id in the response).

Do all the responses have to come back in the same package, so that I
know when I have received the last one?


S 3.2.
>        different servers.  For example it could send the first two method
>        calls to server A, then the third to server B, before sending the
>        fourth to server A again.  By passing the createdIds of the
>        previous response to the next request, it can ensure all of these
>        still resolve.  See section 5.8 for further discussion of proxy
>        considerations.

This is a bit hard to parse and would be improved by an example.


S 3.5.2.
>      and, unless otherwise specified, further processing MUST NOT happen
>      within that method call.

>      Any further method calls in the request MUST then be processed as
>      normal.  Errors at the method level MUST NOT generate an HTTP-level
>      error.

So, what do I do if I want to have method 1 execute and then method 2
execute only if method 1 succeeded. E.g., copy an object and then
delete the original? Do two requests? it looks like maybe I can use
back-references for this, but will that always work?


S 5.4.
>      to copy them using the _Foo/copy_ method, then once the copy has
>      succeeded, delete the original.  The _onSuccessDestroyOriginal_
>      argument allows you to try to do this in one method call, however
>      note that the two different actions are not atomic, and so it is
>      possible for the copy to succeed but the original not to be destroyed
>      for some reason.

Can the other direction happen?


S 8.1.
>  8.1.  Transport confidentiality

>      All HTTP requests MUST use [RFC8446] TLS (https) transport to ensure
>      the confidentiality and integrity of data sent and received via JMAP.
>      Clients MUST validate TLS certificate chains to protect against man-
>      in-the-middle attacks.

You should cite 7525. Also, you need to specify which versions are
acceptbale.
2019-02-16
14 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2019-02-12
14 Tero Kivinen Request for Telechat review by SECDIR Completed: Ready. Reviewer: Tero Kivinen. Sent review to list.
2019-02-07
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tero Kivinen
2019-02-07
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tero Kivinen
2019-02-04
14 Amy Vezza Placed on agenda for telechat - 2019-02-21
2019-02-04
14 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2019-02-04
14 Alexey Melnikov Ballot has been issued
2019-02-04
14 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-02-04
14 Alexey Melnikov Created "Approve" ballot
2019-02-04
14 Alexey Melnikov Ballot writeup was changed
2019-01-22
14 Alexey Melnikov AD review comments were addressed. Waiting for JMAP Mail to clear IETF LC before adding both to an IESG telechat.
2019-01-16
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-01-16
14 Neil Jenkins New version available: draft-ietf-jmap-core-14.txt
2019-01-16
14 (System) New version approved
2019-01-16
14 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2019-01-16
14 Neil Jenkins Uploaded new revision
2019-01-15
13 Alexey Melnikov A few more minor changes needed in response to belated AD review.
2019-01-15
13 Alexey Melnikov IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup
2019-01-14
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-01-14
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2019-01-14
13 Neil Jenkins New version available: draft-ietf-jmap-core-13.txt
2019-01-14
13 (System) New version approved
2019-01-14
13 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2019-01-14
13 Neil Jenkins Uploaded new revision
2019-01-09
12 Alexey Melnikov IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2019-01-03
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Tero Kivinen. Sent review to list.
2018-12-28
12 Allison Mankin Request for Last Call review by TSVART Completed: Ready. Reviewer: Allison Mankin. Sent review to list.
2018-12-28
12 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-12-27
12 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-12-27
12 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-jmap-core-12. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-jmap-core-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, the authors request a port assignment, for TCP only, for jmap. The authors should submit a template for early allocation and put the Internet Draft as a reference according to RFC6335 as stated in section 8.1.1:

IANA MAY accept early assignment requests (known as "early allocation" therein, see RFC 7120) from IETF working groups that reference a sufficiently stable Internet-Draft instead of a published Standards-Track RFC.

The expert team for port number assignment should note that this service name was previously assigned under the name _JSON Mail Access Protocol_. This will be de-assigned and re-assigned with the approval of the previous assignee.

Second, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a single, new URI will be registered as follows:

URI Suffix: jmap
Change Controller: IETF
Reference: [ RFC-to-be ]
Related Information:
Date registered: [ TBD-at-Registration, Section 2.2 ]
Date modified:

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at:

https://www.iana.org/assignments/params/

a single, new registration will be made as follows:

Registered Parameter Identifier:
Reference: [ RFC-to-be ]
IANA Registry Reference: [ TBD-at-Registration ]

Fourth, Section 9.4 of the current draft requests the creation of a new registry - the JMAP Capabilities registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is managed via Expert Review as defined in RFC 8126 unless the "intended use" field is _common_ or _placeholder_ in which case the registration policy is Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

Capability Reference Intended Change Security and
Name Use Controller Privacy Considerations
---------------------------+-------------+------------+------------+----------------------
urn:ietf:params:jmap:core [ RFC-to-be ] common IETF [ RFC-to-be, Section 8]
urn:ietf:params:jmap:error: [ RFC-to-be ] placeholder IETF [ RFC-to-be, Section 8]

Fifth, a new registry will be created called the JMAP Error Codes registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Expert Review as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------------------------+---------+------------+-------------+
| JMAP Error Code | Intended| Change | Description |
| | Use | Controller | or |
| | | | Reference |
+------------------------------+---------+------------+-------------+
| accountNotFound | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| accountNotSupportedByMethod | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| accountReadOnly | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| anchorNotFound | common | IETF |[ RFC-to-be ]|
| | | | section 5.5 |
| alreadyExists | common | IETF |[ RFC-to-be ]|
| | | | section 5.4 |
| cannotCalculateChanges | common | IETF |[ RFC-to-be ]|
| | | | sections |
| | | | 5.2 and 5.6 |
| forbidden | common | IETF |[ RFC-to-be ]|
| | | | sections |
| | | | 3.5.2, 5.3, |
| | | | and 7.2.1 |
| fromAccountNotFound | common | IETF |[ RFC-to-be ]|
| | | | sections |
| | | | 5.4 and 6.3 |
| fromAccountNotSupportedByMet | common | IETF |[ RFC-to-be ]|
| hod | | | section 5.4 |
| invalidArguments | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| invalidPatch | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| invalidProperties | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| notFound | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| notJSON | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.1 |
| notRequest | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.1 |
| overQuota | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| rateLimit | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| requestTooLarge | common | IETF |[ RFC-to-be ]|
| | | | sections |
| | | | 5.1 and 5.3 |
| invalidResultReference | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| serverFail | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| serverPartialFail | limited | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| serverUnavailable | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| singleton | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| stateMismatch | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| tooLarge | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
| tooManyChanges | common | IETF |[ RFC-to-be ]|
| | | | section 5.6 |
| unknownCapability | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.1 |
| unknownMethod | common | IETF |[ RFC-to-be ]|
| | | | section |
| | | | 3.5.2 |
| unsupportedFilter | common | IETF |[ RFC-to-be ]|
| | | | section 5.5 |
| unsupportedSort | common | IETF |[ RFC-to-be ]|
| | | | section 5.5 |
| willDestroy | common | IETF |[ RFC-to-be ]|
| | | | section 5.3 |
+------------------------------+---------+------------+-------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-12-26
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2018-12-26
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2018-12-20
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2018-12-20
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2018-12-20
12 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2018-12-20
12 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2018-12-18
12 Magnus Westerlund Request for Last Call review by TSVART is assigned to Allison Mankin
2018-12-18
12 Magnus Westerlund Request for Last Call review by TSVART is assigned to Allison Mankin
2018-12-14
12 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-12-14
12 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-12-28):

From: The IESG
To: IETF-Announce
CC: brong@fastmailteam.com, jmap@ietf.org, draft-ietf-jmap-core@ietf.org, alexey.melnikov@isode.com, Bron …
The following Last Call announcement was sent out (ends 2018-12-28):

From: The IESG
To: IETF-Announce
CC: brong@fastmailteam.com, jmap@ietf.org, draft-ietf-jmap-core@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , jmap-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JSON Meta Application Protocol) to Proposed Standard


The IESG has received a request from the JSON Mail Access Protocol WG (jmap)
to consider the following document: - 'JSON Meta Application Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies a protocol for clients to efficiently query,
  fetch and modify JSON-based data objects, with support for push
  notification of changes and fast resynchronisation, and out-of-band
  binary data upload/download.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-jmap-core/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-12-14
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-12-14
12 Alexey Melnikov Last call was requested
2018-12-14
12 Alexey Melnikov Last call announcement was generated
2018-12-14
12 Alexey Melnikov Ballot approval text was generated
2018-12-14
12 Alexey Melnikov Ballot writeup was generated
2018-12-14
12 Alexey Melnikov Dear Secretariat, can you please make this 4 weeks LC due to holiday season.
2018-12-14
12 Alexey Melnikov IESG state changed to Last Call Requested from Publication Requested
2018-12-14
12 Alexey Melnikov Changed consensus to Yes from Unknown
2018-12-02
12 Bron Gondwana
(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 …
(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.


2018-12-02
12 Bron Gondwana IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2018-12-02
12 Bron Gondwana IESG state changed to Publication Requested from AD is watching
2018-12-02
12 Bron Gondwana
(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 …
(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.


2018-12-02
12 Neil Jenkins New version available: draft-ietf-jmap-core-12.txt
2018-12-02
12 (System) New version approved
2018-12-02
12 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2018-12-02
12 Neil Jenkins Uploaded new revision
2018-11-25
11 Bron Gondwana Notification list changed to Bron Gondwana <brong@fastmailteam.com>
2018-11-25
11 Bron Gondwana Document shepherd changed to Bron Gondwana
2018-11-25
11 Neil Jenkins New version available: draft-ietf-jmap-core-11.txt
2018-11-25
11 (System) New version approved
2018-11-25
11 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2018-11-25
11 Neil Jenkins Uploaded new revision
2018-11-16
10 Alexey Melnikov Responsible AD changed to Alexey Melnikov
2018-11-16
10 Alexey Melnikov Intended Status changed to Proposed Standard
2018-11-16
10 Alexey Melnikov IESG process started in state AD is watching
2018-11-16
10 (System) Earlier history may be found in the Comment Log for /doc/draft-jenkins-jmap/
2018-11-06
10 Neil Jenkins New version available: draft-ietf-jmap-core-10.txt
2018-11-06
10 (System) New version approved
2018-11-06
10 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2018-11-06
10 Neil Jenkins Uploaded new revision
2018-10-23
09 Neil Jenkins New version available: draft-ietf-jmap-core-09.txt
2018-10-23
09 (System) New version approved
2018-10-23
09 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2018-10-23
09 Neil Jenkins Uploaded new revision
2018-09-11
08 Bron Gondwana Long WGLC to give time for implementations to be completed.
2018-09-11
08 Bron Gondwana IETF WG state changed to In WG Last Call from WG Document
2018-09-10
08 Neil Jenkins New version available: draft-ietf-jmap-core-08.txt
2018-09-10
08 (System) New version approved
2018-09-10
08 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Chris Newman
2018-09-10
08 Neil Jenkins Uploaded new revision
2018-08-06
07 Neil Jenkins New version available: draft-ietf-jmap-core-07.txt
2018-08-06
07 (System) New version approved
2018-08-06
07 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , jmap-chairs@ietf.org
2018-08-06
07 Neil Jenkins Uploaded new revision
2018-07-02
06 Neil Jenkins New version available: draft-ietf-jmap-core-06.txt
2018-07-02
06 (System) New version approved
2018-07-02
06 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins
2018-07-02
06 Neil Jenkins Uploaded new revision
2018-05-08
05 Neil Jenkins New version available: draft-ietf-jmap-core-05.txt
2018-05-08
05 (System) New version approved
2018-05-08
05 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins
2018-05-08
05 Neil Jenkins Uploaded new revision
2018-03-04
04 Neil Jenkins New version available: draft-ietf-jmap-core-04.txt
2018-03-04
04 (System) New version approved
2018-03-04
04 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins
2018-03-04
04 Neil Jenkins Uploaded new revision
2017-11-28
03 Neil Jenkins New version available: draft-ietf-jmap-core-03.txt
2017-11-28
03 (System) New version approved
2017-11-28
03 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins
2017-11-28
03 Neil Jenkins Uploaded new revision
2017-10-29
02 Neil Jenkins New version available: draft-ietf-jmap-core-02.txt
2017-10-29
02 (System) New version approved
2017-10-29
02 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , jmap-chairs@ietf.org
2017-10-29
02 Neil Jenkins Uploaded new revision
2017-07-16
01 Neil Jenkins New version available: draft-ietf-jmap-core-01.txt
2017-07-16
01 (System) New version approved
2017-07-16
01 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins
2017-07-16
01 Neil Jenkins Uploaded new revision
2017-04-19
00 Bron Gondwana Added to session: IETF-98: jmap  Thu-1520
2017-03-28
00 Bron Gondwana This document now replaces draft-jenkins-jmap instead of None
2017-03-28
00 Neil Jenkins New version available: draft-ietf-jmap-core-00.txt
2017-03-28
00 (System) WG -00 approved
2017-03-28
00 Neil Jenkins Set submitter to "Neil Jenkins ", replaces to draft-jenkins-jmap and sent approval email to group chairs: jmap-chairs@ietf.org
2017-03-28
00 Neil Jenkins Uploaded new revision