Connecting the world and beyond

Migration from the ASN.1:1988/1990 notation to the ASN.1:1994/1997/2002 notation

NOTE: This text is slightly adapted from Annexes A and E as they were published in the 1994 and 1997 editions of ITU-T Rec. X.680 ¦ ISO/IEC8824-1. It applies to the 1994, 1997 and (currently in force) 2002 editions of the ASN.1 notation, for there were no changes that were not backwards compatible.

Annex A: Use of ASN.1:1988/1990 notation

A.1 Maintenance

The term ASN.1:1988/1990 notation is used to refer to that ASN.1 notation specified in CCITT Rec. X.208 which was withdrawn in 2002. The term current ASN.1 notation is used to refer to the ITU-T Rec. X.680 | ISO/IEC 8824 series (whether it is dated, 1994, 1997 or 2002).
This document is provided in order to give users of ASN.1 information on how to replace features (particularly ANY and use of the macro notation) of the ASN.1:1988/1990 notation with current ASN.1 notation. (This can be done with no change to bits on the line.)

A.2 Mixing ASN.1:1988/1990 and current ASN.1 notation

Both the ASN.1:1988/1990 and the current ASN.1 notation specify a top-level syntactic construct which is an ASN.1 module. A user of ASN.1 writes a collection of ASN.1 modules, and may import definitions from other ASN.1 modules.
For any given module, the notation used is required to conform (completely) to either the ASN.1:1988/1990 notation or to the current ASN.1 notation, and a user Specification should clearly identify which notation is being used (by reference to the appropriate Recommendation | International Standard) for each module textually included in the user Specification.
Note that it might happen that a user wishes to modify part of a module to use the new notation, but to leave other parts in the old notation. This can (only) be achieved by splitting the module into two modules.
Where a module conforms to the ASN.1:1988/1990 notation, type and value references may be imported from a module that was defined using the current notation. Such types and values must be associated with types that can be defined using only the ASN.1:1988/1990 notation. For example, a module written using the ASN.1:1988/1990 notation cannot import a value of type UniversalString, since this type is defined in the current notation but not in ASN.1:1988/1990; it can, however, import values whose types are, for example, INTEGER, IA5String, etc.
Where a module conforms to the current ASN.1 notation, type and value references may be imported from a module that was defined using the ASN.1:1988/1990 notation. No ASN.1 macro shall be imported. Value notation for an imported type shall only be used in the importing module if identifiers for SET and SEQUENCE and CHOICE values used in the value notation are present, and if is no requirement in the value notation for a value of the ANY type. An inner type constraint shall not be applied to an imported type if the component being constrained does not have an identifier.

A.3 Migration to the current ASN.1 notation

When modifying a module (originally written to conform to the ASN.1:1988/1990 notation) to conform to the current notation, the following points should be noted:

All components of SET and SEQUENCE and CHOICE shall be given identifiers that are unambiguous within that SET, SEQUENCE or CHOICE, and such identifiers shall be included in the value notation.
NOTE – The value notation for a CHOICE type contains a colon (":").
All uses of ANY and ANY DEFINED BY shall be supported by a suitable information object class definition, with the ANY and ANY DEFINED BY (and the referenced component) replaced by appropriate references to fields of that object class. In most cases the specification can be greatly improved by careful attention to the insertion of table and component relation constraints. In many cases the specification can be further improved if the table or component relation constraint is made a parameter of the type.
All macro definitions shall be replaced by either the definition of an information object class, a parameterized type or a parameterized value. If the WITH SYNTAX clause is carefully designed in the definition of an information object class, the notation used to define an object of that class can be made very similar to the notation defined by the old use of the macro notation.
All instances of use of a macro shall be replaced by either equivalent information object definitions, or by references to equivalent "ObjectClassFieldType"s, parameterized types or parameterized values. In most cases the specification of information objects can be greatly improved by grouping such definitions into information object sets, and by giving clear guidance on whether it is mandatory to support all information objects in the set, and on whether implementation-dependent extensions to that information object set are to be accommodated by receiving implementations, and if so, how they are to handle receipt of "unknown" values. It may also be desirable to consider the possibility that a later version of the user Specification may extend the information object set, and to give guidance to current implementors on how such extensions are to be treated.
All occurrences of EXTERNAL should be carefully examined; while such notation is still legal in the current ASN.1, a user Specification can probably be improved by doing the following:
- Consider the use of the INSTANCE OF notation (preferably with a table constraint that may be as a parameter of the type, as discussed above for ANY and ANY DEFINED BY) in place of the EXTERNAL notation; in many cases this will not change the bits on the line.
- Where EXTERNAL is retained, use of inner subtyping of the associated type (see ITU-T Rec. X.680:2002 | ISO/IEC 8824-1 (2002), 47.8) can help to give precision to the specification of whether use of presentation context identifiers is or is not permitted. Earlier comments (see ITU-T Rec. X.680:2002 | ISO/IEC 8824-1 (2002), 34) that give guidance about what values of EXTERNAL are to be supported, and what implementations should do if unsupported values are received also apply here.
- Consider a change to: CHOICE {external EXTERNAL, embedded-pdv EMBEDDED PDV}
  
  (again with inner subtyping if appropriate) to allow a phased migration of distributed peer applications to the current notation. This can affect the bits on the line, and would normally be done as part of a version change in the protocol. The use of EMBEDDED PDV (particularly for new specifications) will normally give more flexibility, as can be seen by comparison of the associated types; further, EMBEDDED PDV is encoded more efficiently than EXTERNAL by all the encoding rules specified in ITU-T Rec. X.690 | ISO/IEC 8825-1.
It may be possible to improve the readability of the notation in existing ASN.1 modules (with no change to bits on the line) by insertion of AUTOMATIC TAGS in the module header and deletion of some or all tags. NOTE – This must be done with care, and with understanding of the way automatic tagging works, since if this is incorrectly applied, the bits on the line will change.
If AUTOMATIC TAGS is not applied to existing modules as described in f) above, it will normally be desirable not to add new type definitions to the existing module, but rather to create a new module (with automatic tagging) for new type definitions. This makes it possible for the benefits of automatic tagging to be enjoyed without affecting the bits on the line.
Attention should be given to fields that contain character strings to see whether the CHARACTER STRING, BMPString, or UniversalString, or UTF8String notation should be employed. This would normally, however, change the bits on the line, and would be done as part of a version change.
The identifiers mantissa, base, and exponent need to be added to any real value notation that uses the "NumericRealValue" alternative of the "RealValue" production. Consideration should be given to restricting base to 2 or 10 in the type notation.

In general, there can be significant improvements in readability, efficiency, precision, and flexibility by use of the new ASN.1 notation (particularly if full advantage is taken of the use of table and component relation constraints and parameterization, and of the new character string types). All users of ASN.1:1988/1990 are urged to undertake migration whenever a Specification is revised, or as a separate activity if no revision is expected for some time.
It is generally regarded as a mistake to make additions to existing modules using notation which does not conform to the current ASN.1 specification, even if references to the ASN.1:1988/1990 specifications are retained for such modules. In particular, new uses of macros and ANY or ANY DEFINED BY, or new SET, SEQUENCE, or CHOICE constructs without unambiguous identifiers should be avoided.

Annex E: Superseded features

A number of features which were included in CCITT Rec. X.208 have been replaced and do not now form a part of ASN.1. They may, however, be encountered in some existing ASN.1 modules. This annex describes these features, and how their capabilities can be achieved by the use of those which replace them.

E.1 Use of identifiers now mandatory

The notation for a NamedType and a NamedValue were defined in CCITT Rec.208 as:

NamedType ::= identifier Type | Type | SelectionType NamedValue ::= identifier Value | Value

but this has been changed to:

NamedType ::= identifier Type NamedValue ::= identifier Value
because the former could result in ambiguous grammar.

Identifiers can be added to "NamedType"s in old ASN.1:1988/1990 specifications without affecting the encoding of the type (although changes to the ASN.1 will be needed for any use of related value notation).

E.2 The CHOICE value

The value notation for the choice type was defined in CCITT Rec. X.208 as:

ChoiceValue ::= NamedValue NamedValue ::= identifier Value | Value

but this has been changed to:

ChoiceValue ::= identifier ":" Value

because the former could result in ambiguous grammar.

E.3 The ANY type

The ANY type was defined in CCITT Rec. X.208.
The normal use of the ANY type was to leave a "hole" in the specification which would be filled in by some other specification. The notation was "AnyType", allowed as an alternative for "Type", and specified as:

AnyType ::= ANY | ANY DEFINED BY identifier

It was strongly recommended that the second alternative of the notation be used. In this alternative, only allowed where the ANY type was one of the component types of a set or sequence type, some other component of the set or sequence (that with the referenced "identifier") would indicate, by its integer or object identifier value (or a choice of these), the actual type governing the any component. The mapping from such values to particular ASN.1 types could be viewed as some sort of "table" which would form part of the abstract syntax. In the absence of the "DEFINED BY identifier" (the first notational alternative), there would be no indication within the notation of how the type of the field could be determined. This frequently led to specifications where the "hole" continued to exist even at the stage where implementations were expected.
The ANY type has now been superseded by the ability to specify information object classes and then to refer to the fields of information object classes from within type definitions (see ITU-T Rec. X.681 | ISO/IEC 8824-2). Since fields may be defined to allow an arbitrary ASN.1 type, the basic ability to leave "holes" is provided. However, the new feature also permits the specification of a "table constraint", wherein a particular "information object set" (a set of information objects of the appropriate information object class) is explicitly cited as constraining the type. This latter capability encompasses that offered by "ANY DEFINED BY identifier".
In addition, some pre-defined uses of the new capabilities are provided (see ITU-T Rec. X.681 | ISO/IEC 8824-2), which correspond to various commonly occurring patterns of use of the any type. For example, a sequence containing an object identifier and an any, often used previously to convey some arbitrary value together with an indication of its type, can now be described as:

INSTANCE OF MUMBLE

where "MUMBLE" is defined as an information object class (not as an ASN.1 type):

MUMBLE ::= TYPE-IDENTIFIER

This notation causes "INSTANCE OF MUMBLE" to be replaced by an object identifier for an object of class MUMBLE, together with the type identified by the object identifier. See ITU-T Rec. X.681:2002 | ISO 8824-2 (2002), E.2.18 for an example.
Particular pairings of object identifier and type are defined as information objects of class MUMBLE, and, if required, particular sets of these can also be defined and used to constrain the INSTANCE OF construct so that only those objects in the set can appear.
The macro capability was often used as a semi-formal way of defining tables of information objects to govern an associated use of an any type, and is also superseded by the new capabilities.

E.4 The macro capability

The macro capability allowed the user of ASN.1 to extend the notation by defining macros.
The predominant usage of the macro capability was to define notation for specifying information objects. This capability has now been included in ASN.1 directly (see ITU-T Rec. X.681 | ISO/IEC 8824-2) without the need for the full generality (and attendant dangers) of user-defined notation.
Besides this, the only other usage for macros seems to be in defining expressions which must be supplied with some parameters before they are fully-defined ASN.1 types. This is now provided through the more general parameterization capability (see ITU-T Rec. X.683 | ISO/IEC 8824-4).