Re: Internationalization and draft-ietf-abfab-eapapplicability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]