Chargeable-User-Identity

[a***@bt.com]

RFC (https://tools.ietf.org/html/rfc4372#page-5) says string, but dictionary says octets.

Is there any reason?

TIA.

-
List info/subscribe/unsubscribe? See http://www.fr

[Alan DeKok]

Post by a***@bt.com
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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list

[a***@bt.com]

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=***@lists.freeradius.org] On Behalf Of Alan DeKok
Sent: 13 November 2018 18:02
To: FreeRadius users mailing list
Subject: Re: Chargeable-User-Identity

Post by a***@bt.com
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.






-
List info/subscribe/unsubsc

[Alan DeKok]

Post by a***@bt.com
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.

If the attribute is "octets", then it's a binary string. The only safe thing to do is to treat it as a hex string.

Post by a***@bt.com
Unless I'm doing something wrong?

You can copy the value of Chargeable-User-Identity to a "string" attribute, and then use that.

When the REST module uses the "string", any binary data will be escaped via normal string escaping rules.

Post by a***@bt.com
Are there any risks associated with me updating the dictionary to make it "string" ?

Don't mangle the default dictionaries. It will break all kinds of things in the server.

In v4, we're putting additional checks in to catch this kind of thing.

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.free