| 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.
|
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
there 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.
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:
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).
|
|
|
