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 > >
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
