ASN.1: Enumerated vs Integer – A Practical Guide

TL;DR

When using ASN.1 for data encoding, ENUMERATED and INTEGER types seem similar but behave differently, especially with default values and decoding. This guide explains the key differences and how to choose the right one.

Understanding the Basics

Both ENUMERATED and INTEGER are used to represent a set of named or numeric values in ASN.1. However, their intended use cases and encoding rules differ significantly.

Key Differences

• Enumerated: Designed for explicitly named values. It’s like creating a list of options where each option has a specific name and associated number.
• Integer: Represents arbitrary numeric values, often with constraints (minimum/maximum).

Step-by-Step Guide

1. Define Your Data: First, determine if your data represents a fixed set of named options or a range of numbers.
2. Use Enumerated for Named Options: If you have a clear list of names (e.g., ‘red’, ‘green’, ‘blue’), use ENUMERATED.

   ENUMERATED { red(0), green(1), blue(2) }

3. Use Integer for Numeric Ranges: If you need to represent a range of numbers (e.g., values between 1 and 100), use INTEGER.

   INTEGER { 1..100 }

4. Default Values: This is where the biggest difference lies.
   • Enumerated: The first value in the list is often implicitly considered the default if no value is explicitly encoded, but this isn’t guaranteed by all encoders/decoders and should not be relied upon.
   • Integer: No implicit default value exists. You *must* encode a value for an INTEGER field. If you don’t, the decoder will likely throw an error or interpret it as invalid data.
5. Encoding Considerations:
   • Enumerated: Encoders may use shorter encoding lengths for ENUMERATED values if the numbers are small, making them more efficient in some cases.
   • Integer: Encoding length depends on the size of the number and any constraints applied. Negative integers require an extra byte to indicate the sign.
6. Decoding Behaviour:
   • Enumerated: Decoders will map the encoded numeric value back to its corresponding name. If an invalid number is encountered, it’s usually treated as an error or a default case (depending on the implementation).
   • Integer: Decoders expect a valid integer within the defined range. Out-of-range values are typically flagged as errors.
7. Example Scenario: Consider representing a status code.
   • Enumerated Approach:

     ENUMERATED { ok(0), warning(1), error(2) }

     This is ideal if you only have these three possible statuses.

   • Integer Approach:

     INTEGER { 0..255 }

     This allows for a wider range of status codes, but requires more careful handling and documentation to ensure valid values are used.

8. Testing: Always test your ASN.1 definitions with various encoders/decoders (e.g., using tools like iperf3 or custom code) to verify the encoding and decoding behaviour, especially regarding default values and error handling.

Practical Tips

• Be Explicit: Always explicitly encode a value for INTEGER fields to avoid ambiguity.
• Documentation is Key: Clearly document the meaning of each value in your ASN.1 definitions, especially for ENUMERATED types.
• Consider Future Expansion: If you anticipate adding more options later, an INTEGER with a wider range might be more flexible, but requires stricter validation.