Last Call Review of draft-ietf-extra-jmapaccess-04
review-ietf-extra-jmapaccess-04-artart-lc-leiba-2023-08-16-00

A fine document and a useful one, this; thanks.

I have only a few nits to pick:

— Section 1 —

   A few IMAP client maintainers have asked for ways to use features
   that are available in JMAP without having to drop their expensively
   tested IMAP code.

I think you want to say “extensively”, with a “t”, yes?  (Though, of course,
the “p” version might be true also…)

— Section 3 —

   This specification does not affect message lifetime: If a client
   accesses a message via IMAP and half a second later via JMAP, then
   the message may have been deleted.

Just to be absolutely clear, I suggest “...via JMAP, the message could have
been deleted in between the two accesses.”

— Section 5 —

   same Oauth backend subsystem, the server infers that the (next)
   access token is just a usable via JMAP as via IMAP.

Typo: “just as usable”

   The server sees that the password is accepted, knows that it and its
   JMAP alter ego the same password database,

Typo: “use the same password database”

   It replies curtly

:-)

— Section 7 —

   However, in this case the client has already authenticated via IMAP.
   By doing so the client already gained access to all of the same mail.
   The authors believe that the debugging value of the response code far
   outweighs its security concerns.

The reviewer agrees.  That said, it would not be a bad thing to add something
like this:

ADD
Server implementations must take care to consider this and not to reveal more
detail about authentication failures than necessary for this purpose. END