Hi, Email discussion about the simple downgrade draft made me think of a concern that I think I failed to mention in my review. In particular, the "tunneling" mechanism allows the creation of several new "Downgraded-*" header fields containing encoded content from the original message. Given that downgraded messages are primarily to be consumed by legacy clients, which we can assume do not know anything about this draft, why would we expect the clients to present those headers to the user, or otherwise notify the user of their existence?
Thanks! Ben. On Sep 18, 2012, at 9:15 PM, Ben Campbell <[email protected]> wrote: > 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.
