Hi, I have downloaded the free radius server and successfully installed on linux machine.. Can you please tell me that does your this implimentation supports the US-ASCII to UTF-8 conversion as you are saying this is compliant to RFC 2865 ? thanks and regards, karnik jain
karnik jain wrote:
Hi,
I have downloaded the free radius server and successfully installed on linux machine.. Can you please tell me that does your this implimentation supports the US-ASCII to UTF-8 conversion
They are compatible. No conversion is required.
as you are saying this is compliant to RFC 2865 ?
Yes. Alan DeKok
Hello Sir, Thank you so much for spending valuable time of yours for the reply. As per my understanding of RFC 2865, It is clearly written in section 5.0 of RFC 2865 that “text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.” So, It has to be converted into UTF-8 as per *RFC 3629 - UTF-8, a transformation format of ISO 10646 *at the time of sending ACCESS REQUEST packet to RADIUS server by NAS and same it has to be decoded by NAS when it is being received from server in ACCESS ACCEPT packet. If it would be compatible to each other than What is the need of including above statement in RFC-2865 clearly? Sir, I am totally confused by your statement that “*there is no need of conversion as it is compatible”.* I have searched a lot regarding this thing and I am not able to find any such thing as said by you. I am also able to find one open source library named *iconv* which can does this encoding and decoding task. *Can you please tell me that? * *From where I can find the information regarding US-ASCII & UTF-8 compatibleness as per your reply or any RFC number if it is known to you?* ** ** *Looking forward to your positive reply at your earliest,* *- Karnik Jain* On Wed, Dec 15, 2010 at 7:52 PM, Alan DeKok <aland@deployingradius.com>wrote:
karnik jain wrote:
Hi,
I have downloaded the free radius server and successfully installed on linux machine.. Can you please tell me that does your this implimentation supports the US-ASCII to UTF-8 conversion
They are compatible. No conversion is required.
as you are saying this is compliant to RFC 2865 ?
Yes.
Alan DeKok - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 12/15/2010 10:00 AM, karnik jain wrote:
Hello Sir,
Thank you so much for spending valuable time of yours for the reply.
As per my understanding of RFC 2865,
It is clearly written in section 5.0 of RFC 2865 that
“text 1-253 octets containing UTF-8 encoded 10646 [7]characters. Text of length zero (0) MUST NOT be sent;omit the entire attribute instead.”
So, It has to be converted into UTF-8 as per*RFC 3629 - UTF-8, a transformation format of ISO 10646*at the time of sending
ACCESS REQUEST packet to RADIUS server by NAS and same it has to be decoded by NAS when it is being received from server
in ACCESS ACCEPT packet.
If it would be compatible to each other thanWhat is the need of including above statement in RFC-2865 clearly?
Sir,
I am totally confused by your statement that “*there is no need of conversion as it is compatible”.*
I have searched a lot regarding this thing and I am not able to find any such thing as said by you.
I am also able to find one open source library named*iconv* which can does this encoding and decoding task.
*Can you please tell me that?*
* From where I can find the information regarding US-ASCII& UTF-8 compatibleness as per your reply or any RFC number if it is known to you?*
ASCII is a proper subset of UTF-8. No conversion is necessary, ASCII is UTF-8 by definition. If you read the relevant RFC's you would know this, it's not hard to find this information thus it's left as an exercise to the reader :-) -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hello, Thank you so much for spending valuable time of yours for the reply. As per my understanding of RFC 2865, It is clearly written in *section 5.0 of RFC 2865* that, *“text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.” * So, It has to be converted into UTF-8 as per RFC 3629 - UTF-8, a transformation format of ISO 10646 at the time of sending ACCESS REQUEST packet to RADIUS server by NAS and same it has to be decoded by NAS when it is being received from server in ACCESS ACCEPT packet. If it would be compatible to each other than What is the need of including above statement in RFC-2865 clearly, correct me If my understanding is wrong? Sir, I am totally confused by your statement that *“there is no need of conversion as it is compatible*”. I have searched a lot regarding this thing and I am not able to find any such thing as said by you. I am also able to find one open source library named *iconv* which can does this encoding and decoding task. ** *Can you please tell me that,* *From where I can find the information regarding US-ASCII & UTF-8 compatibleness as per your reply or any RFC number if it is known to you? * ** Looking forward to your positive reply at your earliest, - Karnik Jain On Wed, Dec 15, 2010 at 7:52 PM, Alan DeKok <aland@deployingradius.com>wrote:
karnik jain wrote:
Hi,
I have downloaded the free radius server and successfully installed on linux machine.. Can you please tell me that does your this implimentation supports the US-ASCII to UTF-8 conversion
They are compatible. No conversion is required.
as you are saying this is compliant to RFC 2865 ?
Yes.
Alan DeKok - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
karnik jain wrote:
As per my understanding of RFC 2865,
It is clearly written in *section 5.0 of RFC 2865* that, *“text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.” *
So, It has to be converted into UTF-8
No. 7 bit US-ASCII is a subset of UTF-8.
If it would be compatible to each other than What is the need of including above statement in RFC-2865 clearly, correct me If my understanding is wrong?
The statement is required for international text. i.e. non US-ASCII.
*Can you please tell me that,* *From where I can find the information regarding US-ASCII & UTF-8 compatibleness as per your reply or any RFC number if it is known to you? *
Read the UTF-8 RFC. This is all documented elsewhere, and is not part of FreeRADIUS. Alan DeKok.
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 ? On Wed, Dec 15, 2010 at 8:43 PM, Alan DeKok <aland@deployingradius.com>wrote: > karnik jain wrote: > > As per my understanding of RFC 2865, > > > > It is clearly written in *section 5.0 of RFC 2865* that, > > *“text 1-253 octets containing UTF-8 encoded 10646 [7] characters. > > Text of length zero (0) MUST NOT be sent; omit the entire attribute > > instead.” * > > > > So, It has to be converted into UTF-8 > > No. 7 bit US-ASCII is a subset of UTF-8. > > > If it would be compatible to each other than What is the need of > > including above statement in RFC-2865 clearly, > > correct me If my understanding is wrong? > > The statement is required for international text. i.e. non US-ASCII. > > > *Can you please tell me that,* > > *From where I can find the information regarding US-ASCII & UTF-8 > > compatibleness as per your reply or any RFC number if it is known to you? > * > > Read the UTF-8 RFC. This is all documented elsewhere, and is not part > of FreeRADIUS. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html >
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. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
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/
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 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.* *-> 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? * **
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.
-> *Can you please focus some more on this point?, I am not at all understood your point sir.* Regards, karnik jain
karnik jain wrote:
*-> 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.* *-> 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? *
If you don't understand how ASCII and UTF-8 work, got read the specifications. This is not a question for FreeRADIUS.
-> *Can you please focus some more on this point?, I am not at all understood your point sir.*
Read the regular expression documentation for how it handles UTF-8. This is not a question for FreeRADIUS. Alan DeKok.
participants (3)
-
Alan DeKok -
John Dennis -
karnik jain