The ASN.1 standard contains two logical parts
- A way to define messages in abstract normal form
- A series of platform-agnostic encoding and decoding rules that normalize the transimission of said messages Encoding rules range from simple encodings like the Basic Encoding Rules (BER) to ultra-compact binary representations.
FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE {
trackingNumber INTEGER,
question IA5String
}
FooAnswer ::= SEQUENCE {
questionNumber INTEGER,
answer BOOLEAN
}
END
But it seems to me that this is a very niche usage...a small subset of what ASN.1 is capable of.
In Continua, the "Personal Area Network" standards which define how personal/consumer-level medical devices (like a weight scale) should talk to a controller/management program/device (like a cell phone) are all based on this standard, only with a special set of encoding/decoding rules called the Medical Device Encoding Rules (MDER).
When implementing a prototype with my IBM colleague Randy Carroll, we had trouble finding an ASN.1 library with an appropriate license and support for the special encoding. Luckily for us, the IEEE 11073 "personal health" standards which defined the messages used a limited subset of the full ASN.1 so we began our own implementation at https://www.projects.openhealthtools.org/sf/projects/stepstone (more on this in a future post).
Just recently I learned about a new messaging standard being release by Google called Protocol Buffers. Boy does it sounds similar. Only, being Google, I'm sure this new protocol technology will be touted as revolutionary and quickly beat out ASN.1 in terms of adoption level. One thing is for sure, Google will make it a lot more accessible than the pages and pages of spec that make up the "X.680 family of specifications".
I wonder, if ITU/ISO/IEC had embraced a more open, spent some time making it easy to read and get started with ASN.1, if it could have really taken off and seen widespread adoption across the IT landscape.
