IMAP Support for UTF-8
Note: This ballot was opened for revision 09 and is now closed.
(Barry Leiba; former steering group member) Yes
For the IESG, I'll note the following from the ballot text, in case anyone misses it. All four documents will be on the 27 Sept telechat. [Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together.]
(Adrian Farrel; former steering group member) No Objection
Section 4 IMAP servers that advertise support for "UTF8=ACCEPT" or "UTF8=ONLY" MUST reject an APPEND command that includes any 8-bit in the message headers with a "NO" response, when IMAP clients do not issue "ENABLE UTF8=ACCEPT" or "ENABLE UTF8=ONLY". This looks like errata 2075 has not been applied. http://www.rfc-editor.org/errata_search.php?rfc=5738 --- When a new document obsoletes an old one, it is really nice to include a short section stating the changes. I think it is unfortunate that this document doesn't include such a section.
(Benoît Claise; former steering group member) No Objection
No objection to the publication of this document. However, please fix the following issue. http://tools.ietf.org/html/draft-ietf-eai-5738bis-09#section-9. "The reference making them obsolete would be good to include", quoting my discussion with Michelle Cotton
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
Barry tells me the working group considered and rejected marking this document as "updates RFC 3501". I'd like the working group to reconsider that decision, considering this text from the IANA considerations: This document redefines two capabilities ("UTF8=ACCEPT" and "UTF8=ONLY") in the IMAP 4 Capabilities registry [RFC3501]. Three other capabilities that were described in the experimental predecessor to this document (UTF8=ALL, UTF8=APPEND, UTF8=USER) are now made OBSOLETE. It seems to me anyone implementing IMAP from scratch or updating an existing implementation should read this document as part of that implementation.
(Robert Sparks; former steering group member) No Objection
Please double-check that this document doesn't need the "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008." boilerplate. RFC5738 did have that. Did the text that caused that document to need it get removed?
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
I took tripped over the same sentence Stephen did. Please consider the following changes proposed by Barry: OLD Because such messages are really variations on the original ones, not really "downgraded ones" (although that terminology is often used for convenience), they inevitably have relationships to the original ones that the IMAP specification [RFC3501] did not anticipate. NEW [no change; just including that sentence here for context] OLD In particular, digital signatures computed over the original message will often not be applicable to the variant version and servers that may be accessed by the same user with different clients or methods (e.g., POP or webmail systems in addition to IMAP or IMAP clients with different capabilities) will need to exert extreme care to be sure that UIDVALIDITY behaves as the user would expect. NEW This brings up two concerns in particular: First, digital signatures computed over and intended for the original message will often not be applicable to the variant message, and will often fail signature verification. (It will be possible for some digital signatures to be verified, if they cover only parts of the original message that are not affected in the creation of the variant.) [no change to the next; I've just split it out as its own sentence.] Second, servers that may be accessed by the same user with different clients or methods (e.g., POP or webmail systems in addition to IMAP or IMAP clients with different capabilities) will need to exert extreme care to be sure that UIDVALIDITY behaves as the user would expect.
(Stephen Farrell; former steering group member) No Objection
I checked the diff with 5738 but its not that useful since there are a lot of changes. Apologies in advance if I comment on something that's unchanged from there and feel free to ignore such comments. - section 1: "Most of this specification" is an odd phrase. It'd be nicer if you could be more precise, or maybe just better to s/Most of this/This/ - p4, 3rd last para says that the "server MUST NOT send UTF-8 in quoted strings to the client unless the client has indicated support using the "ENABLE UTF8=ACCEPT" command." Earlier you said that the "UTF8=ONLY" capability implies this, so I guess that this MUST NOT also doesn't apply in that case. But is that clear enough? Maybe s/using the "ENABLE UTF8=ACCEPT" command/using the "ENABLE UTF8=ACCEPT" command or "UTF8=ONLY" capability/ would be better? - section 7 says that signatures might "not be applicable" to the variant version, which reads oddly to me. I think it'd be better to say that signatures may not longer be verifiable with the variant message. (The next two questions maybe apply to all four documents in this set, but I'll ask 'em here anyway.) - I have a security question, the answer to which isn't clear to me, but maybe you can help. Is there any situation where a mailbox name or a user id might contain non-ascii characters and where the IMAP server will treat those as equivalent to some mapping to ascii? For example if joerg can use an umlaut or not, but has only set up one of the two, is there ever a threat that I could get access to joerg's mail by setting up an account with the one he's not using? I guess I'm wondering if it might be worth adding a warning about that kind of mapping. I don't know if that belongs here or not, or is already somewhere else, since its really like the general problem of "cousin" domains in phishing (paypa1 etc), but I guess some discussion somewhere would be good. - Can EAI make it more likely that a sender would encrypt a message for the wrong recipient? If so, is that worth noting? Not sure where'd be right for that, but I wondered.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Abstain) Recuse
I really didn't work on this version of the document, but they seemed determined to leave my name on it, so I shall Recuse.