4 ms·

While a bit unergonomic to work with, the .7 protocols uses ASN.1 for defining and describing a lot of the protocols and messages. ASN.1 have some nice ideas t

by kpil 8y ago

While a bit unergonomic to work with, the .7 protocols uses ASN.1 for defining and describing a lot of the protocols and messages. ASN.1 have some nice ideas that the developer community has failed to grok, reverting back to simpler ideas that are more immediately rewarding, such as hand coding a lot of code that blasts away text based messages that may or may not be understandable to the recipients because, hey it works on my machine. The core idea is that there is a language that defines the abstract message content, and there can be several encoders - binary, text, compact binary, depening on needs and computing and bandwidth requirements. There are also some support for defining the criticality of any extensions to a protocol, to inform recipients if the can disregard an additional part it does not understand or if it's critical. This is not an afterthough as json schema, but the core idea.

sebcat 8y ago
ASN.1 JER (JSON Encoding Rules) exists, for anyone who wants it.
cesarb 8y ago
Part of the issue might be a variant of FUTON bias (https://en.wikipedia.org/wiki/FUTON_bias https://en.wikipedia.org/wiki/FUTON_bias): can I easily get the official text of the ASN.1 standard, without having to register somewhere and/or pay hundreds of Euros?
- otterlicious 8y ago
  Yes, the ASN.1 standards are freely available: https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
- kpil 8y ago
  I think it specifically is not used because it's a more complex idea that requires a lot of initial effort and mental work until the benefits are apparent. I guess it's just like most other "actually better than x" languages and standards out there. In this case it's also not the nicest language to read and it's a bit dated. It would be nice with an ASN.2 though...
  - lttlrck 8y ago
    The idea is similar to protocol buffers. Tooling is a significant barrier to entry. - The commercial offerings are very expensive. - it is a little hard to read, but very difficult to write correctly. - it is difficult to parse the spec and code generation is non-trivial, and although Basic Encoding Rules are relatively straightforward, Packed Encoding Rules are not. So rolling your own is daunting. - There are some open source tools but until recently they were unable to parse the latest language features used in LTE. I am convinced it is designed to be hard to parse to protect the encumbents. - Unless you are using C/C++ (most tools generate these) you have to somehow generate FFI bindings, which you’ll want to automate for a large spec which requires parsing the spec...
    - yaantc 8y ago
      > - There are some open source tools but until recently they were unable to parse the latest > language features used in LTE. > I am convinced it is designed to be hard to parse to protect the encumbents I don't think so, and I work for a small company doing LTE products. LTE uses a rather small subset of ASN.1, and it's not a big problem to handle it really. It's not a barrier at all, it's even making things simpler compared to a less formal definition of protocol messages. I experienced informal protocols, with the result of wasting a lot of energy on interoperability tests due to different interpretations. ASN.1 in LTE gets rid of this. IIRC, ASN.1 was created as a specification language written by humans for humans. Only later on it became used for direct code generation. So its design was not meant to be easy to parse for a compiler, although it's the way it's used now. There are several reasons to the lack of open source tools IMHO. A full ASN.1 compiler is a complex project, so that's some barrier to entry: not everyone can invest the needed time. The fact that any application typically need only a subset of the full ASN.1 means that there's likely a lot of partial /ad-hoc implementations, so not very fit to open source. Then there is a cultural aspect leading to a lack of interest: ASN.1 is old and from a specific, non mainstream culture (the telco world). The new kids are just busy with JSON or protocol buffer, even if ASN.1 works very well. It's software, we're all busy re-inventing our own better wheel ;)
      - 8y ago

by kpil 8y ago

sebcat 8y ago

ASN.1 JER (JSON Encoding Rules) exists, for anyone who wants it.

cesarb 8y ago

Part of the issue might be a variant of FUTON bias (https://en.wikipedia.org/wiki/FUTON_bias https://en.wikipedia.org/wiki/FUTON_bias): can I easily get the official text of the ASN.1 standard, without having to register somewhere and/or pay hundreds of Euros?

otterlicious 8y ago
Yes, the ASN.1 standards are freely available: https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
kpil 8y ago
I think it specifically is not used because it's a more complex idea that requires a lot of initial effort and mental work until the benefits are apparent. I guess it's just like most other "actually better than x" languages and standards out there. In this case it's also not the nicest language to read and it's a bit dated. It would be nice with an ASN.2 though...
- lttlrck 8y ago
  The idea is similar to protocol buffers. Tooling is a significant barrier to entry. - The commercial offerings are very expensive. - it is a little hard to read, but very difficult to write correctly. - it is difficult to parse the spec and code generation is non-trivial, and although Basic Encoding Rules are relatively straightforward, Packed Encoding Rules are not. So rolling your own is daunting. - There are some open source tools but until recently they were unable to parse the latest language features used in LTE. I am convinced it is designed to be hard to parse to protect the encumbents. - Unless you are using C/C++ (most tools generate these) you have to somehow generate FFI bindings, which you’ll want to automate for a large spec which requires parsing the spec...
  - yaantc 8y ago
    > - There are some open source tools but until recently they were unable to parse the latest > language features used in LTE. > I am convinced it is designed to be hard to parse to protect the encumbents I don't think so, and I work for a small company doing LTE products. LTE uses a rather small subset of ASN.1, and it's not a big problem to handle it really. It's not a barrier at all, it's even making things simpler compared to a less formal definition of protocol messages. I experienced informal protocols, with the result of wasting a lot of energy on interoperability tests due to different interpretations. ASN.1 in LTE gets rid of this. IIRC, ASN.1 was created as a specification language written by humans for humans. Only later on it became used for direct code generation. So its design was not meant to be easy to parse for a compiler, although it's the way it's used now. There are several reasons to the lack of open source tools IMHO. A full ASN.1 compiler is a complex project, so that's some barrier to entry: not everyone can invest the needed time. The fact that any application typically need only a subset of the full ASN.1 means that there's likely a lot of partial /ad-hoc implementations, so not very fit to open source. Then there is a cultural aspect leading to a lack of interest: ASN.1 is old and from a specific, non mainstream culture (the telco world). The new kids are just busy with JSON or protocol buffer, even if ASN.1 works very well. It's software, we're all busy re-inventing our own better wheel ;)
    - 8y ago