Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
RFC 8265

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

(Ben Campbell) Yes

Adam Roach Yes

Comment (2017-07-05 for -08)
No email
send info
Nit: The final paragraph of section 1 is missing a paren after "[RFC7622]".

Nit: Step 2 in section 4.2.2 cites RFC 4013 as text rather than the normal citation format of [RFC4013]

I have the same comment as I did on rfc7700bis regarding the implications of operation idempotence.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-07-05 for -08)
No email
send info
Taking a page from Benoit's playbook, here is a diff from RFC7613: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-precis-7613bis-08.txt&url2=https://tools.ietf.org/rfc/rfc7613.txt
(I feel really stupid for not realizing this earlier, but diff'ing a -bis from the base RFC is a: obvious and b: really useful for understanding which bits need more review)

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Eric Rescorla) No Objection

Comment (2017-07-05 for -08)
No email
send info
I agree with jsalowey's point about discouraging raw password comparison. Can you do something about that?

The use of "false positive" is confusing because positive can either mean "accept" or "reject". I would use "false accept" or "false reject" or some other clearer term

Alvaro Retana No Objection

Alexey Melnikov Recuse

Comment (2017-06-27 for -08)
No email
send info
I am a co-editor.