| ▲ | dikei a day ago |
| DER is still easy, UPER (unaligned packed encoding rules) is so much harder, yet it's prevalent in Telecom industry.
Last I checked, there was no freely available tool than can handle UPER l00% |
|
| ▲ | bryancoxwell a day ago | parent | next [-] |
| Not only is UPER hard to parse, but (I believe) 3GPP ASN1 definitions are provided only in .docx files which aren’t exactly the easiest to work with. It’s just really not a fun domain. |
| |
| ▲ | jeroenhd a day ago | parent | next [-] | | The ASN.1 format itself isn't too bad. It shows its age and has some very weird decisions behind it as places, but it's not that difficult to encode and is quite efficient. Unfortunately, the protocols themselves can be confusing, badly (or worse: inconsistently) documented, and the binary formats often lack sensible backwards compatibility (or, even worse: optional backwards compatibility). Definitions are spread across different protocols (and versions thereof) and vendors within the space like to make their own custom protocols that are like the official standardised protocols, but slightly different in infuriating ways. If you parser works (something open source rarely cares about so good luck finding one for your platform), the definitions extracted from those DOCX files are probably the least of your challenges. | |
| ▲ | sobkas a day ago | parent | prev [-] | | First you can download specifications in either PDF or doc(x). Second doc(x) are simple enough that simple doc(x) to ASCII/text is good enough to produce working ASN.1 definition. Copy&paste is also an option. |
|
|
| ▲ | masklinn a day ago | parent | prev | next [-] |
| FWIW rasn linked above claims to support UPER, but I couldn't tell you how completely. |
| |
| ▲ | nicce a day ago | parent [-] | | There are many tools that can handle UPER up to certain level (some rare ASN.1 types might not be supported). I think the main issue is not in the codec, rather the lack of compilers that can create correct language-level representation of the ASN.1 definitions. 3GPP specifications are enormous and you don't want to create them by hand. ASN.1 has some very difficult notations, e.g. inner subtype constraints and information object classes. Subtype constraints may affect for the encoding output in UPER and if you are not representing them correctly overall, then you are not compatible. |
|
|
| ▲ | flowerthoughts a day ago | parent | prev | next [-] |
| How come they don't (just) apply zlib on DER? Is telco equipment able to stream process UPER without buffering more than non-constructed values? |
| |
| ▲ | userbinator a day ago | parent | next [-] | | When every bit passing through the network gets charged (if not to the customer, then it's taking up capacity that could otherwise be charged to the customer), and the software in the endpoints needs to be as low-power as possible, zlib is additional overhead you definitely don't want. | |
| ▲ | eqvinox a day ago | parent | prev [-] | | PER were defined in 1994; back then applying zlib wasn't something you "just" do. Modern use is backwards compatibility (or cargo cult.) | | |
| ▲ | nicce a day ago | parent [-] | | UPER is extremely compact encoding format. It still makes sense to use UPER, because after all, it is an international standard and telecommunication protocols itself are supposed to add as little overhead on top of actual payload as possible. For example, if you have ASN.1 UTF-8 string that is constrained to 52 specific characters - UPER encoding can present every character with 6 bits (not bytes). In modern world you can apply zlib on top of UPER encoding or internal payload, however, depending on the use case. |
|
|
|
| ▲ | nly a day ago | parent | prev [-] |
| asn1c claims to support "unaligned basic PER" |
