Sponsored development rlm_ldap and ocsp

[John Dennis]

On 08/25/2010 08:41 AM, Kostas Kalevras wrote:
>    On 25/8/2010 3:32 μμ, John Dennis wrote:
>> 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?
>>
> RADIUS attributes sent over the wire that are expected to contain a
> UTF-8 value (like Reply-Message) should be set as UTF-8 in the LDAP
> schema. Other attributes which are primarily used by freeradius
> internally (like huntgroupname or groupname) could be set to UTF-8 as
> long as freeradius is able to handle UTF-8 values. Alan could answer on
> the last one better.
>

O.K. so were all in agreement :-)

Just to recap, the current LDAP schema has a number of these values 
specified to be IA5 rather than UTF-8 and all I was suggesting is that 
we fix what appears to have been a historical mistake.

-- 
John Dennis <jdennis at redhat.com>

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