The issue I have is when values are passed to the REST module and how they end up looking. Octets come over as HEX but strings are much more user friendly. Unless I'm doing something wrong? Are there any risks associated with me updating the dictionary to make it "string" ? Thanks again. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+adrian.p.smith=bt.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 13 November 2018 18:02 To: FreeRadius users mailing list Subject: Re: Chargeable-User-Identity On Nov 13, 2018, at 11:45 AM, <adrian.p.smith@bt.com> <adrian.p.smith@bt.com> wrote:
RFC (https://tools.ietf.org/html/rfc4372#page-5) says string, but dictionary says octets.
Is there any reason?
I had an argument with the IETF 20 years ago, and lost. That might not happen now. :) The original RADIUS RFC (2038 and 2138) used "string" for both printable and binary attributes. I suggested that this was wrong. I converted the FreeRADIUS dictionaries to use "string" for printable attributes, and "octets" for binary ones. That made sense to me. The RADIUS working group listened enough to fix it, but they chose to call printable attributes "text", and binary ones "string" (RFC 2865). 20 years on, I still think it was the wrong decision. All complaints aside, the names of the data types don't matter. They could be called "a", "b", and "c" with no loss of functionality. The names have no more meaning than the attribute names. The FreeRADIUS attribute names are *generally* the same as the RFCs, but they're sometimes different. Especially for vendor attributes. The "man" page for the dictionaries documents what the data types are, and what they mean. Nothing else really matters. Alan DeKok.