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@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/