Sponsored development rlm_ldap and ocsp

[John Dennis]

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 at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/