Hi, > The alternative is for supplicants to simply start using UTF-8. It's > likely a good idea, in any case. >
Yes, I'd be very happy if supplicants did that. Obviously some refrained from doing it so far, and I don't think there is a lot of incentive to make them change their code if we can't even rightfully claim that the current behaviour is violating the EAP RFC. > A compatibility option would be for the server to look at it's list of > known users, and convert them (where appropriate) to UTF-8. > 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. 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. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
