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.