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