Stefan Winter wrote: > I start to wonder how this was supposed to work reliably anyway so far. > The encoding is undefined, so even if a user db on the server side and > what a client sends are in sync initially, the process could break at > any time with a character-set related change in the client's OS which > is not necessarily related to the supplicant. I.e. it looks to me that > using non-ASCII characters in EAP-Identities so far was a question of > chance.
Yes. However, we can reasonably expect that a user's locale && character encoding will change rarely on one machine. We can reasonable expect that the same locale && character encodings will result in the same output data for different installations of the same OS. The result is that it's likely not much of a problem for non-roaming situations. It also bolsters my opinion that usernames are treated as opaque tokens, and not as words in a language that should be internationalized. > That, or simply people didn't use non-ASCII for identities. Which leads > to the third option: screw non-ASCII in NAIs. Though that is probably > not an overly popular approach. And RFC4282 includes it as valid > explicitly. People use non-ASCII strings for identities. Breaking this is not nice. However, using UTF-8 is likely a better choice than depending on implementation-specific behavior. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
