query
John Dennis
jdennis at redhat.com
Thu Dec 16 14:56:24 CET 2010
On 12/16/2010 08:14 AM, John Dennis wrote:
> On 12/16/2010 04:25 AM, karnik jain wrote:
>> Ok, I understood your point.
>> But as per RFC 2865,
>> what is the meaning of then "UTF-8 encoded 10646 [7] characters", *the [7]?*
>> *7 stands for what over here?*
>> **
>>
>> And one more thing as per RFC 2865,
>> 1) As per this new RFC only only we need to support US-ASCII not any
>> other character set, right?
>> 2) Does free RADIUS only supporting US-ASCII ?
>
> I cannot follow how you are reaching your conclusions. Perhaps you don't
> understand UTF-8 encoding, but since you reference footnote [7] above
> which is the UTF-8 RFC it might be a good idea to read it. Or read the
> Wikipedia entry for it which is easier to understand
> http://en.wikipedia.org/wiki/Utf-8.
>
> Bottom line, FreeRADIUS supports international text via UTF-8 encodings.
Ah, it occurred to me I might know where your confusion is coming from.
In an earlier email you referenced the iconv encoding library and asked
shouldn't FreeRADIUS be encoding/decoding text. The answer is no. The
reason why is because radius implementations treat text as an octet
string (e.g. a sequence of bytes). Those octets are supposed to be a
UTF-8 encoding and are supplied to FreeRADIUS by external entities. It's
those external entities which are responsible for assuring the octet
string they supply is a proper UTF-8 encoding. That includes backends
which look-up text during processing, network clients supplying values
and any text editor used to read/write config files.
I can think of only one area which might be problematic. The regular
expression engine used to match and extract strings fundamentally wants
to operate on characters not encoded octets. But that is not an RFC
compliance issue.
--
John Dennis <jdennis at redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the Freeradius-Users
mailing list