Sponsored development rlm_ldap and ocsp

[Alan DeKok]

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.