[1] ECN is designed to be used along with ASN.1, and each ECN specification (a coherent set of encoding definitions) is explicitly related to a particular ASN.1 specification (a coherent set of type definitions).
The ECN standard is published by both the ITU-T and the ISO, and is officially named ITU-T Recommendation X.692 | ISO/IEC 8825-3, Information technology – ASN.1 encoding rules: Specification of Encoding Control Notation (ECN).
Encoding rules specify the representation of these abstract values as a series of bits.
Here are some examples of possible situations that require some smaller or larger deviations from the standard encodings: In the above cases and in many other similar cases, the combined use of ASN.1 and ECN makes it possible to create a full, formal specification of both abstract syntax (schema) and encodings.
This is a significant factor in reducing both the amount of work and the possibility of errors in making interoperable systems.
Another significant advantage of ECN is the ability to provide automatic tool support for testing.
To understand how ECN works, it is useful to focus on four kinds of elements of the ASN.1 language: built-in types (e.g., INTEGER and UTF8String), built-in constructor keywords (e.g., SEQUENCE, CHOICE, SEQUENCE OF, OPTIONAL), user-defined simple types (e.g., Age ::= INTEGER(0..200), Color ::= ENUMERATED { green, yellow, red }), and user-defined complex types (e.g., Name ::= SEQUENCE { first UTF8String, middle UTF8String, last UTF8String }).
Examples of ECN constructor keywords are: #SEQUENCE, #CHOICE, #SEQUENCE-OF, and #OPTIONAL (all built-in).
The latter can be applied recursively, in the sense that an encoding step for a component of an ECN type may result in a further in-place modification of the remaining part of the ECN type that is being encoded.