Thank you all for the clarification. At least I now know in this case octetString is referring to []byte. I did the conversion to []byte and the radius server accepted the result. I was just confused when the one handling the radius server asked for "raw binary" in the response. Help appreciated!!
On Wed, Mar 15, 2023 at 6:39 PM Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > On Tue, Mar 14, 2023 at 10:25 AM Van Fury <furyva...@gmail.com> wrote: > >> Am developing a server (diameter) which will response with an AVP >> SIP-Authenticate. >> In the specification >> >> " The SIP-Authenticate AVP is of type OctetString and It shall contain, >> binary encoded, the concatenation of the authentication challenge RAND and >> the token AUTN" >> The RAND and the AUTN in this case are hexadecimal strings s1 and s2. >> >> My problem is how to encode s1 and s2 concatenated and then be able to >> decode at the server side too. >> >> > You probably want to start thinking about representations. Your > application has some internal representation of the (128-bit long) RAND and > AUTN token. And there's a representation on the "wire" in the protocol. The > protocol representation is decided for you, but you can pick any you'd like > for the internal representation. OctetString is just a synonym for []byte > in this case. And the output is going to be at length 32. You have a > function pair which encodes/decodes from your internal representation to > the protocol (and back). > > Were it me, I'd represent the internal RAND and AUTN as [16]byte data. > Then, the encoder/decoder is just the identity function in this case. If > you need a hexadecimal representation elsewhere in the application, you'd > hex-encode when you need it. It sounds to me you have chosen a hexadecimal > encoding as your internal representation, but I'd advise against it. You > end up having to do far more work getting into the right form all over in > your app. > > In any case, the advantage of thinking about internal/protocol > representation is that the conversion points between the formats become > explicit and controlled in the application. This makes it far easier to > evolve the application internally without having to worry about the wire > format. Both the wire format and the application can evolve independently > of each other. > > > -- > J. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALnxq2jjA%3DOTSwxxr9VjdW360RK4V6HRuTi8wwPgifpvdXCD7Q%40mail.gmail.com.
