John Dennis wrote:
Internally most software is agnostic as to whether string data is ASCII or UTF-8 provided it handles the string as a whole unit and does not try to operate on individual characters or substrings.
FYI: Pretty much all of the "readable content" RADIUS attributes are UTF-8. Any non-readable content attributes are opaque binary blobs.
Not all attributes are appropriate candidates for i18n support, however those which are fundamentally names and descriptions would benefit. For example when I added client (e.g. NAS) support to rlm_ldap it seemed to me the client short name and description should support i18n. For the previously existing attributes in the schema I would imagine things the the GroupName, HuntGroupName, Prompt, UserCategory, ReplyMessage, etc. would be friendlier if you could specify these values in your native language.
All of the "internal" FreeRADIUS attributes like "Group" or "Huntgroup" should be UTF-8.
An open question is if internally FreeRADIUS does anything with these values other than copy them and compare them for equality, if that's the only operations then there shouldn't in theory be a problem.
Pretty much, yes.
However even if there were internal problems with these values being encoded in UTF-8 that is an independent issue from whether the specification of a backend database schema which might be widely deployed should fundamentally prohibit the possibility of storing strings in a native language.
The server should be able to handle any printable string as UTF-8. Alan DeKok.