Registration of further IMAP/JMAP keywords and mailbox name attributes
draft-ietf-mailmaint-messageflag-mailboxattribute-14

Thanks to Rich Salz for their secdir review

Why not MUST/MUST NOT?  In many places in Section 3-8 there are instances of SHOULD/SHOULD NOT where it isn't clear under what circumstances one might ignore the SHOULD or SHOULD NOT.  Either provide an example of why one might choose to ignore the statement, or perhaps it should be a MUST or MUST NOT.  For example in Section 4, last sentence, it seems like MUST NOT would be a reasonable choice.  Where in Section 5.2, para 3, the 'SHOULD present these messages differently' might depend on the UI of the client.

Section 10: I recognize the updates that have been made wrt the secdir review, and I agree that it makes the specification clearer. Just one more tweak:  It would be better to have the security caution for '$muted' be in the section where it is specified, Section 7.6.  While I agree it is repetitive to have this in both 7.6 and 9.14, one might argue that an implementer/integrator is more likely to read Section 7.6, where the rest of the requirements are listed.

Thanks for this document -- it's useful to document conventions that have emerged across vendors.

The title and text imply that these keywords apply equally to IMAP and JMAP, but the Introduction never mentions JMAP. Please consider updating the registry reference to the actual registry names (with "IMAP/JMAP") and adding an explicit statement that IMAP and JMAP both use these registries.

In general, "SHOULD consider" isn't a useful phrase to find in an RFC, and Section 3.2 is no exception. If we think a certain behavior is generally useful but optional, this is simply "SHOULD."

In Section 3, the keywords aren't defined in Section 9.1.[9-11], they're merely registered there. The definitions of them are here in Section 3.

In Section 7.6, I'm slightly more concerned about this threat than the text suggests. While there are certainly all manners of harm one can do with a compromised e-mail account, this seems like one of the few where the effects would continue to happen even after control of the account is recovered.

I support Paul's DISCUSS.

Hi Neil and Daniel, 

Thank you for the effort put into this specification.

The description of the keywords/attributes is clear and well articulated. I found the use of the normative language a bit concerning in some places, mainly the use of SHOULDs. I suspect this is to accommodate existing implementations. No?

Cheers,
Med

(revised ballot for -13)

Thank you to Meral Shirazipour for the GENART review.

Thank you for addressing my DISCUSS feedback.

** For the responsible AD and MAILMAINT WG Chairs, the charter text says “milestones will be used to track all approved work, including during chartering and rechartering.”  However, this document and none of the adopted document have milestones.

Thanks for addressing my concerns. I have updated my ballot to No Objection.