Ukraine We stand with Ukraine

TOP

ASN.1 Made Simple — Why ASN.1?


Schema Expressivity and Schema Authority

Whether you're an experienced user or just starting, it may be hard to pick the right schema technology out of many popular alternatives such as ASN.1, JSON schema, and Google Protocol Buffers. There are two important factors that may help you with your decision - schema expressivity and schema authority. Both will allow your solution to grow without compromising its integrity and to avoid punitive costs.

Schema Expressivity

Writing a schema requires a good balance between being under- and over-expressive. For example, writing a JSON schema can easily include both extremes. On one hand, it allows defining only parts of the entire message, and on the other hand, it enables complex (algorithmic) expressions (such as if/then, not, anyOf/allOf, etc.), which can be difficult to follow.

An under-expressive schema is almost like having no schema at all, as it lacks the structural integrity of the data it's supposed to validate.

An over-expressive schema can be difficult to interpret and is prone to human errors, e.g. its semantics can be easily "lost in translation".

An ASN.1 schema offers a middle ground. It requires a complete definition of every field in the message and it is easily read by a human/designer.

Example

A schema for a basic empty object:

JSON Schema ASN.1 Schema 
{
  "additionalProperties": false,
  "definitions": {},
  "description": "Empty Object",
  "properties": {},
  "type": [
    "object",
    "null"
  ]
}

-- Empty Object
EmptyObject ::= SEQUENCE {}

Schema Authority

Schema evolution is a boon. However, technologies that are too permissive, offering extensive backward and forward compatibility, are prone to spill the data validation throughout the entire application code base. In the end, whether you want it or not, when you choose to communicate with Protobuf or JSON Schema, you have to use more developers and spend more time to ensure the sanity of your data.

An ASN.1 schema allows extensibility (an evolution) as well, but it does this in a predictable way, at compile-time (as in strongly-typed data), ensuring schema authority and a well-defined boundary for the validation logic. ASN.1 technology offers a "right time, right place" solution for scaling larger applications without compromising data integrity.

Creative scenarios for ASN.1

ASN.1 is primarily used in telecommunications and computer networking, yet its applications can go beyond these conventional uses:

Data Compression

Scenario: Use PER to compress data efficiently
Description

PER is a compact binary encoding that significantly reduces the data size, which is especially useful in bandwidth-constrained environments.

Example
  • Streaming telemetry data from sensors in remote locations where a constrained integer may take a few bits
A ::= INTEGER (1234567..1234570)
a A ::= 1234568 -- encoded in 2 bits
External link icon Try it on the Playground | External link icon Try it with ASN.1/Python | External link icon Try it with ASN.1/C Web

Data Modeling and Interchange

Scenario: Use ASN.1 to define data models for applications that need to exchange data between different systems and platforms
Example
  • Designing a healthcare information system where patient data needs to be shared across different hospital systems, web, and mobile health applications
Why use ASN.1?

ASN.1's flexibility allows for complex data structures to be easily shared and understood across various systems.

Interoperability Testing

Scenario: Create test data sets and test cases using ASN.1 to ensure interoperability between different systems and components
Why use ASN.1?

ASN.1's clear and structured format makes it easy to generate and validate test data.

Document Archiving, Long-term Data Storage

Scenario: Archive structured documents and messages in a format defined by ASN.1
Example
  • Storing legal documents in an archival system that uses ASN.1 to define the structure of stored data, ensuring it remains accessible and understandable over time
Why use ASN.1?

Structured documents and messages stored in a format defined by ASN.1 can be read and interpreted in the future, regardless of changes in technology.

Command-line arguments and configuration parameters validation

Scenario: Handle command-line arguments and configuration parameters
Description

In software development, applications often require a reliable method to handle command-line arguments and configuration parameters. These inputs can range from simple options to complex configurations. Ensuring correct syntax and validation is crucial for application stability and security. Traditional methods using custom parsing and validation can be error-prone and difficult to maintain.

Example

The ASN.1 schema can also be considered as the application synopsis. It's easy to follow, eliminates interpretation ambiguity, and is both rigorous and extensible:

AppParameters ::= SEQUENCE {
    inputFile        UTF8String,
    outputFile       UTF8String,
    loggingOptions   LoggingOptions OPTIONAL
}

LoggingOptions ::= SEQUENCE {
    logLevel         ENUMERATED {debug, info, warn, error} DEFAULT error,
    logFile          UTF8String OPTIONAL -- no file means console
}

From this schema, an ASN.1 compiler can generate bindings (structures that can be populated with command-line arguments and configuration file parameters) and validation code for the programming language of your choice.

Why use ASN.1?

Using ASN.1 provides a standardized, robust, and extensible solution. By leveraging ASN.1's capabilities, developers can ensure their applications handle inputs correctly, enhancing stability and security while reducing the maintenance burden associated with custom validation logic.