Hello, This message is more precisely direted to Alan. I have noticed that the "Class" attribute as defined in rfc2865 is a string value, but looking at dictionary that comes with freeradius i saw that it's an octet value. As far as I know none of the rfc updating 2865 redefine the class attribute. Is there a reason for this, is it safe to make it a string value?
Alexandre Chapellon wrote:
I have noticed that the "Class" attribute as defined in rfc2865 is a string value, but looking at dictionary that comes with freeradius i saw that it's an octet value.
FreeRADIUS was the first to mark some attributes as "binary" versus "ascii". The original RFC's didn't make that distinction. When they were updated, they chose different names for the types. We chose "string" and "octets" to mean "ascii" and "binary". They chose "text" and "string".
As far as I know none of the rfc updating 2865 redefine the class attribute. Is there a reason for this, is it safe to make it a string value?
I very much suggest leaving it alone. Editing things just to make the "closer" to the RFC's is not a good idea. The RFC's are well known to be wrong in many cases. e.g. After a number of similar discussions, RFC 5080 was issued. It fixes a bunch of problems in earlier RFC's, and at one point, says that the FreeRADIUS way of doing things is the best way. Since I'm a co-author, that statement was easy to make. I'm currently authoring or co-authoring 4-5 other RADIUS RFC's. One of will update RFC 4282, which is substantially wrong. Alan DeKok.
As far as I know none of the rfc updating 2865 redefine the class attribute. Is there a reason for this, is it safe to make it a string value?
I very much suggest leaving it alone. Editing things just to make the "closer" to the RFC's is not a good idea. The RFC's are well known to be wrong in many cases.
One point of (probably minor) interest; we changed it to be "string" here, because it allowed us to get readable text in SQL queries. i.e. before we had: insert into blah ... '%{Class}' ...expanding to: insert into blah ... '0xTHEHEX' ...and if it's a string we get: insert into blah ... 'thestring' ...but that only works because we *know* that we're putting readable strings into Class everywhere.
Le 27.11.2008 21:41, Alan DeKok a écrit :
Alexandre Chapellon wrote:
I have noticed that the "Class" attribute as defined in rfc2865 is a string value, but looking at dictionary that comes with freeradius i saw that it's an octet value.
FreeRADIUS was the first to mark some attributes as "binary" versus "ascii". The original RFC's didn't make that distinction. When they were updated, they chose different names for the types.
We chose "string" and "octets" to mean "ascii" and "binary". They chose "text" and "string".
As far as I know none of the rfc updating 2865 redefine the class attribute. Is there a reason for this, is it safe to make it a string value?
I very much suggest leaving it alone. Editing things just to make the "closer" to the RFC's is not a good idea. The RFC's are well known to be wrong in many cases.
Well the aim of switching type is not to be closer to rfc, i'm not fanatic enough :)! My problem is I need to send a string to the NASes in the Access-Accept and want them to sent it back to me as is in Accounting packets. Is there other attributes of type string that allow such a behaviour from the NASes?
e.g. After a number of similar discussions, RFC 5080 was issued. It fixes a bunch of problems in earlier RFC's, and at one point, says that the FreeRADIUS way of doing things is the best way. Since I'm a co-author, that statement was easy to make.
I'm currently authoring or co-authoring 4-5 other RADIUS RFC's. One of will update RFC 4282, which is substantially wrong.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alexandre Chapellon wrote:
My problem is I need to send a string to the NASes in the Access-Accept and want them to sent it back to me as is in Accounting packets. Is there other attributes of type string that allow such a behaviour from the NASes?
No. You *can* edit the dictionaries. But be aware that this is a global change, and may affect the interaction with other servers. Alan DeKok.
participants (3)
-
Alan DeKok -
Alexandre Chapellon -
Phil Mayers