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

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

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.

​

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

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.

​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).