>>>>> "Stefan" == Stefan Winter <stefan.winter@xxxxxxxxxx> writes:
Stefan> In the other hell, it can be sure to receive UTF-8 in NFC,
Stefan> and if that doesn't match what it needs, it can convert it.
Stefan> In my naïve thinking, that second hell is a lot less hot
Stefan> and much more habitable.
This discussion has also moved to the abfab list.
I'm responding there because ultimately we'll need WG consensus for any
change.
however there's one point I'll respond in my last message on this
thread..
you have: a UTF-8 NFC hashed password response to your password
challenge.
You want: the same input to the hash except the input should be UTF-16
encoded with the normalization implicit in the Windows input method.
Or
you have: a UTF-8 NFC encoded username
you want: whatever PAM wants. Your PAM stack is complex and may involve
network protocols with their own encodings.
The second example is intended to illustrate why OS folks like Nico
Williams tend to favor normalizing usernames as late as possible. In
this case the original client and PAM probably have more information
about what is required than the goo in the middle, and you can win in
cases where you preserve the form the user gave their system but not in
other cases.
Full interop in this second case is probably impossible.