Asn.1 Value Assignment

Compiler Errors Reference (0001-0499)

A0001W

Message Format

Message Cause

Under ASN.1:1990 syntax rules, APPLICATION tags must be unique within a module. A particular APPLICATION tag number has been used more than once.

Example

Module-A0001W DEFINITIONS ::= BEGIN Code1 ::= [APPLICATION 1] INTEGER Code2 ::= [APPLICATION 1] REAL END

Error Message

Possible Solution

Each tag number must be unique. Remove the duplicate tag number and add a unique number.

C0002E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

A0003E

Message Format

Message Cause

One or more types are circularly defined.

Example

Module-A0003E DEFINITIONS ::= BEGIN Name1 ::= Name2 Name2 ::= Name1 END

Error Message

Possible Solution

Remove the circular reference.

A0004E

Message Format

Message Cause

A value employs a type that is circularly defined.

Possible Solution

Remove the circular reference.

A0005E

Message Format

Message Cause

The type of a value in a value reference is circularly defined.

Example

Module-A0005E DEFINITIONS ::= BEGIN Name1 ::= Name2 Name2 ::= Name1 personA Name2 ::= "Tom" personB Name ::= personA Name ::= PrintableString END

Error Message

Possible Solution

Fix the circular definition.

A0006E

Message Format

Message Cause

This error occurs when a number in a list of named numbers that belong to a type is specified more than once. The type can be a BIT STRING, INTEGER, ENUMERATED, or a similar type.

Example

Module-A0006E DEFINITIONS ::= BEGIN NamedInt ::= INTEGER {red(0), white(1), blue(1)} END

Error Message

Possible Solution

Each number in a list of named numbers must be unique. Replace the duplicate number with a unique one.

C0007E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

A0008E

Message Format

Message Cause

The identifier referred to by the ANY DEFINED BY is not found within the same SEQUENCE as the ANY DEFINED BY. This error usually occurs when the identifier is either misspelled or is defined outside the SEQUENCE.

Example

Module-A0008E DEFINITIONS ::= BEGIN OperationPDU ::= SEQUENCE { priority INTEGER, parameters ANY DEFINED BY number } END

Error Message

Possible Solution

Consider the following solutions:

  • Replace the identifier with one that belongs to the same SET or SEQUENCE as contains the ANY DEFINED BY.
  • Correct the spelling of the identifier.

A0009E

Message Format

Message Cause

This error is generated when an ANY DEFINED BY references an identifier that is not defined.

Example

Module-A0009E DEFINITIONS ::= BEGIN OperationPDU ::= SEQUENCE { priority INTEGER, ANY DEFINED BY number } END

Error Message

Possible Solution

Replace the undefined identifier with one that is defined in the input ASN.1 syntax.

A0010E

Message Format

Message Cause

The type referenced by an ANY DEFINED BY is used as a key to determine how the ANY DEFINED BY is handled. Therefore it must be present and cannot be specified as optional.

Example

Module-A0010E DEFINITIONS ::= BEGIN OperationPDU ::= SEQUENCE { priority INTEGER OPTIONAL, parameters ANY DEFINED BY priority } END

Error Message

Possible Solution

You can either replace the type referenced by the ANY DEFINED BY with one that is not optional or remove the keyword OPTIONAL.

C0011E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0012E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0013E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

A0014E

Message Format

Message Cause

The size constraint flagged contains a negative number. Size constraints limit the length of a string or the size of an array, and therefore a negative number has no meaning.

Example

Module-A0014E DEFINITIONS ::= BEGIN Name ::= OCTET STRING (SIZE(-2..10)) END

Error Message

Possible Solution

Remove all negative integers from the size constraint and make sure you define only positive integers.

A0015E

Message Format

Message Cause

A node in an object identifier is neither an INTEGER value nor an object identifier value. It is the wrong type.

Example

Module-A0015E DEFINITIONS ::= BEGIN OperationID ::= OBJECT IDENTIFIER iso2 GeneralString ::= "{ 1 0 }" ftam1 OperationID ::= { iso2 8571 2 1 } END

Error Message

Possible Solution

Ensure that all nodes are specified as OBJECT IDENTIFIERs or INTEGERs.

A0016E

Message Format

Message Cause

A node in an object identifier value is not defined.

Example

Module-A0016E DEFINITIONS ::= BEGIN ModuleOI ::= OBJECT IDENTIFIER b ModuleOI ::= { i 4 5 6 7 } END

Error Message

Possible Solution

Replace the undefined node identifier with one that is defined.

A0017W

Message Format

Message Cause

The ASN.1 standard allows OBJECT IDENTIFIERs beginning with { 0 0 } to have a third node. The third node can be a letter a through z that optionally has a corresponding number, namely, a(1), b(2), c(3), d(4), ..., z(26). The flagged OBJECT IDENTIFIER uses one of the letters but with an incorrect number, for example, a(5).

Example

Module-A0017W DEFINITIONS ::= BEGIN ModuleOI ::= OBJECT IDENTIFIER b ModuleOI ::= { 0 0 a(2) } END

Error Message

Possible Solution

Replace the number in the third node with its corresponding predefined value. In this case, a(2) is replaced with a(1).

C0018W

Message Format

Message Cause

The value specified in a SingleValueConstraint is incompatible with the type constrained. The OSS run-time constraint checking routines require that values in SingleValueConstraints have the same C representation as the type constrained (for complex types such as SEQUENCE).

Example

Module-C0018W DEFINITIONS ::= BEGIN A ::= SEQUENCE { a INTEGER --<SHORT>--} a A ::= { a 2 } B ::= SEQUENCE { a INTEGER --<LONG>--} (a) END

Error Message

Possible Solution

Consider the following solutions:

  • Remove the SingleValueConstraint, which in this case is (a).
  • Replace the type of the value in the SingleValueConstraint with one that has the same representation as the type constrained.

A0019E

Message Format

Message Cause

An OBJECT IDENTIFIER value begins with { 0 0 } and the NameNumber pair in the third position conflicts with one of the preset NameNumber pairs for values that begin with { 0 0 }. The preset pairs are:

See Also

A0017W

A0020E

Message Format

Message Cause

The input ASN.1 syntax contains an OBJECT IDENTIFIER value with nodes that are required to be numbers (e.g., in: {iso standard 8571 abstract-syntax ftam-pci ...}, the third component must be a number), but are not found to be so.

See Also

A0017W

A0021E

Message Format

Message Cause

The year position of the flagged time value contains a non-numeric character. For GeneralizedTime the year is found in positions 1-4; for UTCTime the year is found in positions 1-2.

Example

Module-A0021E DEFINITIONS ::= BEGIN time1 UTCTime ::= "DC9310252013.31Z" -- Invalid time2 GeneralizedTime ::= "DC199310252013.31" -- Invalid time3 GeneralizedTime ::= "199310252013.31" -- Valid END

Error Message

Possible Solution

Change the incorrect time values to start with a two-digit or four-digit year.

A0022E

Message Format

Message Cause

This error occurs when the time value of one or more components is outside the accepted range of values.

Example

Module-A0022E DEFINITIONS ::= BEGIN StartTime ::= GeneralizedTime time1 StartTime ::= "199331232021.06" -- Invalid month time2 StartTime ::= "199310322021.06" -- Invalid day time3 StartTime ::= "199310232521.06" -- Invalid hour time4 StartTime ::= "199310232061.06" -- Invalid minutes time5 StartTime ::= "19931023205165.06" -- Invalid seconds time6 StartTime ::= "19931023205155.06-24" -- Invalid hour diff time7 StartTime ::= "19931023205155.06-0865" -- Invalid minute diff END

Error Message

Possible Solution

Make sure the time value components are valid.

A0023E

Message Format

Message Cause

The period (".") at the end of the time value indicates that a fractional component is going to be used and it must be followed by a sequence of one or more digits.

Example

Module-A0023E DEFINITIONS ::= BEGIN StartTime ::= GeneralizedTime time1 StartTime ::= "199310232051." time2 StartTime ::= "19931023205122." END

Error Message

Possible Solution

Remove the decimal point at the end of the time value or add a numeric fractional component.

A0024W

Message Format

Message Cause

The compiler found and ignored extra characters that follow a time value.

Example

Module-A0024W DEFINITIONS ::= BEGIN StartTime ::= UTCTime time1 StartTime ::= "9310251421Z-0500" time2 GeneralizedTime ::= "19931025142122.56PM" END

Error Message

Possible Solution

Remove the extra characters.

A0025E

Message Format

Message Cause

The UTCTime time value does not end in uppercase Z.

Example

Module-A0025E DEFINITIONS ::= BEGIN StartTime ::= UTCTime time1 StartTime ::= "9301232021z" time2 StartTime ::= "9301232021" END

Error Message

Possible Solution

Make sure the last character of the UTCTime value is uppercase Z.

A0026E

Message Format

Message Cause

Two or more ContainedSubtypes form a circular reference.

Example

Module-A0026E DEFINITIONS ::= BEGIN OperationCode ::= PrintableString (INCLUDES Code) Code ::= PrintableString ("M"|"R"|INCLUDES OperationCode) END

Error Message

Possible Solution

Remove the circular reference from the ContainedSubtypes.

A0027E

Message Format

Message Cause

The input ASN.1 syntax contains an included type that is not compatible with the parent type.

NOTE: This message may also be issued for information object instances that do not conform to their WITH SYNTAX specifications. For example, an IDENTIFIED BY is missing in an ABSTRACT-SYNTAX class instance.

Example

Module-A0027E DEFINITIONS ::= BEGIN OperationCode ::= PrintableString ("1"|"40") Code ::= OCTET STRING (INCLUDES OperationCode) END

Error Message

Possible Solution

Make sure the included subtype matches the parent type.

A0028E

Message Format

Message Cause

A ValueRange subtype is applied to types that do not support it. A ValueRange subtype can be applied only to an INTEGER or a REAL type.

Example

Module-A0028E DEFINITIONS ::= BEGIN A ::= PrintableString ("Antelope" .. "Zebra") END

Error Message

Possible Solution

Remove the ValueRange subtype or replace it with a SingleValue or another subtype.

A0029E

Message Format

Message Cause

A SIZE constraint is applied to types that do not support it. A SIZE constraint can be applied to a BIT STRING, OCTET STRING, character string, SET OF, or SEQUENCE OF.

Example

Module-A0029E DEFINITIONS ::= BEGIN Password ::= VisibleString (SIZE(6..20)) -- Valid Hundreds ::= INTEGER (SIZE(100..999)) -- Invalid END

Error Message

Possible Solution

Remove the SIZE constraint or replace it with a ValueRange or another subtype.

A0030E

Message Format

Message Cause

A SIZE constraint does not conform to the ASN.1 standard. The constraint must be a subtype of INTEGER (0 .. MAX).

Example

Module-A0030E DEFINITIONS ::= BEGIN Evens ::= INTEGER (2 | 4 | 6 | 8 | 10) Vowels ::= [1] VisibleString ("A" | "E" | "I" | "O" | "U") EvenStrings ::= [2] VisibleString (SIZE(INCLUDES Vowels)) -- Invalid OddStrings ::= BIT STRING (SIZE(1 | 3 | 5 | 7 | 9)) Password ::= [3] VisibleString (SIZE(6..20)) -- Valid END

Error Message

Possible Solution

Redefine the SIZE constraint with valid INTEGER values.

A0031E

Message Format

Message Cause

A FROM subtype constraint does not contain characters or it contains an invalid set of characters.

Example

Module-A0031E DEFINITIONS ::= BEGIN A ::= [0] VisibleString (FROM ("A" | "E" | "I" | "O" | "U")) -- Valid B ::= [1] VisibleString (FROM (INCLUDES A)) -- Valid D ::= [2] VisibleString (FROM (SIZE(5))) -- Invalid E ::= [3] VisibleString (FROM (FROM(INCLUDES A))) -- Invalid F ::= INTEGER (FROM (SIZE(5))) -- Invalid END

Error Message

Possible Solution

Replace the invalid contents of the FROM subtype with valid characters or remove the subtype.

A0032E

Message Format

Message Cause

A FROM subtype constraint is applied to a non-character string type.

Example

Module-A0032E DEFINITIONS ::= BEGIN Type1 ::= INTEGER (FROM (1|2|3)) END

Error Message

Possible Solution

Remove the FROM subtype.

C0033E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

A0034E

Message Format

Message Cause

A WITH COMPONENT inner subtype is applied to a type that is not a SET, SEQUENCE, CHOICE, SET OF, or SEQUENCE OF.

Possible Solution

Remove the inner subtype.

See Also

A0547E

A0035E

Message Format

Message Cause

A WITH COMPONENT inner subtype is applied to a type that is not a SET, SEQUENCE, CHOICE, SET OF, or SEQUENCE OF.

Possible Solution

Remove the inner subtype.

See Also

A0547E

A0036E

Message Format

Message Cause

The input ASN.1 syntax contains a value assignment in which the value on the right-hand side is not supported for the base type on the left-hand side.

Possible Solution

Replace the invalid value with one that is compatible with the base type of the value assignment.

A0037W

Message Format

Message Cause

A value assignment of a CHOICE alternative does not use the identifier-colon-value notation introduced in ASN.1:1994.

Example

Module-A0037W DEFINITIONS ::= BEGIN number INTEGER ::= 5 Code ::= CHOICE { int INTEGER, real REAL } value Code ::= number -- ok, but discouraged value2 Code ::= int : number -- preferred END

Error Message

Possible Solution

Replace the value assignment with an identifier-colon-value on the right-hand side.

A0038W

Message Format

Message Cause

A value assignment of a CHOICE type does not have an identifier associated with it.

Example

Module-A0038W DEFINITIONS ::= BEGIN number INTEGER ::= 5 Code ::= [0] CHOICE { INTEGER, REAL } value Code ::= number END

Error Message

Possible Solution

Add identifiers to the CHOICE type and replace the value assignment with one that has an identifier-colon-value on the right-hand side.

C0039E

Message Format

Message Cause

The input ASN.1 syntax contains an invalid compiler directive application to the INSTANCE OF type.

Possible Solution

Remove the invalid directive application.

See Also

C0042E

A0040E

Message Format

Message Cause

The input ASN.1 syntax contains an invalid forward circular reference in a COMPONENTS OF constraint.

Possible Solution

Remove the invalid forward circular reference.

C0041S

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0042E

Message Format

Message Cause

The input ASN.1 syntax contains an invalid compiler directive application.

Example

Module-C0042E DEFINITIONS ::= BEGIN Name2 ::= CHOICE { a INTEGER --<NULLTERM>--, b VisibleString } END

Error Message

Possible Solution

To find out more information, see Compiler Directives.

C0043I

Message Format

Message Cause

This message contains information about the number of error, warning, and informatory messages issued.

Example

Module-C0043I DEFINITIONS ::= BEGIN MySet ::= SET { a [1] INTEGER b [2] BOOLEAN } END

Error Message

Possible Solution

To ignore the messages, specify the -suppress 0043 option.

C0044E

Message Format

Message Cause

The input ASN.1 syntax contains value notation for a UTF8String, but one or more of the characters assigned falls in the reserved character range as defined by the ASN.1 standard.

Example

Module-C0044E DEFINITIONS ::= BEGIN UString ::= UTF8String myName UString ::= {{0,0,0,65}, {0, 0,255,254}} END

Error Message

Possible Solution

Replace the invalid characters from the string with values that are allowed for UTF8String types.

C0045E

Message Format

Message Cause

The input ASN.1 syntax contains an invalid compiler directive application to the OBJECT IDENTIFIER type.

Possible Solution

Remove the invalid directive application.

See Also

C0042E

A0046E

Message Format

Message Cause

A WITH COMPONENTS constraint does not include all the elements specified in the SET type.

Example

Module-A0046E DEFINITIONS ::= BEGIN Set ::= SET { d BOOLEAN, e INTEGER, f VisibleString } Set1 ::= Set (WITH COMPONENTS {f, d}) END

Error Message

Possible Solution

Use OPTIONAL in the parent type for the type that is omitted from the WITH COMPONENTS constraint.

A0047E

Message Format

Message Cause

The type-tag is negative or greater than the maximum allowed value, as specified in the ASN.1 standard.

Example

Module-A0047E DEFINITIONS ::= BEGIN A ::= [16383] INTEGER -- Valid B ::= [16384] INTEGER -- Invalid negnum INTEGER ::= -2 C ::= [negnum] INTEGER -- Invalid END

Error Message

Possible Solution

Make sure the tag number is positive and does not exceed the maximum allowed limit.

A0048E

Message Format

Message Cause

The input ASN.1 syntax contains a type whose tag conflicts with one predefined by the ASN.1 standard.

Example

Module-A0048E DEFINITIONS ::= BEGIN WrongTag1 ::= [UNIVERSAL 8] CHOICE { a INTEGER, b BOOLEAN } WrongTag2 ::= [UNIVERSAL 8] ANY END

Error Message

Possible Solution

Change the class of the tag from UNIVERSAL to PRIVATE or to context-specific.

A0049E

Message Format

Message Cause

A UNIVERSAL tag is applied to a built-in type that has a predefined UNIVERSAL tag.

Example

Module-A0049E DEFINITIONS ::= BEGIN Code ::= [UNIVERSAL 8] INTEGER END

Error Message

Possible Solution

To correct this error, remove the UNIVERSAL tag. Optionally, you can specify the -ignoreError 49 option.

A0050E

Message Format

See Also

A0256W

C0051E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

A0052E

Message Format

Message Cause

The input ASN.1 syntax contains a reference to a type that has not been defined.

Example

Module-A0052E DEFINITIONS ::= BEGIN PersonnelRecord ::= SEQUENCE { name Name, age INTEGER } END

Error Message

Possible Solution

Define the type in the input ASN.1 specification.

C0053E

Message Format

Message Cause

The input ASN.1 syntax contains a reference to a non-built-in type that has not been defined or is circular.

Example

Module-C0053E DEFINITIONS ::= BEGIN B ::= b < B END

Error Message

Possible Solution

Redefine the type.

A0054E

Message Format

Message Cause

A NamedBitList contains a NamedBit that has a negative value.

Example

Module-A0054E DEFINITIONS ::= BEGIN one INTEGER ::= 1 two INTEGER ::= -2 three INTEGER ::= 3 Bitcount ::= BIT STRING { ready(one), set(two), go(three) } END

Error Message

Possible Solution

Replace the negative NamedBit value with a positive one.

A0055E

Message Format

Message Cause

A NamedBitList or a NamedNumberList contains an item that has an incorrect value. The value must be an integer.

Example

Module-A0055E DEFINITIONS ::= BEGIN t REAL ::= { 32948, 10, 568 } ColorCode ::= ENUMERATED { red(t), blue(0) } END

Error Message

Possible Solution

Replace the value of the item with an integer.

A0056E

Message Format

Message Cause

The value assigned is not compatible with the type on the left side.

Example

Module-A0056E DEFINITIONS ::= BEGIN PlaceHolder ::= NULL number INTEGER ::= 1 avalue PlaceHolder ::= number -- invalid END

Error Message

Possible Solution

Replace the incompatible type with one that is compatible with the value or vice versa.

A0057E

Message Format

Message Cause

The COMPONENTS OF clause is trying to import items from an incompatible structure. In this case, the COMPONENTS OF clause within a SET is trying to import items from a SEQUENCE or vice versa.

Example

Module-A0057E DEFINITIONS ::= BEGIN Set1 ::= SET { d BOOLEAN, e INTEGER, f VisibleString, } Seq1 ::= SEQUENCE { g BOOLEAN, h INTEGER, i VisibleString, COMPONENTS OF Set1 -- invalid } END

Error Message

Possible Solution

Make sure that the structure that contains the COMPONENTS OF clause and the one that is referenced by the COMPONENTS OF clause are of the same type.

A0058E

Message Format

Message Cause

The WITH COMPONENTS clause from the input ASN.1 syntax contains an item that doesn't have an identifier.

Example

Module-A0058E DEFINITIONS ::= BEGIN Record ::= SEQUENCE { name PrintableString, age INTEGER OPTIONAL, address GeneralString OPTIONAL } Rec ::= Record (WITH COMPONENTS {name, ABSENT, address}) END

Error Message

Possible Solution

Specify the identifier of the component you want to use in the WITH COMPONENTS clause.

A0059E

Message Format

Message Cause

The WITH COMPONENTS clause is trying to access a component that is not present in the parent type.

Example

Module-A0059E DEFINITIONS ::= BEGIN ParameterList ::= SEQUENCE { requestID INTEGER, command PrintableString } RequestParams ::= ParameterList (WITH COMPONENTS {requestID, command, result PRESENT}) -- invalid END

Error Message

Possible Solution

Make sure the reference is spelled correctly or add a component to the source type with the same spelling as the reference.

A0060E

Message Format

Message Cause

The COMPONENTS OF clause is trying to import items from a structure, but the list order of the items in the COMPONENTS OF clause does not match the list order of the items in their original structure.

Example

Module-A0060E DEFINITIONS ::= BEGIN ParameterList ::= SEQUENCE { requestID INTEGER, command PrintableString } WrongSeq ::= ParameterList (WITH COMPONENTS {command, requestID}) END

Error Message

Possible Solution

Make sure the order of the list items in the COMPONENTS OF clause is the same as the order of the list items in the original structure.

A0061E

Message Format

Message Cause

The WITH COMPONENTS constraint uses an ABSENT/OPTIONAL keyword for a component that is not marked as optional in its original definition or is defined with a DEFAULT value and the -designerWarnings command-line option was specified.

Example

Module-A0061E DEFINITIONS ::= BEGIN ParameterList ::= SEQUENCE { requestID INTEGER, command PrintableString } OneParam ::= ParameterList (WITH COMPONENTS {requestID, command ABSENT}) END

Error Message

Possible Solution

Use the OPTIONAL keyword for the component or remove the DEFAULT value for that field.

A0062W

Message Format

Message Cause

The WITH COMPONENTS constraint in the input ASN.1 syntax uses a PRESENT keyword for a type that is not optional. This keyword can be applied only to optional components.

Example

Module-A0062W DEFINITIONS ::= BEGIN ParameterList ::= SEQUENCE { requestID INTEGER, command PrintableString } OneParam ::= ParameterList (WITH COMPONENTS {requestID, command PRESENT}) END

Error Message

Possible Solution

Mark the type as OPTIONAL in its original definition.

A0063E

Message Format

Message Cause

The WITH COMPONENTS constraint references an identifier that is not present in the parent type.

Example

Module-A0063E DEFINITIONS ::= BEGIN ParameterList ::= SET { requestID INTEGER, command PrintableString } OneParam ::= ParameterList (WITH COMPONENTS {requestID, command, list ABSENT}) END

Error Message

Possible Solution

Remove the identifier.

C0064I

Message Format

Message Cause

OSS-specific or ASN.1 standard compiler directives could not be applied to any part of the schema, most likely because the absolute reference provided does not exist.

Example

--<OSS.HUGE Module-C0064I.HugeINT>-- Module-C0064I DEFINITIONS ::= BEGIN HugeInt ::= INTEGER --Note the difference in letter-case END

Error Message

Possible Solution

Replace the absolute reference provided in the compiler directive with an identical type or remove the compiler directive.

C0065W

Message Format

Message format when using the compiler GUI

Message Cause

You have specified the OSS.INDEFINITE compiler directive, but it does not support the -toed option.

Example

--<OSS.INDEFINITE>-- Module-C0065W DEFINITIONS ::= BEGIN Name1 ::= SEQUENCE { a INTEGER, b VisibleString } Name2 ::= SET { c INTEGER, d VisibleString } --<DEFINITE>-- END

Error Message

Possible Solution

Specify the -soed option and recompile your syntax.

C0066W

Message Format

Message Cause

The input ASN.1 syntax contains an implementation-specific compiler directive (--<DSET., --<HP., --<TCSI., --<IBM., --<CMIS., --<GDMO., --<XMP., --<XOM., etc.). The OSS ASN.1 compiler ignores these types of directives.

Example

--<HP.DirectiveName>-- Module-C0066W DEFINITIONS ::= BEGIN A ::= INTEGER END

Error Message

Possible Solution

Remove the implementation-specific directive.

A0067E

Message Format

Message Cause

This error occurs if you use identical identifiers in the input ASN.1 syntax. According to the ASN.1 standard, the identifiers across SETs, SEQUENCEs, and CHOICEs must be unique within a specified scope.

Example

Module-A0067E DEFINITIONS ::= BEGIN Name1 ::= CHOICE { name [0] PrintableString, NULL } Name2 ::= SET { name [1] PrintableString, Name1 } END

Error Message

Possible Solution

To avoid conflicts, use unique identifiers.

A0068E

Message Format

Message Cause

An unnamed CHOICE type is nested within another structure and one of the fields has an identifier that conflicts with an identifier of the containing type.

Possible Solution

To avoid ambiguity, add an identifier to the nested CHOICE type.

A0069S

Message Format

Message Cause

The input ASN.1 syntax contains a problematic circular reference.

Possible Solution

Remove the circular reference.

A0070S

Message Format

Message Cause

The input ASN.1 syntax contains an invalid circular reference.

Example

Module-A0070S DEFINITIONS ::= BEGIN TCLASS ::= INSTANCE OF TCLASS Dummy ::= INTEGER END

Error Message

Possible Solution

Remove the circular reference.

A0071S

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error. Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0072S

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error. Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

A0073W

Message Format

Message Cause

An OBJECT IDENTIFIER value reference has a node name which conflicts with a predefined name in the OBJECT IDENTIFIER tree.

Example

Module-A0073W DEFINITIONS ::= BEGIN OperationID ::= OBJECT IDENTIFIER ftam1 OperationID ::= { iso(0) standard 2 1 } END

Error Message

Possible Solution

Rename the identifier.

A0074E

Message Format

Message Cause

The name of the second node of the OBJECT IDENTIFIER tree conflicts with a predefined name or has not been defined in the syntax.

NOTE: The value of component #2 of an object identifier is determined by the value of the first component. You can either use the predefined identifiers of the object identifier tree or define your own.

Example

Module-A0074E DEFINITIONS ::= BEGIN OperationID ::= OBJECT IDENTIFIER ftam1 OperationID ::= { 0 standard 2 1 } END

Error Message

Possible Solution

Replace the incorrect node name with one accepted in the ASN.1 standard.

A0075E

Message Format

Message Cause

You have not assigned an INTEGER value to a node of the OBJECT IDENTIFIER tree. All nodes of the OBJECT IDENTIFIER tree must have INTEGER values.

Example

Module-A0075E DEFINITIONS ::= BEGIN a BOOLEAN ::= TRUE b INTEGER ::= 2 c OBJECT IDENTIFIER ::= { ccitt question a b } END

Error Message

Possible Solution

Replace the non-integer value with an INTEGER one.

A0076E

Message Format

Message Cause

The value of the third node of the OBJECT IDENTIFIER tree is not defined correctly. For OBJECT IDENTIFIERS, the correct values are defined as follows: a(1), b(2), …, z(26).

Example

Module-A0076E DEFINITIONS ::= BEGIN ModuleOI ::= OBJECT IDENTIFIER b ModuleOI ::= { 0 0 29 } END

Error Message

Possible Solution

Replace the invalid value with one between 1 and 26, inclusive, or specify the -ignoreError 76 command-line option.

A0077E

Message Format

Message Cause

The value of a node of the OBJECT IDENTIFIER tree exceeds the accepted range of the values.

NOTE: One or more arcs of the OBJECT IDENTIFIER tree have predefined values. The root of the tree is divided into 3 arcs labeled 0, 1, and 2. Additionally, the arc labeled 1 is divided into 4 arcs labeled 0, 1, 2, and 3. The other initial branches work similarly. This error message is displayed when using other values that are not predefined.

Example

Module-A0077E DEFINITIONS ::= BEGIN OID ::= OBJECT IDENTIFIER v OID ::= { 55 44 55 66 } w OID ::= { 1 44 55 66 } END

Error Message

Possible Solution

Replace the invalid node value with one that falls between the acceptable range. Alternatively, to suppress this error message, you can specify the -allowBadValues or the -ignoreError 0077 command-line option.

A0078W

Message Format

Message Cause

An INCLUDES clause does not conform to the ASN.1 standard.

Possible Solution

Make sure the INCLUDES clause is valid.

A0079E

Message Format

Message Cause

You are trying to use a non-information-object field as a link field.

Possible Solution

Make sure the field is an object field.

A0080W

Message Format

Message Cause

The NamedBit is not placed inside braces.

Example

Module-A0080W DEFINITIONS ::= BEGIN BitString ::= BIT STRING { a(0) } b BitString ::= { a } c BitString ::= a END

Error Message

Possible Solution

Place the NamedBit inside braces.

A0081W

Message Format

Message Cause

The value reference in an ENUMERATED type value assignment has the same name as one of the bits in the NamedNumberList.

Example

Module-A0081W DEFINITIONS ::= BEGIN ColorCode ::= ENUMERATED { red(1), blue(2) } red ColorCode ::= blue END

Error Message

Possible Solution

Rename the value reference.

A0082E

Message Format

Message Cause

One of the following keywords is missing from the input ASN.1 syntax: IMPLICIT, EXPLICIT, or AUTOMATIC.

Example

Module-A0082E DEFINITIONS TAGS ::= BEGIN A ::= INTEGER END

Error Message

Possible Solution

Add the missing keyword.

A0083E

Message Format

Message Cause

The type reference name does not begin with an uppercase letter.

Example

Module-A0083E DEFINITIONS ::= BEGIN c ::= INTEGER { c(4) } Dummy ::= BOOLEAN END

Error Message

Possible Solution

Replace the lowercase letter of the type reference with an uppercase letter.

A0084E

Message Format

Message Cause

The value reference or the object reference does not begin with a lowercase letter.

Example

Module-A0084E DEFINITIONS ::= BEGIN Value BOOLEAN ::= TRUE END

Error Message

Possible Solution

Replace the uppercase letter of the value or the object reference with a lowercase letter.

A0085W

Message Format

Message Cause

One of the following types in the input ASN.1 syntax uses implicit tagging instead of explicit tagging: CHOICE, ANY or ANY DEFINED BY.

Possible Solution

Replace the implicit tag of the type with an explicit tag.

A0086E

Message Format

Message Cause

A module definition does not have a name.

Example

{iso(1) identified-organization(3) oss(1) module-5(5)} DEFINITIONS ::= BEGIN A ::= INTEGER END

Error Message

Possible Solution

Add a name at the beginning of the defined module in accordance with the guidelines of the ASN.1 standard.

A0087E

Message Format

Message Cause

The IMPORTS statement contains one or more arguments that are not valid.

Possible Solution

Remove the arguments from the IMPORTS statement.

C0088W

Message Format

Message Cause

The EXPORTS statement in the input ASN.1 syntax contains two or more identical arguments.

Example

DupExp DEFINITIONS ::= BEGIN EXPORTS A, A; IMPORTS B FROM X; A ::= INTEGER END
X DEFINITIONS ::= BEGIN B ::= BOOLEAN END

Error Message

Possible Solution

Remove the duplicate argument from the EXPORTS statement.

A0089E/A0089W

Message Format

Message Cause

An IMPORTS statement s trying to import a type from the source module, but the type is not present. This error often occurs when the argument is misspelled.

Example

Common DEFINITIONS ::= BEGIN Responder ::= [PRIVATE 1] GeneralizedTime END
Module-A0089E DEFINITIONS ::= BEGIN IMPORTS Responde FROM Common; InvokePDU ::= SEQUENCE { Responde } END

Error Message

Possible Solution

Make sure the arguments in the IMPORTS statement are spelled correctly.

NOTE: Starting with version 8.1.2, if you specify the -ignoreIncompleteItems option, the ASN.1 syntax checker displays a warning instead of an error message.

A0090W

Message Format

Message Cause

An IMPORTS statement is trying to import an item from another module that does not include an EXPORT statement with a list of items.

NOTE: According to the ASN.1 standard, if a module includes an explicit EXPORTS clause, you can export only the types listed as arguments, otherwise, all items are implicitly marked as exportable.

Example

Import1 DEFINITIONS ::= BEGIN IMPORTS Ex1, c, Ex2 FROM Export1; T ::= Ex1 e T ::= c a Ex2 ::= 3 END
Export1 DEFINITIONS ::= BEGIN EXPORTS Ex1, Ex2; IMPORTS T, a FROM Import1; Ex1 ::= BOOLEAN Ex2 ::= INTEGER b Ex2 ::= a c T ::= TRUE END

Error Message

Possible Solution

Add the item to the EXPORTS statement of the source module or remove the EXPORTS statement.

A0091E

Message Format

Message Cause

The ASN.1 compiler cannot resolve the type reference in the input ASN.1 syntax.

Possible Solution

Make sure the type reference is a basic ASN.1 type or another representable structure.

L0092W

Message Cause

This message code is used by OSS Nokalva for internal purposes.

C0093E

Message Format

Message Cause

The macro referenced in the input ASN.1 syntax has not been defined.

Possible Solution

Make sure you define the macro first.

A0094E

Message Format

Message Cause

The input ASN.1 syntax contains a module definition that does not have a module name.

Example

DEFINITIONS ::= BEGIN A ::= INTEGER END

Error Message

Possible Solution

Specify a name for the module.

A0095E

Message Format

Message Cause

An IMPORTS statement contains arguments which are not separated by comma or the keyword FROM is missing from the statement.

Example

Module-A0095E DEFINITIONS ::= BEGIN EXPORTS Timestamp; IMPORTS Responder; Timestamp ::= Responder END

Error Message

Possible Solution

Add the missing comma or the keyword FROM.

C0096E

Message Cause

This message code is used by OSS Nokalva for internal purposes.

A0097E

Message Format

Message Cause

The type that is referenced is not defined or the macro is defined after being referenced.

Example

Module-A0097E DEFINITIONS ::= BEGIN ERROR1 MACRO ::= ERROR ERROR MACRO ::= BEGIN TYPE NOTATION ::= "PARAMETER" NamedType | empty VALUE NOTATION ::= value(VALUE INTEGER) NamedType ::= identifier type | type END END

Error Message

Possible Solution

Make sure all referenced types are defined and all macros are precisely rendered before they are used.

A0098E

Message Format

Message Cause

An ANY type might cause tag conflicts within a SET, CHOICE, or other tag-sensitive context.

Example

Module-A0098E DEFINITIONS ::= BEGIN L ::= SET { seq SEQUENCE OF CHOICE { sharp INTEGER, eyes ANY } } END

Error Message

Possible Solution

Add an explicit tag to the ambiguous ANY type.

C0099E

Message Format

Message Cause

One or more components in a CHOICE type might cause a possible tag conflict.

Example

Module-C0099E DEFINITIONS ::= BEGIN Name1 ::= CHOICE { name PrintableString, id INTEGER, next Name1 } END

Error Message

Possible Solution

Add an explicit tag.

A0100E

Message Format

Message Cause

The input ASN.1 syntax contains duplicate tags that will cause ambiguity problems in decoding.

Example

A0100E DEFINITIONS ::= BEGIN MySet ::= SET { a [1] INTEGER, b [1] BOOLEAN } END

Error Message

Possible Solution

Consider the following solutions:

  • Make sure all components have unique tags.
  • Remove the tags and add the AUTOMATIC TAGS keyword at the beginning of the module definition.

C0101E

Message Format

Message Cause

The input ASN.1 syntax contains duplicate tags that will cause ambiguity problems in decoding. This message is issued if the -unique option is specified.

Example

Module-C0101E DEFINITIONS ::= BEGIN C ::= BOOLEAN D ::= CHOICE { e INTEGER, f BOOLEAN } END

Error Message

Possible Solution

Make sure all components have unique tags or do not specify the -uniquePDU ASN.1 compiler command-line option.

C0102S

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0103S

Message Format

Message Cause

Your input ASN.1 syntax contains more than seven levels of nested INCLUDES clauses. The compiler imposes a restriction of at most seven levels of nested INCLUDES clauses.

Possible Solution

Redefine your schema and make sure you do not need so many levels of nesting.

C0104S

Message Format

Message Cause

The ASN.1 compiler cannot open an internal temporary file used in parsing your ASN.1 syntax.

Possible Solution

Make sure the process executing the ASN.1 compiler has write permission in the current working directory.

C0105S

Message Format

Message Cause

The maximum number of type and value references that can be used in a single macro definition is 20. Your input ASN.1 syntax contains more than 20 type and value references in a single macro definition.

Possible Solution

To comply with the accepted limit, remove one or more of the local type and value references in the macro definition.

A0106E

Message Format

Message Cause

The input ASN.1 syntax contains a MACRO keyword, but the macro definition is missing.

Example

Module-A0106E DEFINITIONS ::= BEGIN ERROR MACRO ::= 5 END

Error Message

Possible Solution

Add a macro definition after the MACRO keyword.

A0107E

Message Format

Message Cause

The input ASN.1 syntax contains a macro with a TYPE production but the VALUE production is missing.

Example

Module-A0107E DEFINITIONS ::= BEGIN ERROR MACRO ::= BEGIN TYPE NOTATION ::= "PARAMETER" NamedType | empty Value NOTATION ::= value(VALUE INTEGER) NamedType ::= identifier type | type END END

Error Message

Possible Solution

Make sure the keyword VALUE is spelled correctly or, in case there isn't one, add a VALUE production.

A0108E

Message Format

Message Cause

A macro contains one or more productions that do not end in a token (SymbolElement).

Example

A0108E DEFINITIONS ::= BEGIN ERROR MACRO ::= BEGIN TYPE NOTATION ::= "PARAMETER" NamedType | empty | VALUE NOTATION ::= value(VALUE INTEGER) empty NamedType ::= identifier type -- | type NamedType ::= type END END

Error Message

Possible Solution

Remove the extra "|" characters at the end of the production or add another token.

A0109E

Message Format

Message Cause

The name of the macro does not conform to the ASN.1 standard.

Example

Module-A0109E DEFINITIONS ::= BEGIN ErrOR MACRO ::= BEGIN TYPE NOTATION ::= "PARAMETER" NamedType | empty VALUE NOTATION ::= value(VALUE INTEGER) NamedType ::= identifier type | type END END

Error Message

Possible Solution

Make sure the name of the macro contains uppercase, digits, or hyphens.

A0110E

Message Format

Message Cause

A production reference in the input ASN.1 syntax is used more than once in the same macro definition.

Example

Module-A0110E DEFINITIONS ::= BEGIN ERROR MACRO ::= BEGIN TYPE NOTATION ::= "PARAMETER" NamedType | empty VALUE NOTATION ::= value(VALUE INTEGER) empty NamedType ::= identifier type NamedType ::= type END END

Error Message

Possible Solution

Use only distinct names for productions.

C0111S

Message Format

Message Cause

The maximum number of tokens that can be used in a macro definition is 32,700. Your input ASN.1 syntax contains more than 32,700 tokens in a macro definition.

Possible Solution

Make sure the macro definition is divided into shorter definitions.

A0112E

Message Cause

This message code is used by OSS Nokalva for internal purposes.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0113S

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0114S

Message Format

Message Cause

Your input ASN.1 syntax has caused an internal discrepancy in the ASN.1 compiler. The most likely cause of this message is a serious syntax error in your input.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0115E

Message Format

Message Cause

The input ASN.1 syntax contains a derived type that is not consistent with the parent type.

Example

C0115E DEFINITIONS ::= BEGIN A ::= INTEGER {one(1),two(2),three(3)} UseG ::= G (WITH COMPONENT (MIN..five)) G ::= SET OF A five A ::= 5 UseE ::= E (WITH COMPONENTS {...,c (thirtythree) }) E ::= SEQUENCE {a A, b BOOLEAN OPTIONAL} END

Error Message

Possible Solution

Make sure all derived types are consistent with their parent types.

C0116E

Message Format

Message Cause

A forward reference to a user-defined type is inconsistent with its actual definition.

Example

Module-C0116E DEFINITIONS ::= BEGIN hydrogen Element ::= "H" Element ::= CHOICE { atomicNumber INTEGER (1..109), symbol PrintableString (SIZE(1..2)) } END

Error Message

Possible Solution

Make sure all forward references are consistent with the definition of the type referenced.

C0117S

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0118E

Message Format

Message Cause

The ASN.1 compiler has encountered an internal error.
Your ASN.1 input likely contains erroneous syntax, but in a new and unexpected form, which we need to further analyze.

Next Action

Send the exact command line and ASN.1 input used to Technical Support ‹support@oss.com› for review.

C0119S

Message Format


NOTE: This message is outdated.

A0120E

Message Format

Message Cause

A symbol (a comma, a word etc.) is missing, is placed in an inappropriate location, or is substituted by another symbol. In general, this error occurs when you redefine or misplace predefined ASN.1 reserved words (APPLICATION, MAX, OBJECT, WITH).

Example


Extract from Abstract Syntax Notation One (ASN.1) - The Tutorial and Reference
by Doug Steedman


E.1 What is ASN.1?

ASN.1 is the acronym for Abstract Syntax Notation One, a language for describing structured information; typically, information intended to be conveyed across some interface or communication medium. ASN.1 has been standardised internationally. It is widely used in the specification of communication protocols.

Prior to ASN.1, information to be conveyed in communication protocols was typically specified by ascribing meanings to particular bits and bytes in protocol messages, much as programmers, before the advent of high level languages, had to deal with the bits and bytes of storage layout.

With ASN.1, the protocol designer can view and describe the relevant information and its structure at a high level and need not be unduly concerned with how it is represented while in transit .Compilers can provide run-time code to convert an instance of user or protocol information to bits on the line.

ASN.1 comes into its own when the information being described is complex. This is because the language allows arbitrarily complex structures to be built up in a uniform way from simpler components, and ultimately from a few simple information types. ASN.1 is, in effect, a data definition language, allowing a designer to define the parameters in a protocol data unit without concern as to how they are encoded for transmission. He merely states a need for an Integer followed by text, followed by a floating point number, etc. They can be named and tagged such that two integers can be differentiated as meaning "filesize" or "record number", for example.


Given any ASN.1 description of a message, a representation can be derived mechanically by applying a set of encoding rules. While many such sets could be imagined, initially only a single set, the Basic Encoding Rules (BER), were standardised as a companion standard to ASN.1 itself. Subsequently two subsets of the basic rules have been approved. These are the Canonical and the Distinguished Encoding Rules. These are exact subsets of the BER, but where it has choices the subsets restrict these to a single possible encoding. In addition, a completely new set of encoding rules has been devised in response to the criticism that BER is highly inefficient, e.g., three bytes to encode a boolean. These are called the packed encoding rules

The "One" was added to the ASN name by ISO to leave open the future possibility of a better language for expressing abstract syntaxes. However, an "ASN.2", should it ever be considered necessary, will have to be significantly more powerful than ASN.1 to be worth inventing.

E.1.1 Abstract Syntax

To illustrate the concept of abstract syntax consider, for example, ameteorological station, which reports on the prevailing atmospheric conditions to a monitoring centre. At the monitoring centre, the information is input to a weather forecasting program.

With abstract syntax the concern is solely with the information conveyed between the application program running in the computer at the weather station and the application program running in the computer at the monitoring centre.

For different reasons, both programs need to "know" what information is included in a report. The application in the weather station needs to know so that it can create reports from the appropriate sensor readings. The application in the centre needs to know because it must be able to analyse reports and make weather forecasts.

This knowledge, which is essential for the programs to be written, is that of the abstractsyntax; the set of all possible (distinct) reports. The designer of the abstract syntax also defines the meaning of each possible report, and this allows the developers of the programs at each end to implement the appropriate actions.

It would be very unusual for a designer to define the abstract syntax of a message type by explicitly listing all possible messages. This is because any realistic message type will allow an infinite number of distinct possibilities, integer as a simple example of this. Instead, the abstract syntax will generally be structured. The set of possible messages and their meanings can then be inferred from knowledge of the possibilities for each of the components of the structure.

ASN.1 notation is recognisable as a high level definition language. It is constructed in modules with unique identifiers. There are over 20 built data types such as:

Simple data typesCharacter stringsUseful Types
BOOLEAN NumericString GeneralizedTime
INTEGER PrintableString UTCTime
ENUMERATED TeletexString EXTERNAL
REAL IA5StringObjectDescriptor
BIT STRINGGraphicString
OCTET STRINGGeneralString
NULL

Arbitrarily complex structures can be built up from these data types using constructors such as:

  • SET{} - order not significant
  • SEQUENCE{} - fixed order

and other useful modifiers such as: OPTIONAL and IMPLICIT

Using ASN.1, the weather report abstract syntax could be expressed as follows:

WeatherReport ::=SEQUENCE { stationNumber INTEGER (1..99999), timeOfReport UTCTime pressure INTEGER (850..1100) temperature INTEGER (-100..60) humidity INTEGER (0..100) windVelocity INTEGER (0..500) windDirection INTEGER (0..48) }

A simple protocol data unit might take the form

File-Open-Request ::=SEQUENCE { filename [0] INTEGER password [1] Password OPTIONAL mode BITSTRING {read o, write 1' delete 2} Password ::=CHOICE {OCTETSTRING, PrintableString}

E.1.2 Transfer Syntax

Earlier standards such as ASCII and EBCDIC specified both the abstract syntax (the letter A) and the encoding, or transfer syntax, (hexadecimal 21 or 41). ASN.1 separates these two concepts, such that at connect time you can chose to encode the data. Youcan chose an encoding which is efficient on the line or reliable or easy to decode. The first defined for ASN.1 was the Basic Encoding Rules (BER)

The BER allow the automatic derivation of a transfer syntax for every abstract syntax defined using ASN.1. Transfer syntaxes produced by application of the BER can be used over any communications medium which allows the transfer of strings of octets. The encoding rules approach to transfer syntax definition results in considerable saving of effort for application protocol designers. This is particularly pronounced where the messages involved are complex. Perhaps even more important than the savings to the designers are the potential savings to implementors, through the ability to develop general-purpose run-time support. Thus, for example, encoding and decoding subroutines can be developed once and then used in a wide range of applications.

A set of encoding rule can only be developed in the context of an agreed set ofconcepts such as those provided by ASN.1. For example, the concepts required in designing the weather report abstract syntax included the ability to create a message from a sequence of fields, and the concepts of integer and whole number (restricted to certain ranges).

As the structure of ASN.1 is hierarchical, the basic encoding rules follow this structure. They operate on a Tag, Length Value (TLV) scheme. This is actually known in ASN.1 as Identifier, Length, Contents. (ILC). The structure is therefore recursive such that the contents can be a series of ILCs. This bottoms out with genuine contents such as a text string or an integer.

E.2 Basics of ASN.1

E.2.1 Types and Values

The fundamental concepts of ASN.1 are the inter-related notions of type and value. A type is a (non-empty) set of values, and represents a potential for conveying information. Only values are actually conveyed, but their type governs the domain of possibilities. It is by selecting one particular value of the type, rather than the others, that the sender of a message conveys information. The type may have only a

few values, and therefore be capable of conveying only a few distinctions. An example of such a type is Boolean, which has only the two values true and false, with nothing in between. On the other hand, some types, such as Integer and Real, have an infinite number of values and can thus express arbitrarily fine distinctions.

An abstract syntax can be defined as a type, normally a structured type. Its values are precisely the set of valid messages under that abstract syntax. Should the messages be structured, as they commonly are, into fields, then the various fields themselves are defined as types. The values of such a type, in turn, are the set of permitted contents of that field.

A type is a subtype of another, its parent (type), if its values are a subset of those of the parent. Thus, for example, a type "whole number"" whose values are the non-negative integers, could be defined as a subtype of Integer. (ASN.1 does not provide such a type, but one could be defined by the user if needed). Another example would be to define the YEAR as the twelve months and the subtype SPRING as March, April and May.

A type may be simple or structured. The simple types are the basic building blocks of ASN.1, and include types like Boolean and integer. A simple type will generally be used to describe a single aspect of something. A structured type, on the other hand, is defined in terms of other types - its components - and its values are made up of values of the component types. Each of these components may itself be simple or structured, and this nesting can proceed to an arbitrary depth, to suite the needs of the application. All structured types are ultimately defined in terms of simple types.

ASN.1 makes available to the abstract syntax designer a number of simple types, as well as techniques for defining structured types and subtypes. The designer employs these types by using the type notation which ASN.1 provides for each such type. ASN.1 also provides value notation which allows arbitrary values of these types to be written down.

Any type ( or indeed value) which can be written down can be given a name by which it can be referenced. This allows users to define and name types and values that are useful within some enterprise or sphere of interest. These defined types (or defined values) can than be made available for use by others. The defined types within some enterprise can be seen as supplementing the built-in types - those provided directly by ASN.1. ASN.1 also provides a small number of useful types, types which have been defined in terms of the built-in types but which are potentially of use across a wide range of enterprises.

A type is defined by means of a type assignment, and a value is defined by a value assignment. A type assignment has three syntactic components: the type reference (the name being allocated to the new type); the symbol "::=", which can be read as "is defined as"; and the appropriate type notation. For example:

WeatherReport ::=SEQUENCE { stationNumber INTEGER (1..99999), timeOfReport UTCTime pressure INTEGER (850..1100) temperature INTEGER (-100..60) humidity INTEGER (0..100) windVelocity INTEGER (0..500) windDirection INTEGER (0..48) }

defines a type called WeatherReport. Everything following the "::=" constitutes valid type notation (for a structured type which comprises a sequence of simple and structured types).

A value assignment is similar, but has an additional syntactic component: the type to which the value belongs. This appears between the value reference (the name being allocated to the value), and the "::=". For example:

sampleReport WeatherReport::=SEQUENCE { stationNumber 73290 timeOfReport "900102125703Z", pressure 1056, temperature -3, humidity 26, windVelocity 15, windDirection 0 }

defines a value of type WeatherReport called sampleReport. The characters after the "::=" constitute valid notation for a value of WeatherReport.

The definition of types and values is almost the only thing that ASN.1 users do. Of these two, the definition of types predominates. This is because an abstract syntax itself is a type, as are its components, and their components, and so on. In a specification, it is the types, the sets of possible values, which are most significant. Individual values only appear as examples and defaults. Consider how much more useful in a specification is the type INTEGER than the particular value 314 (or any other integer value for that matter). Conversely, in instances of communication it is values which are significant.

E.2.2 Subtypes

Frequently the designer intends only some subset of the values of an ASN.1 type to be valid in some situation. For instance, in conveying a measure of humidity as a percentage, only numbers in the range 0 to 100 are valid, or when conveying a postal code only strings with certain characters and whose length falls within a certain range are to be permitted. Perhaps when some protocol message is used in a certain context, the optional checksum field is to be absent.

These are all examples of constraints which can be expressed by defining a subtype of a suitable parent type. This is done by appending to the notation for the parent a suitable subtype specification. The result is itself a type and can be used anywhere a type is allowed. (Thus a subtype specification can also be applied to a subtype, in which case it may serve to further reduce the set of values).

A subtype specification consists of one or more subtype value sets, separated by "|" (pronounced "or"). The whole list is in round brackets(()).

For example in:

Weekend ::= DaysOfTheWeek (saturday | sunday)

the type Weekend is defined by appending a subtype specification to a parent type DaysOfThe Week. The subtype specification (the expression in round brackets) defines which of the values of DaysOfTheWeek are also to be values of Weekend.

There are six different value set notations. Two of these are applicable to all parent types, others to only certain parent types.

The value set notations that are applicable to all parent types are single value and contained subtype. The former notation is simply some value of the a parent type, the resulting value set consisting of that value alone. Examples of this are "saturday" and "sunday" above, each of which is a single value of DaysOfTheWeek. The contained subtype notation comprises the keyword INCLUDES, followed by some other subtype of the same parent type, and denotes the value set consisting of all the values in that subtype.

For example, given:

LongWeekend ::= DaysOfTheWeek (INCLUDES Weekend | monday)

the type LongWeekend includes the three values saturday, sunday, and monday, the union of the value sets used in its definition

Each value set defines some subset of the values of the parent type. The resulting subtype has the values in the union of these subsets, which must be non-empty..

The value range notation can be used to subtype any type whose values are ordered (for example, the integer type). It involves specifying the lower and upper bounds of the range.

A size range can be included for any type whose values have a defined size (for example, the bit string type). Here the value set includes all of the values whose size, measured in the appropriate units, is within the designated range.

An alphabet limitation can be applied only to character string types and allows only the values formed from some subset of the characters.

Finally, inner subtyping can be employed to define value sets of structured types (for example, set and set-of-types). Here the value set includes all those values whose component values meet certain constraints.

E.2.3 Names

Several categories of object in ASN.1 have names by which they can be referenced.We have actually met examples of each of these kinds of name above, as follows:

type reference: WeatherReport
value reference: sampleReport
identifier:humidity

It is very important that names are chosen, as in these examples, to have significance to the human reader. Indeed, if names are chosen correctly (and appropriate layout conventions followed), then the essence of some piece of ASN.1 can often be grasped, even by someone unskilled in the language.

All names in ASN.1 are character strings drawn from the same set of characters, namely:

upper-case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ
lower-case letters: abcdefghijklmnopqrstuvwxyz
decimal digits: 0123456789
hyphen: -

The first character in a name must be a letter. The case of the letters in a name is significant, so that "borders" and "Borders" are different names. In fact the case of the initial letter is of special significance, as type references (and also module references, see below) must start with an upper-case letter, while value references and identifiers must start with a lower-case letter. It is not a good idea, however, to use two or more names which differ only by the case of some of their letters.

The names chosen by users must be chosen so as to avoid clashing with the reserved words of ASN.1 (which include most of the keywords of the language). Since the keywords are generally in upper-case, the use of lower-case letters in names makes it easy to adhere to this, and also generally makes the names more readable. There is no upper limit on the length of names, and this allows the use of an appropriate phrase as the name of an object.

Examples of legal (and probably appropriate) names are:

UnformattedPostalAddress
Access-control-list
ACL
Temperature
MverifyPDU
recordLow
ib-g3facsimile-non-basic-parameters

The first few of these examples are valid for use as type references, the others as identifiers or value references.

Notice that two different conventions are used in these examples for forming multi-word names, since spaces are not valid in names and thus can not be used to separate the individual works.

E.2.4 Modules

As with any modern programming language ASN.1 is modular. A module is a named collection of definitions of types and values (and macros - see next section). A module normally groups together a set of related definitions, such as all those used in defining some abstract syntax. However, the basis for grouping definitions into modules is entirely in the hands of the designer, who could put all definitions into one module, or organise them into several modules, according to taste.

Within a module, definitions can appear in any order, with none of the restrictions sometimes found in programming languages, such as "define before use". It is up to the designer to organise the definitions to make the result most understandable to the reader.

All types and values defined in a single module must be allocated distinct references, and within the module such a reference unambiguously identifies the applicable type or value.

A module consists of, in order: the module identifier; the keyword DEFINITIONS; optionally, the tag style default; the symbol "::="; the module body. The module body consists of the exports and imports statements, if any, followed by the type and value assignments, all enclosed between BEGIN and END.

An example of a module is as follows. The component parts - what should be inside the second and third curly brackets - are omitted, but see Section E.2.1 for what would be entered.

WeatherReporting {2 6 6 247 1} DEFINITIONS ::= BEGIN WeatherReport ::= SEQUENCE { ..... } sampleReport WeatherReport ::= { .....} END

The module identifier (which precedes the keyword DEFINITIONS) constitutes the complete and unambiguous identification of the module. It consists of two components, the first a module reference and the second an object identifier value; in the example they are WeatherReporting and {2 6 6 247 1} respectively.

A module reference is the same (syntactically) as a type reference. The module reference should be chosen so as to be suggestive of the contents of the module in some way, and, if possible, unambiguous.

The other component, the object identifier value, is a globally unique identification for the module, made up of a sequence of non-negative numbers.

Object Identifier was originally developed as part of the ASN.1 standard, but is now ubiquitous. It is essential in any global network as it is a unique naming space. It allows any communications object to be uniquely identified. It is a hierarchical naming space, with the authority to specify Object Identifiers being passed down the hierarchy. Thus an enterprise may register itself and then sub-allocate number space to its branches or subsidiaries.

Specifically Object Identifiers are becoming used more and more to identify Managed Objects whether these are SMTP or ISO Managed Objects. This allows for global network management on the basis that every type of object has a unique identification.

While the object identifier value is optional, this is largely for backwards compatibility reasons, because it was not present in the first version of ASN.1. In practice it is not a good idea to omit it.

E.3 Macros

ASN.1 provides a mechanism whereby users can extend the notation for their own use, or for use by others. This allows the designer to extend the language to define a new "object" such as a modem or a switch. These have "normal" ASN.1 properties and additional properties such as parenthood and physical location. For example an "asynchronous modem" may have "generic modem" as a parent. It inherits properties from the parent. A modem may physically be in the same rack as others and we have a second hierarchy of physical location. ASN.1 itself can be used to define properties such as:

modem ::= SEQUENCE { speed INTEGER modulation IA5 String manufacturer IA5 String }

but the additional features require the MACRO extensions to specify them. This generates a form of "template" for the designer to fill in.

A user extending the notation does so by defining one or more macros, using the macro definition notation (MDN). Each macro has a macro reference (like a type reference except that all letters, not just the first, must be in upper-case), and grammars for type and value notation. These grammars are defined by the macro designer using Baccus Naur Format (BNF).

A macro definition can be imported and exported by means of its macroreference, just as with type and value definitions.

The macro capability provides fairly powerful abilities for the definition of new type and value notation within ASN.1 modules, with the full power of BNF available to the designer, as well as some powerful built-in symbols, such as for types and values.

The macro defines a kind of definition form or template for a concept which is more complex than just an ASN.1 type and value. In fact it is an assemblage of related types and values, related through being aspects of the same operation.

Such a form or template could clearly have been defined by means outside of ASN.1. However, because many or all of the aspects of such a concept are specified using ASN.1, it proves very convenient to be able to include the definition within an ASN.1, module along with the definitions of the types and values involved. Furthermore, because the use of macros results in ASN.1 types and values, they can be given reference names, can be included in modules, and can be imported and exported using all of the same mechanisms already provided in ASN.1.

The macro corresponds to some concept, more complex than a data type, of which users can define instances. The type notation defines the form or template, with all of the appropriate degrees of freedom provided. The value notation is almost always an integer or object identifier value which is the delivered value, and which constitutes the "run-time" identification of the instance.

E.4 Encoding Rules

When the encoding rules were separated from the notation, they were dubbed the Basic Encoding Rules (BER), with the idea that there might be justification for defining different sets of encoding rules. Such encoding rules would not just be different for the sake of being different, but would be designed to meet some functional requirement, such as optimising compactness of encoding at the expense of computational overhead, or vice versa.

Thus additional rules were defined in subsequent revisions. These are in two flavours. The first, Canonical and Distinguished Encoding Rules, are designed to reduce options for encoding and thus reduce decoding computational overhead. The second are exactly targeted at reducing line overhead. They provide line efficiency at the cost of processing overhead.

It is worth noting that a clear advantage of the use of encoding rules such as the BER rather than hand-crafting transfer syntaxes is that application designers do not need to be familiar with their details; indeed neither do most implementors. This is analogous with the way that programmers using high-level languages do not have to know in detail how data structures are held in memory. However in both cases it helps to have a general awareness, if for no other reason than to know how "expensive" various constructs are.

The BER generate encodings which are of a class known as type - length - value (TLV), so called because the basis of encoding is a structure made up of those three parts. Many protocols employ encoding schemes of this general kind. However, few apply the idea so consistently as the BER.

With BER, the encoding of every data value in an abstract syntax, whether an entire PDU or some component of it, is constructed in TLV style. The three parts are actually termed identifier (I), length (L) and contents (C).

The identifier conveys three pieces of information: the tag class of the data value being conveyed; the tag number, the formof the encoding - whether it is primitive or constructed.

The length (together with the form) allows the end of the contents to be found. The receiving system need not understand the tag to find the end of the contents, and this allows an encoding to be skipped if it cannot (yet) be decoded.

The contents is the substance of the encoding, conveying the actual value. When the form of the encoding is primitive, the contents is simply a series of octets (zero or more) and when the form is constructed, the contents is a series of nested encodings, each itself having identifier, length and contents.

This nesting can be as deep or as shallow as needed; its primary purpose is to convey values which have components which themselves have components, and so on, to any depth. Nesting stops either with a primitive encoding, or with a constructed encoding with empty contents. Each part of the encoding (and therefore also the encoding as a whole) is an integral number of octets.

E.5 ASN.1 Developments

ASN.1 is at the core of open systems applications today and has been revised to include a replacement for the MACRO mechanism and additional encoding rules. The main parts of the standard are summarized below. ASN.1 is now ubiquitous and even used by the Internet network management protocol, SNMP.

X.680 ISO/IEC 8824-1 Basic ASN.1 Notation
X.681ISO/IEC 8824-2Information Objects Specification
X.682ISO/IEC 8824-3 Constraint Specification
X.683 ISO/IEC 8824-4Parameterization
X.690 ISO/IEC 8825-1Basic, Canonical and Distinguished Encoding Rules
X.691SO/IEC 8825-2Packed Encoding Rules
Amendment 1 Rules for Extensibility

[This chapter is based on extracts from Doug Steedman's book Abstract Syntax Notation One (ASN.1) - The Tutorial and Reference, published by Technology Appraisals]

Further Reading
[1] Steedman, Douglas., Abstract Syntax Notation One (ASN.1) - The Tutorial and Reference, Technology Appraisals, 1990.

� Technology Appraisals Limited 1990, 1996


Technology Appraisals Ltd
webmaster@techapps.co.uk
Phone +44 (0)181 893 3986
Fax +44 (0) 181 744 1149
82 Hampton Road, Twickenham
TW2 5QS UK

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *