[Gen-art] Gen-ART LC Review of draft-ietf-eai-popimap-downgrade-07

[Ben Campbell <[e-mail]>]

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-popimap-downgrade-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.

[Note: The same issue is there for draft-ietf-eai-simpledowngrade]

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.

--  draft-ietf-eai-simpledowngrade proposes to register a "DOWNGRADED" response code. It seems like that should be used by both or neither downgrade draft. (This is mentioned as an open issue in draft-ietf-eai-simpledowngrade).

Nits/editorial comments:

-- General: 

As far as I can tell, this draft and draft-ietf-eai-simpledowngrade offer two alternatives to solve the same problem. Unfortunately they are very different in structure and terminology. It would make life easier for the reader if they were more consistent with one-another.

I found the structure hard to read in places. In particular, the mixing of imperative sentences  in paragraph form with complicated conditions made it easy to get lost. Either a more descriptive vs imperative style, or breaking things down more into (numbered or bulleted) steps might make it easier to read. 

-- 1.1:

It would be helpful to be more explicit about what is meant by "legacy clients". Am I correct to assume it means clients that do not support the UTF8 capabilities in the relevant drafts from this workgroup?

-- 1.3, 2nd paragraph

s/ "unknown/broken" / "unknown or broken"

-- 3.1.8, 1st paragraph: " If the <local-part> of the <mailbox> element does not contain non-ASCII characters, the <domain> element contains non-ASCII characters."

This appears to say that if the local part has no non-ASCII characters, then the domain part does. Is that the intent? I.e. there is no possibility that neither has non-ASCII chars?

-- 3.1.8, 2nd paragraph: "... the model above."

Please reference the section number.

-- 3.2.1:

Jumping right into the header field list without any preamble is rather abrubt.

--3.2.1: First paragraph after the header field list: " Optionally add those words where appropriate to the next paragraph, but I think once will make it clear."

I assume this was an internal comment meant to be deleted?

-- 3.2.9: 2nd paragraph: "Perform <UNSTRUCTURED> downgrading."

Is there a condition missing here? (The structure of 3.2.9 is confusing in general--the paragraphs feel out of order.)

-- 5: 

Nothing for content-type?

-- 6, 1st paragraph: "But they still contain MIME-encapsulated header fields that contain non-ASCII strings."

Is that always true?

-- 6, 4th paragraph: "Receivers may know they need to update their MUAs, or they don’t care."

I don't get the point of this sentence.

-- 8, 1st paragraph: "Please change "should now be" and "should be" to "have been""

It's probably not worth changing at this point, but I suggest in general writing the words you want to see in the RFC. With all due respect to the apparent super powers of the RFC editor staff, asking them to change things unnecessarily creates opportunities for error.

-- 8, 2nd paragraph: "However [RFC6530] obsoleted [RFC5504] and this document does not use all "Downgraded-" header fields registered by [RFC5504]."

... And therefore what? I sounds like you expect the reader to draw a conclusion--better to spell it out.