Information Objects and Classes are used to define multi-layer protocols in which “holes” are defined within ASN.1 types for passing message components to different layers for processing. These items are also used to define the contents of various messages that are allowed in a particular exchange of messages. The ASN1C compiler extracts the types involved in these message exchanges and generates encoders/decoders for them. The “holes” in the types are accounted for by adding open type holders to the generated structures. These open type holders consist of a byte count and pointer for storing information on an encoded message fragment for processing at the next level.
The ASN1C compiler is capable of generating code in one of two forms for information in an object specification:
Simple form: in this form, references to variable type fields within standard types are simply treated as open types and an open type placeholder is inserted.
Table unions form: in this form, all of the classes, objects, and object sets within a specification result in the generation of code for parsing and formatting the information field references within standard type structures. Open types with relational constraints result in the generation of C union structures that enumerate all of allowed fields as defined by the constraint. This form is selected by using the -table-unions command-line option.
Legacy table form: this is similar to 2 in that all information object related items result in the generation of additional code. In this case, however, instead of a union structure being generated for open types with relational constraints, a void pointer is used to hold an object in decoded form. This form is selected using the -tables command-line option.
To better understand the support in this area, the individual components of Information Object specifications are examined. We begin with the “CLASS” specification that provides a schema for Information Object definitions. A sample class specification is as follows:
OPERATION ::= CLASS {
&operationCode CHOICE { local INTEGER,
global OBJECT IDENTIFIER },
&ArgumentType,
&ResultType,
&Errors ERROR OPTIONAL
}
Users familiar with ASN.1 will recognize this as a simplified definition of the ROSE OPERATION MACRO using the Information Object format. When a class specification such as this is parsed, information on its fields is maintained in memory for later reference. In the simple form of code generation, the class definition itself does not result in the generation of any corresponding C or C++ code. It is only an abstract template that will be used to define new items later on in the specification. In the table form, if C++ is specified, an abstract base class is generated off of which other classes are derived for information object specifications.
Fields from within the class can be referenced in standard ASN.1 types. It is these types of references that the compiler is mainly concerned with. These are typically “header” types that are used to add a common header to a variety of other message body types. An example would be the following ASN.1 type definition for a ROSE invoke message header:
Invoke ::= SEQUENCE {
invokeID INTEGER,
opcode OPERATION.&operationCode,
argument OPERATION.&ArgumentType
}
This is a very simple case that purposely omits a lot of additional information such as Information Object Set constraints that are typically a part of definitions such as this. The reason this information is not present is because we are just interested in showing the items that the compiler is concerned with. We will use this type to demonstrate the simple form of code generation. We will then add table constraints and discuss what changes when the –tables command line options is used.
The opcode field within this definition is an example of a fixed type field reference. It is known as this because if you go back to the original class specification, you will see that operationCode is defined to be of a specific type (namely a choice between a local and global value). The generated typedef for this field will contain a reference to the type from the class definition.
The argument field is an example of a variable type field.. In this case, if you refer back to the class definition, you will see that no type is provided. This means that this field can contain an instance of any encoded type (note: in practice, table constraints can be used with Information Object Sets to limit the message types that can be placed in this field). The generated typedef for this field contains an “open type” (ASN1OpenType) reference to hold a previously encoded component to be specified in the final message.