Simon Josefsson wrote:
Informative Note: Implementors are encouraged to create test cases
that use both username passwords with non-ASCII characters. In
particular, it's useful to test characters whose "normalization
form C" and "normalization form KC" are different. Some examples
of such characters include Vulgar Fraction One Half (U+00BD) and
Acute Accent (U+00B4).
+1.
Do you think this would increase the likelihood of interoperability
with non-ASCII passwords?
For implementers that decides to use SASLprep but just happens to get
things wrong, yes. For those, I think test vectors would be even more
useful.
I was also hoping the tests would convince implementors to actually do
SASLprep :-) Otherwise, they might test their implementation with a
couple of non-ASCII passwords, and conclude that "just use UTF-8"
interoperates just fine (with someone else's code).
(If you just pick some non-ASCII password for your test case, it's
quite likely that its NFC and NFKC are equivalent, and the input
to your code is already NFC...)
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf