| |
| ▲ | cryptonector 3 months ago | parent [-] | | > But if you happen to have one of the use cases that require ASN.1, open sourced tooling can be problematic precisely because of the need for a robust SLA. Why would you need a support SLA for ASN.1 and not for PB/FB? That makes no sense. And there's plenty of open source ASN.1 tooling now -- just look around this thread! | | |
| ▲ | dikei 3 months ago | parent | next [-] | | The difference is the quality of the OSS implementation: most OSS ASN.1 tool choke on the enormous 3GPP specs and others used in the telco industry, thus cannot generate 100% valid code. For some use-cases, you can get by with manually adjust the generated code. That works until the hardware vendors release a new device that use a more modern 3GPP specs and your code start breaking again. When using a commercial ASN.1 tooling, they often update their compilers to support the latest 3GPP specs even before the hardware vendors, and thus supporting a new device is way simpler. | | |
| ▲ | cryptonector 3 months ago | parent [-] | | If I got paid to write an 3GPP implementation one of the things I might do is make one open source ASN.1 stack really good. I've worked on open source projects as part of proprietary work. |
| |
| ▲ | memling 3 months ago | parent | prev [-] | | > Why would you need a support SLA for ASN.1 and not for PB/FB? That makes no sense. And there's plenty of open source ASN.1 tooling now -- just look around this thread! If your business depends on five nines plus of reliability in your 5g communications stack, you might be willing to fork over the price for it. Or if you need a bug fix made in a timely fashion to the compiker or runtime, likewise. As I've noted above, a client of mine moved to a commercial suite of tools for this reason. Protobuf and flatbuffers have different use cases in my experience, although that's somewhat limited. Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard, but these days incompatibikities have to go through ISO or ITU, etc. Your experience may be different of course. I'm just pointing out that there are reasons people will opt for a commercial product. | | |
| ▲ | cryptonector 3 months ago | parent | next [-] | | > Protobuf and flatbuffers have different use cases in my experience, although that's somewhat limited. This is true for the ASN.1 encoding rules as well. > Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard, When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code. | | |
| ▲ | memling 3 months ago | parent [-] | | > When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code. Good question. I was thinking of the transitions in the '80s, although my experience with standards written during that time is very limited. But yes, one of the reasons people use ASN.1 is because of its hard and fast commitments to backwards compatibility. |
| |
| ▲ | cryptonector 3 months ago | parent | prev [-] | | > five nines Does one pay for an SLA for every piece of hardware, firmware, and software? The codecs are the least likely cause of downtime. |
|
|
|
