Skip to main content

Last Call Review of draft-ietf-extra-jmapaccess-04

Request Review of draft-ietf-extra-jmapaccess
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-08-28
Requested 2023-08-14
Authors Arnt Gulbrandsen , Bron Gondwana
I-D last updated 2023-08-16
Completed reviews Artart Last Call review of -04 by Barry Leiba (diff)
Genart Last Call review of -04 by Robert Sparks (diff)
Secdir Last Call review of -04 by Daniel Migault (diff)
Assignment Reviewer Barry Leiba
State Completed
Request Last Call review on draft-ietf-extra-jmapaccess by ART Area Review Team Assigned
Posted at
Reviewed revision 04 (document currently at 09)
Result Ready w/nits
Completed 2023-08-16
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:

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