| ▲ | cryptonector 15 hours ago |
| Would you rather they reinvent the wheel badly? Thjat's what ProtocolBuffers is: badly reinvented ASN.1/DER! PB is: - TLV (tag-length-value), like DER
- you have to explicitly list the
tags in the IDL as if it was ASN.1
in 1984 (but actually, worse,
because even back then tags were
not always required in ASN.1, only
for diambiguation)
- it's super similar to DER, yet not
not the same
- PB was created in part because ASN.1
had so little open source tooling,
but PB had none until they wrote it
so they could just have written the
ASN.1 tooling they'd wished they had
smh |
|
| ▲ | RainyDayTmrw 14 hours ago | parent | next [-] |
| In complete fairnes to PBs, PBs have a heck of a lot less surface area than ASN.1. You could argue, why not use a subset of ASN.1, but it seems people have trouble agreeing which subset to use. |
| |
| ▲ | cryptonector 2 hours ago | parent [-] | | I don't agree with that. PB is practically the same as DER. All the attack surface area lies in the codec, specifically in the decoder. |
|
|
| ▲ | mort96 11 hours ago | parent | prev | next [-] |
| Why wouldn't you want to explicitly number fields? Protocols evolve and get extended over time, making the numbering explicit ensures that there's no accidental backwards compat breakage from re-ordering fields. Implicit field numbers sounds like an excellent reason to not use ASN.1. This shilling for an over-engineered 80s encoding ecosystem that nobody uses is really putting me off. |
| |
| ▲ | cryptonector 2 hours ago | parent [-] | | > Why wouldn't you want to explicitly number fields? Protocols evolve and get extended over time, making the numbering explicit ensures that there's no accidental backwards compat breakage from re-ordering fields. ASN.1 went through this whole evolution, and ended up developing extensive support for extensibility and "automatic tagging" so you don't have to manually tag. That happened because the tagging was a) annoying, b) led to inconsistent use, c) led to mistakes, d) was almost completely unnecessary in encoding rules that aren't tag-length-value, like PER and OER. The fact that you are not yet able to imagine that evolution, and that you are not cognizant with ASN.1's history proves the point that one should study what came before before reinventing the wheel [badly]. |
|
|
| ▲ | flowerthoughts 15 hours ago | parent | prev [-] |
| The one thing that grinds my gears about BER/CER/DER is that they managed to come up with two different varint encoding schemes for the tag and length. |
| |
| ▲ | cryptonector 14 hours ago | parent [-] | | Meh. One rarely ever needs tags larger than 30, and even more seldom tags larger than twice that, say. | | |
| ▲ | flowerthoughts 6 hours ago | parent [-] | | Yeah, but if you're writing a parser for use by others, you have to implement both, even if it's "rarely" used. Or some intern somewhere will have a bad day after getting tasked with "just add this value here, it'll be an easy starter project." :) | | |
|
|
