Reviewer: Barry Leiba Review result: Ready with Nits 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
