dictionary.rfc2865 incorrect Class attribute definition

[elislenio]

According to rfc2865 the Class attribute is a string not octet.

In file dictionary.rfc2865
Wrong:
ATTRIBUTE Class 25 octets

Right:
ATTRIBUTE Class 25 string

Workaround is to load a custom dictionary file with definition override

[psanford]

node-radius follows the freeradius dictionary convention where 'string' is expected to be a valid utf-8 field and 'octets' is arbitrary bytes (it might still be a valid string). See https://freeradius.org/radiusd/man/dictionary.html :

     string       UTF-8 printable text (the RFCs call this "text") 
     octets       opaque binary data (the RFCs call this "string") 

Its extra confusing because the freeradius terms do not match the radius RFCs. RFC 2865 says:

      text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead.

So since rfc 2865 calls Class a string, I think it is correct that in the dictionary it is an octets field. This also matches the freeradius dictionaries.

[elislenio]

Thank you Peter for clarify the subject.
Now I think this is not an issue, but it has in fact impact when dealing with decoded packets.

It is quite common, with most of the attributes that are defined as octets, to contain some encoded string (ASCII, UTF8, other)

About my use case, I am writting a tiny RADIUS server for storing Accounting packets. The server receives a packet, decodes it and stores some attributes as a MongoDB BSON document for latter quering from API calls.

With current implementation additional code is needed to properly decode such "octet" attributes to get the values as string.
In the hurry, since BSON strings are UTF-8, overriding the type in a custom dictionary file was a quick solution.

I'm thinking maybe having a config option to treat octect attributes as string attributes can do the trick and save some time.

Regards