[cryptonector]

People have been reinventing IDLs since forever and a day.

S-expressions are the oldest serialization format that I know of. ASN.1 is a fairly ancient IDL that was used for RPC back in the early 80s (ISODE/ROSE). There's ONC RPC, with XDR as the IDL. There's DCE RPC (and MS-RPC). And many many many many others. There's tons of serialization formats, and they all tend to have one or more related sort of RPC frameworks, ad-hoc or otherwise. Perl5 has several, no?

This is the space of NIH.

Take protocol buffers. It's supposed to be an anti-ASN.1, but it's actually remarkably similar to ASN.1's DER (distinguished encoding rules), which means it has lots of the same mistakes. It's all very sad.

[cmeiklejohn]

If you actually read the paper, we talk about ASN.1 and why it's insuffient for what we are doing. That's clearly stated, and it's clear you didn't read that paragraph.

[toddh]

If you want people to be supportive and care about your work, this is not the way to go about it.

[cryptonector]

Thanks for noting this. I was hoping my lengthy reply would get this point across more subtly, but maybe a more explicit note will be better.

[cryptonector]

I was responding to a comment, not TFA. I had not read TFA at all at that time. Looking at the one paragraph that mentions ASN.1 (skimming the rest for context), I cannot help but wonder how familiar you are with ASN.1. SNMP is not a good example of how to use ASN.1. To be fair you're referencing a paper that discusses SNMP's use of ASN.1, but... you say nothing at all about how ASN.1 is inadequate, or what might be missing from it! What gives. Did you actually read anything about ASN.1? Did you even skim the ITU-T x.68x and x.69x document series?

[EDIT: I missed the second citation about why ASN.1 is inadequate. I will have to read that, though I'll admit that I am skeptical. Keep in mind that ASN.1 has been extended over time, so that one good question might be: what is missing that cannot be added? This is especially a good question when the alternative is to start from scratch.]

Note that I am [and my earlier comment certainly was] not defending or promoting ASN.1. I am saying that we have had a lot of reinventions of IDLs.

Now I'm also adding that a lot of ASN.1 haters don't really have a clue about ASN.1. Typically what they hate is a) the tag-length-value encoding rules (but not all ASN.1 encoding rules are TLV!), BER/DER/CER, and b) the syntax (which, whatever, it's just syntax).

The ASN.1 haters completely miss out on: the rather vast literature on encoding rules (including PER and OER which most closely resemble XDR), advanced features (e.g., the Information Object System), and especially the related SDL (which, granted, I believe simply hasn't had much use at all, at least that I'm aware of, but it's a very interesting idea that deserves more study). Instead, the ASN.1 haters generally produce or choose alternatives which either have roughly the same darned problems (Protocol Buffers, I'm looking at you), or a completely different set of also-obnoxious problems (e.g., JSON's escaping requirements for strings).

And so the circle of NIH [bad] wheel reinvention goes.

Another common objection to ASN.1 is lack of open source tooling. However, this is not really true anymore, with several decent open source ASN.1 compilers in existence. Of course, if you choose to invent a new IDL, then initially there will be no open source tooling for it!

I'm perfectly happy to not use ASN.1. I'll be perfectly happy if someone else doesn't use it. I'm not happy to see ASN.1 haters toss the baby (ASN.1's good ideas) out with the bathwater only to then reinvent the wheel badly. Your exceedingly-light on the evidence dismissal of ASN.1 is par for the course, and does not help.

EDIT: Note that I'm not calling you an "ASN.1 hater".

[cryptonector]

I have looked at that second reference[0] (your reference [9]). That's a paper from 1994! The ASN.1 Information Object System was brand new, as well as parametrization, and the paper does make use of them. That paper does not even reference any of the ASN.1 specifications(!) -- this is infuriating but understandable given that those ITU-T specs were not freely accessible back then, which is even more infuriating, but still, you'd expect academics to still include references to them, and even to purchase access.

More importantly, there are NO conclusions in [0] (your [9]) that would support your dismissal of ASN.1. On the contrary, I would think it's the opposite. My conclusion is that you did not read your own references and did not do the research you should have done. This is, of course, par for the course in this sub-field of computer science. Everyone seems to always think they know better without actually making sure that they do. Some of this, of course, is due to the sheer cognitive load of the literature to which you and everyone else seem eager to add without doing anything to make it easier on the rest of us. You've taken the easy, lazy path. I'm not expecting you to do a full survey of IDLs, and I'm not expecting you to look at ASN.1 and say "aha! they have all the answers", but I am expecting you to have more than no idea about it when you reference it, or if you're going to use a reference as authoritative for some statement, make sure that it actually is.

If I've made a mistake chasing down references, please let me know. I'm eager to understand why you reject ASN.1. I'm particularly interested in what it is missing or does badly. Thanks.

[0] http://people.cs.vt.edu/~kafura/PreviousPapers/asn1++-ulpaa9...