Encoding Control Notation
The Encoding Control Notation is a standardized formal language that is part of the Abstract Syntax Notation One family of international standards. ECN is designed to be used along with ASN.1, and each ECN specification is explicitly related to a particular ASN.1 specification.
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 supports the formal specification of non-standard encoding rules for ASN.1 type definitions, and is intended to be used whenever it is necessary to use encodings that differ from those provided by standardized encoding rules such as BER or PER.
Uses of ECN
An ASN.1 type has a set of abstract values. Encoding rules specify the representation of these abstract values as a series of bits. There are applications in which special encodings, different from those obtainable through any of the standard sets of ASN.1 encoding rules, are required.Here are some examples of possible situations that require some smaller or larger deviations from the standard encodings:
- a protocol may require extremely compact encodings; even though the Unaligned Packed Encoding Rules are generally quite compact, further compactness can be achieved in certain cases by exploiting the statistical distribution of the values of certain fields or by removing other forms of redundancy;
- a protocol may require that certain parts of an encoded message be easily accessible without the need to decode the whole message with, say, a full PER decoder; in general, jumping into the middle of a PER-encoded message and starting to decode from that point is not a recommended practice, but in certain cases this may be necessary or useful; in such cases, access to particular parts of an encoding can be facilitated and made reliable by specifying a modified version of PER;
- there are some standard protocols that encode their data in a tag-length-value format similar to BER; one might want to create a formal ASN.1 specification for one of those protocols and specify a modified version of BER that matches the ad hoc TLV format;
- there are many standard protocols that encode their data in an ad hoc binary format, which may differ significantly from PER or any other set of ASN.1 encoding rules; one might want to create a formal ASN.1 specification for one of those protocols and specify a binary encoding that matches the ad hoc format.
Overview of ECN
Concepts
To understand how ECN works, it is useful to focus on four kinds of elements of the ASN.1 language: built-in types, built-in constructor keywords, user-defined simple types, and user-defined complex types. There are other aspects of ASN.1 that are also reflected in ECN, but we will not discuss them here.The ECN language also has built-in types, built-in constructor keywords, user-defined simple types, and user-defined complex types. These elements of the ECN language are similar to those of ASN.1, but their names always begin with a
#. Officially they are called encoding classes but here we will simply call them ECN types and ECN constructor keywords. Examples of ECN types are: #INTEGER, #UTF8String, #Age, #Name. Examples of ECN constructor keywords are: #SEQUENCE, #CHOICE, #SEQUENCE-OF, and #OPTIONAL.Unlike ASN.1, ECN allows the user of the language to define synonyms of ECN constructor keywords. Therefore, in ECN there are user-defined ECN constructor keywords as well as built-in ECN constructor keywords.
From the ECN viewpoint, every user-defined ASN.1 type occurring in an ASN.1 specification has a hidden ECN type implicitly associated with it. Officially this hidden ECN type is called an implicitly generated encoding structure but here we will simply call it the hidden ECN type of the ASN.1 type. Hidden ECN types are a special kind of user-defined ECN types, but they behave like other user-defined ECN types.
The hidden ECN type of an ASN.1 type is almost identical to the original ASN.1 type and is the starting point for an encoding process, specified in ECN, which ultimately generates the series of bits representing any given value of the original ASN.1 type. An ASN.1 type is not directly referenceable for the purpose of specifying an encoding in ECN, but its hidden ECN type is. ECN types and ECN constructor keywords can be explicitly referenced within an ECN specification and are encoded by applying the rules contained in the ECN specification.
Roughly speaking, an ECN specification does two things: it says how to modify a hidden ECN type to produce a new hidden ECN type, and it says how an ECN type is to be encoded. 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. This process can go on through any number of cycles, until the final ECN type has been completely encoded, that is, all the bits representing the value of the original ASN.1 type have been generated.
Lastly we introduce the concept of encoding object. This is a very important element of the ECN language, and refers to each individual encoding rule that is part of an ECN specification and is applied to an ECN type or ECN constructor keyword, either built-in or user-defined, occurring in the specification.
Mechanisms
The first step of the encoding process is the automatic generation of hidden ECN types from all ASN.1 types present in the ASN.1 specification. The hidden ECN types corresponding to complex user-defined ASN.1 types can be modified by a mechanism called coloring, which consists in replacing the names of the types of some of their components with synonyms. It is also possible to replace the ECN built-in constructor keywords occurring in a hidden ECN type with synonyms. In ECN there are a few built-in synonyms for both constructor keywords and built-in types, but a user of the language can define both user-defined types and user-defined constructor keywords as synonyms of others. The purpose of the coloring step is to prepare a hidden ECN type for the next step, which is the encoding of its components, in case it is necessary to encode in a different way different occurrences of the same ECN type or different occurrences of the same ECN constructor keyword present in the hidden ECN type. For example, a complex hidden ECN type might contain two lists, but one list is to be encoded by inserting a count field before the first item of the list, and the other is to be encoded by inserting a terminating pattern after the last item of the list. This can be done, for example, by replacing the first#SEQUENCE-OF keyword in the hidden ECN type with, say, #CountBasedRepetition, by replacing the second #SEQUENCE-OF keyword with, say, #TerminatingPatternBasedRepetition, and by declaring these two names as user-defined synonyms of the ECN constructor keyword #SEQUENCE-OF. Once these two different constructor keywords have been included in the hidden ECN type, each of the two lists can be encoded with a different encoding object.The second step of the encoding process is the application of an encoding object to a hidden ECN type. The value to be encoded will be one of the possible values of an ASN.1 type defined in the ASN.1 specification, and the encoding process will select the hidden ECN type of that ASN.1 type and will apply the appropriate encoding object to it.
There may be further steps consisting in the recursive application of encoding objects that work by replacing an ECN type with another ECN type.
In ECN there are several kinds of encoding objects. Some encoding objects completely determine the actual bit-level encoding of simple ECN types and are the easiest to understand. Others apply to ECN constructor keywords rather than to ECN types, and determine some structural aspects of the encoding of the complex ECN type constructed by an ECN constructor keyword. Others work by replacing an ECN type with another ECN type, which must then be encoded by applying a different encoding object to it.
The most important kinds of encoding objects in ECN are listed below:
- some encoding objects specify the bit-level encoding of the ECN type;
- some encoding objects specify that the ECN type must be replaced by a user-defined ECN type that contains the former ECN type as one of its components;
- some encoding objects specify that the ECN type must be replaced by a user-defined ECN type, and specify how to map each value of the former type to a value of the latter type;
- some encoding objects specify how to represent the presence or absence of a component of a
#SEQUENCEtype that is declared#OPTIONAL; these encoding objects can only be applied to ECN types that are optional components of a#SEQUENCEtype; - some encoding objects specify how to represent the number of items of a list ; these encoding objects can only be applied to ECN types that are
#SEQUENCE-OFtypes; - some encoding objects specify how to indicate which of the alternatives of a
#CHOICEtype is present, and can only be applied to ECN types that are#CHOICEtypes; - some encoding objects specify that the ECN type is to be encoded by applying a standard set of encoding rules to it.