It could be worse - it could be CIMOM. Another one of those spectres of OSI that won’t die, like LDAP (hint: the TCP makes it “L”), X.509, X.25, IS-IS (actually simpler and better than the IP equivalent, OSPF, hence why it still lives, and for the enthusiasts amongst you… Radia Perlman did it), X.400 (mostly dead now, Exchange doesn’t support it anymore), and X.224 (mega obscure, but RDP uses it).
Hah. Years ago, I worked for a major national retailer. Each region was operated as a distinct unit, and it was my job to get all the regions’ networks to talk to each other.
At one point, I had IPX, SNA, AppleTalk, and IP devices all able to talk to each other. We flirted with IS-IS, but eventually settled on EIGRP before migrating to OSPF for routing information on the IP side.
(There was also Cisco’s other custom routing protocol, not EIGRP, the other one. What was it…I can’t remember now. Basically zero configuration but not designed for larger networks…it was neat.)
Those were the..well, those were definitely days of some sort.
No, but thank you. I was pulling my hair out, so I finally found it. You gotta remember that this was like 20 years ago.
Cisco’s On-Demand Routing (ODR) was what I was thinking of. They had the Cisco Discovery Protocol (CDP), which is a proprietary data-link-layer protocol. When two Cisco devices were connected via a link that supported it, they’d send identification information back and forth, and each device would learn from the other what was on the other end.
On-Demand Routing is an extension to that, where hub-and-spoke/star topology networks would basically have all their routing discovered/configured automatically.
It only worked for the simplest of network topologies, but it was truly fire-and-forget. It was neat. We ended up not being able to use it (for obvious reasons; we had a complex setup), but I just remember really liking it. It wasn’t really a “routing protocol” per se, except in the simplest terms.
Especially the great idea of custom tags that makes in impossible to decode otherwise sensible TLV without specification.
I know I repeat myself, but do not under any circumstances even consider using ASN.1 for anything. Stick with CBOR, an extensible TLV format with sane semantics. Pretty please!
Nothing prevents you from using CBOR with ASN.1… Also their use case is different. CBOR is meant for unstructured data and ASN.1 (and it’s encodings, it is important to differentiate between them) is meant for structured data. So ASN.1 is more similar to ProtoBufs rather than CBOR.
No need. In dynamically typed languages I can validate payloads with jsonschema and use them directly. In statically typed languages (Haskell, Rust) an applicative parser can be used (Aeson for example).
ASN.1 should be used to generate the parser. But in practice OpenSSL rolled their own by hand. I wonder why? It resulted in several notable exploits.
The problem with JSON-Schema is that it is only about JSON. And from what I see CDDL could be used as “ASN.2” format, just define other encodings for that and I would be happy.
I think that ASN.1 could benefit from revised version of ASN.2 that would remove obsolete cruft and uniform the naming. Maybe with some syntax cleanups. This would be useful as the ASN.1 representations are quite vast (for example JER and XER for those who may be interested in that) and I think that with proper RFC and promotion it could gain some traction again as a contender to ProtoBufs or similar data description languages.
I’d argue against having a new version. ASN.1 is used extensively in my line of work, telecom, and the lack of support in most libraries is daunting. Having a new revised standard would mean even more division. Right now the only parsers that can fully support ASN.1 syntax are all proprietary, none of the open source ones can decently parse advanced schemas. That’s in part because of a monopoly in who drives those standards to begin with as it can give an edge when new telecom standards choose to adopt specific encoding.
Having a new revised standard would mean even more division.
Partially I agree, however with “clean state” standard, that would remove much of accumulated cruft, it could be easier to implement new FLOSS libraries that would support it fully.
Additionally I meant to make it backwards compatible, so all existing encodings still would be possible to describe with new specification format.
…and the lack of support in most libraries is daunting
When ever I looked at protobuf everything seemed to just to C bindings to libprotobuf which means there is really only one implementation; which as a standard makes it pointless[1].
ASN.1, warts and all, at least there are multiple implementations to pick from. The Erlang ASN.1 implementation looks pretty comprehensive (unsurprising giving its history) though I have not had to use it in anger.
[1] msgpack is mostly awful, but it does at least have multiple implementations…for better or worse
Then please make your request more precise, I’m afraid this reply for now sounds to me as equal to “this counterexample doesn’t fit my narrative ergo it is not valid”. Please also try to avoid argument by vague ridcule.
edit: Umm, how about a Java implementation that I found like, on the first page of Google results? Ok, I suppose it is also authored by Google; so is it now bad that the protocol authors provide many implementations? If yes, why?
I see lot of haters here which makes me a bit sad. So I want to thank you for your article and express, that there are also people who like ASN.1. It is very powerful (meta)format.
I am one of them. I am in a project using a protocol specified using (a small variation of) ASN.1 and it has been an interesting experience, which made me wonder why people are so crazy about JSON everywhere.
In fact, a couple of weeks ago, when I saw a post about MessagePack in here, I wondered why the authors decided to re-invent the wheel.
Every time I deal with SNMP (where ASN.1 plays a major role), I’m reminded that the “S” is a vile lie.
It could be worse - it could be CIMOM. Another one of those spectres of OSI that won’t die, like LDAP (hint: the TCP makes it “L”), X.509, X.25, IS-IS (actually simpler and better than the IP equivalent, OSPF, hence why it still lives, and for the enthusiasts amongst you… Radia Perlman did it), X.400 (mostly dead now, Exchange doesn’t support it anymore), and X.224 (mega obscure, but RDP uses it).
Hah. Years ago, I worked for a major national retailer. Each region was operated as a distinct unit, and it was my job to get all the regions’ networks to talk to each other.
At one point, I had IPX, SNA, AppleTalk, and IP devices all able to talk to each other. We flirted with IS-IS, but eventually settled on EIGRP before migrating to OSPF for routing information on the IP side.
(There was also Cisco’s other custom routing protocol, not EIGRP, the other one. What was it…I can’t remember now. Basically zero configuration but not designed for larger networks…it was neat.)
Those were the..well, those were definitely days of some sort.
Were you thinking of IGRP, the precursor to EIGRP?
No, but thank you. I was pulling my hair out, so I finally found it. You gotta remember that this was like 20 years ago.
Cisco’s On-Demand Routing (ODR) was what I was thinking of. They had the Cisco Discovery Protocol (CDP), which is a proprietary data-link-layer protocol. When two Cisco devices were connected via a link that supported it, they’d send identification information back and forth, and each device would learn from the other what was on the other end.
On-Demand Routing is an extension to that, where hub-and-spoke/star topology networks would basically have all their routing discovered/configured automatically.
It only worked for the simplest of network topologies, but it was truly fire-and-forget. It was neat. We ended up not being able to use it (for obvious reasons; we had a complex setup), but I just remember really liking it. It wasn’t really a “routing protocol” per se, except in the simplest terms.
It’s a trap!
Especially the great idea of custom tags that makes in impossible to decode otherwise sensible TLV without specification.
I know I repeat myself, but do not under any circumstances even consider using ASN.1 for anything. Stick with CBOR, an extensible TLV format with sane semantics. Pretty please!
Nothing prevents you from using CBOR with ASN.1… Also their use case is different. CBOR is meant for unstructured data and ASN.1 (and it’s encodings, it is important to differentiate between them) is meant for structured data. So ASN.1 is more similar to ProtoBufs rather than CBOR.
No need. In dynamically typed languages I can validate payloads with jsonschema and use them directly. In statically typed languages (Haskell, Rust) an applicative parser can be used (Aeson for example).
ASN.1 should be used to generate the parser. But in practice OpenSSL rolled their own by hand. I wonder why? It resulted in several notable exploits.
The problem with JSON-Schema is that it is only about JSON. And from what I see CDDL could be used as “ASN.2” format, just define other encodings for that and I would be happy.
I tell people to, where possible, just use Cap’n Proto. You get serialization and security benefits. It also might be faster than the alternative.
Is it possible to send an integer from Python to C without schema? If not, I’d stay away unless I have specific needs.
But still way better than ASN.1 / [DB]ER.
I think that ASN.1 could benefit from revised version of ASN.2 that would remove obsolete cruft and uniform the naming. Maybe with some syntax cleanups. This would be useful as the ASN.1 representations are quite vast (for example JER and XER for those who may be interested in that) and I think that with proper RFC and promotion it could gain some traction again as a contender to ProtoBufs or similar data description languages.
I’d argue against having a new version. ASN.1 is used extensively in my line of work, telecom, and the lack of support in most libraries is daunting. Having a new revised standard would mean even more division. Right now the only parsers that can fully support ASN.1 syntax are all proprietary, none of the open source ones can decently parse advanced schemas. That’s in part because of a monopoly in who drives those standards to begin with as it can give an edge when new telecom standards choose to adopt specific encoding.
Partially I agree, however with “clean state” standard, that would remove much of accumulated cruft, it could be easier to implement new FLOSS libraries that would support it fully.
Additionally I meant to make it backwards compatible, so all existing encodings still would be possible to describe with new specification format.
When ever I looked at protobuf everything seemed to just to C bindings to
libprotobufwhich means there is really only one implementation; which as a standard makes it pointless[1].ASN.1, warts and all, at least there are multiple implementations to pick from. The Erlang ASN.1 implementation looks pretty comprehensive (unsurprising giving its history) though I have not had to use it in anger.
[1] msgpack is mostly awful, but it does at least have multiple implementations…for better or worse
I don’t think the Go protobuf library links to the C one? I don’t seem to see
Cin its import graph… so, I’d guess this counters your point?Go is a bit of cop out counterpoint by any stretch, the folks who invented both happen to interop is not really ‘stop the press’ territory.
Then please make your request more precise, I’m afraid this reply for now sounds to me as equal to “this counterexample doesn’t fit my narrative ergo it is not valid”. Please also try to avoid argument by vague ridcule.
edit: Umm, how about a Java implementation that I found like, on the first page of Google results? Ok, I suppose it is also authored by Google; so is it now bad that the protocol authors provide many implementations? If yes, why?
http://wondermark.com/735/
I see lot of haters here which makes me a bit sad. So I want to thank you for your article and express, that there are also people who like ASN.1. It is very powerful (meta)format.
I am one of them. I am in a project using a protocol specified using (a small variation of) ASN.1 and it has been an interesting experience, which made me wonder why people are so crazy about JSON everywhere.
In fact, a couple of weeks ago, when I saw a post about MessagePack in here, I wondered why the authors decided to re-invent the wheel.
But, well, there are so many serialisation formats, and different people seem to like the different flavors.
If I can, I will keep using it. :)
Add two more consecutive optional fields with an identical type to one of your structs and you’ll understand.
I tried to read some ASN.1 guide once and got super confused by it; this post however makes it seem so simple! 💕