Information Objects

---

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:

1. 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.

2. Table 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.

The second form is selected by specifying 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.

Simple Form Code Generation

In the simple form of information object code generation, the Invoke type above would result in the following C or C++ typedefs being generated:

      typedef struct Invoke ::= SEQUENCE {
 
         ASN1INT        invokeID;
 
         OPERATION_operationCode opcode;
 
         ASN1OpenType   argument;
 
      }
 

The following would be the procedure to add the Invoke header type to an ASN.1 message body:

1. Encode the body type
2. Get the message pointer and length of the encoded body
3. Plug the pointer and length into the "numocts" and "data" items of the argument open type field in the Invoke type variable.
4. Populate the remaining Invoke type fields.
5. Encode the Invoke type to produce the final message.

In this case, the amount of code generated to support the information object references is minimal. The amount of coding required by a user to encode or decode the variable type field elements, however, can be rather large. This is a tradeoff that exists between using the compiler generated table constraints solution (as we will see below) and using the simple form.

Table Form Code Generation

If we now add table constraints to our original type definition, it might look as follows:

     Invoke ::= SEQUENCE {
 
       invoke     IDINTEGER,
 
       opcode     OPERATION.&operationCode ({My-ops}),
 
       argument   OPERATION.&ArgumentType ({My-ops}{@opcode})
 
     }
 

The "{My-ops}" constraint on the opcode element specifies an information object set (not shown) that constrains the element value to one of the values in the object set. The {My-ops}{@opcode} constraint on the argument element goes a step further - it ties the type of the field to the type specified in the row that matches the given opcode value.

ASN1C generates an in-memory table (either an array or a list of structures) for each of the items in the information object sets defined in a specification. In the example above, a table would be generated for the My-ops information object set. The code generated for the type would then use this table to verify that the given items in a structure that reference this table match the constraints.

The C or C++ type generated for the SEQUENCE above when -tables is specified would be as follows:

    typedef struct Invoke {
 
       ASN1INT        invokeID;
 
       OPERATION_operationCode opcode;
 
       ASN1Object     argument;
 
    } Invoke;
 

This is almost identical to the type generated in the simple case. The difference is the ASN1Object type (or ASN1TObject for C++) that is used instead of ASN1OpenType. This type is defined in the asn1type.h run-time header file as follows:

    typedef struct ASN1Object {
 
       ASN1OpenType  encoded;
 
       void*         decoded;
 
       ASN1INT       index;
 
    }
 

This holds the value to be encoded or decoded in both encoded or decoded form. The way a user uses this to encode a value of this type is as follows:

1. Populate a variable of the type to be used as the argument to the invoke type.
2. Plug the address of this variable into the decoded void pointer in the structure above.
3. Populate the remaining Invoke type fields.
4. Encode the Invoke type to produce the final message.

Note that in this case, the intermediate type does not need to be manually encoded by the user. The generated encoder has logic built-in to encode the complete message using the information in the generated tables.