ETSI ETR 060 ed.2 (1995-09)

SLOVENSKI STANDARD
01-april-2005
Signalizacijski protokoli in komutacija (SPS) - Navodila za uporabo zapisa
abstraktne skladnje št. 1 (ASN.1) v telekomunikacijsko aplikacijskih protokolih
Signalling Protocols and Switching (SPS); Guidelines for using Abstract Syntax Notation
One (ASN.1) in telecommunication application protocols
Ta slovenski standard je istoveten z: ETR 060 Edition 2
ICS:
33.040.30 Komutacijski in signalizacijski Switching and signalling
sistem systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI ETR 060
TECHNICAL September 1995
REPORT Second Edition
Source: ETSI TC-SPS Reference: RTR/SPS-02015
ICS: 35.100.60
ASN.1
Key words:
Signalling Protocols and Switching (SPS);
Guidelines for using Abstract Syntax Notation One (ASN.1)
in telecommunication application protocols
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
F-06921 Sophia Antipolis CEDEX - FRANCE
Postal address:
650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Office address:
c=fr, a=atlas, p=etsi, s=secretariat - secretariat@etsi.fr
X.400: Internet:
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1995. All rights reserved.
New presentation - see History box

Page 2
ETR 060: September 1995
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Standards Approval Dept." at the address shown on the title page.

Page 3
ETR 060: September 1995
Contents
Foreword .5
1 Scope .7
2 References.8
3 Abbreviations.9
4 Overview of ASN.1 .9
5 Specification of protocol data units.10
5.1 Modules .10
5.2 Tagging.11
5.3 Handling of optional and default elements.12
5.4 Subtyping .13
5.5 Importing and exporting data types.14
5.5.1 Exporting .14
5.5.2 Importing .14
5.6 Comments and user-defined constraints.15
5.7 Information elements dependencies.17
5.8 Miscellaneous .17
5.8.1 Elements and types.17
5.8.2 Order of elements .18
5.8.3 Specification of nested structures .19
5.8.4 Enumerated types .19
5.8.5 Specification of operations and errors.20
6 Leaving holes in specifications.20
6.1 General aspects.20
6.2 Embedding information.20
6.3 Defining generic types .22
7 Protocol modifications .23
7.1 Changes to abstract-syntaxes descriptions .23
7.1.1 Non compatible changes.23
7.1.2 Changes without impact on the abstract-syntax.24
7.1.3 Extension of an abstract syntax .24
7.1.4 Private extensions .26
7.2 Impact on the transfer-syntax .26
7.2.1 Non compatible changes.26
7.2.2 Changes without impact on transfer-syntaxes .26
7.2.3 Extension of a transfer-syntax.27
8 Compatibility issues.27
8.1 Backward compatibility .27
8.2 Forward compatibility .28
9 Changing names of information objects.29
9.1 Module names .29
9.2 Abstract syntax names .30
9.3 Application context names.30
Annex A: Migration from 1988/1990 notation to 1994 notation .31
Annex B: Specific guidance for users of the 1988/1990 notation.32

Page 4
ETR 060: September 1995
B.1 Use of identifiers. 32
B.2 Choice and Any values . 32
B.3 Tagging. 33
B.4 Operations and Errors . 36
History. 38

Page 5
ETR 060: September 1995
Foreword
This ETSI Technical Report (ETR) has been produced by the Signalling Protocols and Switching (SPS)
Technical Committee of the European Telecommunications Standards Institute (ETSI).
ETRs are informative documents resulting from ETSI studies which are not appropriate for European
Telecommunication Standard (ETS) or Interim European Telecommunication Standard (I-ETS) status. An
ETR may be used to publish material which is either of an informative nature, relating to the use or the
application of ETSs or I-ETSs, or which is immature and not yet suitable for formal adoption as an ETS or
an I-ETS.
This second edition of ETR 060 takes into account the further evolution of ASN.1 since the publication of
the first edition in 1992.
Page 6
ETR 060: September 1995
Blank page
Page 7
ETR 060: September 1995
1 Scope
The purpose of this ETSI Technical Report (ETR) is to provide guidelines on the use of Abstract Syntax
Notation One (ASN.1) for specifying telecommunication application protocols.
This ETR is based on ITU-T Recommendations X.680 [1], X.681 [2], X.682 [3] and X.683 [4] which specify
the Abstract Syntax Notation One (ASN.1). In case of misalignment, these Recommendations shall be
considered as the primary reference.
Unless explicitly indicated, all references to encoding and decoding functions assume the use of the Basic
Encoding Rules (BER) or any of their variants as they are specified in ITU-T Recommendation X.690 [5] .
This ETR is not a tutorial on ASN.1. Tutorial matter exists on this subject, e.g. "A tutorial on Abstract
Syntax Notation One" [17], "ASN.1 MACRO Facility" [18], "ASN.1 and ROS" [19], "An overview of
ASN.1" [20]. More specific tutorial information on the latest extensions to ASN.1 can be found in "An
introduction to the ASN.1 MACRO replacement notation" [21] and "Efficient encoding rules for ASN.1-
based protocols" [22].
Annex F of ITU-T Recommendation X.680 [1] also provides a set of general guidelines for use of the
notation.
Throughout this ETR, the term "user" denotes a person who employs ASN.1 for protocol design. The term
1988/90 notation is used to refer to that ASN.1 notation specified in CCITT Recommendation X.208
(1988) | ISO/IEC 8824:1990 [9]. The term current notation is used to refer to that specified in ITU-T
Recommendation X.680 [1].
Unless explicitly stated, all the guidelines contained in the body of this ETR are also applicable to users of
the 1988/90 notation.
Annex A provides guidance for the migration from the 1988/90 notation to the current notation.
Annex B provides specific guidance which only applies to superseded features of the 1988/90 notation.
Terms between quotation marks refer directly to items or productions defined by the ASN.1 standard (e.g.
"typereference", "Symbol").
The main objectives of the recommendations made in this ETR are:
a) allow the re-use of data types from one domain to another;
b) ease protocol evolution, taking into account compatibility issues;
c) ease the maintainability of the specifications;
d) ease automated implementation of encoding and decoding functions;
e) ease the production of test specifications, especially when specified using the Tree and Tabular
Combined Notation (see ITU-T Recommendation X.292 [11]) which makes a direct use of the
ASN.1 type definitions of the protocol to be tested.

ITU-T Recommendation X.690 supersedes CCITT Recommendation X.209 [10].

Page 8
ETR 060: September 1995
2 References
This ETR incorporates by dated and undated reference, provisions from other publications. These
references are cited at the appropriate places in the text and the publications are listed hereafter. For
dated references, subsequent amendments to or revisions of any of these publications apply to this ETR
only when incorporated in it by amendment or revision. For undated references the latest edition of the
publication referred to applies.
[1] ITU-T Recommendation X.680 (1994): "Specification of abstract syntax notation
one (ASN.1): Specification of the basic notation" (also published as
ISO/IEC 8824-1).
[2] ITU-T Recommendation X.681 (1994): "Abstract Syntax Notation One (ASN.1):
Information Object Specification" (also published as ISO/IEC 8824-2).
[3] ITU-T Recommendation X.682 (1994): "Abstract Syntax Notation One (ASN.1):
Constraint Specification" (also published as ISO/IEC 8824-3).
[4] ITU-T Recommendation X.683 (1994): "Abstract Syntax Notation One (ASN.1):
Parameterisation of ASN.1 specifications" (also published as ISO/IEC 8824-4).
[5] ITU-T Recommendation X.690 (1994): "Specification of ASN.1 encoding rules:
basic encoding rules" (also published as ISO/IEC 8825-1).
[6] ITU-T Recommendation X.691 (1994): "Abstract Syntax Notation One (ASN.1):
Packed Encoding Rules" (also published as ISO/IEC 8825-2).
[7] ITU-T Recommendation X.680 (1994): "Specification of abstract syntax notation
one (ASN.1): Specification of the basic notation - Amendment 1: Rules for
extensibility".
[8] ITU-T Recommendation X.681 (1994): "Abstract Syntax Notation One (ASN.1):
Information Object Specification - Amendment 1: Rules for extensibility".
[9] CCITT Recommendation X.208 (1988): "Specification of abstract syntax
notation one (ASN.1)" (also published as ISO/IEC 8824:1990).
[10] CCITT Recommendation X.209 (1988): "Specification of basic encoding rules
for abstract syntax notation one (ASN.1)".
[11] ITU-T Recommendation X.292 (1993): "OSI Conformance Testing Methodology
and Framework: Tree and Tabular Combined Notation (TTCN)" (also published
as ISO/IEC 9646-3).
[12] CCITT Recommendation X.219 (1988): "Remote operations; model, notation
and service definition".
[13] ITU-T Recommendations Q.771 to Q.775 (1993): "Specifications of Signalling
System No 7: Transaction Capabilities (TC)".
[14] CCITT Recommendations Q.771 to Q.775 (1988): "Specifications of Signalling
System No. 7, Transaction Capabilities Application Part (TCAP)".
[15] ETS 300 351 (1994): "ETSI object identifier tree; Rules and registration
procedures".
[16] ITU-T Recommendation X.880 (1995): "Remote Operations: concepts, model
and notation".
[17] "A tutorial on Abstract Syntax Notation One" - David Chappel, Cray Research
Inc. - OMNICOM Open System Data Transfer, Trans #25, December 1986.

Page 9
ETR 060: September 1995
[18] "ASN.1 MACRO Facility" - Jim Reinstedler, Ungermann-Bass Inc. - OMNICOM
Open System Data Transfer, Trans #33, April 1988.
[19] "ASN.1 and ROS: The impact of X400 on OSI" - James E. White - IEEE Journal
on Selected Areas In Communications, Vol.7, No.7 - September 1989.
[20] "An overview of ASN.1" - Gerald Neufeld, Son Vuang - Computers and ISDN
Systems - No.23 (1992).
[21] "An introduction to the ASN.1 MACRO replacement notation" - Nilo Mitra - AT&T
Technical Journal - Vol.73 - No.3 - May/June 1994.
[22] "Efficient encoding rules for ASN.1-based protocols"- Nilo Mitra - AT&T
Technical Journal - Vol.73 - No.3 - May/June 1994.
3 Abbreviations
For the purposes of this ETR, the following abbreviations apply
AC Application Context
APDU Application Protocol Data Unit
ASE Application Service Element
ASN.1 Abstract Syntax Notation One
BER Basic Encoding Rules
DSS1 Digital Subscriber Signalling Number one
MAP Mobile Application Part
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
PER Packed Encoding Rules
ROSE Remote Operation Service Element
SS7 Signalling System No.7
TC Transaction Capabilities
TTCN Tree and Tabular Combined Notation
4 Overview of ASN.1
Signalling messages are often described using a tabular notation; their format and binary representation is
specified using tables whose entries are the information elements from which they are built. This method
is rather convenient when the message structure is simple and when there is no need to consider different
encoding schemes to represent the same information.
The ITU-T Recommendations covering Signalling System No.7 (SS7) and Digital Subscriber Signalling
System No. one (DSS1), currently describe most of the Application Protocol Data Units (APDU) in this
manner (e.g. Telephone User Part messages, DSS1 "layer 3" messages, etc.). This is also the approach
taken in OSI to describe the protocol data units up to layer 5.
However, as far as the signalling information to be exchanged between telecommunication systems
becomes more and more complex, the limits of this tabular notation become clear; difficulties for
representing structured elements, duplication of definitions due to the mixture between the syntax of an
information and the way it is encoded, etc.
For the above reasons, it then becomes necessary to change the description technique of signalling
messages. This is achieved using the Abstract Syntax Notation One (ASN.1).
ASN.1 provides a means to describe data types as well as value of these types in an abstract manner. It
does this without determining the way instances of these data types are to be represented during
transmission.
Since a signalling message, as any protocol data unit, can be represented by a data type (generally a
structured one) ASN.1 fulfils very well the requirements for describing complex messages.

Page 10
ETR 060: September 1995
Beside the abstraction and the formalism of data descriptions, one of the objectives of ASN.1 is to
facilitate the encoding and decoding of values of the types defined using the notation. This is why, unlike
the data declaration portion of programming languages, it provides inherently a means for associating
identification tags with data types.
ITU-T Recommendation X.680 [1] specifies a number of simple and structured built-in types which allows
the user of the notation to define more complex types and associated data values by combining these
built-in types. In addition this notation also provides a set of subtype constructors (e.g. value range, size
constraint) to define types whose values are only a subset of the values of some other type (the parent
type).
Examples of simple built-in types are: boolean type, enumerated type, integer type, octet string type, while
examples of built-in structured types are: sequence type, set type, choice type, etc.
Beyond the specification of data units, the latest version of ASN.1 also provides tools for describing other
kind of information object classes, relationships between components of a PDU or other kind of
constraints, and for parameterizing a specification (see ITU-T Recommendations X.681 [2], X.682 [3],
X.683 [4]). Most of these features are intended to serve as a replacement for the MACRO notation and the
ANY type defined as part of the 1988/90 notation
Although the term "ASN.1" is still often used to refer both to this notation and the Basic Encoding Rules,
new Standards and Recommendations defining signalling protocols should made very clear that the two
aspects are distinct (i.e. other encoding rules may be applied to the defined abstract syntax).
While message description is mainly based on the ASN.1 type notation, the ASN.1 value notation is a
basis for some implementations and for specifying constraints for test cases written using the TTCN
notation (see ITU-T Recommendation X.292 [11]). It is therefore of high importance to define data types in
such a way that it is ensured that the resulting value notation is not ambiguous.
5 Specification of protocol data units
5.1 Modules
The following guidelines are appropriate when considering modules:
a) The set of ASN.1 productions which forms a protocol specification shall be organized into one or
several ASN.1 modules.
The criteria for organizing the modules are up to the protocol designer (functional domain, PDU
type, etc.). However for maintainability purposes, the number of inter-module dependencies (i.e.
number of modules seen from one module, number of symbols exported and imported) shall be
limited.
NOTE: The number of ASN.1 modules involved in the definition of data units of a particular
protocol is independent from the number of ASEs in terms of which this protocol is
structured. It has also no impact on the number of abstract syntaxes used to represent
instances of these data units.
b) Attention should be paid to avoid cross references between modules which make the parsing of
complete protocol data units unnecessarily more complex.
c) As stated in ITU-T Recommendation X.680 [1], each ASN.1 module should be given a module
identifier. This is used as a formal reference when exporting or importing definitions between
modules or when using external references.
This identifier shall be composed of a "modulereference" (i.e. a name starting with an upper case
letter) and optionally a value of type object identifier. Unlike an application-context-name or an
abstract-syntax-name, this value is never exchanged between peer protocol machines. However, it
is recommended that an object identifier value be always allocated to modules defined in ETSI
standards.
For further guidance on the use of object identifiers see "An overview of ASN.1" [20]. Rules for
assigning object identifier values within the scope of ETSI are described in ETS 300 351 [15].

Page 11
ETR 060: September 1995
d) It is suggested that modules defined for signalling applications be allocated a "modulereference" of
the following form:
-
e.g., MAP-Operations
Where identifies a set of related application layer signalling protocols (e.g. MAP)
and is a suitable acronym for the contents of this module (e.g. Operations,
CommonTypes, etc.).
5.2 Tagging
The following guidelines are appropriate when considering tagging:
a) the AUTOMATIC TAGS construct should always be used when defining a new module;
NOTE: The AUTOMATIC TAGS construct is not available to users of the 1988/90 notation.
EXAMPLE:
My-Module DEFINITIONS
AUTOMATIC TAGS
::=
BEGIN
My-Type ::= SEQUENCE {
a INTEGER,
b INTEGER OPTIONAL,
c BOOLEAN OPTIONAL
}
END
b) protocol designers which need to modify a module defined using the 1988/90 notation should follow
the guidelines provided in annex B. They should not add the AUTOMATIC TAGS construct in the
module header;
c) protocol designers should avoid to add new definitions in modules where the AUTOMATIC TAGS
construct was not used. They should preferably create a new module for that purpose;
d) the protocol designer shall be aware that automatic tagging places restrictions on the possible
modifications to a type definition when backward compatibility need to be ensured. In addition to
those provided in clause 7, users of automatic tagging shall apply the following rules:
- the order of elements in an existing set- or choice- type shall not be modified in a new version
of the specification;
- new elements in a set-, sequence- or choice- type shall be added after existing elements.

Page 12
ETR 060: September 1995
5.3 Handling of optional and default elements
When defining a structured type (set or sequence type) the protocol designer has to decide for each
"ComponentType" whether the presence of its value is mandatory or not when an instance of this type is
being used. ASN.1 provides two means to express that the value of a "ComponentType" can be omitted.
The following guidelines are appropriate when considering optional elements:
a) when the "ComponentType" corresponds to a genuine option and has a default value, the
DEFAULT keyword shall be used;
EXAMPLE 1:
DataUnit ::= SEQUENCE {
calledParty Address,
isdnSubscriber BOOLEAN DEFAULT FALSE
}
b) when the "ComponentType" corresponds to a genuine option and has no default value, the
OPTIONAL keyword shall be used;
EXAMPLE 2:
DataUnit ::= SEQUENCE {
calledParty Address,
callingParty Address OPTIONAL
}
c) it is not a good practice to use an OPTIONAL "ComponentType" to represent an information
element whose presence depends on the value of another element. A "TableConstraint" should
preferable be used (see also subclause 5.7).
NOTE: This facility is not available to users of the 1988/90 notation.
EXAMPLE 3: Define:
DataUnit ::= SEQUENCE {
calledParty Address,
supplServiceId SUPPLEMENTARY-SERVICE.&code,
supplServiceInfo SUPPLEMENTARY-SERVICE.¶meters
({SupplServiceSet}{@supplServiceId})
}
-- SUPPLEMENTARY-SERVICE is an information object class defined
-- elsewhere
-- SupplServiceSet is a set of object of this class.
rather than:
DataUnit ::= SEQUENCE {
calledParty Address,
supplServiceId SS-Code,
forwardedToNumber Address OPTIONAL,
-- present if SS-Code is 1
callBarringPassword Password OPTIONAL
-- present if SS-Code is 2
}
Page 13
ETR 060: September 1995
5.4 Subtyping
The following guidelines are appropriate when considering subtyping:
a) as a general rule, all types which appear in the specification of a PDU shall have their boundaries
formally specified. If this is not inherent to the type definition (e.g. a boolean type), this has to be
done using the subtyping mechanisms provided by the notation;
This concerns the integer types, octet string types, bit string types, character string types and all the
types derived from them. The maximum and minimum number of components in a sequence-of
type or set-of type shall also be specified.
b) if it is not possible to reach an agreement on a particular bound, it is recommended to define a
parameterized type, whose parameter is the unresolved bound. The actual bound will have to be
provided as part of national specifications or in the PICS. An exception specification should also be
added in order to provide a clear specification of the behaviour of an entity in case it receives a
value which does not conform to the actual implemented bound;
EXAMPLE 1:
UserData {INTEGER:up} ::= OCTET STRING ((SIZE(1.up)) !ErrorSpec:truncate)
RequestId {INTEGER:max) ::= INTEGER ((1.max) ! ErrorSpec: ignore )
ErrorSpec ::= ENUMERATED {
truncate (1),
ignore(2)
}
NOTE: This facility is not available to users of the 1988/90 notation.
c) when the same boundaries for value ranges or size constraints are used throughout several
subtype specifications or are subject to evolutions, it is recommended to assign a "valuereference"
to each of these values and to use them in the subtype definition;
EXAMPLE 2:
upperBound INTEGER ::= 20
TypeA ::= OCTET STRING (SIZE (1.upperBound))
TypeB ::= OCTET STRING (SIZE(5.upperBound))
d) note that if no lower bound is specified for a type derived from a set-of type or a sequence-type, this
means that a valid value for this type is an empty value. If this is semantically not acceptable, it is
worth to specify the type as follows:
TypeA ::= SEQUENCE SIZE (1.upperBound) OF BaseType.
e) use of inner subtyping is also encouraged to avoid duplications when there is a need to define a
structured type whose component list is a subset of the component list of an other type (mandatory
elements shall be common to both types).

Page 14
ETR 060: September 1995
EXAMPLE 3:
Address ::= SEQUENCE {
numberingPlan [0] NumberingPlan OPTIONAL,
natureOfAddress [1] NatureOfAddress OPTIONAL,
coding [2] Coding,
presentation [3] BOOLEAN,
screening [4] ScreeningIndicator,
addressSignal [5] DigitString
}
IsdnAddress ::= Address (WITH COMPONENTS {
...,
numberingPlan ABSENT,
natureOfAddress PRESENT
} )
5.5 Importing and exporting data types
5.5.1 Exporting
The following guidelines are appropriate when considering exporting of information elements:
a) any "Reference" (e.g. "typereference", "valuereference") which is used by several modules or is
foreseen to be of possible interest to other domains shall be included in the export list of the module
where they are defined;
b) if it is felt that all symbols can be exported, the EXPORTS keyword shall not appear in the module
definition. This is equivalent to exporting every "Symbol" defined in the module.
5.5.2 Importing
The following guidelines are appropriate when considering importing of information elements:
Explicit imports of a "typereference" or a "valuereference" shall be used rather than an
"externaltypereference" or a "externalvaluereference".
EXAMPLE: Define:
IMPORTS TypeA FROM Module-A;
TypeX ::= SEQUENCE {
element1 INTEGER,
element2 TypeA
}
rather than:
TypeX ::= SEQUENCE {
element1 INTEGER,
element2 Module-A.TypeA
}
Page 15
ETR 060: September 1995
5.6 Comments and user-defined constraints
When considering the use of ASN.1 comments and user-defined constraints the following guidelines are
appropriate:
NOTE 1: The notation for User-defined constraints is not available to users of the 1988/90
standard.
a) When there is a need to specify some constraints on the contents of an information element beyond
what can be expressed using ASN.1, the notation for user-defined constraint shall be preferred to
ordinary comments. The latter are best suited to covey explanatory information. This is illustrated by
the following example.
EXAMPLE 1: Define:
TBCD-STRING ::= OCTET STRING (CONSTRAINED BY {
-- two digits per octet, each digit encoded 0000 to 1001 (0 to 9),
-- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
-- as filler when there is an odd number of digits.
-- bits 8765 of octet n encoding digit 2n
-- bits 4321 of octet n encoding digit 2(n-1) +1 --
} )
-- This type (Telephony Binary Coded Decimal String) is used to
-- represent several digits from 0 through 9, *, #, a, b , c, .
rather than:
TBCD-STRING ::= OCTET STRING
-- This type (Telephony Binary Coded Decimal String) is used to
-- represent several digits from 0 through 9, *, #, a, b , c, two
-- digits per octet, each digit encoded 0000 to 1001 (0 to 9),
-- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
-- as filler when there is an odd number of digits.
-- bits 8765 of octet n encoding digit 2n
-- bits 4321 of octet n encoding digit 2(n-1) +1
NOTE 2: The above transformation can be made to existing specifications without any impact
on the encoding.
b) In case of protocols based on Remote Operations, the specification may indicate that some user
error (e.g., unexpectedDataValue) should be returned in case such constraints are violated. In such
a case, it is recommended that the user-defined constraint be followed by an exception
specification.
EXAMPLE 2:
Status ::= OCTET STRING (CONSTRAINED BY
{ -- bit 8-5: 0000 (unused) --
} !Error: unexpectedDataValue)
Error ::= ENUMERATED {unexpectedDataValue(0)}
NOTE 3: The addition of an exception specification to an existing definition does not have any
impact on the encoding.
Page 16
ETR 060: September 1995
c) When the constraint depends on the value of another information element the user defined
constraint should include a formal parameter.
EXAMPLE 3:
ExternalSignalInfo {ProtocolId} ::= SEQUENCE {
protocolId ProtocolId,
signalInfo OCTET STRING (CONSTRAINED BY {
-- contains the complete encoding according to protocol Id --
ProtocolId} )
}
NOTE 4: The above example only make sense if there is a need to maintain compatibility with
an existing specification. If a new protocol were to be defined, the semantic of the
above type is better provided trough the use of the EMBEDDED PDV type.
d) When it is expected that the user-defined constraint can be used to automatically invoke some
user-specific code for checking the constraint, it is recommended that it includes a reference to the
checking procedure to be invoked. This reference can be composed by a keyword (e.g.
EXTERNAL-CHECKING) followed by an object identifier which unambiguously identifies the
checking procedure.
EXAMPLE 4:
AddressString ::= OCTET STRING (CONSTRAINED BY {
-- EXTERNAL-CHECKING id-check-addressString -- } )
EXAMPLE 5: The following Information Object Class may be used by protocol designers to
document the specific checking procedures they define:
EXTERNAL-CHECKING ::= CLASS {
&ConstrainedType ,
&rules PrintableString,
&id OBJECT IDENTIFIER UNIQUE
}
WITH SYNTAX {
TYPE &ConstrainedType
CHECKING RULES &rules
IDENTIFIED BY &id
}
The user-defined constraint for checking that the contents of an octet string
contains an address formed by a numbering plan indicator followed by a series
of digits.
addressStringCheck EXTERNAL-CHECKING ::= {
TYPE OCTET STRING
CHECKING RULES "First octet encoded numbering plan according to
Rec Q.763 Subsequent octets encoded as
two digits per octet, each digit encoded 0000 to
1001 (0 to 9), 1010 (*), 1011 (#), 1100 (a), 1101 (b)
or 1110 (c); 1111 used as filler when there is an odd
number of digits.
bits 8765 of octet n encoding digit 2n
bits 4321 of octet n encoding digit 2(n-1) +1"
IDENTIFIED BY id-check-addressString
}
Page 17
ETR 060: September 1995
5.7 Information elements dependencies
A protocol designer commonly needs to specify that the type of an information element depends on the
value of another information element (classifier). The following guidelines are appropriate when
considering the specification of dependencies between information elements:
NOTE: These guidelines are not appropriate to users of the 1988/90 notation which have to
specify such dependencies using ordinary comments or a combination of the MACRO
notation and the ANY DEFINED BY type.
a) The related information elements should be modelled as fields of an Information Object Class.
Instances of that class shall then be defined to associate a particular value of the classifier element
with the appropriate types for the other elements. This is illustrated by the following example.
EXAMPLE 1:
SUPPLEMENTARY-SERVICE ::= CLASS {
&Subscription ,
&Registration OPTIONAL ,
&code INTEGER UNIQUE
}
WITH SYNTAX {
SUBSCRIPTION INFO &Subscription
[REGISTRATION INFO &Registration]
IDENTIFIED BY &code
}
CallForwarding SUPPLEMENTARY-SERVICE ::= {
SUBSCRIPTION INFO ForwardingOptions
REGISTRATION INFO ForwardedToNumber
IDENTIFIED BY 1
}
b) The PDU which carries the related information elements shall be specified using the notation for
component relation constraints, as illustrated below.
EXAMPLE 2:
SupplServiceInfo ::= SEQUENCE {
id SUPPLEMENTARY-SERVICE.&code,
subscriptionInfo SUPPLEMENTARY-SERVICE.&suscription
({SupplServiceSet} {@id}),
registrationInfo SUPPLEMENTARY-SERVICE.®istration
({SupplServiceSet} {@id}) OPTIONAL
}
-- SupplServiceSet represents the set of supported objects of class
-- "SUPPLEMENTARY-SERVICE"
5.8 Miscellaneous
5.8.1 Elements and types
The following guidelines are appropriate when considering instances versus types:
An application deals with a great number of parameters some of them being mapped to a protocol
information element by the protocol machines. However there is no need to define a distinct data type for
each of these information elements. When two information elements are syntactically equivalent they shall
be represented as occurrences of the same data type, or if required for decoding, as occurrences of two

Page 18
ETR 060: September 1995
isomorphic types derived from the same base type by context-specific tagging. The base type shall be
defined only in one place.
EXAMPLE: Define:
Address ::= -- some suitable definition
Message ::= SEQUENCE {
calledNumber Address,
callingNumber Address,
time Time
}
rather than:
Message ::= SEQUENCE {
calledNumber CalledNumber,
callingNumber CallingNumber,
time Time
}
CalledNumber ::= -- A suitable definition
CallingNumber ::= -- The same definition
5.8.2 Order of elements
The following guidelines are appropriate when considering the order of information elements:
The order of elements when defining a type derived from the sequence type or the set type is up to the
protocol designer. However, when possible (i.e. if there is no special need for an other logical order), it is
recommended to group all the mandatory elements at the beginning of the construct.
This may allow an optimized coding of constructed data values when other encoding rules than the Basic
Encoding Rules (e.g. Packed Encoding Rules (PER), see ITU-T Recommendation X.691 [6]) are used.
EXAMPLE: Define:
Example ::= SEQUENCE {
element1 Type1,
element2 Type2,
element3 Type3,
element4 Type4 OPTIONAL,
element5 Type5 OPTIONAL
}
rather than:
Example ::= SEQUENCE {
element1 Type1,
element2 Type2,
element4 Type4 OPTIONAL,
element3 Type3,
element5 Type5 OPTIONAL
}
Page 19
ETR 060: September 1995
5.8.3 Specification of nested structures
The following guidelines are appropriate when considering the specification of nested structures:
When defining a type derived from a sequence type, a set type or a choice type, the protocol designer
should avoid to expand the definition of the component type in the definition of the structured type where
the component appears.
EXAMPLE: Define:
DataUnit ::= SEQUENCE {
element1 INTEGER,
element2 TypeA OPTIONAL
}
TypeA ::= SEQUENCE {
u1 [0] IMPLICIT INTEGER,
u2 [1] IMPLICIT INTEGER
}
rather than:
DataUnit ::= SEQUENCE {
element1 INTEGER,
element2 SEQUENCE {
u1 [0] IMPLICIT INTEGER,
u2 [1] IMPLICIT INTEGER} OPTIONAL
}
5.8.4 Enumerated types
It is recommended that each "EnumerationItem" be an "identifier" rather than a "NamedNumber".
EXAMPLE: Define:
Type-A ::= ENUMERATED {
item1,
item2,
item3,
item4
}
rather than:
Type-A ::= ENUMERATED {
item1 (0),
item2 (1),
item3 (2),
item4 (3)
}
Page 20
ETR 060: September 1995
5.8.5 Specification of operations and errors
Existing signalling protocols based on TC or ROSE have been defined in terms of Operations and Errors,
using the ASN.1 MACROs provided in ITU-T Recommendation Q.773 [13] and CCITT Recommendation
X.219 [12].
Since the MACRO notation does not belong to the current notation, it is strongly recommended that
Operations and Errors specified for new protocols be defined as instances of the Information Object
Classes contained in ITU-T Recommendation X.880 [16]. Guidance for migrating from the MACRO
notation to its replacement is provided in annex C of ITU-T Recommendation X.880 [16].
It should also be noticed that the new notation provides a formal way to specify whether an operation
argument (or a result parameter, or an error parameter) is optional or mandatory.
6 Leaving holes in specifications
6.1 General aspects
There exist a number of circumstances where there is a need to leave holes in the specification of a set of
protocol data units. This ETR identifies the following four main cases:
1) need to make provision for extension of the protocol;
2) need for embedding information from another protocol;
3) need to carry information whose syntax is not known to the designer of the main protocol (e.g.,
private extensions) and/or is expected to evolve independently from this main protocol;
4) need to define a generic PDU whose definition is expected to be refined in other specifications.
The first amendment to ITU-T Recommendation X.680 [7] and the first amendment to ITU-
Recommendation X.681 [8] provide a mean for supporting the first type of need. This is known as the
"ellipsis notation" and is further discussed in subclause 8.2.
As far as cases 2) and 3) are concerned, ASN.1 offers three possible notations:
- the EXTERNAL type;
- the EMBEDDED PDV type;
- the Instance-Of type.
NOTE 1: The last two alternatives are not available to users of the 1988/90 notation.
The use of parameterized types supports the last requirement (case 4)
NOTE 2: This facility is not available to users of the 1988/90 notation.
6.2 Embedding information
The following general guidelines are appropriate when considering the use of the above types:
a) the use of the EXTERNAL type is deprecated for the design of new protocols;
b) when the external information is related to a different protocol (i.e. embedding of one protocol into
another), it is recommended to use an EXTERNAL or EMBEDDED PDV type;
c) when the external information must be encoded using different rules than the embedding protocol, it
is necessary to use an EXTERNAL or EMBEDDED PDV type;
d) in all other situations the protocol designer shall prefer Instance-Of types which produce less
overhead than EMBEDDED PDV when their values are encoded using the Basic Encoding Rules.
The use of the Instance-Of type is illustrated below:

Page 21
ETR 060: September 1995
EXAMPLE 1: Given the following main definition:
SubscriberProfile ::= SEQUENCE {
directoryNumber IsdnAddressString,
category Category DEFAULT {ordinary},
supplementaryServices SET OF SupplementaryServiceInformation,
operatorSpecificServices SET OF OperatorSpecificService
}
OperatorSpecificService can be defined as an Instance-Of type as follows:
OperatorSpecificService ::= INSTANCE OF OPERATOR-SPECIFIC-SERVICE
OPERATOR-SPECIFIC-SERVICE ::= TYPE-IDENTIFIER
Which is equivalent to the following expanded definition:
OperatorSpecificService ::= [UNIVERSAL 8] IMPLICIT SEQUENCE {
type-id OPERATOR-SPECIFIC-SERVICE.&id
value OPERATOR-SPECIFIC-SERVICE.&Type ({@type-id})
}
Particular instances can be defined as follows:
JupiterFreephone OPERATOR-SPECIFIC-SERVICE ::= {
SpecificServiceInfo
IDENTIFIED BY { iso identified-organization jupiter-telecom (100)
supplementaryService (2) freephone (11)}
}
NOTE 1: The BER encoding of a value of an instance-of type is compatible with the BER
encoding of the equivalent value of an EXTERNAL type when the "Single-ASN1-type"
encoding option is used.
e) due to the absence of presentation layer in the current signalling environment, it is essential that no
presentation context information be used in external types and embedded-PDV types;
f) it is recommended that the following two subtypes be used by designers of signalling protocols in
place of the EXTERNAL and EMBEDDED PDV types;
NOTE 2: The following definitions are not available to users of the 1988/90 notation.
EXAMPLE 2:
SIG-EXTERNAL ::= EXTERNAL (WITH COMPONENTS {
...,
identification (WITH COMPONENTS {
...,
presentation-context-id ABSENT,
context-negociation ABSENT
} ) } )
SIG-EMBEDDED-PDV ::= EMBEDDED-PDV (WITH COMPONENTS {
...,
identification (WITH COMPONENTS {
...,
presentation-context-id ABSENT,
context-negociation ABSENT
} ) } )
Page 22
ETR 060: September 1995
g) a protocol designer who wants to make use of an external or embedded PDV type shall first define
an abstract syntax which encompasses all the data values which may be carried by this external or
embedded-PDV type. Then he shall assign a name (i.e. an object identifier value) to this abstract
syntax.
This name is used as the value of the "identification.syntaxes.abstract" element of the
"EmbeddedPdvValue" or of the "identification.syntax" element of the "ExternalValue".
NOTE 3: When an external type is used, the transfer-syntax associated with a particular
abstract-syntax is supposed to be agreed "a priori" between the peers. The embedded
PDV type allows an explicit identification of the transfer syntax.)
NOTE 4: This abstract syntax is independe
...