Hi, > We don't get to place requirements on applications except to say what > they need to do to use EAP. The protocol requirement for that is that > applications using EAP need to know what character set they have so that > EAP can convert the identity to UTF-8 and so that EAP methods can do any > needed conversions. That text sounds pretty good, and is probably all ABFAB needs to say about this. I'm still not happy with the i18n situation in EAP; especially that EAP itself doesn't always know its requirements regarding encoding and normalization. I think the basic problem is that identities and other credentials are eap-type specific and one might expect that neither core EAP nor the AAA transport have to care about what an EAP method thinks it wants as encoding. But that isn't true, since at least the Identity part (not the passwords; I'm not saying these would need to be normalised at all) may be needed by the EAP method, but they transpire through to the EAP-Identity and RADIUS/other-AAA User-Names. It's a spill-over effect, where an EAP method's decisions re encoding and normalisation impose something on other protocols. Due to that, an EAP method's way of constructing *identities* needs to be regulated so that the method, core EAP, and AAA transports can get along. Nothing of this needs to happen in ABFAB, but I think work needs to be done. Either by modifying EAP itself to impose a common encoding and maybe normalisation on EAP-Identity (which in turn forces EAP methods to use that same encoding and/or normalisation in their "outer" or "only" phase), or by making sure all EAP methods use an encoding that does not create problems on EAP core and the AAA layer. I think this really has "force use of UTF-8" written all over it. The question for me is which path to take, and where/who does the work. 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
Attachment:
signature.asc
Description: OpenPGP digital signature