<div>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.<br>
</div>
<div class="gmail_quote">
<div> </div>
<div><strong>-> I understood that ones who wants to use text other than ASCII than that is up him to convert into UTF-8 first and send it to RADIUS server.</strong></div>
<div><strong>-> But then How can free RADIUS server can performed the job of varrifying credentials in above UTF-8 case, because it is not going to understand UTF-8? </strong></div>
<div><strong></strong> </div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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. </blockquote>

<div> </div>
<div> </div>
<div>->   <strong>Can you please focus some more on this point?, I am not at all understood your point sir.</strong></div>
<div> </div>
<div> </div>
<div>Regards,</div>
<div>karnik jain</div></div>