I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-eai-simpledowngrade-07 Reviewer: Ben Campbell Review Date: 2012-09-18 IETF LC End Date: 2012-09-20 Summary: This draft is mostly on the right track, but has open issues Major issues: -- I'm concerned about the security considerations related to having a mail drop modify a potentially signed message. The draft mentions that this is an issue. I think more discussion is warranted. In particular. What client behavior is expected when a signature is invalidated due to downgrading? I suspect the answer is "warn the user, who will most likely just click through without understanding the issue." I'm concerned about adding yet another reason to train end users to ignore security warnings. OTOH, should the mail drop strip out signatures? That has it's own issues. I'm not saying that I know the answer--merely that it's not clear to me that it has been sufficiently explored. Minor Issues: -- It's not clear to me why this is standards track rather than informational. As far as I can tell, it's mainly used by the IMAP UTF8 capability draft. But that draft seems to list this as an example of something you can do, and lists it as an informational reference. -- section 3, 2nd paragraph: Are there any limits on how much the size can differ from the actual delivered message? Can it be larger? Smaller? It's worth commenting on whether this could cause errors in the client. (e.g. Improper memory allocation) -- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document also mention DOWNGRADED?" Good question. It seems like they should be consistent on things like this. (This is really more a comment on that draft than this one.) Nits and Editorial Comments: -- This draft appears to dispense with 2119 language. It be nice if all the drafts in the group handled this consistently. -- Abstract should mention that this updates 3501 -- section 1: Can you more explicitly define "conventional"? I assume this means clients not supporting the relevant UTF8 capabilities? This terminology is inconsistent between this and draft-ietf-eai-popimap-downgrade.