Introduction
This Recommendation | International Standard presents a standard notation for the definition of data types and values.
A data type (or type for short) is a category of information (for example, numeric, textual, still image or video
information). A data value (or value for short) is an instance of such a type. This Recommendation | International
Standard defines several basic types and their corresponding values, and rules for combining them into more complex
types and values.
In some protocol architectures, each message is specified as the binary value of a sequence of octets. However,
standards-writers need to define quite complex data types to carry their messages, without concern for their binary
representation. In order to specify these data types, they require a notation that does not necessarily determine the
representation of each value. ASN.1 is such a notation. This notation is supplemented by the specification of one or
more algorithms called encoding rules that determine the value of the octets that carry the application semantics
(called the transfer syntax). ITU-T Rec. X.690 | ISO/IEC 8825-1, ITU-T Rec. X.691 | ISO/IEC 8825-2 and ITU-T
Rec. X.693 | ISO/IEC 8825-4 specify three families of standardized encoding rules, called Basic Encoding Rules
(BER), Packed Encoding Rules (PER), and XML Encoding Rules (XER).
Some users wish to redefine their legacy protocols using ASN.1, but cannot use standardized encoding rules because
they need to retain their existing binary representations. Other users wish to have more complete control over the
exact layout of the bits on the wire (the transfer syntax). These requirements are addressed by ITU-T Rec. X.692 |
ISO/IEC@8825-3 which specifies an Encoding Control Notation (ECN) for ASN.1. ECN enables designers to formally
specify the abstract syntax of a protocol using ASN.1, but to then (if they so wish) take complete or partial control of
the bits on the wire by writing an accompanying ECN specification (which may reference standardized Encoding
Rules for some parts of the encoding).
A very general technique for defining a complicated type at the abstract level is to define a small number of simple
types by defining all possible values of the simple types, then combining these simple types in various ways. Some of
the ways of defining new types are as follows:
a) given an (ordered) list of existing types, a value can be formed as an (ordered) sequence of values, one
from each of the existing types; the collection of all possible values obtained in this way is a new type
(if the existing types in the list are all distinct, this mechanism can be extended to allow omission of
some values from the list);
b) given an unordered set of (distinct) existing types, a value can be formed as an (unordered) set of
values, one from each of the existing types; the collection of all possible unordered sets of values
obtained in this way is a new type (the mechanism can again be extended to allow omission of some
values);
c) given a single existing type, a value can be formed as an (ordered) list or (unordered) set of zero, one or
more values of the existing type; the collection of all possible lists or sets of values obtained in this way
is a new type;
d) given a list of (distinct) types, a value can be chosen from any one of them; the set of all possible values
obtained in this way is a new type;
e) given a type, a new type can be formed as a subset of it by using some structure or order relationship
among the values.
An important aspect of combining types in this way is that encoding rules should recognize the combining constructs,
providing unambiguous encodings of the collection of values of the basic types. Thus, every basic type defined using
the notation specified in this Recommendation | International Standard is assigned a tag to aid in the unambiguous
encoding of values.
Tags are mainly intended for machine use, and are not essential for the human notation defined in this
Recommendation | International Standard. Where, however, it is necessary to require that certain types be distinct, this
is expressed by requiring that they have distinct tags. The allocation of tags is therefore an important part of the use of
this notation, but (since 1994) it is possible to specify the automatic allocation of tags.
NOTE 1 – Within this Recommendation | International Standard, tag values are assigned to all simple types and construction
mechanisms. The restrictions placed on the use of the notation ensure that tags can be used in transfer for unambiguous
identification of values.
An ASN.1 specification will initially be produced with a set of fully defined ASN.1 types. At a later stage, however, it
may be necessary to change those types (usually by the addition of extra components in a sequence or set type). If this
is to be possible in such a way that implementations using the old type definitions can interwork with implementations
using the new type definitions in a defined way, encoding rules need to provide appropriate support. The ASN.1
notation supports the inclusion of an extension marker on a number of types. This signals to encoding rules the
iv ITU-T Rec. X.680 (07/2002)
我的内容管理
收起
我的收益 登录查看自己的收益
我的积分
登录查看自己的积分
我的C币
登录后查看C币余额
我的收藏 
我的下载 
下载帮助 
