3 ms·

> Look, ASN.1 is a crappy (but not awful!) schema language, TBH I think it's awful. The type system is woefully overcomplicated, and the syntax is totally unre

> Look, ASN.1 is a crappy (but not awful!) schema language, TBH I think it's awful. The type system is woefully overcomplicated, and the syntax is totally unrelated to any popular programming language, making it hard to learn. The fact that there are so many encodings creates confusion for the average developer who frankly cares much more about the schema language accessibility, tooling, API, language support, and documentation than the actual encoding. Protobuf is way, way ahead on all of those compared to ASN.1. > The only thing since ASN.1 that doesn't suck is XDR. Sun XDR, from the 80's? Is that actually newer than ASN.1?

cryptonector 7y ago
> > Look, ASN.1 is a crappy (but not awful!) schema language, > TBH I think it's awful. The type system is woefully overcomplicated, and the syntax is totally unrelated to any popular programming language, making it hard to learn. Is it? How? What is an alternative you like better? > > The only thing since ASN.1 that doesn't suck is XDR. > Sun XDR, from the 80's? Is that actually newer than ASN.1? The first ASN.1 specs are from 1984 (I guess it goes back a bit further). XDR/NFS are from 1986-1987. ASN.1 probably did not inform XDR in the least. Other RPC technologies from that time probably did (thinking of Apollo and such). What's interesting is that even if XDR is completely uninformed by ASN.1, it's essentially a subset of ASN.1 with different syntax and a PER-like encoding with 4-octet unit size and alignment -- the similarities are striking! And even more interesting is that the ASN.1 crowd in 1984 felt that TLV encodings were easy and non-TLV encodings like PER difficult, but XDR shows that non-TLV is not very difficult at all. The lesson of the ASN.1 experience is that TLV == bad, and PER-like == good, though flatbuffers is probably the best. And more than that, the real lesson is that open source tooling is essential. It took too many decades for ASN.1 to have decent open source tooling. Another lesson of the ASN.1 experience is that non-free standards really suck for pervasive and essential technologies. It took way to long for the ITU-T to make the ASN.1 specs available for free downloads. Now, I do understand that the ASN.1 specs are extremely well-written -- it's clear that it cost quite a lot of money to produce them, and somehow that has to be paid for, for the IETF model is much more accessible, and that is much more important than the high quality of specifications that the ITU-T is able to produce (much better than IETF RFCs, IMO).
- kentonv 7y ago
  > Is it? How? There's like a million built-in types and too many unnecessary options for specifying constraints. > What is an alternative you like better? I think Protobuf has a simpler, more practical type system and more accessible syntax compared to ASN.1. Cap'n Proto is very close to Protobuf in terms of type system and syntax, but adds some polish on both. (But Cap'n Proto is my own design, so obviously I think it's the best.) In terms of encoding, Cap'n Proto is, of course, completely different from Protobuf. I guess it is closer to PER and OER... but not particularly close.
  - cryptonector 7y ago
    Protobufs is a TLV encoding no better than DER. If it's just the syntax, then it's not much of an upgrade. Syntax is not a big deal, but semantics is, and there hasn't been much, if anything at all that's new semantics-wise since ASN.1. (Of course, that the ASN.1 syntax is difficult to parse with LALR(1) parsers is a problem. But the syntax doesn't have to change much to be easier to parse.) You don't have to know about and use all the built-in universal types in ASN.1 -- they're there if you need them. Protobufs is just a history-repetition disaster. IDK about Cap'n Proto, but I'm glad it's closer to PER/OER, if it is.
    - kentonv 7y ago
      I'm saying both the syntax and semantics (i.e. type system design) of protobuf are much superior to ASN.1 (mostly, by being much simpler and easier to understand). I believe syntax and type system are, in fact, much more important than the encoding details. To most application developers, there is no difference whatsoever between protobuf encoding, BER, DER, PER, OER, etc., because they never see the encoding. The library and tools handle that part. As long as the data gets through end-to-end with acceptable performance, nobody cares how it is represented in the interim. Cap'n Proto's encoding is different in that by being zero-copy it actually enables new use cases, like mmap()ing a very large file for random access. Still, I'd certainly choose protobuf's syntax and encoding over ASN.1's syntax paired with Cap'n Proto's encoding.

cryptonector 7y ago

> > Look, ASN.1 is a crappy (but not awful!) schema language, > TBH I think it's awful. The type system is woefully overcomplicated, and the syntax is totally unrelated to any popular programming language, making it hard to learn. Is it? How? What is an alternative you like better? > > The only thing since ASN.1 that doesn't suck is XDR. > Sun XDR, from the 80's? Is that actually newer than ASN.1? The first ASN.1 specs are from 1984 (I guess it goes back a bit further). XDR/NFS are from 1986-1987. ASN.1 probably did not inform XDR in the least. Other RPC technologies from that time probably did (thinking of Apollo and such). What's interesting is that even if XDR is completely uninformed by ASN.1, it's essentially a subset of ASN.1 with different syntax and a PER-like encoding with 4-octet unit size and alignment -- the similarities are striking! And even more interesting is that the ASN.1 crowd in 1984 felt that TLV encodings were easy and non-TLV encodings like PER difficult, but XDR shows that non-TLV is not very difficult at all. The lesson of the ASN.1 experience is that TLV == bad, and PER-like == good, though flatbuffers is probably the best. And more than that, the real lesson is that open source tooling is essential. It took too many decades for ASN.1 to have decent open source tooling. Another lesson of the ASN.1 experience is that non-free standards really suck for pervasive and essential technologies. It took way to long for the ITU-T to make the ASN.1 specs available for free downloads. Now, I do understand that the ASN.1 specs are extremely well-written -- it's clear that it cost quite a lot of money to produce them, and somehow that has to be paid for, for the IETF model is much more accessible, and that is much more important than the high quality of specifications that the ITU-T is able to produce (much better than IETF RFCs, IMO).

kentonv 7y ago
> Is it? How? There's like a million built-in types and too many unnecessary options for specifying constraints. > What is an alternative you like better? I think Protobuf has a simpler, more practical type system and more accessible syntax compared to ASN.1. Cap'n Proto is very close to Protobuf in terms of type system and syntax, but adds some polish on both. (But Cap'n Proto is my own design, so obviously I think it's the best.) In terms of encoding, Cap'n Proto is, of course, completely different from Protobuf. I guess it is closer to PER and OER... but not particularly close.
- cryptonector 7y ago
  Protobufs is a TLV encoding no better than DER. If it's just the syntax, then it's not much of an upgrade. Syntax is not a big deal, but semantics is, and there hasn't been much, if anything at all that's new semantics-wise since ASN.1. (Of course, that the ASN.1 syntax is difficult to parse with LALR(1) parsers is a problem. But the syntax doesn't have to change much to be easier to parse.) You don't have to know about and use all the built-in universal types in ASN.1 -- they're there if you need them. Protobufs is just a history-repetition disaster. IDK about Cap'n Proto, but I'm glad it's closer to PER/OER, if it is.
  - kentonv 7y ago
    I'm saying both the syntax and semantics (i.e. type system design) of protobuf are much superior to ASN.1 (mostly, by being much simpler and easier to understand). I believe syntax and type system are, in fact, much more important than the encoding details. To most application developers, there is no difference whatsoever between protobuf encoding, BER, DER, PER, OER, etc., because they never see the encoding. The library and tools handle that part. As long as the data gets through end-to-end with acceptable performance, nobody cares how it is represented in the interim. Cap'n Proto's encoding is different in that by being zero-copy it actually enables new use cases, like mmap()ing a very large file for random access. Still, I'd certainly choose protobuf's syntax and encoding over ASN.1's syntax paired with Cap'n Proto's encoding.