ASN.1 Information Object Class is a concept widely used in ASN.1 specifications to address issues related to protocol specification similar to issues addressed by CORBA/IDL specifications.
Contents
Information Object Classes are used for example to specify ROSE (Remote Operations Service Element) protocol in ASN.1.
Abbreviations
Abbreviations used throughout this article:
Introduction
The simplest way of thinking of ASN.1 Information Object Classes is to regard them as a way to represent IDL specification in ASN.1 using concepts derived from the relational databases theory and SQL syntax in particular.
The concepts used in ASN.1 are more flexible than the ones used in IDL, because, continuing the analogy, they allow to "customize grammar" of the "IDL specification". ASN.1 encoding rules are used as a transfer syntax for remote invocations that resemble CORBA/IIOP.
In the light of this comparison, we can draw an approximate analogy between concepts used in Information Object Classes and SQL and IDL concepts as shown in Table 1.
Analogy by example
Table 2 illustrates by example correspondence of ASN.1 concepts to similar constructs found in SQL and IDL.
Parameterization
If you carefully examine the ASN.1 example presented in Table 2 and compare it to IDL concepts, you will see one important limitation on the ASN.1 side.
Our example ASN.1 data types which we agreed to compare to a high-level CORBA/IDL transfer syntax specification are limited to definition of such transfer syntax only for a single instance of what we compared to an IDL interface (Information Object Set in ASN.1 terms).
In other words, such transfer syntax is not generic and it is not reusable.
With the current set of known tools you can't define such a transfer syntax in a generic way in, say, ASN.1 specification A and then reuse it in ASN.1 specifications B and C that define concrete application-specific "IDL interfaces" on which A does not depend.
The reason for the current limitation is that we currently hard-code our Information Object Set (MyWarehouseOps
in case of OPERATION
, or MyErrorSet
in case of ERROR
) into our ASN.1 data types (high-level transfer syntax specification).
Now we need to make one last step to have a complete and fully functioning system. We need to introduce a concept of type parameterization using Information Object Set as a type formal parameter.
Here is our Request
type rewritten with the concept of parameterization in mind:
Now the high-level transfer syntax descriptor Request
can be parameterized with any arbitrary Information Object Set ("IDL interface") conforming to the Information Object Class specification ("IDL grammar").
Therefore, we can now instantiate it for any Information Object Set as follows:
Request1 ::= Request{MyWarehouseOps} Request2 ::= Request{MyOtherSetOfOps} -- etc.The WITH SYNTAX clause
The WITH SYNTAX clause is effectively a tiny grammar language used to express ways of syntactic definitions of Information Objects.
Consider the following example:
OPERATION ::= CLASS { &opcode INTEGER UNIQUE, &InvocationParsType, &ResponseParsAndResultType, &ExceptionList ERROR OPTIONAL } WITH SYNTAX { OPCODE &opcode REQUEST ARGUMENTS &InvocationParsType RESPONSE ARGUMENTS &ResponseParsAndResultType [ERRORS &ExceptionList] }Enclosure in square brackets ([]) means optionality of syntactic constructs contained in [].
Optionality can be nested.
Tokens all in capital mean keywords, tokens starting with & mean productions requiring substitution of the corresponding entity in place of the token (ASN.1 value, type, or Information Object Set, either instance or reference thereof), depending on the Information Object Class to which this field refers.
Now what we would have otherwise been written as:
getCustomersNum OPERATION ::= { &operationCode get-customers-num-op-type-code, &InvocationParsType Get-customers-num-req-pars-type, &ResponseParsAndResultType Get-customers-num-ind-pars-type, &ExceptionList { wrong-product | wrong-department } }in the presence of the WITH SYNTAX clause can be rewritten as follows:
getCustomersNum OPERATION ::= { OPCODE get-customers-num-op-type-code, REQUEST ARGUMENTS Get-customers-num-req-pars-type, RESPONSE ARGUMENTS Get-customers-num-ind-pars-type, -- according to BNF in the WITH SYNTAX clause, the following line can be omitted ERRORS { wrong-product | wrong-department } }To fully understand the grammar concept behind the WITH SYNTAX clause, imagine we wrote our OPERATION Information Object Class definition as follows:
OPERATION ::= CLASS { &opcode INTEGER UNIQUE, &InvocationParsType, &ResponseParsAndResultType, &ExceptionList ERROR OPTIONAL } WITH SYNTAX { &opcode &InvocationParsType &ResponseParsAndResultType [&ExceptionList] }Then a corresponding Information Object instance for the definition above is to be defined as follows:
getCustomersNum OPERATION ::= { get-customers-num-op-type-code Get-customers-num-req-pars-type Get-customers-num-ind-pars-type { wrong-product | wrong-department } }