IMAP Support for UTF-8
RFC 6855

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.

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

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.

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?

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.

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.