On 08/25/2010 03:51 AM, Kostas Kalevras wrote:
All attribute values could use the syntax "<op> <value>" where<op> one of =,:=, += etc (it's been a while since i used it though, see ldap_pairget()). So it's probably a good idea to keep them that way.Why would you handle most RADIUS attribute values as UTF-8 instead of plain ASCII?
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. 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. 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. 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. Remember that ASCII is a proper subset of UTF-8 so if current practice remains storing only ASCII strings nothing would be affected (other than we've provided one part of the path for any future support of i18n without having to go back and modify your database). Does that make more sense? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/