ASN.1 Type to CORBA-IDL Translation

Introduction

Figure: Inputs and Outputs for ASN.1 Specification Translation

Since nicknames will be used as the basis for naming files, generated IDL files will only be reusable in an environments where identical nickname databases are used. Therefore, it is desirable to make the nickname database as standard as possible (for example, have standard nicknames for all registered ASN.1 modules). In order to facilitate this, the following nickname selection method is recommended (but not mandatory):

• For ASN.1 modules, the nickname is formed by taking the nickname of the standard in which the module occurs, followed by the first three characters of the module label. For example, the InformationFramework module of X.501 would have the nickname X501Inf.

• Where more than one module label in a document has the same initial three letters, append a number to the nicknames for the second and subsequent module labels to disambiguate. This means that the first module would have no numeric suffix, the second colliding module would have the suffix "1", the third "2" and so on.

As it is illegal to modify the existing contents of a standard in this context, it is assumed that the nickname always refers to the latest version of the standard. If, for any reason, parts of the original standard are modified in a revision, the last 2 digits of the revision year can be appended to the nickname.

In order to translate between ASN.1 and CORBA IDL, (hereinafter referred to simply as IDL), it is necessary to be able to map the basic definitions (that is, mapping between ASN.1 types and IDL type definitions).

There are two versions of ASN.1 defined, ASN.1:1990 (see reference ASN1) and ASN.1:1994 (see reference ASN1:1994). Since GDMO explicitly builds on ASN.1 and all new GDMO will provide ASN.1:1990 versions (at least in the short term), this document focuses on that version. However, translation is also provided for all the basic types (for example, BMPString and UniversalString) from ASN.1:1994 as a step towards migration to ASN.1:1994. Further steps on this path may be taken in the future.

In this document, unless otherwise noted, the unqualified name ASN.1 refers to ASN.1:1990.

ASN.1 has a much more complex type system than IDL. As a result, the translation necessarily loses some information; for instance in terms of tag values, sub-range types, compound type constants, etc. Capturing this information for subsequent use in the run-time system is a key issue. A number of schemes have been proposed including the use of string constants and #pragma directives, but the definitive statement is deferred to Interaction Translation.

In a number of cases, the complexity of some data types makes it desirable to define operations for manipulating their values. In CORBA, the standard technique is to define pseudo-IDL (PIDL) which allows a fairly tight definition of the operations but with the implication that these operations have library implementations and can only be invoked locally. For example, this is used to provide access methods to support manipulation of the BitString data type.

Outline of the Translation Process

1. Use as input the original published document. The same order of identifiers is fundamental to consistently generating the same IDL code.

2. Map each ASN.1 module to an IDL module in a separate IDL file.

3. Prior to mapping each of the clauses contained in an ASN.1 module, transform it into a canonical form by means of:

   • ignoring macros¹

   • expanding COMPONENTS OF, selection types and WITH COMPONENTS clauses as described in the following sections in this document.

4. Traverse the contents of the canonical ASN.1 module in order, and map each of the clauses as follows:

   • Export clauses are ignored.

   • Import clauses are mapped as described in the following sections in this document.

   • Type assignments are mapped as described in the following sections in this document. If expanded types are generated, lexical disambiguation of the named type names of the structured outer type (SET, SEQUENCE, CHOICE) must be done prior to anonymous type generation.

   • Value assignments are mapped either into OMG IDL constants or into operations in a constant interface at the end of the generated IDL module, as explained later in this document.

   Lexical disambiguation is done when generating the mapping in this step, as described in the following sections in this document.

5. Re-order the generated IDL code to obtain valid OMG IDL code by eliminating forward references.

File Names and IDL Modules

• Each file will start with a comment identifying the ASN.1 module from which it was generated.

• Definitions contained in IDL generated files must be enclosed within #ifndef ... #endif directives as shown below and will enclose mappings of ASN.1 template definitions.

  #ifndef _<capitalised_nickname>_IDL_
  #define _<capitalised_nickname>_IDL_
  module <nickname> {
  
  <generated-IDL-code>
  
  };
  #endif /* _<capitalised_nickname>_IDL_ */
  

• For each ASN.1 module that is contained in the input file, generate an IDL file named <module_nickname>.idl containing an IDL module named <module_nickname>, where <module_nickname> is the nickname that has been assigned to the ASN.1 module.

• For each ASN.1 module from which symbols are imported, add the directive:

  #include "<module_nickname>.idl"
  

  to the corresponding IDL file, where <module_nickname> is the nickname that has been assigned to the imported ASN.1 module. This directive appears before the module being defined.

Standard Files for Specification Translation

ASN1Types.idl

contains the base definitions for translating ASN.1 types (see IDL Modules for Builtin ASN.1 Types ).

ASN1Limits.idl

contains the definitions for ASN.1 limits (see ASN1Limits.idl File ).

Example

Example: File X501Inf.idl

// Generated from X501.asn1
// X501Inf.idl file:

#ifndef _X501INF_IDL_
#define _X501INF_IDL_

module X501Inf {
	<exports-imports-clause-mapping>
	<ASN.1-definition-mapping-list>
};

#endif /* _X501INF_IDL_ */

Lexical Translation

In ASN.1, names for type-references, identifiers, value-references and module-references consist of an arbitrary sequence of one or more letters, digits, and hyphens. The letters and digits in ASN.1 names are mapped directly retaining case. The ASN.1 hyphen ("-") maps to IDL underscore ("_"). Subject to the possible suffixing as described below, names will be preserved, for example, CMISFilter type in ASN.1 will be mapped as CMISFilterType[n] in IDL.

ASN.1 names are case sensitive and IDL identifiers are not. In addition, ASN.1 has different name-spaces for types-references, identifiers and value-references, whereas IDL has a single namespace. Both have scoped naming spaces, but the naming scopes do not directly map. For example, enumerated types create a new naming scope in ASN.1 but not in IDL. It is therefore not possible to simply map ASN.1 names to IDL identifiers. To handle this, the translator must maintain a table of all identifiers in each resulting IDL scope and modify colliding identifiers within a given IDL scope to avoid such conflicts.

Not all conflicts arise from ASN.1 names. Additional conflicts could arise from clashes with IDL reserved words such as "interface" and identifiers and types defined in the base IDL file ASN1Types.idl and ASN1Limits.idl. The translator must take account of such existing definitions and use the same disambiguating mechanism to avoid clashes.

Clearly, all identifiers could be modified in order to disambiguate, however the goal of the translation mechanism to generate the simplest mapping where possible, leads to a slightly more complex algorithm but preserves a direct mapping where no ambiguity arises. The mapping used will therefore be context dependent and hence the final mapping will be a necessary input to the Interaction Translation since any gateway must be able to replicate such mappings. The rules for disambiguation are as follows:

Rule 1

The first identifier is mapped "as it is", that is, the case is preserved. Second and subsequent identifiers in the same IDL scope that differ only in case will be suffixed with a double underbar followed by a numeric disambiguator, for example, <__n> where n is the count of such instances. Thus the first identifier will not have a suffix, and second and subsequent clashing identifiers will have suffixes <__1>, <__2> and so on. For example, the ASN.1 identifiers aab, aAB and aaB would be translated as aab, aAB__1 and aaB__2 respectively.

This rule is also applied in the case where "Choice" and "Choice<__n>" is appended in order to disambiguate CHOICE values.

Rule 2

The first type reference is mapped with the suffix "Type". Second and subsequent type references in the same IDL scope that differ only in case will be suffixed with "Type<n>" where <n> is the count of such instances. Thus the first type reference will not have the suffix "Type", and second and subsequent clashing type references will have suffixes "Type1", "Type2" and so on. The case of the type reference is always preserved. For example, the ASN.1 type references Aab, AAB and AaB would be translated as AabType, AABType1 and AaBType2 respectively.

This rule is also applied in the case where "Choice" and "Choice<n>" is appended in order to disambiguate CHOICE types.

Rule 3

Value-references are handled as identifiers.

With this scheme, type references cannot clash with identifiers or value references and these latter two are disambiguated numerically. Since the most commonly occurring clash is between data type names and identifiers differentiated only by the case of the first letter, this algorithm avoids the majority of clashes. For example, constructs such as eventRecord EventRecord translate to EventRecordType eventRecord;. In addition, it is easy to recover the original ASN.1 type identifier by finding the "Type" suffix and removing it and all subsequent text from the identifier. Giving preference to identifiers ensures minimum impact on the names of members of sequences and sets and such like so that application code is minimally impacted. The "Type<n>" suffix marks all types explicitly which, in many ways, helps code readability.

Further ambiguity can arise from directly translated names colliding with generated names. For example, a type may have name MyData, and a variable may have name myDataType. The translation of MyData would be MyDataType and this would collide with the direct translation of myDataType. This would be resolved by the normal disambiguation rule. In the same way, translations of ASN.1 constructs may append Opt, Default, etc, to type names, so this must also be considered during disambiguation.

The use of double underbar ("__") to separate numeric disambiguators guarantees that there will be no clash with ASN.1 identifiers since "--" (which would translate to "__") is an ASN.1 comment delimiter and thus cannot be part of an identifier. "_" is not a valid character for ASN.1 identifiers.

In subsequent examples, it is assumed that there are no clashes with identifiers or types outside the given ASN.1 text. Thus identifiers largely map unchanged and type identifiers are mapped mapped with the "Type" suffix.

Warning

This disambiguation scheme is order sensitive. Thus changes to the ASN.1 which make no difference to the meaning and hence are allowed, may impact the translation changing some of the disambiguation. It is important that users are aware of this and use identical source for both manager and agent sides. It is recommended that the unmodified standard texts are used.

For lexical mapping collisions, a strict order of the ASN.1 input actually mapped to IDL is applied. That is, identifiers, names or literals that are not used for the translation process, are not considered for lexical collision purposes. This means that:

Whenever mapping says that the original ASN.1 code should first be modified or expanded prior to being translated, the resulting code is the valid one for the lexical mapping collision algorithm. This actually affects selection types, COMPONENTS OF clauses, WITH COMPONENTS clauses, and other unused identifiers, (for example, value numbers of an enumerated literal when the value is specified as a defined value, or identifiers of unreachable code as in the examples below).

Example

A ::= ENUMERATED { a(1), b(x) }
B ::= ENUMERATED { x(1), y(2) }
x ::= INTEGER = 3

The defined value "x" of the "b" literal in "A" type is not mapped, so it is not considered. Thus resulting mapping code would be:

enum AType = {a, b};
enum BType = {x, y};
const ASN1_Integer x__1 = 3;

Mapping ASN.1 Module to IDL Module

<ModuleDefinition> ::=
    <ModuleIdentifier> DEFINITIONS <TagDefault> ::= BEGIN
        <ModuleBody>
    END

<ModuleIdentifier> ::=
    <modulereference>
    <DefinitiveIdentifier>

<TagDefault> ::= EXPLICIT TAGS | IMPLICIT TAGS |
                 AUTOMATIC TAGS | empty

<ModuleBody> ::=
    <Exports> <Imports> <AssignmentList> | empty

<Exports> ::=
    EXPORTS <SymbolsList> ; | empty

<Imports> ::=
    IMPORTS <SymbolsImported> ; | empty

<SymbolsImported> ::=
    <SymbolsFromModuleList> | empty

<SymbolsFromModuleList> ::=
    <SymbolsFromModule> | <SymbolsFromModuleList> <SymbolsFromModule>

<SymbolsFromModule> ::=
    <SymbolList> FROM <GlobalModuleReference>

<GlobalModuleReference> ::=
    <modulereference AssignedIdentifier>

<SymbolList> ::=
    <Symbol> | <SymbolList> , <Symbol>

<AssignmentList> ::=
    <Assignment> | <AssignmentList> <Assignment>

Table: Production of Module Definition

Mapping of Module Identifier

// ModuleIdentifier:<ModuleIdentifier>

In addition, an IDL #pragma is generated as follows:

#pragma ID <moduleNickname> "OSIOID:<DefinitiveIdentifier>"

If there is no definitive identifier then nothing is generated.

Mapping of Tag Default

Mapping of Exports

Mapping of Imports

For each module imported from, an include directive is generated before the importing module definitions as follows:

#include <module_nickname>.idl

The production:

IMPORTS <symbol1>, ..., <symboln> FROM <GlobalModuleReference>

is mapped as follows for imported types:

typedef <moduleNickname>::<mapped symbol1> <mapped symbol1>
  ........
typedef <moduleNickname>::<mapped symboln> <mapped symboln>

The two mapped symbols may be different as they are disambiguated in different naming contexts - the imported from and the importing modules.

For imported ASN.1 values, code will be generated depending on whether their types are simple or complex (see Mapping of Values ). For simple types the following code will be generated:

const <type of imported const> <mapped symbol1> =
                                <moduleNickname>::<mapped symbol1>
 ...
const <type of imported const> <mapped symboln> =
                                <moduleNickname>::<mapped symboln>

Note that <GlobalModuleReference> is only used to identify the unique module nickname and does not appear in the IDL.

Mapping of Referencing Type and Value Definition

Otherwise, they are mapped as per normal.

Mapping of Assigning Types

Mapping of Assigning Values

Mapping of ASN.1 Comments

An ASN.1 comment commences with a pair of adjacent hyphens ("--") and ends with the next pair of adjacent hyphens or at the end of the line, which ever comes first. In IDL, comments are delimited as per C++, using either /* and */ or // and end of line. The choice of which delimitation to use is left as an implementation concern.

Mapping of Primitive ASN.1 Types and Values

Mapping of ASN.1 Primitive Types

Table: Mapping of ASN.1 Types to IDL Types

Mapping of Values

Functions defined as translation of complex ASN.1 constants are included at the end of the IDL modules in the ConstValues interface. In general, a constant declaration of type <ConstType> with identifier <constName> would result in the generation of the operation:

interface ConstValues {
	<ConstType> <constName>(); // returns "<text of constant value definition>"
    ........
};

For examples, see Examples .

Mapping of NULL types

typedef   char    ASN1_Null;
const     ASN1_Null ASN1_NullValue = '\x00';

Mapping of Boolean Type

Examples

Example: Mapping of Boolean Type

Mapping of Integer Type

For a named-number, the form <name>(<number>) within an integer type <type> generates the IDL const declaration:

const <type>Type[n] <name> = <number>;

The form <name>(<identifier>) within an integer type <type> generates the IDL const declaration:

const <type>Type[n] <name> = <translated identifier>;

Note that the identifier must also be translated in order to ensure that the right IDL identifier is referenced. Note also that these named values are subject to disambiguation in the normal way.

Examples

Example: Mapping of Integer Type

Mapping of Real Type

ASN.1 constants PLUS-INFINITY and MINUS-INFINITY are mapped to IDL double precision floating point constants plus_infinity and minus_infinity respectively. The values of these constants are defined int the file ASN1Limits.idl. In ASN.1, a floating point value may be defined as a triple of mantissa, base and exponent. In this case, the value of the constant is calculated and the corresponding double precision decimal floating point constant is used

Examples

Example: Mapping of Real Type

Mapping of Enumerated Type

This does not preserve the actual values of the element values and the Interaction Translation process would need to support the dynamic mapping between values received on the wire and the corresponding enum values. As a consequence of this, any application requiring to access the actual values would be able to retrieve them via the management knowledge at run-time. The full details of the creation and maintenance of the management knowledge is addressed in the Interaction Translation Document.

It is important to note that the names of values in an enumerated type are identifiers in the enclosing scope since in IDL, enum does not define a new naming scope. This means that enum names are subject to disambiguation in the normal way but in a slightly wider scope than might otherwise be expected.

Examples

Example: Mapping of Enumerated Type

Message ::= ENUMERATED {basic(0),
    extended(1)}

enum MessageType { basic, extended };

ASN.1 and IDL

DayOfTheWeek ::= ENUMERATED {
    sunday(0),monday(1), tuesday (2),
    wednesday (3), thursday(4),
    friday(5), saturday(7)}
first DayOfTheWeek ::= sunday

enum DayOfTheWeekType {
    sunday, monday, tuesday,
    wednesday, thursday,
    friday, saturday };

interface ConstValues {
 ....
DayOfTheWeekType first(); // returns "sunday";
 ....
};

ASN.1 and IDL

MaritalStatus ::= ENUMERATED {
    single(0), married(2), widowed(1)}
}

enum MaritalStatusType {
    single, married, widowed
};

Mapping of Bit String Type

BIT STRING literal values encoded in this way, cannot be represented as IDL constants and are handled via the mechanism defined in Mapping of Values .

Each named bit is mapped as an IDL constant of type unsigned long with value equal to the offset into the bit string. The name of the constant is the given name, disambiguated by the usual rules:

const unsigned long <bitname> = <offset>;

Note that offset may be defined by another constant.

PIDL for BitString Access Functions

interface ASN1_BitStringHandler {      // PIDL
typedef short BitValue;

ASN1_BitString createBitString (in unsigned long number_of_bits);

BitValue getBit (in ASN1_BitString bit_string, in unsigned long
position);

void setBit (inout ASN1_BitString bit_string, in unsigned long position,
        in BitValue new_bit_value);

long length (in ASN1_BitString bit_string);

string asString (in ASN1_BitString bit_string);
// produces a string with binary values ("1001011B")

void setFromString (inout ASN1_BitString bit_string, in string
string_value);
};

Examples

Example: Mapping of Bit String Type

Mapping of Octet String Type

OCTET STRING literals can be either binary of hexadecimal strings. In either case, the value is expanded from left to right as a sequence of bits with octets taken in order from the left. The final octet is padded with 0 bits if necessary.

Octet string literals cannot be represented as constants in IDL and hence, are mapped in accordance with Mapping of Values .

Examples

Example: Mapping of Octet String Type

Mapping of ASN.1 String Types

• strings containing single byte characters, mapped as sequence<octet>

• strings that support wide characters, mapped as sequence of wider types.

The IDL file ASN1Types.idl contains the following typedefs which can then be used directly in the translated IDL:

// These can contain X'00'
typedef sequence<octet> ASN1_GeneralString;
typedef sequence<octet> ASN1_GraphicString;

// These should support wide characters
typedef sequence<unsigned long> ASN1_UniversalString;
typedef sequence<unsigned short> ASN1_BMPString;

// These cannot
typedef string ASN1_IA5String;
typedef string ASN1_ISO646String;
typedef string ASN1_NumericString;
typedef string ASN1_PrintableString;
typedef string ASN1_TeletexString;
typedef string ASN1_T61String;
typedef string ASN1_VideotexString;
typedef string ASN1_VisibleString;

Mapping of Useful Type

typedef ASN1_GraphicString ASN1_ObjectDescriptor;

GeneralizedTime and UTCTime are formatted string representations of time values (see reference ASN.1, clause 32). As strings, these values are not particularly easy to manipulate, for example, for comparison. For this reason PIDL functions are provided to manipulate these values converting to and from a more useful form corresponding to the POSIX timeval structure. Note that both GeneralizedTime and UTCTime optionally contain time zone information. Where this is not present, all operations assume that the time is local time and work accordingly.

PIDL for Time Access Functions

#include "ASN1Types.idl"

interface ASN1_GeneralizedTimeHandler // PIDL
{
    void set(inout ASN1_GeneralizedTime t, in unsigned long seconds,
        in long useconds, in long tzp);
    void get(in ASN1_GeneralizedTime t, out unsigned long seconds,
        out long useconds, out long tzp);
    short compare(in ASN1_GeneralizedTime t1, in ASN1_GeneralizedTime t2);
    void setFromString( inout ASN1_GeneralizedTime t, in string s );
    string asString(in ASN1_GeneralizedTime t );
}
    
interface ASN1_UTCTimeHandler // PIDL
{
    void set(inout ASN1_UTCTime t, in unsigned long seconds,
        in long useconds, in long tzp);
    void get(in ASN1_UTCTime t, out unsigned long seconds,
        out long useconds, out long tzp);
    short compare(in ASN1_UTCTime t1, in ASN1_UTCTime t2);
    void setFromString(inout ASN1_UTCTime t, in string s );
    string asString(in ASN1_UTCTime t );
}

The format of the time strings is the ASN.1 value notation.

Mapping of Object Identifier

typedef string ASN1_ObjectIdentifier;

The contents of an ASN.1_ObjectIdentifier will be one of the following:

• a CORBA scoped name - if the OBJECT IDENTIFIER is defined in a document

• the value of the ASN.1 object identifier in dot notation - if the OBJECT IDENTIFIER is not defined in any document.

Constants of this ASN.1_ObjectIdentifier type are represented as string literals which contain the CORBA scoped name instead of the original ASN.1 OBJECT IDENTIFIER. In addition to this IDL const, a #pragma ID will be generated with the value of the original object identifier literal in dot notation with the prefix of "OSIOID:". The use of this pragma makes this information available via the CORBA Interface Repository as the RepositoryId field for use during Interaction Translation or by any application which requires the OID value.

Note:

This section of the document is likely to be impacted by subsequent work on Interaction Translation.

The Interaction Translation process will need to map between OBJECT IDENTIFIER and Management Meta-knowledge, , for example,.g IDL Typedefs, for resolving ANY DEFINED BY. This is left as an issue for the Interaction Translation document.

Examples

Example: Mapping of Object Identifier

Mapping of Any Type

Examples

Example: Mapping of Any Type

Mapping of Tagged Type

Mapping of External Type

struct ASN1_External {
	ASN1_ObjectIdentifier syntax;
	ASN1_DefinedAny data_value; // by 'syntax'
};

This mapping requires the gateway to fully resolve the encoded form of the External value it receives and re-encoded it using the CORBA any type. This ensures that no CORBA objects need support BER to handle this type. The Object Identifier for the abstract syntax is passed to provide semantic information in cases where the function cannot be determined solely by the type and also to enable the gateway to re-encode it when translating back to the OSI domain.

Mapping of Recursive Types

When recursion is detected, the following rules are applied, in the order given below:

Rule 1:

ASN.1 recursive type definitions are mapped by converting the type reference to a bounded IDL sequence of size 1. If a recursive reference occurs directly in a SET OF or SEQUENCE OF, then the bound is omitted (see Examples of Choice and Recursion ).

Rule 2:

ASN.1 recursive type definitions are expanded in place (see example below).

When a recursion is encountered together with OPTIONAL functionality, Rule 2 is applied.

Examples

Example: Mapping of Recursive Types

Mapping of ASN.1 Constructed Types

The approach to mapping constructed types is to map them according to Mapping of ASN.1 Type Constructors to IDL Type Constructors . However, there are some additional complexities which must be addressed. To facilitate type manipulation by programmers, complex data structures will be simplified by creating new IDL intermediate types (see Composite Types ). Some ASN.1 constructs must be resolved to name-type pairs and then translated. These include selection types and COMPONENTS OF. On the other hand, OPTIONAL elements are converted to an IDL union type which is then used as the type of the optional element. Subtype constraints based on the use of WITH COMPONENTS clause will be explained in the corresponding section for subtype mapping. It is anticipated that an intermediate ASN.1 type is generated, equivalent to the original one but without the subtype constraint, and then the common mapping is applied.

CHOICE, SET and SEQUENCE result from the aggregation of other types. From the ASN.1 grammar point of view, they are a list of elements. Each element is basically formed by an ASN.1 Named Type and some optional extra features.

In the case of SET and SEQUENCE type definitions, elements can be OPTIONAL or have default values. Also the COMPONENTS OF structure may be specified instead of the set of elements it represents.

In the case of the CHOICE type definition, none of these features are allowed , but instead the type of the Named Type can take the form of a selection type (which is not allowed for SET or SEQUENCE).

SET OF and SEQUENCE OF result from the aggregation of several instances of the same type which will be called an "item" in this document.

Table: Mapping of ASN.1 Type Constructors to IDL Type Constructors

Rules to map each element or item in a constructed type are provided below:

1. If element contains a selection type or it is a COMPONENTS OF clause, expand it to obtain the correponding element(s).

2. Obtain the name of the element or item. Apply rules for Anonymous Elements and Items if necessary. (See Anonymous Elements and Items ).

3. Resolve name collisions with previous elements inside the scope of the constructed type.

4. Once the name of the element or item has been obtained, then obtain its corresponding type:

   • If recursion is found, apply rules described in Mapping of Recursive Types .

   • Check for composite types and create corresponding new types if necessary. Follow the rules described for Composite Types (see Composite Types ).

   • If OPTIONAL flag is present, create corresponding optional type following the rules described in OPTIONAL Components .

5. Once the name and the type of the element/item is obtained, create the corresponding IDL mapped element/item.

6. Finally, if default values were defined, create the corresponding constant as described in DEFAULT Components .

Composite Types

• Constructed type:

  • CHOICE

  • SET, SEQUENCE

  • SET OF, SEQUENCE OF

• Enumeration

• Integer with Named Number List

• BitStrings with Named Bits.

When used in the elements or items of a constructed type, these are considered composite types. To avoid nested type declarations, they are extracted and a new IDL type is defined (unless recursion is detected). Thus a named IDL type definition is created.

The name of the new IDL type assignment is formed by concatenating the ASN.1 name of the container type (that is, the name of the constructed type that contains the current element/item without the "Type[<n>]" suffix) with the name of the element/item with an upper case first letter. Note that if it is an element, disambiguation with prior element names in the same constructed type must be done. Then the general rules for lexical mapping disambiguation of types are applied (that is, the corresponding Type[<n>] suffix is added).

Note that if recursion is detected, no external IDL named types are created, as described in Mapping of Recursive Types .

Examples

Example: Mapping of ASN.1 Constructed Types

Anonymous Elements and Items

IDL does not fully support similar constructs, therefore the mapping needs to resolve these issues.

An element without an explicit name is converted to an element with a name taking the form elem<n>, where <n> specifies the position of such element within the definition of the constructed type..

When dealing with an item, if it represents a composite type, a new type is created as described above. A name has to be provided because these definition types have no name associated with them. To provide an homogeneous way to solve the mapping, the identifier item will be used as if it were the name of an element whose type is the one defined by the item. Thus the item identifier will be used as the name of the item when Composite Type rules are to be applied (see Composite Types ).

Note that when SET OF and SEQUENCE OF constructs have an item which is a Composite Type, it is always an anonymous item also. This is because items do not have an identifier name in the ASN.1 grammar.

Examples

Example: Anonymous Elements and Items

Mapping of Choice

The IDL identifier for the type of the discriminator is formed by adding a suffix "Choice" to the translated identifier of the CHOICE type. For each alternate, there will be one identifier in the discriminator type. This translated identifier is the identifier of the alternate suffixed by "Choice" and disambiguated within its IDL scope in the normal way.

Finally, the union type itself is constructed with one case for each alternate with label according to the enum type and the type and identifier according to the (intermediate) alternate. The resulting IDL looks like:

enum <choicetype>Choice {
	<translated-identifier>Choice,
	....... // one for each alternate
}

union <choicetype> switch (<choicetype>Choice) {
	case <translated-identifier>Choice: <type> <translated-identifier>;
	....... // one for each alternate
}

where <choicetype> is the name of the translated type (including "Type" suffix and numeric disambiguator if necessary).

Examples

Example: Examples of Choice and Recursion

Here is a fragment of the X.721 | ISO/IEC 10165-2 (1992) definition of ProbableCause showing the constants adapterError and applicationSubsystemFailure.

Attribute-ASN1Module {
  joint-iso-ccitt ms(9) smi(3) part2(2) asn1Module(2) 1}
  DEFINITIONS IMPLICIT TAGS ::= BEGIN
    IMPORTS .......;
  ....
  adapterError ProbableCause ::= globalValue : { arfProbableCause 1 }
  applicationSubsystemFailure ProbableCause ::=
    globalValue : { arfProbableCause 2 }
  ..........
  ProbableCause ::= CHOICE {
    globalValue OBJECT IDENTIFIER, localValue INTEGER
 }
 ..........
END

module X721Att {
	enum ProbableCauseTypeChoice {
		globalValueChoice,
		localValueChoice
	};

	union ProbableCauseType switch (ProbableCauseTypeChoice) {
		case globalValueChoice: ASN1_ObjectIdentifier globalValue;
		case localValueChoice:  ASN1_Integer localValue;
	};
	...
	interface ConstValues {
		ProbableCauseType adapterError();
		ProbableCauseType applicationSubsystemFailure();
		...
	};
};

Then an application program might access the values along the following lines:

// obtain access to the predefined ConstValue object for accessing the
// interface defined constants. This would probably be a pseudo object
X721Att::ConstValues constants (...);
// use constant in an assignment
ProbableCauseType pc; pc = constants.adapterError();

Mapping of Selection

Examples

Example: Mapping of Selection

Mapping of Sequence and Set

COMPONENTS OF <type> Production

OPTIONAL Components

SEQUENCE { <identifier> <type> OPTIONAL}

the resultant IDL would be:

union <mapped type name>Opt switch (boolean) {case TRUE: <mapped type name> value;};

DEFAULT Components

const <mapped type name> <element-name>Default = <value>;

Translating to IDL

Examples

Example: Mapping of Sequence and Set

The last example is worth looking at in more detail. First all composite types are handled by explicitly generating named types, DataKeywordType, DataKeywordTypeOpt and DataCreateModifierType.

Next, apply the rules for OPTIONAL and DEFAULT, generating a named value for the default and a union type in place of the OPTIONAL component, that is, replaceWithDefaultDefault and DataKeywordTypeOpt.

Now all the problem cases have been removed, the translation proceeds naturally resulting in the IDL as shown in the table above.

Mapping of Sequence Of and Set Of

Examples

Example: Mapping of Sequence Of and Set Of

Mapping of EmbeddedPDV and Character String Types

Mapping of Constraints and Subtypes

Mapping of Constrained Type

typedef sequence <<ItemType>, <upper-bound>> <type>;

where <ItemType> is the type of the SEQUENCE OF/SET OF item and <type> is the translated name of the compound type. For example:

T1 ::= SEQUENCE SIZE(0..10) OF ObjectInstance
T2 ::= SEQUENCE SIZE(1|3|5) OF INTEGER

maps to:

typedef sequence<ObjectInstanceType, 10> T1Type;
// T1Type SIZE(0..10)
typedef sequence<ASN1_Integer, 5> T2Type;
// T2Type SIZE(1|3|5)

Dynamic access to size information in order to ensure validity may be covered as part of Interaction Translation.

When a size constraint is applied to BIT STRING types, a constant integer literal is generated in the IDL. The identifier for the integer literal is generated by adding "_size" as a suffix to the translated parent type. This is because the mapping of BIT STRING to sequence of octet does not have the necessary granularity to usefully bound the sequence.

When a size constraint is applied to OCTET STRING or other STRING derived types, these are mapped as string or bounded sequences depending on the original type definition, where the upper-bound of the sequence in IDL is determined by the upper-end-value of the size constraint.

More complex type constraints are ignored by Specification Translation and may be addressed in Interaction Translation.

Mapping of Subtype Elements

Mapping of Value Range

Table: Mapping ASN.1 INTEGER with Value Range to IDL Types

The lower and upper bounds for the ASN.1 INTEGER subtype must be within the minimum and maximum stated values for the corresponding IDL type (inclusive), and they should also fulfill the corresponding condition. In the table, the lower bound value of the ASN.1 value range INTEGER subtype is referred to as "lower", and the corresponding upper bound value as "upper"

If the ASN.1 type has a value range INTEGER subtype specification that is beyond the stated limits for ASN1_Unsigned64 and ASN1_Integer64, an ASN1_Unsigned64 will be generated if the lower bound has a positive or 0 value, otherwise an ASN1_Integer64 will be generated. The user will be informed of the translation limitation.

REAL is mapped as double in IDL. Value ranges are ignored.

Mapping of SingleValue

A ::= INTEGER(1|3|5|7)

would be translated as

typedef ASN1_Unsigned16 AType;  // AType (1|3|5|7)

Mapping of ASN.1 MIN and MAX

Mapping of Permitted Alphabet

Mapping of INCLUDES

Mapping of InnerTypeConstraints

Single Type Constraint (WITH COMPONENT) is ignored during Specification Translation. The specified type is generated without constraints.

Multiple Type Constraints (WITH COMPONENTS) are used for SET, SEQUENCE and CHOICE. This kind of constraint contains a list of constraints on the component of types of the parent type. The inner type to which the constraint applies is determined by the identifier.

When Full Specification is used there is an implied presence constraint of ABSENT on all inner types which can be constrained to be absent and which is not explicitly listed.

When Partial Specification is used and the parent type is a SET or SEQUENCE type, there are no implied constraints and any inner type can be omitted from the list. When an empty Presence Constraint is used, it is equivalent to a constraint PRESENT for a SET or SEQUENCE component marked OPTIONAL. In a Partial Specification no such constraint is imposed.

When Partial Specification is used and the parent type is a CHOICE type, there is implied presence constraint of PRESENT on all inner types which are not explicitly listed.

When Multiple Type Constraints are used to define a type from another type, the translation process generates a new type. Its components depend on the Multiple Type Constraints. The rules are as follows:

1.

Define an intermediate ASN.1 type as that of that parent type. The type reference of the new type is that of the constrained type. The new ASN.1 type and the parent are of identical type (SET, SEQUENCE or CHOICE)

2.

for each NamedConstraint in TypeConstraint of Full Specification:

2.1

if the parent type is a SET or SEQUENCE then:

2.1.1

if ValueConstraint is not empty, PresenceConstraint is empty and if the corresponding component type is OPTIONAL, then the corresponding component is copied from parent type to the new ASN.1 type. The ValueConstraint is applied as ConstrainedType of the form Type Constraint for the component.

2.1.2

if PresenceConstraint is not empty:

2.1.2.1

if PRESENT is used then the corresponding component is copied from parent type to the new ASN.1 type; if the ValueConstraint in ComponentConstraint is not empty then the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component. If the component has OPTIONAL label, this label will be dropped from the component in the new type.

2.1.2.2

if OPTIONAL is used then the corresponding component is copied from parent type to the new ASN.1 type; if the ValueConstraint in ComponentConstraint is not empty then the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component. If the component does not have an OPTIONAL label then component will be labelled OPTIONAL.

2.2

if the parent type is a CHOICE:

2.2.1

if PresenceConstraint is not empty:

2.2.1.1

if ABSENT is used then the corresponding component is not copied from the parent type to the new ASN.1 type; if the ValueConstraint in ComponentConstraint is not empty then the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component.

3.

For each NamedConstraint in TypeConstraint of Partial Specification:

3.1

if the parent type is a SET or SEQUENCE and:

3.1.1

if PresenceConstraint is not empty:

3.1.1.1

if PRESENT is used then the corresponding component is copied from parent type to the new ASN.1 type; if the ValueConstraint in ComponentConstraint is not empty then the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component. If the component has OPTIONAL label, this label will be dropped from the component in the new type.

3.1.1.2

if OPTIONAL is used then the corresponding component is copied from parent type to the new ASN.1 type; if the ValueConstraint in ComponentConstraint is not empty then the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component. If the component does not have an OPTIONAL label then component will be labelled OPTIONAL.

3.1.2

if ValueConstraint is not empty then the corresponding component is copied from parent type to the new ASN.1 type and the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component.

3.1.3

if both ValueConstraint and PresenceConstraint are empty then the corresponding component is copied from parent type to the new ASN.1 type and labelled OPTIONAL. If the ValueConstraint in ComponentConstraint is not empty then the ValueConstraint is applied as ConstrainedType of the form TypeConstraint for the component.

3.2

if the parent type is a CHOICE:

3.2.1

if PresenceConstraint is not empty then copy all the components of parent type to the component:

3.2.1.1

if ABSENT is used then remove the corresponding component from the new ASN.1 type.

4.

Finally, map the new ASN.1 type to IDL as defined for any other ASN.1 type.

When the Inner Type Constraint is applied to a base type that is defined in a different module, it may occur that the types of some of the members of the new subtype are not known in the scope of the current module. In this case they must be explicitly imported from the module in which the base type is defined³.

Examples

PDU ::= SET {
    alpha INTEGER,
    beta IA5String OPTIONAL,
    gamma SEQUENCE OF Parameter,
    delta BOOLEAN
}
TestPDU ::= PDU (WITH COMPONENTS { ..., delta (FALSE),
            alpha (MIN..<0) }) -- PartialSpecification
FurtherTestPdu ::= TestPDU (WITH COMPONENTS {... ,
            beta (SIZE (5|12)) PRESENT})

is treated as if it were the following equivalent ASN.1 form which can be translated to IDL via the usual rules.

TestPDU ::= SET {
    alpha INTEGER (MIN..<0),
    beta IA5String OPTIONAL,
    gamma SEQUENCE OF Parameter OPTIONAL,
    delta BOOLEAN (FALSE)
}
FurtherTestPdu ::= SET {
    alpha INTEGER (MIN..<0) OPTIONAL,
    beta IA5String (SIZE (5|12) ,
    gamma SEQUENCE OF Parameter OPTIONAL,
    delta BOOLEAN (FALSE) OPTIONAL
}

TestPDU ::= PDU (WITH COMPONENTS { delta (FALSE),
            alpha (MIN..<0) }) -- FullSpecification

would change the equivalent ASN.1 form to:

TestPDU ::= SET {
    alpha INTEGER (MIN..<0),
    delta BOOLEAN (FALSE)
}

Now apply the SetType mapping scheme for ASN.1 to IDL on TestPDU and FurtherTestPDU.

Z ::= CHOICE { a A, b B, c C, d D, e E}
V::= Z (WITH COMPONENTS { ..., a ABSENT,
     b ABSENT}) -- TaU & TbU must be absent
W::= Z (WITH COMPONENTS { ...,
     a PRESENT }) -- TaU must be present
X::= Z (WITH COMPONENTS { a PRESENT })
     -- TaU must be present
Y::= Z (WITH COMPONENTS { a ABSENT, b, c})
     -- TaU, TdU and TeU must be absent

is treated as the following equivalent ASN.1 form:

V ::= CHOICE { c C, d D, e E}
W ::= CHOICE { a A, b B, c C, d D, e E}
X ::= CHOICE { a A}
W ::= CHOICE { b B, c C}

IDL Modules for Builtin ASN.1 Types

The two files are contained in ASN1Types.idl File and ASN1Limits.idl File .

Footnotes

1.

Macros are not ignored when translating SNMP.

2.

These routines could be automatically generated as part of the translation process.

3.

This module may have imported the type from yet another module, but there is no need to follow a chain back to the original definition.