Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames

Note: This ballot was opened for revision 07 and is now closed.

Ben Campbell Yes

Terry Manderson Yes

Alexey Melnikov Yes

Adam Roach Yes

Comment (2017-07-05 for -08)
I like the clear explanation of some of the design choices in here (e.g., the rationale for using NFKC).

There are two places that I think a slight bit of additional text might be useful:

1. When talking about processing "each string" in section 2.4, it's probably worth noting that implementations should be careful not to assume that any information received from a wire protocol has necessarily had any of the rules in this document applied to it (as this might allow intentionally noncompliant clients to slip certain kinds of shenanigans past their checks); and

2. Where the final paragraph of section 4 indicates that the operations in this document are not necessarily idempotent, it is probably worth being more explicit that they should be applied repeatedly until the output string is stable; or, if the string does not stabilize after a reasonable number of iterations (is this possible?), that it should be rejected as invalid.

Alia Atlas No Objection

Deborah Brungard No Objection

Benoit Claise No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-07-04 for -08)
This is wildly outside my area of expertise -- about the only thing I know about PRECIS, Unicode, internationalization and similar is that it is tricky and subtle. 
I'm balloting No Objection with the belief that the author and AD understand this stuff :-)

I would like to point out the OpsDir review from Nevil: (which, I see, you have already responded to).

Mirja K├╝hlewind No Objection

Kathleen Moriarty No Objection

Eric Rescorla No Objection

Alvaro Retana No Objection