Correct, the compiler allows you to generate the Rust bindings automatically. Worth noting that the compiler is at an earlier stage of development (the library was started six years ago, the compiler started roughly two years ago). So there are features that aren't used or supported by the compiler that are available in the library.
Yes writing the definitions by hand can time consuming and error-prone, but I designed the library in mind around the declarative API to make it easy to both manually write and generate, I also personally prefer writing Rust whenever possible, so nowadays I would sooner write an ASN.1 module in Rust and then if needed build a generator for the ASN.1 textual representation than write ASN.1 directly since I get access to much better and stronger tooling.
Also in my research when designing the crate, there are often requests in other ASN.1 or X.509 libraries to allow decoding semantically invalid messages because in the wild there are often services sending incorrect data, and so I designed rasn to allow you mix and match and easily build your own ASN.1 types from definitions so that when you do need something bespoke, it's easy and safe.
> Yes writing the definitions by hand can time consuming and error-prone
With the proper environment, this isn't that time consuming or error-prone anymore, based on my recent experiments. When I initially started exploring with the library, it was a bit difficult at first (mostly because back then there was no reference documentation and you had to rely on tests), but after some time API gets easy to understand. Actual type definitions remain very small because of the derive macros.
Nowadays LLMs are pretty good at handling ASN.1 definitions. If you provide the context correctly, by giving e.g. the reference from the rasn's README, maybe even some type definitions from the library itself, and just give the ASN.1 schemas, LLMs can generate the bindings very accurately. The workflow switches from being the manual writer to be just the reviewer. Compiler is also already good at generating the basic definitions on most cases.
I really like the idea that then standard can be published as a crate, and nobody needs to ever touch for the same standard again, unless there is a bug or standard gets an update. Crates can be then used with different open-source projects with the same types. What I known about commercial ASN.1 usage, different companies buy these products to compile the same standards over and over again.
I bet that there are no many companies that define their internal APIs with ASN.1 and buys commercial tool just to support ASN.1 usage in their own business, without any international standards included.
> > Yes writing the definitions by hand can time consuming and error-prone
> With the proper environment, this isn't that time consuming or error-prone anymore, based on my recent experiments.
If you have modules with automatic, and manual IMPLICIT and EXPLICIT tagging and you fail to translate those things correctly then you can trivially make mistakes that cause your implementation to not interoperate.
Whether it’s malice or clumsiness isn’t relevant, it’s poor communication and process, which is the responsibility of leadership.
The project leadership has continuously failed in these areas, and there has only been an effort to improve those things when they’ve been publicly called out. Without people openly communicating leadership failures, problems have often been ignored and maligned.
Yes, it is indeed their responsibility. It is also a minor thing.
People sometimes drop the ball, sometimes repeatedly, especially in committees. Public shaming is generally reserved for egregious acts, and so needs to be justified.
Attempting to shame people, without explaining what exactly happened, suggests a hissy fit.
To be clear: I am willing to entertain the accusation that the Rust team is toxic, but that’s a case that needs to be … you know … actually argued.
People are free to speak their mind, they don’t have to justify that to you or anyone else.
> Attempting to shame people, without explaining what exactly happened, suggests a hissy fit.
Feels like self-projecting given how much you’re commenting in multiple threads to say “it’s not a big deal”, I don’t think someone who thinks it’s not a big deal would comment and try to argue so much if they actually thought it was.
They did write about compile-time reflection, their talk was part of the conference[1], and now they’re not doing the talk. That’s enough to me take what they say at face value, especially now that in the wake of this there have been resignations in the leadership.
When has any democracy worked even remotely like that? There are countless issues politicians must take a position on, you won't agree with all of them. So you prioritize. Or you just vote party line, which is by far what most people do.
All standards about ASN.1 (not including standards that use ASN.1 like MMS) are available for free from the ITU under the X.680 to X.697 series of standards.[0]
> would be really happy to see some good open source compilers with extensible encoding support being listed here
This is a shameless plug, and not a compiler per se, but it's pretty close[0]. It's a codec framework for ASN.1 in Rust similar to `serde` for other formats if you're aware of that. It uses Rust's traits to define seperate layers for the codec model, and the encoding rules, allowing you to have one model used with many encodings, and share one decoder & encoder for all models. Extensibility just uses the regular Rust `#[non_exhaustive]` attribute. It doesn't support formats like A/UPER yet, but that is coming in the next year. :)
I don't know of any third-party projects that are using it, though from talking to users and looking at the download numbers there are quite a few, they're just closed-source. You can look at the dependent downloads[0] to get an idea of whose using the implementations included with rasn.
> How easy is it to use as a codec layer from other programming languages?
It's as easy as using any Rust code from other programming languages. Rasn is completely IO-agnostic, it works entirely using byte slices (`&[u8]`). So all that should be required is writing a C-friendly layer if doing this by hand, or using a language specific binding library like PyO3 to generate more friendly bindings.
> also ASN.1 does not solve futute-extending out-of-the-box. In JSON/bencoding/XML, it's trivial to add another key/element to a dictionary/array/element and allow applications to use it if they can and ignore it otherwise. Okay, TLV looks like it could handle that, but there's nothing about it in the description language itself.
This is wrong. ASN.1 has always had support for "extensibility" out of the box. See section 52 of X.680[0] for complete details but I've included a couple of examples below. Also ASN.1 unlike other IDLs allows encodings to optionally take advantage of whether a type is considered in extensible. For example in PER, a type is a smaller encoding when it is not extensible.
A ::= INTEGER (0..10, ..., 12) -- A is 0 to 10, or 12.
-- V1 of B contains `a, b`, V2 contains `a, b, c`
B ::= SEQUENCE {
a INTEGER,
b BOOLEAN,
...
c OCTET STRING,
}
Shameless plug, but you may be interested in my library (which is MIT/Apache-2.0) that offers decoding from BER/DER/CER all from a single model in code, there's no UPER/APER support at the moment, but it's coming in the next few months. :)
Condemn me all you like, but considering the fact this is my firsthand account and that I've worked directly with these people for the past few years, and others who have worked them have said that their experience with these people was similar. And considering that you have not worked with these people or in the rust-lang organisation, which of us is really wildly speculating here? :)
Yes writing the definitions by hand can time consuming and error-prone, but I designed the library in mind around the declarative API to make it easy to both manually write and generate, I also personally prefer writing Rust whenever possible, so nowadays I would sooner write an ASN.1 module in Rust and then if needed build a generator for the ASN.1 textual representation than write ASN.1 directly since I get access to much better and stronger tooling.
Also in my research when designing the crate, there are often requests in other ASN.1 or X.509 libraries to allow decoding semantically invalid messages because in the wild there are often services sending incorrect data, and so I designed rasn to allow you mix and match and easily build your own ASN.1 types from definitions so that when you do need something bespoke, it's easy and safe.