Last Call Review of draft-ietf-eai-simpledowngrade-
review-ietf-eai-simpledowngrade-genart-lc-campbell-2012-09-20-00

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.