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 <ben(_at_)nostrum(_dot_)com> 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.