query

[John Dennis]

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/