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.

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.