INTERNATIONAL TELECOMMUNICATION UNION

ITU-T
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU

X.680
(07/2002)

SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI networking and system aspects – Abstract Syntax Notation One (ASN.1)

Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation

ITU-T Recommendation X.680

ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS PUBLIC DATA NETWORKS Services and facilities Interfaces Transmission, signalling and switching Network aspects Maintenance Administrative arrangements OPEN SYSTEMS INTERCONNECTION Model and notation Service definitions Connection-mode protocol specifications Connectionless-mode protocol specifications PICS proformas Protocol Identification Security Protocols Layer Managed Objects Conformance testing INTERWORKING BETWEEN NETWORKS General Satellite data transmission systems IP-based networks MESSAGE HANDLING SYSTEMS DIRECTORY OSI NETWORKING AND SYSTEM ASPECTS Networking Efficiency Quality of service Naming, Addressing and Registration Abstract Syntax Notation One (ASN.1) OSI MANAGEMENT Systems Management framework and architecture Management Communication Service and Protocol Structure of Management Information Management functions and ODMA functions SECURITY OSI APPLICATIONS Commitment, Concurrency and Recovery Transaction processing Remote operations OPEN DISTRIBUTED PROCESSING
For further details, please refer to the list of ITU-T Recommendations.

X.1–X.19 X.20–X.49 X.50–X.89 X.90–X.149 X.150–X.179 X.180–X.199 X.200–X.209 X.210–X.219 X.220–X.229 X.230–X.239 X.240–X.259 X.260–X.269 X.270–X.279 X.280–X.289 X.290–X.299 X.300–X.349 X.350–X.369 X.370–X.399 X.400–X.499 X.500–X.599 X.600–X.629 X.630–X.639 X.640–X.649 X.650–X.679 X.680–X.699 X.700–X.709 X.710–X.719 X.720–X.729 X.730–X.799 X.800–X.849 X.850–X.859 X.860–X.879 X.880–X.899 X.900–X.999

INTERNATIONAL STANDARD ISO/IEC 8824-1 ITU-T RECOMMENDATION X.680

Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation

Summary
This Recommendation | International Standard provides a notation called Abstract Syntax Notation One (ASN.1) for defining the syntax of information data. It defines a number of simple data types and specifies a notation for referencing these types and for specifying values of these types. The ASN.1 notations can be applied whenever it is necessary to define the abstract syntax of information without constraining in any way how the information is encoded for transmission.

Source
ITU-T Recommendation X.680 was prepared by ITU-T Study Group 17 (2001-2004) and approved on 14 July 2002. An identical text is also published as ISO/IEC 8824-1.

ITU-T Rec. X.680 (07/2002)

i

The World Telecommunication Standardization Assembly (WTSA). produce Recommendations on these topics. ITU [had/had not] received notice of intellectual property. X. by any means whatsoever. the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.680 (07/2002) . The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. ii ITU-T Rec. the necessary standards are prepared on a collaborative basis with ISO and IEC. implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. NOTE In this Recommendation. However. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. which may be required to implement this Recommendation. establishes the topics for study by the ITU-T study groups which. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. which meets every four years.FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. In some areas of information technology which fall within ITU-T's purview. ITU-T is responsible for studying technical. in turn. As of the date of approval of this Recommendation. protected by patents. No part of this publication may be reproduced. ITU takes no position concerning the evidence. operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. whether asserted by ITU members or others outside of the Recommendation development process. validity or applicability of claimed Intellectual Property Rights. without the prior written permission of ITU.  ITU 2003 All rights reserved.

............................... 5.......12 Hexadecimal strings ..........................................9 References to a lexical item ..................... 5............ 5............................................................ 11..................6 Comments ............................ ASN............ 11................................ The ASN..............................11 XML binary string item ........................................................................................................1 character set...........................................................................................................1 General rules ...............................4 Value references.............................................. 1 2 Scope .....................................................................................4 Non-spacing indicator ........................................................................................ 3...........1 model of type extension .................. Normative references .................................1 Identical Recommendations | International Standards .................................................................................................................................................................................................................................................................. The ASN................................. 5...................................................... 5.......................................................................................................................4 Structure for identification of organizations............................................................3 Parameterization of ASN...................................................................................... Definitions............................................................................. 11..........CONTENTS Page Introduction ............................................................... 2..8 References to permitted sequences of lexical items ..................................................... 5...............................................................5 Module references............................................................. 11.......15 XML character string item ...17 Range separator................................11 Value references and the typing of values......... 5.................................................................................................................................. vii 1 1 1 2 2 2 2 2 3 3 3 7 8 8 8 8 9 9 9 9 9 9 9 10 10 11 12 12 13 14 14 14 15 15 15 15 15 15 16 16 16 16 16 17 17 19 19 19 3 4 5 6 7 8 9 10 11 ITU-T Rec.................................................................................................................................3 Identifiers ....................................... 5........................................................................16 Assignment lexical item ................................................................................................................................................2 Productions.... 3...........14 Character strings..................... Use of the ASN.......................................................................................................8 Numbers ..................................................................................................................................................................... 2........................1 notation...................................................................................................................................................................................................... 11............................................................................................................................. 5.. 11................................. X............................................................................................................... Extensibility requirements on encoding rules....................................... 11...............................................................................................................................................................18 Ellipsis .......................................................................................................... 11....................................................................... 11..................................................5 Universal Multiple-Octet Coded Character Set (UCS) .........................................................10 Short-hand notations ..............................................................................9 Real numbers........7 Empty lexical item . 11......................680 (07/2002) iii ........................................................................................................... Notation....1 Information object specification........... 11...........6 Additional definitions.................................................. Tags ....... 11....................................................................................................................................................................................10 Binary strings ................................................................................................................2 Type references ........................................2 Additional references ..................................................................... 3...............................................................................7 Recursion ............................................................................................................5 Example of a production .......................................................................................... 11........................ 3........................ Abbreviations ...................................... 3..................................................................................................................... 3............................................................................................................ 11........................................................6 Layout ..............................................................1 lexical items....................................................................................................... 5................................................................................................................................................................................................................................................................................................................................................................................................................. 11..............................................................................................1 specification ..... 11..................................... 11.....................................13 XML hexadecimal string item......................................................................................................... 5................................................2 Constraint specification..................................................................................................................................1 General ...................................... 11......................................................................................................3 The alternative collections ................................

............................ XML single tag end item................ Notation for the enumerated type .............................................. Notation for selection types.....................................19 11.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................25 11........................................................................................................................................................................................................................................................ The character string types.......................................................................................................................................................................... Assigning types and values ...... Notation for the integer type..... Naming characters and collections defined in ISO/IEC 10646-1........................................................................................................................................................... Notation for the object identifier type ...................................................................................................................... X................................... Constrained Types.............. Element set specification................................................................................................... Notation for sequence-of types............................................................................................ 47.............................................................................................................................................. Reserved words ...................................... Notation to support references to ASN............................................................ Right version brackets.............................. Definition of restricted character string types ...........................................................................................11........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ Notation for the real type....................1 General ........................................ Notation for character string types ...................... iv ITU-T Rec.....................................21 11.................... Notation for tagged types .........22 11............................................................. Referencing type and value definitions ......................680 (07/2002) ................................................................................................................................................. XML end tag start item ............................ Notation for the octetstring type.................................................................................................................................. XML boolean true item ......................................................................................................3 Contained Subtype ..............................................................................................................................................................................................................................................20 11..................................................................................................... Notation for the external type............ XML tag names for ASN....................................................................................................................................24 11....................................... Canonical order of characters ..................................................................................................................... Single character lexical items..........................................................26 11................. 19 19 19 20 20 20 20 21 22 22 26 27 28 30 32 33 34 35 36 37 38 38 42 44 45 45 47 48 49 50 51 53 54 55 55 59 62 62 64 64 65 65 66 67 69 69 70 70 Module definition ............................................................................................................................................................................................................................................................. Notation for types defined in clauses 42 to 44 ............................................. Notation for sequence types ........................ Notation for choice types....2 Single Value................................... Notation for the null type .................................................................1 components ..................................................................................................................................................................................................... Notation for the bitstring type .................................................................................................................. 47....................................................................................................................................... Definition of types and values .................................................................................................................................................................................................................................................... The object descriptor type ......... Subtype elements................................. Generalized time...........................23 11............................................................ Definition of unrestricted character string types ........................................................ Notation for the boolean type ....................................... Notation for set-of types.............................. Notation for set types ..................................................................................................................27 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 Left version brackets .......................................................................................... Notation for the embedded-pdv type ............................ Notation for the relative object identifier type ..............................................................................................................................................................1 types.. XML boolean false item........................................ Universal time ........................................................................................................................ 47..................................................

.. E..............................................................7 Examples........................................... F...................................................................................................................................................... E................................. F......................................................47.......................................8 47........................................................................ BMPString and UTF8String .................. B....5 Additional value mappings defined for the character string types ..........................................................................................................................9 48 49 Value Range.......................................3 On ISO/IEC 10646-1 conformance requirements ............14 Selection type.....................1 regular expressions .........2 Value mappings...1 character strings .. E..................2..................................................................... C................................... Permitted Alphabet..........................................................................................2...................................1 Informal description of Personnel Record...........1 Example of a personnel record........................................................................... E............................................ E................................................4 Subtypes .6 Octet string................................................................................................................................................................................................ E..........................11 Set and set-of.. B................... Size Constraint ........7 47...........................1 users on ISO/IEC 10646-1 conformance................................................................................................................ Annex B – Rules for Type and Value Compatibility.................................... Type Constraint...................................................................................................................................................4 Real .......... E........2.........3 Identical type definitions........1 and encoding rules standards .. Annex C – Assigned object identifier values.................2 ASN.................................................................................................5 47..............................................................18 Instance-of........ E.....................................................2. UTF8String and BMPString types..................................................1........... 71 71 72 72 72 73 73 75 77 77 77 80 80 82 83 85 85 86 87 89 89 89 91 91 91 92 92 93 93 93 93 94 95 95 95 96 97 98 99 100 102 104 105 107 108 108 108 109 109 110 113 113 113 114 114 115 The extension marker ..............................2...............................................................................................................................................................................................................................................................................7 UniversalString.........................................................................................................1 Definition ................................................................................. B....................................1 Root assignment of object identifier component values..16 Embedded-pdv ..................2............2 ITU-T assignment of object identifier component values ......................................13 Choice ...............................10 Sequence and sequence-of .........4 47.................. ITU-T Rec............................................................................2....................................................................... B..............................................................2..........................1 ....................................................................................................... E............. A........ D................................. Annex D – Assignment of object identifier component values ................. E.............6 Specific type and value compatibility requirements.............1 The need for the value mapping concept (Tutorial introduction).............. D.................................................................................................................................................................... E.........2....................................................................................................................................................1............... B............1 Character string support in ASN.........................2.......... E........................... E...................................................................................................................................2 Object identifiers in the ASN.. X...................................5 Bit string.................. C............ Inner Subtyping..................... D............ F.................................................680 (07/2002) v ...................3 Enumerated .....................................6 47................................................................ E..............................................2 Guidelines for use of the notation .......................................................4 Specification of value mappings .4 Joint assignment of object identifier component values..................................................................................... E..3 Identifying abstract syntaxes.................................................... F.2.............2......2...................................................... B......................................................... The exception identifier........................................................17 External .............................. E.......................................................................................... D......... E.........................................................2 The UniversalString..........................................................................................19 Relative Object Identifier .............................................................................. A.............................................................................................................................................................12 Tagged. E.................... E............................................... E.......................................................................................................................... B.......................................... E................................................................................................................................... Pattern constraint..... Annex F – Tutorial annex on ASN.....5 Adopted subsets as parameters of the abstract syntax...........................................................4 Recommendations for ASN.....................................................................................2.................1 description of the record structure.. Annex E – Examples and hints ....1 Object identifiers assigned in this Recommendation | International Standard ...........................................................................................................................................................................................................................2.....................1 Boolean .......... F....2 Metacharacters ...................................2................................................................................................................................................... Annex A – ASN.............................3 ISO assignment of object identifier component values ........................... E.......2 Integer ......

....680 (07/2002) ...................... G.....................................6 The CHARACTER STRING type ...4 Use of the Contained Subtype notation...1 Overview.......................................................1 model of type extension ......... G........................ Annex H – Summary of the ASN................................1 notation ....................................4............................... 115 116 116 117 118 118 118 118 119 120 121 Annex G – Tutorial annex on the ASN................................................................................................. G...................................2 Serial application of constraints ......................................... G....................................................4..................................................................................... G.....................................................................................................4....... G..............................................4 Combination of (possibly extensible) constraints .......... vi ITU-T Rec.......... G...........................................................................................3 Requirements on encoding rules ...............3 Use of set arithmetic.4..............................1 Model ...................................................................................................... G.....F...............................................................................................................2 Meaning of version numbers................ X............................

ECN enables designers to formally specify the abstract syntax of a protocol using ASN. however. given a type.. X.693 | ISO/IEC 8825-4 specify three families of standardized encoding rules. textual. The allocation of tags is therefore an important part of the use of this notation. encoding rules need to provide appropriate support. 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. This signals to encoding rules the intention of the designer that this type is one of a series of related types (i. X.1. 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). the set of all possible values obtained in this way is a new type. Thus. it may be necessary to change those types (usually by the addition of extra components in a sequence or set type). A data value (or value for short) is an instance of such a type. one or more values of the existing type.Introduction This Recommendation | International Standard presents a standard notation for the definition of data types and values. ITU-T Rec. Packed Encoding Rules (PER). A data type (or type for short) is a category of information (for example. An ASN. In order to specify these data types. NOTE 1 – Within this Recommendation | International Standard. this mechanism can be extended to allow omission of some values from the list). and XML Encoding Rules (XER).680 (07/2002) vii . However. providing unambiguous encodings of the collection of values of the basic types. This Recommendation | International Standard defines several basic types and their corresponding values. The restrictions placed on the use of the notation ensure that tags can be used in transfer for unambiguous identification of values. given a single existing type. the collection of all possible values obtained in this way is a new type (if the existing types in the list are all distinct.1 is such a notation. and are not essential for the human notation defined in this Recommendation | International Standard. Other users wish to have more complete control over the exact layout of the bits on the wire (the transfer syntax). but cannot use standardized encoding rules because they need to retain their existing binary representations.1 specification will initially be produced with a set of fully defined ASN. ITU-T Rec. a value can be formed as an (ordered) list or (unordered) set of zero. and that the encoding rules are required to enable information transfer between implementations using different types that are related by being part of the same extension series. standards-writers need to define quite complex data types to carry their messages. X. tag values are assigned to all simple types and construction mechanisms.1 notation supports the inclusion of an extension marker on a number of types. 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. 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). Some users wish to redefine their legacy protocols using ASN. numeric. it is necessary to require that certain types be distinct.692 | ISO/IEC 8825-3 which specifies an Encoding Control Notation (ECN) for ASN. they require a notation that does not necessarily determine the representation of each value. 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).1. The ASN. but (since 1994) it is possible to specify the automatic allocation of tags. without concern for their binary representation. one from each of the existing types. X. given an unordered set of (distinct) existing types. a new type can be formed as a subset of it by using some structure or order relationship among the values. given a list of (distinct) types. each message is specified as the binary value of a sequence of octets. the collection of all possible lists or sets of values obtained in this way is a new type. versions of the same initial type) called an extension series. a value can be formed as an (unordered) set of values. a value can be chosen from any one of them. These requirements are addressed by ITU-T Rec.691 | ISO/IEC 8825-2 and ITU-T Rec. Tags are mainly intended for machine use. At a later stage. still image or video information). In some protocol architectures. then combining these simple types in various ways. this is expressed by requiring that they have distinct tags. called Basic Encoding Rules (BER). and rules for combining them into more complex types and values. X. 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.1 types.e. ITU-T Rec. however. Where. ASN. b) c) d) e) An important aspect of combining types in this way is that encoding rules should recognize the combining constructs. a value can be formed as an (ordered) sequence of values. Some of the ways of defining new types are as follows: a) given an (ordered) list of existing types.1.690 | ISO/IEC 8825-1.

and specify the notation to be used for referencing simple types and for defining new types using them. and describes the top-level arcs of the registration tree for object identifiers. and provides a value notation using Extensible Markup Language (XML).1 notation.1 Value Notation. and specifies rules for type and value compatibility. and has been part of the ASN.1 types specified in a "version 1" specification to be identified as likely to be extended in "version 2". Annex A forms an integral part of this Recommendation | International Standard. Clauses 10 to 31 also specify notations to be used for specifying values of types defined using ASN. viii ITU-T Rec. Annex F does not form an integral part of this Recommendation | International Standard.1 regular expressions. X. and provides a tutorial on ASN. Two value notations are provided. but which require no additional encoding rules. Thus. and for additions made in subsequent versions to be separately listed and identified with their version number.1 value notation.1 series of Recommendations | International Standards.1 model of type extension. The second is called the XML ASN. and specifies ASN. Clause 49 defines a notation which allows ASN. NOTE 2 – The XML Value Notation provides a means of representing ASN.1 character strings. Clauses 35 to 40 (inclusive) define the character string types.1 type definition also specifies the structure and content of an XML element. an ASN. This makes ASN.1. and provides a tutorial on the ASN. Annex C forms an integral part of this Recommendation | International Standard. and provides a summary of ASN. Annex H does not form an integral part of this Recommendation | International Standard. Clauses 45 to 47 (inclusive) define a notation which enables subtypes to be defined from the values of a parent type.1 notation since its first introduction.680 (07/2002) .1 using the notation of clause 5. Annex B forms an integral part of this Recommendation | International Standard. Annex D does not form an integral part of this Recommendation | International Standard. Clauses 33 to 34 (inclusive) define the types supported by ASN. and provides examples and hints on the use of the ASN.1. The first is called the basic ASN. Clause 48 defines a notation which allows ASN.1 values using XML. Annex E does not form an integral part of this Recommendation | International Standard. and records object identifier and object descriptor values assigned in the ASN.1 type definitions to contain an indication of the intended error handling if encodings are received for values which lie outside those specified in the current standardized definition.1 types.1 for carrying within them the complete encoding of ASN. Clauses 41 to 44 (inclusive) define certain types which are considered to be of general utility.Clauses 10 to 31 (inclusive) define the simple types supported by ASN. Annex G does not form an integral part of this Recommendation | International Standard.1 a simple schema language for XML.

Members of IEC and ISO maintain registers of currently valid International Standards. ITU-T Recommendation X.1. and specifies a notation for referencing these types and for specifying values of these types.690 (2002) | ISO/IEC 8825-1:2002. values.1) that is used for the definition of data types. ITU-T Recommendation X. This Recommendation | International Standard: – – – defines a number of simple types. constitute provisions of this Recommendation | International Standard. Information technology – Abstract Syntax Notation One (ASN. through reference in this text. 2 Normative references The following Recommendations and International Standards contain provisions which. defines mechanisms for constructing new types from more basic types.1 encoding rules: Specification of Encoding Control Notation (ECN). Information technology – Abstract Syntax Notation One (ASN.1 notation is referenced by other standards which define encoding rules for the ASN.1): Specification of basic notation 1 Scope This Recommendation | International Standard provides a standard notation called Abstract Syntax Notation One (ASN.681 (2002) | ISO/IEC 8824-2:2002. the editions indicated were valid.1 types. Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). Information technology – ASN. Information technology – Open Systems Interconnection – Procedures for the operation of OSI Registration Authorities: General procedures: (plus amendments). X.660 (1992) | ISO/IEC 9834-1:1993. The ASN.680 (2002 E) ITU-T RECOMMENDATION Information technology – Abstract Syntax Notation One (ASN.692 (2002) | ISO/IEC 8825-3:2002. At the time of publication. ITU-T Recommendation X. and parties to agreements based on this Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent edition of the Recommendations and Standards listed below. with their tags. ITU-T Recommendation X.1): Information object specification. X. defines character sets (by reference to other Recommendations and/or International Standards) for use within ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER). Information technology – Abstract Syntax Notation One (ASN.682 (2002) | ISO/IEC 8824-3:2002. The ASN. 2.683 (2002) | ISO/IEC 8824-4:2002. and for specifying values of these types. All Recommendations and Standards are subject to revision.1 notation can be applied whenever it is necessary to define the abstract syntax of information.680 (07/2002) 1 – – – – – – . Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).1 Identical Recommendations | International Standards – CCITT Recommendation X. Information technology – ASN.1): Constraint specification.691 (2002) | ISO/IEC 8825-2:2002. and specifies a notation for defining such types and assigning them tags.1 specifications.1): Parameterization of ASN. The Telecommunication Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations. and constraints on data types.ISO/IEC 8824-1:2003 (E) INTERNATIONAL STANDARD ISO/IEC 8824-1 : 2002 (E) ITU-T Rec. ITU-T Rec. ITU-T Recommendation X. ITU-T Recommendation X.

Institut National de Recherche en Informatique et en Automatique. Extensible Markup Language (XML) 1. 3. W3C XML 1.2. Information technology – Character code structure and extension techniques.ISO/IEC 8824-1:2003 (E) – ITU-T Recommendation X. Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane.100 (1988). ISO/IEC 646:1991. ISO/IEC 10646-1:2000. X. Standard-frequency and time-signal emissions.org/TR/2000/REC-xml-20001006. NOTE 2 – The reference to a document within this Recommendation | International Standard does not give it.0:2000. X. Information technology – ASN. MA.693 (2001) | ISO/IEC 8825-4:2002.683 | ISO/IEC 8824-4: 2 ITU-T Rec. information object class. information object set.2 Constraint specification a) b) component relation constraint. This Recommendation | International Standard uses the following terms defined in ITU-T Rec.680 (07/2002) .1 Information object specification a) b) c) d) e) information object.3 Parameterization of ASN. (Massachusetts Institute of Technology.1 specification a) b) parameterized type. ISO/IEC 2022:1994. Information technology – Registration of repertoires of graphic characters from ISO/IEC 10367.0 (Second Edition). Data elements and interchange formats – Information interchange – Representation of dates and times. object class field type. Data interchange – Structures for the identification of organizations. W3C Recommendation. ITU-T Recommendation T. Addison-Wesley) NOTE 1 – The above reference is included because it provides names for control characters. X. ISO/IEC 7350:1991. parameterized value. This Recommendation | International Standard uses the following terms defined in ITU-T Rec. ISO 8601:2000. as a stand-alone document. http://www. instance-of type. CCITT Recommendation T. The Unicode Consortium. the status of a Recommendation or International Standard. Version 3. ISO International Register of Coded Character Sets to be used with Escape Sequences. the following definitions apply. This Recommendation | International Standard uses the following terms defined in ITU-T Rec.2 Additional references – – – – – – – – – – – – ITU-R Recommendation TF.101 (1994).460-5 (1997). 2. International information exchange for interactive videotex.0:2002. Keio University). International interworking for videotex services.1 encoding rules: XML Encoding Rules (XER). ISO/IEC 6523:1998.681 | ISO/IEC 8824-2: 3.682 | ISO/IEC 8824-3: 3. (Reading. table constraint.w3. Copyright © [6 October 2000] World Wide Web Consortium. The Unicode Standard. X. Information technology – ISO 7-bit coded character set for information interchange. 3 Definitions For the purposes of this Recommendation | International Standard.

682 | ISO/IEC 8824-3. This Recommendation | International Standard uses the following terms defined in ISO/IEC 6523: 3. independently of how it is represented in any encoding.3 3.9 character abstract syntax: Any abstract syntax whose values are specified as the set of character strings of zero.6. 3.4 3. one or more bits. plane.ISO/IEC 8824-1:2003 (E) 3.6. group. one or more characters from some specified collection of characters.6.5 Universal Multiple-Octet Coded Character Set (UCS) a) b) c) d) e) f) g) h) i) Basic Multilingual Plane (BMP).6 bitstring type: A simple type whose distinguished values are an ordered sequence of zero.1 data. associated type: A type which is used only for defining the value and subtype notation for a type.6. NOTE – The information will normally include some or all of the following items: a) a graphic symbol. the use of a bitstring (or an octetstring) type without a contents constraint (see ITU-T Rec.6.10 character repertoire: The characters in a character set without any implication on how such characters are encoded.1 specification: A collection of one or more ASN. c) the definition of functions associated with the character when used in particular environments. organization code. 3. Associated types do not appear in user specifications. 3. Otherwise. row.7 3. Additional definitions abstract character: An abstract value which is used for the organization. character property: The set of information associated with a cell in a table defining a character repertoire.6. the boolean type.2 abstract value: A value whose definition is based only on the type used to carry some semantics. the use of the embedded-pdv type (see clause 33) provides a more flexible mechanism. clause 11) is deprecated. a character string type. limited subset.6 3. 3. NOTE – Associated types are defined in this Recommendation | International Standard when it is necessary to make it clear that there may be a significant difference between how the type is defined in ASN.11 character string types: Simple types whose values are strings of characters from some defined character set.1 modules.680 (07/2002) 3 . combining character. specified in clause 10. used in the ASN.6. ASN. control or representation of textual NOTE – Annex F provides a more complete description of the term abstract character. d) whether it represents a digit.6. or of a type which is a sequence (or a choice) of an integer and a boolean. cell. NOTE – Where there is a need to carry embedded encodings of an abstract value. b) a character name. NOTE – Examples of abstract values are the values of the integer type.1 and how it is encoded. allowing the announcement of the abstract syntax and of the encoding of the abstract value that is embedded.1 character set: The set of characters.6. 3.6.6. X. graphic symbol.5 ASN.4 Structure for identification of organizations a) b) c) issuing organization.1 notation. X. e) an associated character differing only in (upper/lower) case.8 boolean type: A simple type with two distinguished values. selected subset. International Code Designator. 3. 3. ITU-T Rec. This Recommendation | International Standard uses the following terms defined in ISO/IEC 10646-1: 3.

This type can be used in an ASN. or that is extensible through the use of set arithmetic with extensible sets of values.6. 3. For a constraint it is the addition of (only) one subtype element. respectively. and. X. sequence or choice type grouped within version brackets. are not relevant.13 choice types: Types defined by referencing a list of distinct types.6. 3. DATA LINK ESCAPE (16) is an example of a control character that has been assigned a function in a communication environment. This location is the end of the type notation of the immediately preceding type in the extension series if there is 4 ITU-T Rec.1 type. 3.22 encoding: The bit-pattern resulting from the application of a set of encoding rules to an abstract value. increasing tags). 3. to define a subtype of that type. or constraint: A notation which can be used in association with a type.21 embedded-pdv type: A type whose set of values is formally the union of the sets of values in all possible abstract syntaxes.19 element: A value of a governing type or an information object of a governing information object class. all of which are values of a governing type.6. SET. 3. SET OF.15 component type: One of the types referenced when defining a CHOICE.1) encoding rules: Rules which specify the representation during transfer of the values of ASN.6.6.20 element set: A set of elements.27 extension addition type: A type contained within an extension addition group or a single component type that is itself an extension addition (in such a case it is not contained within an extension addition group).1 specification. sequence and choice types.17 control characters: Characters appearing in some character repertoires that have been given a name (and perhaps a defined function in relation to certain environments) but which have not been assigned a graphic symbol. NOTE 2 – UTC and Greenwich Mean Time (GMT) are two alternative time standards which for most practical purposes determine the same time. 3.6. 3.29 extension insertion point (or insertion point): The location within a type definition where extension additions are inserted.681 | ISO/IEC 8824-2. 3. as well as an identification of the encoding rules used to encode that abstract value. and can identify that version with a simple integer.14 3. NOTE 1 – The source of this definition is ITU-R Rec. given knowledge of the type. 3.6.23 (ASN.25 extension addition: One of the added notations in an extension series. 3. SEQUENCE.6.4. NOTE – Governing class is defined in ITU-T Rec. distinguable from all other values of the same type or information objects of the same class.460-5. 3.6.680 (07/2002) . in the case of CHOICE alternatives.6. An extension addition group is used to clearly identify the components of a set. sequence or choice type that were added in a particular version of an ASN. TF. SEQUENCE OF. each extension addition is the addition of either a single extension addition group or a single component type.18 Coordinated Universal Time (UTC): The time scale maintained by the Bureau International de l'Heure (International Time Bureau) that forms the basis of a coordinated dissemination of standard frequencies and time signals.16 contents constraint: A constraint on a bit string or octet string type that specifies either that the contents are to be an encoding of a specified ASN.6. For set.7. each value of the choice type is derived from the value of one of the component types. 3. NOTE – ASN.6. or information objects of a governing class. 3. which can provide alternative notations for built-in types (and values). NOTE – For the purpose of specifying encoding rules. or that specified procedures are to be used to produce and process the contents.1 does not support character transfer syntaxes which do not encode all character strings as an integral multiple of 8 bits.6.6. Encoding rules also enable the values to be recovered from the representation. and which are not spacing characters.6.12 character transfer syntax: Any transfer syntax for a character abstract syntax.28 extensible constraint: A subtype constraint with an extension marker at the outer level.26 extension addition group: One or more components of a set.6. NOTE – HORIZONTAL TABULATION (9) and LINE FEED (10) are examples of control characters that have been assigned a formatting function in a printing environment.ISO/IEC 8824-1:2003 (E) 3.1 specification that wishes to carry in its protocol an abstract value whose type may be defined externally to that ASN. ITU-R has also defined the acronym for Coordinated Universal Time as UTC.6. NOTE – Extension additions are both textually ordered (following the extension marker) and logically ordered (having increasing enumeration values. 3. the various referenced type (and value) notations.24 enumerated types: Simple types whose values are given distinct identifiers as part of the type notation. It carries an identification of the abstract syntax (the type) of the abstract value being carried. For enumerated types it is the addition of a single further enumeration.1 module. X.1 types. 3.6. 3. 3.

X. or set type. value set.37 external type: A type which is a part of an ASN.6. NOTE – An object descriptor value is usually associated with a single object.31 extension marker: A syntactic flag (an ellipsis) that is included in all types that form part of an extension extension marker pair: A pair of extension markers between which extension additions are inserted.34 extension series: A series of ASN. X. 3.6.46 object descriptor type: A type whose distinguished values are human-readable text providing a brief description of an object (see 3. 3. information object class. comments and white-space between the extension markers. ITU-T Rec.TypeReference 3.1 specification that carries a value whose type may be defined externally to that ASN. It carries either the extension marker with no additional notation other than comments and white-space between the extension marker and the matching "}" or ")".30 series. information object. 3. which is used in forming the ASN.6.1 notation. It also carries an identification of the type of the value being carried.1 character set.1 "Type" production (see clause 16) are defined as identical type definitions if. 3. 3.39 governing (type). sequence. they are identical ordered lists of identical lexical items (see clause 11).6.1 module notation (see clause 12).683 | ISO/IEC 8824-4.680 (07/2002) 5 .45). EXAMPLE – ModuleName. 3. such limitations are chosen so as not to affect any user of ASN.47 object identifier: A globally unique value associated with an object to unambiguously identify it.33 extension root: An extensible type that is the first type in an extension series.6.6. 3. 3.32 extension-related: Two types that have the same extension root.1 types which can be ordered in such a way that each successive type in the series is formed by the addition of text at the extension insertion point. 3.6. 3. or specification which requires a name in order to identify its use in an instance of communication.45 object: A well-defined piece of information.1 specification. NOTE – There can be at most one insertion point within the components of any choice. X. NOTE – Such an object may be an information object as defined in ITU-T Rec. X.6.42 lexical item: A named sequence of characters from the ASN.1 syntax to reference values in the governing type. Only an object identifier value unambiguously identifies an object.43 module: One or more instances of the use of the ASN.6.1 syntax.48 object identifier type: A simple type whose values are the set of all object identifiers allocated in accordance with the rules of ITU-T Rec.6.35 extensible type: A type with an extension marker. definition. 3.6. 3. value reference. or an extension marker pair with no additional notation other than a single comma. or to which an extensible constraint has been applied. where one was created by adding zero or more extension additions to the other.36 external reference: A type reference.6.41 integer type: A simple type with distinguished values which are the positive and negative whole numbers.ISO/IEC 8824-1:2003 (E) a single ellipsis in the type definition.6.44 null type: A simple type consisting of a single value. and which is being referred to by prefixing the module name to the referenced item. 3.6. 3. and parameterization is specified in ITU-T Rec. 3.6. governor: A type definition or reference which affects the interpretation of a part of the ASN. and information object set (as well as the parameterized variant of those). 3.6.6. NOTE – When particular encoding rules limit the range of an integer.6.1.1 notation for type. or immediately before the second ellipsis if there is an extension marker pair in the definition of the type.40 identical type definitions: Two instances of the ASN. encapsulated using the ASN.681 | ISO/IEC 8824-2. 3. also called null. X.38 false: One of the distinguished values of the boolean type (see also "true"). after performing the transformations specified in Annex B. requiring that part of the ASN.) are specified in ITU-T Rec.660 | ISO/IEC 9834 series. value. including zero (as a single value). 3.681 | ISO/IEC 8824-2. NOTE – The terms information object class (etc. specified in clause 11.6. that is defined in some other module than the one in which it is being referenced.6. information object class reference. NOTE – Only an extension root can be the first type in an extension series. information object reference. or information object set reference (which may be parameterized).

3. 3. 3. 3. 3.1 is used in an OSI environment. and which governs the subtype notation.6. X. 3.6.50 open systems interconnection: An architecture for computer communication which provides a number of terms which are used in this Recommendation | International Standard preceded by the abbreviation "OSI".680 (07/2002) . 3.6. each value of the sequence type is an ordered list of values. 3. Knowledge of the type of the value being encoded in the "open type notation" is needed before the abstract value for that field can be unambiguously determined.59 selection types: Types defined by reference to a component type of a choice type. 3. list of types (some of which may be declared to be optional).660 | ISO/IEC 9834-1 permit a wide range of authorities to independently associate object identifiers with objects. NOTE 3 – The only notation in this Recommendation | International Standard which is an open type notation is the "ObjectClassFieldType" specified in ITU-T Rec. X. each value in the set type is an unordered list of values.54 real type: A simple type whose distinguished values (specified in clause 20) are members of the set of real numbers. NOTE 1 – The term "open type" is used synonymously with "open type notation" in the body of this Recommendation | International Standard. intersection and set difference (use of EXCEPT) as specified in 46. 6 ITU-T Rec. clause 14.ISO/IEC 8824-1:2003 (E) NOTE – The rules of ITU-T Rec.6.1 notation used to denote a set of values from more than one ASN.49 octetstring type: A simple type whose distinguished values are an ordered sequence of zero.53 production: A part of the formal notation (also called grammar or Backus-Naur Form. 3. NOTE – The meaning of such terms can be obtained from the ITU-T Rec. 3.6.60 sequence types: Types defined by referencing a fixed. NOTE – The result of serial application of constraints is not covered by the term "set arithmetic". NOTE – Recursive definitions are allowed in ASN. X. which carries values from ASN.6.681 | ISO/IEC 8824-2.52 parent type (of a subtype): The type that is being constrained when defining a subtype.1 types that are not normally determined at specification time. and whose values are precisely the values of that component type. a value of the set type need not contain a value of that component type.6.56 relative object identifier: A value which identifies an object by its position relative to some known object identifier (see 3. NOTE – Where a component type is declared to be optional.1: the user of the notation has the responsibility for ensuring that those values (of the resulting types) which are used have a finite representation and that the value set associated with the type contains at least one value. 3.62 serial application (of constraints): The application of a constraint to a parent type which is already constrained.63 set arithmetic: The formation of new sets of values or information objects using the operations of union. unordered.6.57 relative object identifier type: A simple type whose values are the set of all possible relative object identifiers.6. one from each component type. ordered list of types (some of which may be declared to be optional). each value in the sequence-of type is an ordered list of zero.6. 3.1 encoding rules provide unambiguous encodings for the values of a single ASN. one or more octets. NOTE – The parent type may itself be a subtype of some other type.6. X.1 type. a value of the sequence type need not contain a value of that component type.6. The terms are only applicable if ASN.2. NOTE 2 – All ASN.1 type.55 recursive definition (of a type): A set of ASN.6.47). 3.1 definitions which cannot be reordered so that all types used in a construction are defined before the definition of the construction. They do not necessarily provide unambiguous encodings for "open type notation".64 set types: Types defined by referencing a fixed. one or more values of the component type. one from each component type.51 open type notation: An ASN.58 restricted character string type: A character string type whose characters are taken from a fixed character repertoire identified in the type specification.6. each octet being an ordered sequence of eight bits.6. 3.200 series and equivalent ISO/IEC Standards if needed. NOTE – Where a component type is declared to be optional.1. where the "FieldName" denotes either a type field or a variable-type value field.6.6.61 sequence-of types: Types defined by referencing a single component type. 3. BNF) used to specify ASN.

value set: A collection of values of a type.83 white-space: Any formatting action that yields a space on a printed page.81 version brackets: A pair of adjacent left and right brackets ("[[" or "]]") used to delineate the start and end of an extension addition group. together with an identification of the character abstract syntax and of the character transfer syntax to be used in its encoding.6.6.65 set-of types: Types defined by referencing a single component type. 3.1.6. the following abbreviations apply: ITU-T Rec. type: A named set of values. 3.6. Other reference names are defined in other Recommendations | International Standards.6.6. for example. these are universally available within ASN.6.6. the new type is isomorphic to the existing type. 3.82 version number: A number which can be associated with a version bracket (see G.79 3.8). or set. 3. type reference name: A name associated uniquely with a type within some context.1. This can. 3.71 tagging: Replacing the existing (possibly the default) tag of a type by a specified tag. 3.75 true: One of the distinguished values of the boolean type (see also "false").1.ISO/IEC 8824-1:2003 (E) 3.78 value mapping: A 1-1 relationship between values in two types that enables a reference to one of those values to be used as a reference to the other value. Semantically equivalent to a subtype. X.6.6.6. 3.1 BER BMP DCC DNIC Abstract Syntax Notation One Basic Encoding Rules of ASN.17).6.6. such as spaces or tabs.77 user (of ASN. NOTE – A version number cannot be added to an extension addition which is not part of an extension addition group.680 (07/2002) 7 .69 tag: A type denotation which is associated with every ASN. NOTE – There may be a single spacing character in the character repertoire. or there may be multiple spacing characters with varying widths. sequence.80 value reference name: A name associated uniquely with a value within some context. one or more values of the component type.72 transfer syntax: The set of bit strings used to exchange the abstract values in an abstract syntax.76 unrestricted character string type: A type whose abstract values are values from a character abstract syntax.68 subtype (of a parent type): A type whose values are a subset (or the complete set) of the values of some other type (the parent type). usually obtained by application of encoding rules to an abstract syntax. nor to extension additions to any type other than choice. 3. NOTE – The term "transfer syntax" is synonymous with "encoding". 3. The pair of left brackets can optionally be followed by a number giving a version number for the extension addition group.6.8. 3.6.1 type. be used in specifying subtypes and default values (see Annex B).70 tagged types: A type defined by referencing a single existing type and a tag.6. 3.66 simple types: Types defined by directly specifying the set of their values. and are applicable only in the context of that Recommendation | International Standard.74 3. 3. 4 Abbreviations ASN. but is distinct from it. 3.1 Basic Multilingual Plane Data Country Code Data Network Identification Code For the purposes of this Recommendation | International Standard. 3. NOTE – Reference names are assigned to the types defined in this Recommendation | International Standard.1): The individual or organization that defines the abstract syntax of a particular piece of information using ASN.67 spacing character: A character in a character repertoire which is intended for inclusion with graphic characters in the printing of a character string but which is represented in the physical rendition by empty space. each value in the set-of type is an unordered list of zero. it is not normally considered to be a control character (see 3. 3.73 3.6.6.6.

1 Recognized Operating Agency Universal Multiple-Octet Coded Character Set Coordinated Universal Time Extensible Markup Language 5 5.2 Each use of the ASN.1.3.c) is specified by a list of names.1 notation consists of a sequence of characters from the ASN. 5. NOTE – If the same sequence of lexical items appears in more than one alternative.2 5.2. this Recommendation | International Standard uses a formal notation defined in the following subclauses.2.2.2. This uses the names of lexical items and of permitted sequences of lexical items and forms a new named permitted sequence of lexical items.1 Each alternative in a production (see 5. and permitted sequences of lexical items are named. 5.1 Productions All lexical items are named (see clause 11).3 Each production consists of the following parts. 5.2. 5.4 A sequence of lexical items is present in the new permitted sequence of lexical items if it is present in one or more of the alternatives. 5.3.3 The ASN.1 notation. Each name is either the name of a lexical item.3. 5. X.2 The permitted sequence of lexical items defined by each alternative consists of all sequences obtained by taking any one of the sequences (or the lexical item) associated with the first name. The new permitted sequence of lexical items is referenced in this Recommendation | International Standard by the name in 5.3. as defined in 5. 5.2 A new (more complex) permitted sequence of lexical items is defined by means of a production.1.1. separated by the character | 5. in combination with (and followed 8 ITU-T Rec.4 In order to specify the permitted sequences of lexical items. any semantic ambiguity in the resulting notation is resolved by associated text.1 International Code Designator International Electrotechnical Commission International Organization for Standardization International Telecommunication Union – Telecommunication Standardization Sector Object Identifier Open Systems Interconnection Packed Encoding Rules of ASN.2.ISO/IEC 8824-1:2003 (E) ECN ICD IEC ISO ITU-T OID OSI PER ROA UCS UTC XML Encoding Control Notation of ASN.1. or is the name of a permitted sequence of lexical items defined and named by some other production.1 character set specified in clause 10. and names each item.1 notation is specified in clause 12 (and following clauses) by specifying and naming those sequences of lexical items which form valid instances of the ASN.1 semantics of each sequence.3 The alternative collections 5.1 5.1 character set grouped into lexical items.1 notation contains characters from the ASN. the characters ::= one or more alternative sequences of lexical items. 5. on one or several lines. Clause 11 specifies all the sequences of characters forming lexical items. and by specifying the ASN.3 a) above.680 (07/2002) .1 Notation General The ASN. in order: a) b) c) a name for the new permitted sequence of lexical items.

and so on up to and including the last name (or lexical item) in the alternative.5.7). The production may be on a single line.5. Some or all of the sequences in the set may themselves contain an unbounded number of lexical items. 5. NOTE – This indicator is only used in productions that describe the XML value notation. the following short-hand notations are used in the definition of permitted sequences of lexical items in this Recommendation | International Standard and also in ITU-T Rec.682 | ISO/IEC 8824-3 and ITU-T Rec.6 Layout Each production used in this Recommendation | International Standard is preceded and followed by an empty line.2 In this example. NOTE – In many cases.7 Recursion The productions in this Recommendation | International Standard are frequently recursive. preceded by a "{" and followed by a "}". 5. or one of the permitted sequences of lexical items associated with "A". or may be spread over several lines. the name is surrounded by the QUOTATION MARK (34) character (") to distinguish it from natural language text. "A" and "B". This is not an error. either before or after the production defining "ExampleProduction". 5. 5. 5.ISO/IEC 8824-1:2003 (E) by) any one of the sequences (or lexical item) associated with the second name. unless it appears as part of a production. or any sequence of lexical items associated with "IdentifierList". when the name appears in natural language text.4 Non-spacing indicator If the non-spacing indicator "&" (AMPERSAND) is inserted between these items in production sequences. In this case the productions are to be continuously reapplied until no new sequences are generated. in combination with (and followed by) any one of the sequences (or lexical item) associated with the third name. and could be confused with such text.9 References to a lexical item This Recommendation | International Standard references a lexical item by using the name of the lexical item. it is used to specify that the lexical item "<" is to be immediately followed by an XML tag name. ITU-T Rec. such reapplication results in an infinite set of permitted sequences of lexical items. Empty lines do not appear within productions. 5. denotes the "empty" lexical item (see 11. X. X.8 References to permitted sequences of lexical items This Recommendation | International Standard references a permitted sequence of lexical items (part of the ASN.26). or any "hstring" (a lexical item). "IdentifierList" would be defined by a further production.680 (07/2002) 9 . NOTE – "{" and "}" are the names of lexical items containing the single characters { and } (see 11.1 Example of a production The production: ExampleProduction ::= bstring | hstring | "{" IdentifierList "}" associates the name "ExampleProduction" with the following sequences of lexical items: a) b) c) any "bstring" (a lexical item). then the lexical item that precedes it and the lexical item that follows it shall not be separated by white-space. or an alternating series of one of the ITU-T Rec. X.1 notation) by referencing the name that appears before the "::=" in a production. X. Layout is not significant.683 | ISO/IEC 8824-4: a) An asterisk (*) following two names. 5.681 | ISO/IEC 8824-2.5 5. For example.10 Short-hand notations In order to make productions more concise and more readable. then it is surrounded by the QUOTATION MARK (34) character ("). 5.

X.. a decoder may detect: 10 ITU-T Rec.1 model of type extension a) the absence of expected extension additions in a sequence or set type. a reference to the first value can be used wherever a reference to a value in the second type is required. 6 The ASN..1 construct is legal or not. These legality specifications generally require that two or more types be "compatible". or When decoding an extensible type.11. Annex B describes and specifies the value mapping mechanism that allows a value reference name for a value of one type to identify a value of a second (similar) type.7) or a permitted sequence of lexical items associated with "A". The normative Annex B uses the value mapping concept to give a precise statement about whether any given ASN.2).1 standards normal English text is used to specify legality (or otherwise) of constructs where more than one type is involved.2. b) A plus sign (+) is similar to the asterisk in a)...1 The ASN.11 Value references and the typing of values 5. 5. This name can be used wherever a reference to that value is needed.2 In the body of the ASN. c) A question mark (?) following a name denotes either the "empty" lexical item (see 11. For example. EXAMPLE – "C ::= A B *" is the shorthand notation for the following alternatives of C: empty A ABA ABABA ABABABA . Thus: C ::= A B * is equivalent to: C ::= D | empty D ::= A | A B D "D" being an auxiliary name not appearing elsewhere in the productions.1 value assignment notation enables a name to be given to a value of a specified type.680 (07/2002) . Thus. 5.11. except that the "empty" lexical item is excluded. both starting and finishing with one associated with "A". Thus: F ::= A ? is equivalent to: F ::= empty | A NOTE – These short-hand notations take precedence over the juxtaposition of lexical items in production sequences (see 5. Thus: E ::= A B + is equivalent to: E ::= A | A B E EXAMPLE – "E ::= A B +" is the shorthand notation for the following alternatives of E: A ABA ABABA ABABABA .ISO/IEC 8824-1:2003 (E) sequences of lexical items associated with "A" and one of the sequences of lexical items associated with "B". the type used in defining a value reference is required to be "compatible with" the governing type when the value reference is used.

the encoding rules shall allow the values that were decoded using Y to be re-encoded (using Y) and decoded using a third extensible type Z that is extension related to Y (and hence X also). ITU-T Rec. 7. an abstract syntax defined by the extensible type X contains not only the values of type X. an abstract value of each extension addition that is present in both X and Y.ISO/IEC 8824-1:2003 (E) b) the presence of arbitrary unexpected extension additions above those defined (if any) in a sequence or set type.1 satisfy all these requirements. Encodings specified using ECN may or may not provide such identification. 7 Extensibility requirements on encoding rules NOTE – These requirements apply to standardized encoding rules. then it is successfully decoded. NOTE 2 – PER and BER do not identify the version number in the encoding of an extension addition. or of an unexpected length or value of a type whose constraint is extensible. it shall be possible for the decoder to delimit the encoding of it and to identify it as a value of an (unknown) extension addition. while system B is using an extension-related type (type Y) that has two extension additions where each is an optional integer type. provided that the same transfer syntax is used on the subsequent transmission. but may do so. the presence of extension additions shall not affect the ability to recognize later material when a type with an extension marker is nested inside some other type.1 encoding rules shall specify the encoding and decoding of types with extensible constraints in such a way that if a transmitted value is in the set of extension additions held in common by the encoder and the decoder. Encoding rules defined using ECN do not necessarily satisfy all these requirements. followed by the second integer value received from B.1 specifier.692 | ISO/IEC 8825-3). X. NOTE – Types X. if so required by the application. 7. In all cases. delimited encoding for each extension addition (if any) that is in X but not in Y. Thus.3 All ASN.1 and the Packed Encoding Rules of ASN. the decoding process never signals an error when either of the above situations (a or b) is detected. then the decoder using type Y obtains an abstract value composed of: a) b) c) an abstract value of the extension root type. Tutorial example: If system A is using an extensible root type (type X) that is a sequence type or a set type with an extension addition of an optional integer type.1 encoding rules shall specify the encoding and decoding of the value of an enumerated type and a choice type in such a way that if a transmitted value is in the set of extension additions held in common by the encoder and the decoder. or to some third party). then transmission by B of a value of Y which omits the integer value of the first extension addition and includes the second must not be confused by A with the presence of the first (only) extension addition of X that it knows about. 7. Unexpected extension additions detected by a decoder in an extensible type can later be included in a subsequent encoding of that type (for transmission back to the sender. and to use a default value or a "missing" indicator for expected extension additions that are absent. Moreover. NOTE – Frequently the action will be to ignore the presence of unexpected additional extensions. If a value of an extensible type X is encoded and then relayed (directly or through a relaying application using extensionrelated type Z) to another application that decodes the value using extensible type Y that is extension-related to X. then it is successfully decoded. Y and Z may appear in any order in the extension series.2 All ASN.1 encoding rules shall allow the encoding of values of an extensible type X in such a way that they can be decoded using an extensible type Y that is extension-related to X. The action that is taken in each situation is determined by the ASN. but also the values of all types that are extension-related to X. That encoding shall be a valid encoding of a value of X. They do not apply to encoding rules defined using ECN (see ITU-T Rec. otherwise it shall be possible for the decoder to delimit the encoding of and to identify it as a value of an (unknown) extension addition. or an unknown enumeration in an enumerated type. X. In formal terms. otherwise. The encodings in c) shall be capable of being included in a later encoding of a value of Y. NOTE 1 – All variants of the Basic Encoding Rules of ASN.1 All ASN. if so required by the application protocol. or of an unknown alternative in a choice type.680 (07/2002) 11 . Further. A must be able to re-encode the value of X with a value present for the first integer type.

application.1 Tags A tag is specified by giving a class and a number within the class.. a private or context-specific class tag could generally be applied instead.1 notation for a type definition shall be "Type" (see 16. NOTE – Clause 30 includes the restriction that users of this notation are not allowed to explicitly specify universal class tags in their ASN.7).1 9.6 The canonical order for tags is based on the outermost tag of each type and is defined as follows: a) those elements or alternatives with universal class tags shall appear first.2 Use of the ASN. X.3 The number is a non-negative integer. NOTE – It is not in general possible to interpret the value notation without knowledge of the type. followed by those with private class tags. 8. as a matter of user choice and style.1 are specified in clause 30. b) 9 9. To provide uniformity. Restrictions on tags assigned by the user of ASN. Where application class tags are employed. context-specific.2 8. There is no formal difference between use of tags from the other three classes. the elements or alternatives shall appear in ascending order of their tag numbers. The class is one of: – – – – universal.6. Table 1 – Universal class tag assignments UNIVERSAL 0 UNIVERSAL 1 UNIVERSAL 2 UNIVERSAL 3 UNIVERSAL 4 UNIVERSAL 5 UNIVERSAL 6 UNIVERSAL 7 UNIVERSAL 8 UNIVERSAL 9 UNIVERSAL 10 UNIVERSAL 11 UNIVERSAL 12 UNIVERSAL 13 UNIVERSAL 14-15 UNIVERSAL 16 UNIVERSAL 17 UNIVERSAL 18-22. 8. 25-30 UNIVERSAL 23-24 UNIVERSAL 31-. within each class of tags. 12 ITU-T Rec.. specified in decimal notation.680 (07/2002) .1 notation for a value of a type shall be "Value" (see 16. private.ISO/IEC 8824-1:2003 (E) 8 8.5 Some encoding rules require a canonical order for tags.1).2.1 specifications. Reserved for use by the encoding rules Boolean type Integer type Bitstring type Octetstring type Null type Object identifier type Object descriptor type External type and Instance-of type Real type Enumerated type Embedded-pdv type UTF8String type Relative object identifier type Reserved for future editions of this Recommendation | International Standard Sequence and Sequence-of types Set and Set-of types Character string types Time types Reserved for addenda to this Recommendation | International Standard 8. but guidance is given in E.4 Table 1 summarizes the assignment of tags in the universal class which are specified in this Recommendation | International Standard. The presence of the three classes is largely for historical reasons. a canonical order for tags is defined in 8. The ASN.1 notation The ASN. followed by those with application class tags. 8. followed by those with context-specific tags.12 on the way in which the classes are usually employed.

1 specifications to be written in various languages. 10. ITU-T Rec.6). . identifier (see 11. additional characters may appear in the following lexical items: – – – typereference (see 11.2) or "ParameterizedValueAssignment" (see ITU-T Rec. This is to allow valid ASN.2).1).ISO/IEC 8824-1:2003 (E) 9. or "ParameterizedValueSetTypeAssignment" (see ITU-T Rec.5). "ValueSetTypeAssignment" (see 15. 10.2).3 The ASN.1 notation for assigning a type to a type reference name shall be either "TypeAssignment" (see 15.2 Where the notation is used to specify the value of a character string type. X. all characters for the defined character set can appear in the ASN. the syntactic distinction achieved by dictating the case of the first character of certain of the above lexical items has to be achieved in some other way. 8. 9.1 notation.3.1 characters A to Z a to z 0 to 9 ! " & ' ( ) * .3 Additional (arbitrary) graphic symbols may appear in the "comment" lexical item (see 11. X.5 The production alternatives of the notation "Assignment" shall only be used within the notation "ModuleDefinition" (except as specified in NOTE 2 of 12. 8.683 | ISO/IEC 8824-4. "ParameterizedTypeAssignment" (see ITU-T Rec. characters are identified by the names they are given in ISO/IEC 10646-1. When additional characters are introduced to accommodate a language in which the distinction between upper-case and lowercase letters is without meaning.1).2).1 A lexical item shall consist of a sequence of the characters listed in Table 2 except as specified in 10.2). 9. In Table 2.683 | ISO/IEC 8824-4. / : .1 notation for assigning a value to a value reference name shall be either "ValueAssignment" (see 15.680 (07/2002) 13 .4). valuereference (see 11. < = > @ [ ] ^ _ { | } (LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) (LATIN SMALL LETTER A to LATIN SMALL LETTER Z) (DIGIT ZERO to DIGIT 9) (EXCLAMATION MARK) (QUOTATION MARK) (AMPERSAND) (APOSTROPHE) (LEFT PARENTHESIS) (RIGHT PARENTHESIS) (ASTERISK) (COMMA) (HYPHEN-MINUS) (FULL STOP) (SOLIDUS) (COLON) (SEMICOLON) (LESS-THAN SIGN) (EQUALS SIGN) (GREATER-THAN SIGN) (COMMERCIAL AT) (LEFT SQUARE BRACKET) (RIGHT SQUARE BRACKET) (CIRCUMFLEX ACCENT) (LOW LINE) (LEFT CURLY BRACKET) (VERTICAL LINE) (RIGHT CURLY BRACKET) NOTE – Where equivalent derivative standards are developed by national standards bodies.14).683 | ISO/IEC 8824-4.1 character set 10.6). surrounded by the QUOTATION MARK (34) characters (") (see 11. 8.4 The ASN.3). X. Table 2 – ASN. X.2 and 10. 10 The ASN. – modulereference (see 11.

11.4 Lexical items may be separated by one or more occurrences of white-space (see 11. 11. X. together with the definition of the character sequences which form the lexical item.1 The following subclauses specify the characters in lexical items. In representing white-space and newline (end of line) in machine-readable specifications. 10. white-space may appear between lexical items. 11.1.27. Within an "XMLTypedValue" production (see 15. but the "comment" lexical item shall not be present. 11.6 This Recommendation | International Standard uses the terms "newline". colour. "hstring" and "cstring") shall not contain white-space (see 11.6.1.1 A "typereference" shall consist of an arbitrary number (one or more) of letters. 11. Such characters never indicate the start of a "comment" lexical item when they appear within an "XMLTypedValue" production.1. the character name and character code specified in The Unicode Standard are given): For white-space: HORIZONTAL TABULATION (9) LINE FEED (10) VERTICAL TABULATION (11) FORM FEED (12) CARRIAGE RETURN (13) SPACE (32) For newline: LINE FEED (10) VERTICAL TABULATION (11) FORM FEED (12) CARRIAGE RETURN (13) NOTE – Any character or character sequence that is a valid newline is also a valid white-space. "bstring". size.6) except when the non-spacing indicator "&" (see 5. any one or more of the following characters may be used in any combination (for each character.1 definitions can also contain white-space characters (see 11.680 (07/2002) . digits. 11 11. 11.6) or comments (see 11.4 There shall be no significance placed on the typographical style.1. A hyphen shall not be immediately followed by another hyphen.2).ISO/IEC 8824-1:2003 (E) 10. and hyphens. 11. NOTE – The rules concerning hyphen are designed to avoid ambiguity with (possibly following) comment.2 The lexical items specified in the subclauses of this clause 11 (except multiple-line "comment".1 ASN.14).1.5 A lexical item shall be separated from a following lexical item by one or more instances of white-space or comment if the initial character (or characters) of the following lexical item is a permitted character (or characters) for inclusion at the end of the characters in the earlier lexical item.6 The upper and lower-case letters shall be regarded as distinct.1. or other display characteristics. 11.1.1.2 A "typereference" shall not be one of the reserved character sequences listed in 11.5 10.2. intensity.2. 14 ITU-T Rec.10. A hyphen shall not be the last character.4) is used.12 and 11.1 lexical items General rules 11.6) between lexical items. 11.3 The length of a line is not restricted.2 Type references Name of lexical item – typereference 11. and "white-space". In each case the name of the lexical item is given. The initial character shall be an upper-case letter. NOTE – This is to avoid ambiguity resulting from the presence of adjacent hyphens or asterisk and solidus within an "xmlcstring" lexical item. ASN.

a "valuereference" is distinguished from an "identifier" by the context in which it appears.1 (see 10.3 Identifiers Name of lexical item – identifier An "identifier" shall consist of an arbitrary number (one or more) of letters. and has no syntactic significance. If a comment beginning with "--" includes the adjacent characters "/*" or "*/". 11.3. it shall end with the next pair of adjacent hyphens or at the end of the line.6.6.7 Empty lexical item Name of lexical item – empty The "empty" item contains no characters.6.1 comment may contain normative text related to the application semantics. it shall end with a corresponding "*/". or constraints on the syntax. provided there are no character string values within the part to be commented out that contain "/*" or "*/". if any. appear at any time between other lexical items.4 Whenever a "comment" begins with "/*". ITU-T Rec. 11. in the context of a Recommendation | International Standard that uses ASN. then the comment terminates when a matching "*/" has been found for each "/*". 11. NOTE – This allows the user to comment parts of an ASN. NOTE – The rules concerning hyphen are designed to avoid ambiguity with (possibly following) comment. 11.4. whether this "*/" is on the same line or not.2 The lexical item "comment" can have two forms: a) b) One-line comments which begin with "--" as defined in 11. X. NOTE – Nonetheless. these hyphens have no special meaning and are considered part of the comment. 11. and hyphens.2.6.1 (see 10.5 Module references Name of lexical item – modulereference A "modulereference" shall consist of the sequence of characters specified for a "typereference" in 11. In analysing an instance of use of this notation. 11. 11. The comment may include graphic symbols which are not in the character set specified in 10.3). whichever occurs first.3 Whenever a "comment" begins with a pair of adjacent hyphens.ISO/IEC 8824-1:2003 (E) 11. however. The comment may include graphic symbols which are not in the character set specified in 10. to indicate that absence of all alternatives is possible.6. these have no special meaning and are considered part of the comment.3. digits. In analysing an instance of use of this notation. The first digit shall not be zero unless the "number" is a single digit.1 module that already contain comments (whether they begin with "--" or "/*") by simply inserting "/*" at the beginning of the part to be commented and "*/" at its end.3). which ends it. If a comment beginning with "/*" includes two adjacent hyphens "--". The initial character shall be a lower-case letter. A comment shall not contain a pair of adjacent hyphens other than the pair which starts it and the pair. If another "/*" is found before a "*/".8 Numbers Name of lexical item – number A "number" shall consist of one or more digits. Multiple-line comments which begin with "/*" as defined in 11. an ASN.6 Comments Name of lexical item – comment 11.680 (07/2002) 15 . It is used in the notation of clause 5 when alternative sets of production sequences are specified. It may. 11.4 Value references Name of lexical item – valuereference A "valuereference" shall consist of the sequence of characters specified for an "identifier" in 11. a "modulereference" is distinguished from a "typereference" by the context in which it appears.1 notation.6.1 A "comment" is not referenced in the definition of the ASN.1. A hyphen shall not be the last character. A hyphen shall not be immediately followed by another hyphen.

). 11.12. preceded by an APOSTROPHE (39) character (') and followed by the pair of characters: 'B EXAMPLE – '01101100'B Occurrences of white-space within a binary string lexical item have no significance. decimal point or fractional part (whichever is last present) can optionally be followed by an e or E and an optionally-signed exponent which is one or more digits. 16 ITU-T Rec. Any white-space characters that appear within a hexadecimal string item have no significance. EXAMPLE – Ab0196 11. The leading digit of the exponent shall not be zero unless the exponent is a single digit. X. ones or white-space.1 An "xmlhstring" shall consist of an arbitrary number (possibly zero) of the characters: 0123456789ABCDEFabcdef or white-space.12 Hexadecimal strings Name of lexical item – hstring 11.1 An "hstring" shall consist of an arbitrary number (possibly zero) of the characters: A B C D E F 0 1 2 3 4 5 6 7 8 9 possibly intermixed with white-space. 11. 11.13 XML hexadecimal string item Name of item – xmlhstring 11.12.680 (07/2002) . an "xmlbstring" is distinguished from an "xmlhstring" or "xmlcstring" by the context in which it appears. 11. In analysing an instance of use of this notation.2 Each character is used to denote the value of a semi-octet using a hexadecimal representation. and optionally a decimal point (. preceded by an APOSTROPHE (39) character (') and followed by the pair of characters: 'H EXAMPLE – 'AB0196'H Occurrences of white-space within a hexadecimal string lexical item have no significance. Any white-space characters that appear within a binary string item have no significance.2 Each character is used to denote the value of a semi-octet using a hexadecimal representation.ISO/IEC 8824-1:2003 (E) NOTE – The "number" lexical item is always mapped to an integer value by interpreting it as decimal notation. The integer part. EXAMPLE – 01101100 This sequence of characters is also a valid instance of "xmlhstring" and "xmlcstring".13.13.11 XML binary string item Name of item – xmlbstring An "xmlbstring" shall consist of an arbitrary number (possibly zero) of zeros. 11.9 Real numbers Name of lexical item – realnumber A "realnumber" shall consist of an integer part that is a series of one or more digits. The decimal point can optionally be followed by a fractional part which is one or more digits.10 Binary strings Name of lexical item – bstring A "bstring" shall consist of an arbitrary number (possibly zero) of the characters: 0 1 possibly intermixed with white-space. 11.

inclusive. this character (if present in the character string being represented by the "cstring") shall be represented in the "cstring" by a pair of QUOTATION MARK (34) characters on the same line with no intervening spacing character. inclusive.14 Character strings Name of lexical item – cstring 11. Spacing characters immediately preceding or following any end of line in the "cstring" are not part of the character string being represented (they are ignored). and thus a corresponding "cstring" should be printed as two characters and not as the single character é.2 When a character is a combining character (see Annex F) it shall be denoted in a printed representation of the "cstring" as an individual character.1 A "cstring" shall consist of an arbitrary number (possibly zero) of graphic symbols and spacing characters from the character set referenced by the character string type. 11.ISO/IEC 8824-1:2003 (E) 11. 11. an "xmlhstring" is distinguished from an "xmlbstring" or "xmlcstring" by the context in which it appears. the character string denoted by "cstring" may be ambiguous in that printed representation. or where the graphic symbols in the character repertoire are not unambiguous in a printed representation.680 (07/2002) 17 . It shall not be overprinted with the characters with which it combines. any character whose ISO/IEC 10646-1 character code is in the range 32 (20 hex) to 55295 (D7FF hex). X. In analysing an instance of use of this notation.15. inclusive. any character whose ISO/IEC 10646-1 character code is in the range 65536 (10000 hex) to 1114111 (10FFFF hex).3 Some instances of "xmlhstring" are also valid instances of "xmlbstring" and "xmlcstring". preceded and followed by a QUOTATION MARK (34) character ("). or is a spacing character. alternative ASN. NOTE 1 – The "cstring" can only be used to unambiguously represent (on a printed page) character strings for which every character in the string being represented has either been assigned a graphic symbol. Any spacing characters that appear immediately prior to or following the end of line in the "cstring" have no significance.) EXAMPLE – Lower case "e" and the accent combining character are two characters in ISO/IEC 10646-1.13. The "cstring" may span more than one line of text. 11.1 An "xmlcstring" shall consist of an arbitrary number (possibly zero) of the following ISO/IEC 10646-1 characters: a) b) c) d) e) f) HORIZONTAL TABULATION (9). EXAMPLE 1 – " EXAMPLE 2 – The "cstring": "ABCDE " FGH IJK""XYZ" can be used to represent a character string value of type IA5String.1 syntax is available (see clause 35). NOTE 2 – The character string represented by a "cstring" consists of the characters associated with the graphic symbols and spacing characters.14. any character whose ISO/IEC 10646-1 character code is in the range 57344 (E000 hex) to 65533 (FFFD hex). (This ensures that the order of combining characters in the string value is unambiguously defined in the printed version. Where spacing characters are included in the "cstring". Where a character string containing control characters needs to be denoted in a printed representation. The value represented consists of the characters: ABCDE FGHIJK"XYZ where the precise number of spaces intended between E and F can be ambiguous in a printed representation if a proportional spacing font (such as is used above) is used in the printed specification.15 XML character string item Name of item – xmlcstring 11. If the character set includes a QUOTATION MARK (34) character. or if the character repertoire contains multiple spacing characters of different widths. in which case the character string being represented shall not include spacing characters in the position prior to or following the end of line in the "cstring". CARRIAGE RETURN (13).14. LINE FEED (10). ITU-T Rec.

8.693 | ISO/IEC 8825-4).4 or 11. in an instance of use. then at least one of the adjacent HYPHEN-MINUS characters shall be represented by the escape sequences specified in 11.4 If the characters "&" (AMPERSAND). 11. or the escape sequences "&amp. nor can it represent characters which might be defined with ISO/IEC 10646-1 character codes above 10FFFF hex.15.15.3 An "xmlcstring" is used to represent the value of a restricted character string (see 37. If this character sequence is present in an abstract character string value being represented by the "xmlcstring".2) forming part of an XER encoding (see ITU-T Rec.6).15.15.1 module.693 | ISO/IEC 8825-4).9).5. Table 3 – Escape sequences for control characters in an "xmlcstring" ISO/IEC 10646-1 character code 0 (0 hex) 1 (1 hex) 2 (2 hex) 3 (3 hex) 4 (4 hex) 5 (5 hex) 6 (6 hex) 7 (7 hex) 8 (8 hex) 11 (B hex) 12 (C hex) 14 (E hex) 15 (F hex) 16 (10 hex) "xmlcstring" representation <nul/> <soh/> <stx/> <etx/> <eot/> <enq/> <ack/> <bel/> <bs/> <vt/> <ff/> <so/> <si/> <dle/> ISO/IEC 10646-1 character code 17 (11 hex) 18 (12 hex) 19 (13 hex) 20 (14 hex) 21 (15 hex) 22 (16 hex) 23 (17 hex) 24 (18 hex) 25 (19 hex) 26 (1A hex) 27 (1B hex) 28 (1C hex) 29 (1D hex) 30 (1E hex) 31 (1F hex) "xmlcstring" representation <dc1/> <dc2/> <dc3/> <dc4/> <nak/> <syn/> <etb/> <can/> <em/> <sub/> <esc/> <is4/> <is3/> <is2/> <is1/> 11. and can be used to represent all combinations of ISO/IEC 10646-1 characters.5 If a character with an ISO/IEC 10646-1 character code in column 1 of Table 3 is present in the abstract character string value being represented by the "xmlcstring" (see 37." or "&gt. either directly.1. These escape sequences shall not contain white-space (see 11.15.8.15." respectively. NOTE 1 – An "xmlcstring" cannot be used to represent characters that are not present in ISO/IEC 10646-1. When used within an instance of XML value notation in an ASN. it may contain adjacent HYPHEN-MINUS (45) characters.2 The characters "&" (AMPERSAND).6 When "xmlcstring" is used within an "XMLTypedValue" (see 15. "<" (LESS-THAN SIGN) or ">" (GREATER-THAN SIGN) shall appear only as part of one of the character sequences specified in 11.".7 When "xmlcstring" is used within an "XMLTypedValue" forming part of an XER encoding (see ITU-T Rec. 18 ITU-T Rec. "&lt. 11. NOTE – This does not include characters with decimal character codes 9. 11. 11.1 module. shall contain only characters permitted by the governing character string type.ISO/IEC 8824-1:2003 (E) NOTE – Additional restrictions are imposed by the requirement that the "xmlcstring". NOTE 2 – The characters LINE FEED (10) and CARRIAGE RETURN (13) and the pair CARRIAGE RETURN + LINE FEED are not distinguished when processed by conforming XML processors.15. or by using the escape sequences specified below. X. and 13. and all the letters in these character sequences are lowercase. it shall be represented by the character sequence in column 2 of Table 3. These character sequences shall not contain white-space (see 11.15. X. If this character sequence is present in an abstract character string value being represented by the "xmlcstring" in an ASN.8. it shall not contain two adjacent HYPHEN-MINUS characters. When used within an instance of XML value notation in an ASN.6). 11.15. such as some of the control characters which can appear in GeneralString.1. then at least one of the adjacent ASTERISK and SOLIDUS characters shall be represented by the escape sequences specified in 11.9). X.9).15.15.680 (07/2002) . 10. they shall be represented in the "xmlcstring" by either a) b) the escape sequences specified in 11. it shall not contain adjacent ASTERISK and SOLIDUS characters (in any order). it may contain adjacent ASTERISK (42) and SOLIDUS (47) characters in any order. "<" (LESS-THAN SIGN) or ">" (GREATER-THAN SIGN) are present in an abstract character string value being represented by "xmlcstring" (see 37.1 module.

11." (where n is the ISO/IEC 10646-1 character code in decimal notation) or of the form "&#xn. NOTE – This sequence does not contain white-space (see 11.2). 11.1.1. NOTE 1 – Leading zeros are permitted in the decimal and hexadecimal values of "n" and both lowercase and uppercase letters "A"-"F" can be used in the hexadecimal value.2)...1.19 Left version brackets Name of lexical item – "[[" This lexical item shall consist of the sequence of characters: [[ NOTE – This sequence does not contain white-space (see 11. The value represented consists of the characters: ABCDé FGHîJK&XYZ where the precise space characters between é and F can be ambiguous in print media if a proportional spacing font (such as above) is used in the specification...XYZ can be used to represent a character string value of type UTF8String.JK&amp.6)." (where n is the ISO/IEC 10646-1 character code in hexadecimal notation).15. NOTE – This sequence does not contain white-space (see 11." This lexical item shall consist of the sequence of characters: .680 (07/2002) 19 . 11..2).1. 11. These escape sequences shall not contain white-space (see 11.20 Right version brackets Name of lexical item – "]]" This lexical item shall consist of the sequence of characters: ]] NOTE – This sequence does not contain white-space (see 11.8 Any character that can appear directly in an "xmlcstring" can also be represented in the "xmlcstring" by an escape sequence of the form "&#n.2).1. NOTE 2 – If the escape sequences "&#n" and "&#xn" are used for ISO/IEC 10646-1 characters which are not in the Basic Multilingual Plane (BMP). 11. EXAMPLE – The "xmlcstring": ABCD&#233. 11." This lexical item shall consist of the sequence of characters: .ISO/IEC 8824-1:2003 (E) 11.1..18 Ellipsis Name of lexical item – ". FGH&#xEE.2).16 Assignment lexical item Name of lexical item – "::=" This lexical item shall consist of the sequence of characters: ::= NOTE – This sequence does not contain white-space (see 11.21 XML end tag start item Name of item – "</" This item shall consist of the sequence of characters: ITU-T Rec.17 Range separator Name of lexical item – ". the value of "n" will be greater than 65535 (FFFF hex). X.

23.24.3 The "xmlasn1typename" for the "UsefulType"s (see 41.25.25.1 This item shall consist of the sequence of characters: false 11.2.22 XML single tag end item Name of item – "/>" This item shall consist of the sequence of characters: /> NOTE – This sequence does not contain any white-space characters (see 11. 11.4 The character sequence in the "xmlasn1typename" item for the "ObjectClassFieldType" and for the "InstanceOfType" are specified in ITU-T Rec.681 | ISO/IEC 8824-2.5 If the ASN.1 built-in type is identified in column 1 of Table 4 by its production name.5 shall be recursively applied. 11.2).1. The ASN.2 Table 4 lists the character sequences that are to form the "xmlasn1typename" for each of the ASN.1 This item shall consist of the sequence of characters: true 11.23 XML boolean true item Name of item – "true" 11.680 (07/2002) .25.24. 14. 11. 11.1 and Annex C.2). 11. NOTE – This sequence does not contain any white-space characters (see 11. a "false" is distinguished from a "valuereference" or an "identifier" by the context in which it appears.1.2).2).1 built-in types are to be used as XML tag names.1. If this is itself a "TaggedType".2 In analysing an instance of use of this notation.ISO/IEC 8824-1:2003 (E) </ NOTE – This sequence does not contain any white-space characters (see 11.1 types Name of item – xmlasn1typename 11.1 built-in types listed in 16.1 built-in type is a "TaggedType" then the type which determines the "xmlasn1typename" shall be "Type" in the "TaggedType" (see 30.2 In analyzing an instance of use of this notation. a "true" is distinguished from a "valuereference" or an "identifier" by the context in which it appears.25.1). X. then this subclause 11. The character sequence which shall be used for "xmlasn1typename" is identified in column 2 of Table 4. 20 ITU-T Rec. 11.1) shall be the "typereference" used in their definition.1. X. NOTE – This sequence does not contain any white-space characters (see 11.23. 11.25. with no white-space before or after these character sequences.1 This Recommendation | International Standard uses the item "xmlasn1typename" when ASN.25 XML tag names for ASN.25.24 XML boolean false item Name of item – "false" 11. 11.

ISO/IEC 8824-1:2003 (E) Table 4 – Characters in xmlasn1typename ASN. ITU-T Rec. X. X." ".g." "(" ")" "[" "]" "-" ":" "=" """ "'" "" ".10 and 14.25.26 Single character lexical items "{" "}" "<" ">" ".680 (07/2002) 21 ." "@" "|" "!" "^" Names of lexical items – (HYPEN-MINUS) (QUOTATION MARK) (APOSTROPHE) (SPACE) A lexical item with any of the names listed above shall consist of the single character without the quotation marks. IA5String) SEQUENCE SEQUENCE_OF SET SET_OF See 11.1 type production name BitStringType BooleanType ChoiceType EmbeddedPDVType EnumeratedType ExternalType InstanceOfType IntegerType NullType ObjectClassFieldType ObjectIdentifierType OctetStringType RealType RelativeOIDType RestrictedCharacterStringType SequenceType SequenceOfType SetType SetOfType TaggedType UnrestrictedCharacterStringType BIT_STRING BOOLEAN CHOICE SEQUENCE ENUMERATED SEQUENCE SEQUENCE INTEGER NULL See ITU-T Rec.11 OBJECT_IDENTIFIER OCTET_STRING REAL RELATIVE_OID The type name (e.5 SEQUENCE Characters in xmlasn1typename 11.681 | ISO/IEC 8824-2. 14.

ISO/IEC 8824-1:2003 (E)

11.27
ABSENT

Reserved words
ENCODED END ENUMERATED EXCEPT EXPLICIT EXPORTS EXTENSIBILITY EXTERNAL FALSE FROM GeneralizedTime GeneralString GraphicString IA5String IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INSTANCE INTEGER INTERSECTION ISO646String MAX MIN MINUS-INFINITY NULL NumericString OBJECT ObjectDescriptor OCTET OF OPTIONAL PATTERN PDV PLUS-INFINITY PRESENT PrintableString PRIVATE REAL RELATIVE-OID SEQUENCE SET SIZE STRING SYNTAX T61String TAGS TeletexString TRUE TYPE-IDENTIFIER UNION UNIQUE UNIVERSAL UniversalString UTCTime UTF8String VideotexString VisibleString WITH

Names of reserved words –
ABSTRACT-SYNTAX ALL APPLICATION AUTOMATIC BEGIN BIT BMPString BOOLEAN BY CHARACTER CHOICE CLASS COMPONENT COMPONENTS CONSTRAINED CONTAINING DEFAULT DEFINITIONS EMBEDDED

Lexical items with the above names shall consist of the sequence of characters in the name, and are reserved character sequences.
NOTE 1 – White-space does not occur in these sequences. NOTE 2 – The keywords CLASS, CONSTRAINED, CONTAINING, ENCODED, INSTANCE, SYNTAX and UNIQUE are not used in this Recommendation | International Standard; they are used in ITU-T Rec. X.681 | ISO/IEC 8824-2, ITU-T Rec. X.682 | ISO/IEC 8824-3 and ITU-T Rec. X.683 | ISO/IEC 8824-4.

12
12.1

Module definition
A "ModuleDefinition" is specified by the following productions: ModuleDefinition ::= ModuleIdentifier
DEFINITIONS

TagDefault ExtensionDefault "::="
BEGIN

ModuleBody
END

ModuleIdentifier ::= modulereference DefinitiveIdentifier DefinitiveIdentifier ::= "{" DefinitiveObjIdComponentList "}" | empty DefinitiveObjIdComponentList ::= DefinitiveObjIdComponent | DefinitiveObjIdComponent DefinitiveObjIdComponentList

22

ITU-T Rec. X.680 (07/2002)

ISO/IEC 8824-1:2003 (E) DefinitiveObjIdComponent ::= NameForm | DefinitiveNumberForm | DefinitiveNameAndNumberForm DefinitiveNumberForm ::= number

DefinitiveNameAndNumberForm ::= identifier "(" DefinitiveNumberForm ")" TagDefault ::= | | |
EXPLICIT TAGS IMPLICIT TAGS AUTOMATIC TAGS

empty
EXTENSIBILITY IMPLIED

ExtensionDefault ::= | empty

ModuleBody ::= Exports Imports AssignmentList | empty Exports ::= | |
EXPORTS SymbolsExported ";" EXPORTS ALL ";"

empty

SymbolsExported ::= SymbolList | empty Imports ::=
IMPORTS SymbolsImported ";"

|

empty

SymbolsImported ::= SymbolsFromModuleList | empty SymbolsFromModuleList ::= SymbolsFromModule | SymbolsFromModuleList SymbolsFromModule SymbolsFromModule ::= SymbolList FROM GlobalModuleReference GlobalModuleReference ::= modulereference AssignedIdentifier AssignedIdentifier ::= ObjectIdentifierValue | DefinedValue | empty SymbolList ::= Symbol | SymbolList "," Symbol Symbol ::= Reference | ParameterizedReference Reference ::= typereference | valuereference | objectclassreference | objectreference | objectsetreference ITU-T Rec. X.680 (07/2002) 23

ISO/IEC 8824-1:2003 (E) AssignmentList ::= Assignment | AssignmentList Assignment Assignment ::= TypeAssignment | ValueAssignment | XMLValueAssignment | ValueSetTypeAssignment | ObjectClassAssignment | ObjectAssignment | ObjectSetAssignment | ParameterizedAssignment
NOTE 1 – The use of a "ParameterizedReference" in the "Exports" and "Imports" lists is specified in ITU-T Rec. X.683 | ISO/IEC 8824-4. NOTE 2 – For examples (and for the definition in this Recommendation | International Standard of types with universal class tags), the "ModuleBody" can be used outside of a "ModuleDefinition". NOTE 3 – "TypeAssignment", "ValueAssignment", "XMLValueAssignment" and "ValueSetTypeAssignment" productions are specified in clause 15. NOTE 4 – The value of "TagDefault" for the module definition affects only those types defined explicitly in the module. It does not affect the interpretation of imported types. NOTE 5 – The character semicolon does not appear in the assignment list specification or any of its subordinate productions, and is reserved for use by ASN.1 tool developers.

12.2

The "TagDefault" is taken as EXPLICIT TAGS if it is "empty".

NOTE – Clause 30 gives the meaning of EXPLICIT TAGS, IMPLICIT TAGS, and AUTOMATIC TAGS.

12.3 When the AUTOMATIC TAGS alternative of "TagDefault" is selected, automatic tagging is said to be selected for the module, otherwise it is said to be not selected. Automatic tagging is a syntactical transformation which is applied (with additional conditions) to the "ComponentTypeLists" and "AlternativeTypeLists" productions occurring within the definition of the module. This transformation is formally specified by 24.7 to 24.9, 26.3 and 28.2 to 28.5 regarding the notations for sequence types, set types and choice types, respectively. 12.4 The EXTENSIBILITY IMPLIED option is equivalent to the textual insertion of an extension marker ("...") in the definition of each type in the module for which it is permitted. The location of the implied extension marker is the last position in the type where an explicitly specified extension marker is allowed. The absence of EXTENSIBILITY IMPLIED means that extensibility is only provided for those types within the module where an extension marker is explicitly present.
NOTE – EXTENSIBILITY IMPLIED affects only types. It has no effect on object sets and subtype constraints.

12.5

The "modulereference" appearing in the "ModuleIdentifier" production is called the module name.

NOTE – The possibility of defining a single ASN.1 module by the use of several occurrences of "ModuleBody" assigned the same "modulereference" was (arguably) permitted in earlier specifications. It is not permitted by this Recommendation | International Standard.

12.6 Module names shall be used only once (except as specified in 12.9) within the sphere of interest of the definition of the module. 12.7 If the "DefinitiveIdentifier" is not empty, the denoted object identifier value unambiguously and uniquely identifies the module being defined. No defined value may be used in defining the object identifier value.
NOTE – The question of what changes to a module require a new "DefinitiveIdentifier" is not addressed in this Recommendation | International Standard.

12.8 If the "AssignedIdentifier" is not empty, the "ObjectIdentifierValue" and the "DefinedValue" alternatives unambiguously and uniquely identify the module from which reference names are being imported. When the "DefinedValue" alternative of "AssignedIdentifier" is used, it shall be a value of type object identifier. Each "valuereference" which textually appears within an "AssignedIdentifier" shall satisfy one of the following rules: a) It is defined in the "AssignmentList" of the module being defined, and all "valuereference"s which textually appear on the right side of the assignment statement also satisfy this rule (rule "a") or the next rule (rule "b"). It appears as a "Symbol" in a "SymbolsFromModule" whose "AssignedIdentifier" does not textually contain any "valuereference"s.

b)

NOTE – It is recommended that an object identifier be assigned so that others can unambiguously refer to the module.

24

ITU-T Rec. X.680 (07/2002)

or be present in the "Imports" clause. 12. NOTE 1 – This does not prohibit the same symbol name defined in two different modules from being imported into another module. every "Symbol" defined in the module or imported by the module may be referenced from other modules subject to the restriction specified in 12. NOTE – The "empty" alternative of "Exports" is included for backwards compatibility. if the same "Symbol" name appears more than once in the "Imports" clause of module A.9 The "GlobalModuleReference" in a "SymbolsFromModule" shall appear in the "ModuleDefinition" of another module. "Type".ISO/IEC 8824-1:2003 (E) 12. then the empty alternative of "SymbolsExported" (not of "Exports") shall be selected.680 (07/2002) 25 . 12.13). or appears exactly once in the "SymbolsImported" alternative of "Imports". and the "AssignedIdentifier".16 When the "empty" alternative of "Imports" is selected.11 When the referenced module has a non-empty "DefinitiveIdentifier".15). the latter shall be considered definitive. "Objectclass". when non-empty. 12. the "modulereference" may differ in the two cases. "Enumeration" or "NamedBitList" are implicitly exported if the typereference that defines them is exported or appears as a component (or subcomponent) within an exported type. NOTE 2 – An effect of c) and d) is that the statement IMPORTS. If there are no such "Symbol"s. b) If the "SymbolsExported" alternative of "Exports" is selected in the definition of the module denoted by the "GlobalModuleReference" in "SymbolsFromModule" the "Symbol" shall appear in its "SymbolsExported". c) d) e) All the "SymbolsFromModule" in the "SymbolsFromModuleList" shall include occurrences of "GlobalModuleReference" such that: i) ii) the "modulereference" in them are all different from each other and from the "modulereference" associated with the referencing module. and the "Symbol" is not defined in the referenced module. the module may still reference "Symbols" defined in other modules by means of an "External<X>Reference". NOTE – A different "modulereference" from that used in the other module should only be used when symbols are to be imported from two modules with the same name (the modules being named in disregard of 12.13 When either the "empty" alternative or the EXPORTS ALL alternative of "Exports" is selected. or "Objectset"). The use of alternative distinct names makes these names available for use in the body of the module (see 12. c) 12. denotes object identifier values which are all different from each other and from the object identifier value (if any) associated with the referencing module. However. that "Symbol" name cannot be exported from A for import to another module B. NOTE – The "empty" alternative of "Imports" is included for backwards compatibility. every "Symbol" to which reference from outside the module is appropriate shall be included in the "SymbolsExported" and only these "Symbol"s may be referenced from outside the module (subject to the relaxation specified in 12.14 Identifiers that appear in a "NamedNumberList". Importing a "Symbol" present in the "Imports" clause of the referenced module is only allowed if there is only one occurrence of the "Symbol" in that clause. 12. Only those "Symbol"s that appear amongst the "SymbolList" of a "SymbolsFromModule" may appear as the symbol in any "External<X>Reference" which has the "modulereference" denoted by the "GlobalModuleReference" of that "SymbolsFromModule" (where <X> is "Value". the "GlobalModuleReference" referencing that module shall not have an empty "AssignedIdentifier". X. 12. except that if it includes a non-empty "DefinitiveIdentifier". implies that the module cannot contain an "External<X>Reference". ITU-T Rec.6).12 When the "SymbolsExported" alternative of "Exports" is selected: a) each "Symbol" in "SymbolsExported" shall satisfy one and only one of the following conditions: i) ii) b) is only defined in the module being constructed. "Object".10 When both a "modulereference" and a non-empty "AssignedIdentifier" are used in referencing a module.12 a). and if there are no such "Symbol"s.15 When the "SymbolsImported" alternative of "Imports" is selected: a) Each "Symbol" in "SymbolsFromModule" shall either be defined in the module body. then the "empty" alternative of "SymbolsImported" shall be selected. 12. of the module denoted by the "GlobalModuleReference" in "SymbolsFromModule".

see ITU-T Rec. "SET" or "SET_OF".681 | ISO/IEC 8824-2. X. and the value identified by a "ParameterizedValue" are specified in ITU-T Rec. The type identified by a "ParameterizedType" and "ParameterizedValueSetType". 8.1 Referencing type and value definitions The defined type and value productions: DefinedType ::= ExternalTypeReference | Typereference | ParameterizedType | ParameterizedValueSetType DefinedValue ::= ExternalValueReference | Valuereference | ParameterizedValue specify the sequences which shall be used to reference type and value definitions. In no two assignments within an "AssignmentList" shall the reference names be the same.3 The third alternative shall not be used as the "NonParameterizedTypeName" in the "XMLTypedValue" of "XMLValueAssignment" (see 15.683 | ISO/IEC 8824-4. X. X. The meaning associated with the "Symbol" is that which it has in the module denoted by the corresponding "GlobalModuleReference".1 type. 26 ITU-T Rec.1 ITU-T Rec.2 The "NonParameterizedTypeName" production: NonParameterizedTypeName ::= ExternalTypeReference | typereference | xmlasn1typename is used when an XML tag name is needed to represent an ASN. X. "SEQUENCE_OF". The restriction is not present for use of this notation in encoding rules (such as XER. denoting the reference name being defined. 11. Where it does not so appear.693 | ISO/IEC 8825-4) because XML tags formed from "xmlasn1typename"s are not used to determine the types that are being encoded. 9.18 A "Symbol" in a "SymbolsFromModule" may appear in "ModuleBody" as a "Reference". "ENUMERATED".2) or of "XMLOpenTypeFieldVal" (see ITU-T Rec.20 The various alternatives for "Assignment" are defined in the following clauses in this Recommendation | International Standard. 13.1 ITU-T Rec.6) when the XML value notation is used in an ASN. 13 13. it shall only be used in an "External<X>Reference".681 | ISO/IEC 8824-2.1 ITU-T Rec.2 15. X. or appears in one or more other instances of "SymbolsFromModule". except as noted otherwise: Assignment alternative "TypeAssignment" "ValueAssignment" "XMLValueAssignment" "ValueSetTypeAssignment" "ObjectClassAssignment" "ObjectAssignment" "ObjectSetAssignment" "ParameterizedAssignment" Defining subclause 15.681 | ISO/IEC 8824-2.1 module if the "xmlasn1typename" is "CHOICE".6 ITU-T Rec.683 | ISO/IEC 8824-4. X.1 module because these "xmlasn1typename"s do not define an ASN.19 Where the "Symbol" also appears in an "AssignmentList" (deprecated). it shall be used directly as a "Reference".680 (07/2002) . X.1 The first symbol of every "Assignment" is one of the alternatives of "Reference". NOTE – This restriction is imposed in XML value notation used in an ASN. X. 12.2 15. 14.ISO/IEC 8824-1:2003 (E) 12.681 | ISO/IEC 8824-2.1 type. 12. 13. "SEQUENCE". 12. 12. "Enumeration" or "NamedBitList" are implicitly imported if the typereference that defines them is imported or appears as a component (or subcomponent) within an imported type.17 Identifiers that appear in a "NamedNumberList".1 15.

values.2).6.1 and 15.6. if the same "Symbol" appears more than once in the IMPORTS clause of a module A. X. the "typereference".6 An external reference shall be used in a module only to refer to a reference name which is defined in a different module. or are present in the "Imports" clause. Referencing a name in the "Imports" clause of another module shall only be allowed if there is no more than one occurrence of the "Symbol" in that clause.2. 13. X. within the "ModuleBody" used to define the corresponding "modulereference".2) to the "typereference" or "valuereference". "ExternalObjectReference" and 13. etc. NOTE – This does not prohibit the same "Symbol" defined in two different modules from being imported into another module. the "modulereference" in the external reference shall appear in the "ModuleDefinition" of the module (different from the referencing module) where the "Reference" is defined. and is specified by the following productions: ExternalTypeReference ::= modulereference ". then that "Symbol" cannot be referenced using module A in an external reference.18.1 specification of a "DefinedValue" is governed by a "Type". 13. "ExternalObjectSetReference") are specified in ITU-T Rec.ISO/IEC 8824-1:2003 (E) 13." ComponentId ItemId ::= ItemSpec ITU-T Rec.2.1 There is a requirement for formal reference to components of ASN. However. 13." ItemSpec ItemSpec ::= typereference | ItemId ". One such instance is the need to write text to identify a specific type within some ASN.9 Every occurrence within an ASN. "valuereference". "ParameterizedValueSetType" or "ParameterizedValue" alternatives shall not be used unless the reference is within the "ModuleBody" in which a type or value is assigned (see 15." typereference ExternalValueReference ::= modulereference ".1 module.1 and 15.8 Where a "DefinedType" is used as part of notation governed by a "Type" (for example. and that "DefinedValue" shall reference a value of a type that is compatible with the governing "Type" as specified in clause B. When the referencing module is defined using the "empty" alternative of "Imports". 13.680 (07/2002) 27 .1 type definition can be referenced by use of the "AbsoluteReference" syntactic construct: AbsoluteReference ::= "@" ModuleIdentifier ".681 | ISO/IEC 8824-2.3 Any part of any ASN. "ParameterizedType". the "modulereference" in the external reference shall appear in the "GlobalModuleReference" of exactly one of the "SymbolsFromModule" in the "SymbolsImported". 14.5 The "ExternalTypeReference" and "ExternalValueReference" shall not be used unless the corresponding "typereference" or "valuereference": a) b) has been assigned a type or value respectively (see 15.1 components 14.1 types. in a "SubtypeConstraint") then the "DefinedType" shall be compatible with the governing "Type" as specified in clause B.4 Except as specified in 12. for many purposes. This clause defines a notation which can be used to provide such references. 14 Notation to support references to ASN.7 When the referencing module is defined using the "SymbolsImported" alternative of "Imports".2 The notation enables any component of a set or sequence type (which is either mandatorily or optionally present in the type) to be identified." valuereference NOTE – Additional external reference productions ("ExternalClassReference". 14.

15 15.5 When the first altenative of "DefinitiveIdentifier" is used as part of the "ModuleIdentifier".* shall be an odd integer) which is used to state that if the number of components in b is odd. and is required to be one of the "identifier"s of the "NamedType" in the "ComponentTypeLists" of that set or sequence. 14.2 A "valuereference" shall be assigned a value by the notation specified by either the "ValueAssignment" or "XMLValueAssignment" productions: ValueAssignment ::= valuereference Type "::=" Value 28 ITU-T Rec. or choice type. b SET OF INTEGER } END the components of "T" could be referenced by text outside an ASN. 14.1 reserved word (see 11.1 module (or in a comment).6 The "typereference" references any ASN. NOTE – In the following example: M DEFINITIONS ::= BEGIN T ::= SEQUENCE { a BOOLEAN. It can also be used if the "ItemId" identifies a choice type.T. 15.if (@M. sequence-of. 14. 14. The value zero identifies a conceptual integer type component (not explicitly present in transfer) that contains a count of the number of instances of the type in the sequence-of or set-of that are present in the value of the enclosing type.b.1. and is then required to be one of the "identifier"s of a "NamedType" in the "AlternativeTypeLists" of that choice type. the "DefinitiveIdentifier" unambiguously and uniquely identifies the module from which a name is being referenced.ISO/IEC 8824-1:2003 (E) ComponentId ::= identifier | number | "*" NOTE – The AbsoluteReference production is not used elsewhere in this Recommendation | International Standard. 14.0 is odd) then: -(@M. It shall be the last "ComponentId" if the component it identifies is not a set. set-of.27).4 The "ModuleIdentifier" identifies an ASN. all components of b must be odd.1 module (see 12.8 The "identifier" form of "ComponentId" can be used if the parent "ItemId" is a set or sequence type.1 type defined in the module identified by "ModuleIdentifier".10 The "*" form of "ComponentId" can be used only if the "ItemId" is a sequence-of or set-of. 14. 14. The value of the number identifies the instance of the type in the sequence-of or set-of. Any semantics associated with the use of the "*" form of "ComponentId" apply to all components of the sequence-of and set-of.1 Assigning types and values A "typereference" shall be assigned a type by the notation specified by the "TypeAssignment" production: TypeAssignment ::= typereference "::=" Type The "typereference" shall not be an ASN. It is provided for the purposes stated in 14. X.T.9 The number form of "ComponentId" can be used only if the "ItemId" is a sequence-of or set-of type. It cannot be used in any other circumstance.1). sequence.7 The "ComponentId" in each "ItemSpec" identifies a component of the type which has been identified by the "ItemId".b. such as: -. with the value "1" identifying the first instance of the type.680 (07/2002) .

3 "Value" is a notation for a value of a type as specified in 16. 15.6 A "typereference" can be assigned a value set by the notation specified by the "ValueSetTypeAssignment" production: ValueSetTypeAssignment ::= typereference Type "::=" ValueSet This notation assigns to "typereference" the type defined as a subtype of the type denoted by "Type" and which contains exactly the values which are specified in or allowed by "ValueSet".5 The second alternative of "XMLTypedValue" (use of an XML empty-element tag) can be used only if an instance of the "XMLValue" production is empty. 15. NOTE – If the "XMLValue" production was an "xmlcstring" containing only white-space.7. 15. and the second alternative could not be used. 15.1 built-in type in the corresponding row of Table 4 (see also 13. X. and is governed by "Type" and shall be a notation for a value of the type defined by "Type" (as specified in 15. specified by "ElementSetSpecs" (see clause 46).7. The "typereference" shall not be an ASN. and shall be a notation for a value of the type defined by "NonParameterizedTypeName" (as specified in 15. including the application of encoding rules.10). 15.7 A value set governed by some type shall be specified by the notation "ValueSet": ValueSet ::= "{" ElementSetSpecs "}" The value set comprises all of the values.3). then it identifies the ASN. this would not be empty. this is defined to be exactly equivalent to the use of the production: typereference "::=" Type "(" ElementSetSpecs ")" with the same "Type" and "ElementSetSpecs" specifications.ISO/IEC 8824-1:2003 (E) XMLValueAssignment ::= valuereference "::=" XMLTypedValue XMLTypedValue ::= "<" & NonParameterizedTypeName ">" XMLValue "</" & NonParameterizedTypeName ">" | "<" & NonParameterizedTypeName "/>" The value being assigned to the "valuereference" in the "ValueAssignment" is "Value". "ValueSet" is defined in 15. 15.8 The "ValueSetTypeAssignment" production expands into: typereference Type "::=" "{" ElementSetSpecs "}" For all purposes.4 "XMLValue" is a notation for a value of a type if "XMLValue" is an "XMLBuiltinValue" notation for the type (see 16. The value being assigned to the "valuereference" in the "XMLValueAssignment" is "XMLValue" (see 16.7).3). If this is the "xmlasn1typename" item.27). and may be referenced as a type.4). of which there shall be at least one. ITU-T Rec.1 reserved word (see 11.680 (07/2002) 29 .

1 are specified by the notation "ReferencedType": ReferencedType ::= DefinedType | UsefulType | SelectionType | TypeFromObject | ValueSetFromObjects The "ReferencedType" notation provides an alternative means of referring to some other type (and ultimately to a builtin type). and the way in which the type to which they refer is determined. X. X.680 (07/2002) .681 | ISO/IEC 8824-2.3 21 17 36 28 33 19 34 ITU-T Rec. are specified in the following places in this Recommendation | International Standard unless otherwise stated: 30 ITU-T Rec.1 Definition of types and values A type shall be specified by the notation "Type": Type ::= BuiltinType | ReferencedType | ConstrainedType 16.ISO/IEC 8824-1:2003 (E) 16 16. The various "ReferencedType" notations. defined as follows: BuiltinType ::= BitStringType | BooleanType | CharacterStringType | ChoiceType | EmbeddedPDVType | EnumeratedType | ExternalType | InstanceOfType | IntegerType | NullType | ObjectClassFieldType | ObjectIdentifierType | OctetStringType | RealType | RelativeOIDType | SequenceType | SequenceOfType | SetType | SetOfType | TaggedType The various "BuiltinType" notations are defined in the following clauses (in this Recommendation | International Standard unless otherwise stated): BitStringType BooleanType CharacterStringType ChoiceType EmbeddedPDVType EnumeratedType ExternalType InstanceOfType IntegerType NullType ObjectClassFieldType ObjectIdentifierType OctetStringType RealType RelativeOIDType SequenceType SequenceOfType SetType SetOfType TaggedType 16.1 are specified by the notation "BuiltinType".1 31 22 20 32 24 25 26 27 30 The referenced types of ASN.681 | ISO/IEC 8824-2. 14. Annex C 18 23 ITU-T Rec. X.2 The built-in types of ASN.

X.4 13.7 A value of some type shall be specified by the notation "Value" or by the notation "XMLValue": Value ::= BuiltinValue | ReferencedValue | ObjectClassFieldValue XMLValue ::= XMLBuiltinValue | XMLObjectClassFieldValue NOTE 1 – "ObjectClassFieldValue" and "XMLObjectClassFieldValue" are defined in ITU-T Rec. can be replaced by a single XML empty-element tag (<field1/>).4.6.ISO/IEC 8824-1:2003 (E) DefinedType UsefulType SelectionType TypeFromObject ValueSetFromObjects 16.682 | ISO/IEC 8824-3).5 This Recommendation | International Standard requires the use of the notation "NamedType" in specifying the components of the set types.10) or "BuiltinValue". in inner subtype constraints and in component relation constraints (see ITU-T Rec. and any intervening white-space. these two XML tags.1. X.1. sequence type or choice type in the value notation. 16. The notation for "NamedType" is: NamedType ::= identifier Type 16. clause 15 ITU-T Rec.681 | ISO/IEC 8824-2.1 29 ITU-T Rec. 14. ITU-T Rec. <field1></field1>).8 If any part of the "XMLValue" production results in an XML start-tag immediately followed by an XML endtag.681 | ISO/IEC 8824-2. sequence types and choice types.4 (for example.6 The "identifier" is used to unambiguously refer to components of a set type.2. the condition above is not satisfied.1 can be specified by the notation "XMLBuiltinValue" (see 16. possibly separated by white-space inserted as permitted by 11.681 | ISO/IEC 8824-2. clause 15 The "ConstrainedType" is defined in clause 45. X. as listed in 16.680 (07/2002) 31 . 16.9 Values of the built-in types of ASN. 16. defined as follows: BuiltinValue ::= BitStringValue | BooleanValue | CharacterStringValue | ChoiceValue | EmbeddedPDVValue | EnumeratedValue | ExternalValue | InstanceOfValue | IntegerValue | NullValue | ObjectIdentifierValue | OctetStringValue | RealValue | RelativeOIDValue | SequenceValue | SequenceOfValue | SetValue | SetOfValue | TaggedValue Each of the various "BuiltinValue" notations is defined in the same subclause as the corresponding "BuiltinType" notation. X. 16. X.1 41. NOTE – If any white-space character. except white-space inserted as permitted by 11. is present between the final ">" character of the start tag and the initial "<" character of the end-tag. and has no effect on the type. It is not part of the type. NOTE 2 – "XMLValue" is only used in "XMLTypedValue".

These productions are: NamedValue ::= identifier Value XMLNamedValue ::= "<" & identifier ">" XMLValue "</" & identifier ">" where the "identifier" is the same as that used in the "NamedType" notation.1 are specified by the notation "ReferencedValue": ReferencedValue ::= DefinedValue | ValueFromObject The "ReferencedValue" notation provides an alternative means of referring to some other value (and ultimately to a built-in value). 16. its values can be specified by either a "BuiltinValue" or "ReferencedValue" of that type.6. 17 17. 16. as listed in 16. The various "ReferencedValue" notations.1 Notation for the boolean type The boolean type (see 3. the value notation for a type with an extension marker is exactly the same as if the extension marker was absent.7) shall be referenced by the notation "BooleanType": BooleanType ::= BOOLEAN 17. sequence type or choice type. It is used to unambiguously refer to the components of a set type.11 The referenced values of ASN. 16. or when used as part of an "XMLValue".1 ITU-T Rec.ISO/IEC 8824-1:2003 (E) 16. clause 15 16.8 prohibits value notation used in a subtype constraint from referencing a value that is not in the extension root of the parent type.681 | ISO/IEC 8824-2. NOTE – Subclause 46.680 (07/2002) . it does not form part of the value itself.4) or explicit presence of an extension marker (see clause 6) in the definition of a type has no effect on the value notation.2 The tag for types defined by this notation is universal class.14 The implied (see 12. and the way in which the value to which they refer is determined.13 The value of a type referenced using the "NamedType" notation shall be defined by the notation "NamedValue". X.12 Regardless of whether or not a type is a "BuiltinType".10 "XMLBuiltinValue" is defined as follows: XMLBuiltinValue ::= XMLBitStringValue | XMLBooleanValue | XMLCharacterStringValue | XMLChoiceValue | XMLEmbeddedPDVValue | XMLEnumeratedValue | XMLExternalValue | XMLInstanceOfValue | XMLIntegerValue | XMLNullValue | XMLObjectIdentifierValue | XMLOctetStringValue | XMLRealValue | XMLRelativeOIDValue | XMLSequenceValue | XMLSequenceOfValue | XMLSetValue | XMLSetOfValue | XMLTaggedValue Each of the various "XMLBuiltinValue" notations is defined in the same clause as the corresponding "BuiltinType" notation. number 1. That is.2 above. X. by the notation "XMLNamedValue". 32 ITU-T Rec. are specified in the following places (in this Recommendation | International Standard unless otherwise stated): DefinedValue ValueFromObject 13. NOTE – The "identifier" is part of the notation. "ReferencedType" or "ConstrainedType".

7 18. by the notation "XMLIntegerValue". and represents a distinguished value of the integer type. 18.10 The "identifier" in "IntegerValue" and in "XMLIntegerValue" shall be one of the "identifier"s in the "IntegerType" with which the value is associated. use of the "identifier" form of "IntegerValue" and "XMLIntegerValue" should be preferred.8 Each "identifier" appearing in the "NamedNumberList" shall be different.38) shall be defined by the notation "BooleanValue". These productions are: IntegerValue ::= SignedNumber | identifier XMLIntegerValue ::= SignedNumber | "<" & identifier "/>" 18. or when used as an "XMLValue".1 Notation for the integer type The integer type (see 3.2 The second alternative of "SignedNumber" shall not be used if the "number" is zero. These productions are: BooleanValue ::= TRUE | FALSE XMLBooleanValue ::= "<" & "true" "/>" | "<" & "false" "/>" 18 18.5 The value of each "SignedNumber" or "DefinedValue" appearing in the "NamedNumberList" shall be different. b(a) } c T2 ::= b d T2 ::= a c denotes the value 1.73 and 3. and d denotes the value 3.9 The value of an integer type shall be defined by the notation "IntegerValue"." NamedNumber NamedNumber ::= identifier "(" SignedNumber ")" | identifier "(" DefinedValue ")" SignedNumber ::= number | "-" number 18. ITU-T Rec.6.6. 18.41) shall be referenced by the notation "IntegerType": IntegerType ::= | INTEGER INTEGER "{" NamedNumberList "}" NamedNumberList ::= NamedNumber | NamedNumberList ".ISO/IEC 8824-1:2003 (E) 17. and shall represent the corresponding number. X.4 The "valuereference" in "DefinedValue" shall be of type integer. NOTE – Since an "identifier" cannot be used to specify the value associated with "NamedNumber".9.3 The value of a boolean type (see 3. The tag for types defined by this notation is universal class.3 The "NamedNumberList" is not significant in the definition of a type. Therefore in the following case a INTEGER ::= 1 T1 ::= INTEGER { a(2) } T2 ::= INTEGER { a(3). by the notation "XMLBooleanValue". The order of the "NamedNumber"s in the "NamedNumberList" is not significant. It is used solely in the value notation specified in 18.680 (07/2002) 33 . or when used as an "XMLValue". NOTE – When referencing an integer value for which an "identifier" has been defined. 18. number 2. since it cannot be a reference to the second nor the third occurrence of a.6. 18. the "DefinedValue" can never be misinterpreted as an "IntegerValue". 18.6 18.

." Enumeration EnumerationItem ::= identifier | NamedNumber NOTE 1 – Each value of an "EnumeratedType" has an identifier which is associated with a distinct integer. 34 ITU-T Rec. Subclauses 18. 19. c(0).. .. 'c' = 1 valid." ExceptionSpec | RootEnumeration "..7 The enumerated type has a tag which is universal class. {a.. the "identifier" and the "SignedNumber" shall be distinct from all other "identifier"s and "SignedNumber"s in the "Enumeration"..6.2 and 18. However.4 The value of each new "AdditionalEnumeration"s in the type... the successive integers starting with 0. . c} b.. c(2)} ----invalid. by the notation "XMLEnumeratedValue". {a. c(3)... d} ----c d d d = = = = 2 3 4 1 19. NOTE 2 – The numeric values inside the "NamedNumber"s in the "RootEnumeration" are not necessarily ordered or contiguous..1 specification. "EnumerationItem" shall be greater than all previously defined 19. {a. . are assigned.. . . {a. d} b. 19. b.2 For each "NamedNumber"." ". number 10. b." ExceptionSpec ". .. c.5 When a "NamedNumber" is used in defining an "EnumerationItem" in the "AdditionalEnumeration"..1 Notation for the enumerated type The enumerated type (see 3.3 Each "EnumerationItem" (in an "EnumeratedType") which is an "identifier" is successively assigned a distinct non-negative integer.. 'c' = 2 19.8 The value of an enumerated type shall be defined by the notation "EnumeratedValue".. since both 'a' and 'c' equal 0 invalid.. or when used as an "XMLValue".. since both 'c' and 'd' equal 2 valid.680 (07/2002) . For example.. but excluding any which are employed in "EnumerationItem"s which are "NamedNumber"s. ." AdditionalEnumeration RootEnumeration ::= Enumeration AdditionalEnumeration ::= Enumeration Enumeration ::= EnumerationItem | EnumerationItem ".ISO/IEC 8824-1:2003 (E) 18. Specifying the "NamedNumber" alternative of "EnumerationItem" provides control of the representation of the value in order to facilitate compatible extensions. 19.. c(1)} b.. {a. d(2)} b(3). .. {a. any occurrence of a name that is both an "identifier" from the "NamedNumberList" and a reference name shall be interpreted as the "identifier". These productions are: EnumeratedValue ::= identifier XMLEnumeratedValue ::= "<" & identifier "/>" 19.9 The "identifier" in "EnumeratedValue" and "XMLEnumeratedValue" shall be equal to that of an "identifier" in the "EnumeratedType" sequence with which the value is associated. It is not otherwise used in the ASN.. the following are all valid: A B C D ::= ::= ::= ::= ENUMERATED ENUMERATED ENUMERATED ENUMERATED {a.. 19 19. NOTE – An integer value is associated with an "EnumerationItem" to assist in the definition of encoding rules. For example: A B C D ::= ::= ::= ::= ENUMERATED ENUMERATED ENUMERATED ENUMERATED {a." "..24) shall be referenced by the notation "EnumeratedType": EnumeratedType ::= ENUMERATED "{" Enumerations "}" Enumerations ::= RootEnumeration | RootEnumeration ". 19. c(0)} b.. and the numeric values inside the "NamedNumber"s in the "AdditionalEnumeration" are ordered but not necessarily contiguous. For the "RootEnumeration". X.6 The value associated with the first "EnumerationItem" in the "AdditionalEnumeration" alternative that is an "identifier" (not a "NamedNumber") shall be the smallest value for which an "EnumerationItem" is not defined in the "RootEnumeration" and all preceding "EnumerationItem"s in the "AdditionalEnumeration" (if any) are smaller. the value associated with it shall be different from the value of all previously defined "EnumerationItem"s (in this type) regardless of whether the previously defined "EnumerationItem"s occur in the enumeration root or not.4 also apply to each "NamedNumber".. d} z(25).11 Within an instance of value notation for an integer type with a "NamedNumberList". the values themselves are not expected to have any integer semantics.

20. B and E: M x BE where M is called the mantissa. 20. and an encoding which permits efficient transformation to and from hardware floating point representations if "base" is 2. B the base. In particular.5 The associated type for value definition and subtyping purposes is (with normative comments): SEQUENCE { mantissa INTEGER. base INTEGER (2|10). and E the exponent.3 The values of the real type are the values PLUS-INFINITY and MINUS-INFINITY together with the real numbers capable of being specified by the following formula involving three integers.1 Notation for the real type The real type (see 3. ITU-T Rec.680 (07/2002) 35 .. by the notation "XMLRealValue": RealValue ::= NumericRealValue | SpecialRealValue NumericRealValue ::= realnumber | "-" realnumber | SequenceValue SpecialRealValue ::= | PLUS-INFINITY MINUS-INFINITY -. the encoding in BER and PER provides a Binary-Coded Decimal (BCD) encoding if "base" is 10.10 Within an instance of value notation for an enumerated type. NOTE – Encoding rules may define a different type which is used to specify encodings. base (10)}) can be used to restrict the set of values to base 10 abstract values (and similarly for base 2 abstract values).6 The value of a real type shall be defined by the notation "RealValue".multiplied by "base" raised to the power "exponent" } NOTE 1 – Non-zero values represented by "base" 2 and by "base" 10 are considered to be distinct abstract values even if they evaluate to the same real number value. NOTE 2 – The notation REAL (WITH COMPONENTS { . or may specify encodings without reference to the associated type. XMLRealValue ::= XMLNumericRealValue | XMLSpecialRealValue XMLNumericRealValue ::= realnumber | "-" realnumber The second alternative of "XMLNumericRealValue" shall not be used for zero values. NOTE 3 – This type is capable of carrying an exact finite representation of any number which can be stored in typical floating point hardware. and may carry different application semantics. exponent INTEGER -. M.. any occurrence of a name that is both an "identifier" from the "Enumeration" and a reference name shall be interpreted as the "identifier".Value of the associated sequence type The second and third alternatives of "NumericRealValue" shall not be used for zero values. . and of any number with a finite character-decimal representation.54) shall be referenced by the notation "RealType": RealType ::= REAL 20. 20 20.4 The real type has an associated type which is used to give precision to the definition of the abstract values of the real type and is also used to support the value and subtype notations of the real type.ISO/IEC 8824-1:2003 (E) 19.6. number 9.2 The real type has a tag which is universal class. 20. X.The associated mathematical real number is "mantissa" -. or when used in an "XMLValue". 20.

21 21. Application designers should therefore ensure that different semantics are not associated with such values which differ only in the number of trailing 0 bits.9 The value of a bitstring type shall be defined by the notation "BitStringValue". the "DefinedValue" can never be misinterpreted as an "IntegerValue". If the "RealType" is constrained to "base" 2.7 When a "NamedBitList" is used in defining a bitstring type ASN. The "DefinedValue" shall be a reference to a non-negative value of type integer.7 When the "realnumber" notation is used it identifies the corresponding "base" 10 abstract value.4 The value of each "number" or "DefinedValue" appearing in the "NamedBitList" shall be different. Therefore in the following case: a INTEGER ::= 1 T1 ::= INTEGER { a(2) } T2 ::= BIT STRING { a(3). 21. The leading bit of the bit string is identified by the "number" zero.6. with succeeding bits having successive values.2 21. as it cannot be a reference to the second nor the third occurrence of a. the "realnumber" identifies the "base" 2 abstract value corresponding either to the decimal value specified by the "realnumber" or to a locally-defined precision if an exact representation is not possible.5 Each "identifier" appearing in the "NamedBitList" shall be different. and is the number of a distinguished bit in a bitstring value.3 The first bit in a bit string is called the leading bit." identifier 36 ITU-T Rec. 21.680 (07/2002) . b(a) } the last occurrence of a denotes the value 1. These productions are: BitStringValue ::= bstring | hstring | "{" IdentifierList "}" | "{" "}" | CONTAINING Value IdentifierList ::= identifier | IdentifierList ". or when used as an "XMLValue".1 encoding rules are free to add (or remove) arbitrarily any trailing 0 bits to (or from) values that are being encoded or decoded. NOTE 1 – The order of the "NamedBit" production sequences in the "NamedBitList" is not significant. 21. NOTE – This terminology is used in specifying the value notation and in defining encoding rules. NOTE 2 – Since an "identifier" that appears within the "NamedBitList" cannot be used to specify the value associated with a "NamedBit". by the notation "XMLBitStringValue".ISO/IEC 8824-1:2003 (E) XMLSpecialRealValue ::= "<" & PLUS-INFINITY "/>" | "<" & MINUS-INFINITY "/>" 20. Values containing 1 bits other than the named bits are permitted. 21. 21.8 This type has a tag which is universal class. 21. number 3.1 Notation for the bitstring type The bitstring type (see 3.6 The presence of a "NamedBitList" has no effect on the set of abstract values of this type." NamedBit NamedBit ::= identifier "(" number ")" | identifier "(" DefinedValue ")" 21. X.6) shall be referenced by the notation "BitStringType": BitStringType ::= | BIT STRING BIT STRING "{" NamedBitList "}" NamedBitList ::= NamedBit | NamedBitList ". The final bit in a bit string is called the trailing bit.

14 If the bitstring has named bits.1 type and does not include an ENCODED BY. 21.6. the "{" "}" production sequence in "BitStringValue" and the "empty" in "XMLBitStringValue" are used to denote the bitstring which contains no one bits.10 The "XMLTypedValue" alternative shall not be used unless the bitstring has a contents constraint which includes an ASN. These productions are: ITU-T Rec. the leading bit of the bitstring value is on the left. the most significant bit of each hexadecimal digit corresponds to the leftmost bit in the bitstring. NOTE – For a "BitStringType" that has a "NamedBitList". clause 11. in any way.3 forbids further constraints after a "ContentsConstraint". 21. the "BitStringValue" or "XMLBitStringValue" notation denotes a bitstring value with ones in the bit positions specified by the numbers corresponding to the "identifier"s.3 The value of an octetstring type shall be defined by the notation "OctetStringValue".17 The "hstring" notation shall not be used unless the bitstring value consists of a multiple of four bits.680 (07/2002) 37 . by the notation "XMLOctetStringValue". X.19 The CONTAINING alternative shall be used if there is a contents constraint on the bitstring type which does not contain ENCODED BY.16 When using the "hstring" notation. which is thus 15 bits in length. constrain the way encoding rules place a bitstring into octets for transfer. If the type was defined using a "NamedBitList". or when used as an "XMLValue". X.12 Each "identifier" in "BitStringValue" or "XMLBitStringValue" shall be the same as an "identifier" in the "BitStringType" production sequence with which the value is associated.ISO/IEC 8824-1:2003 (E) XMLBitStringValue ::= XMLTypedValue | Xmlbstring | XMLIdentifierList | empty XMLIdentifierList ::= "<" & identifier "/>" | XMLIdentifierList "<" & identifier "/>" 21. X.1 Notation for the octetstring type The octetstring type (see 3. 21. If this alternative is used. NOTE – This notation does not. 21.13 The "empty" alternative denotes a bitstring with no bits.1 type in the contents constraint. the trailing zero does form part of the value. EXAMPLE 'A98A'H and '1010100110001010'B are alternative notations for the same bitstring value.2 This type has a tag which is universal class. 21. and the trailing bit of the bitstring value is on the right.682 | ISO/IEC 8824-3. number 4. 21. and with all other bits zero. NOTE – This value notation can never appear in a subtype constraint because ITU-T Rec. If the type was defined without a "NamedBitList". and the above text forbids its use unless the governor has a "ContentsConstraint". which is thus 16 bits in length.49) shall be referenced by the notation "OctetStringType": OctetStringType ::= OCTET STRING 22. the (single) trailing zero does not form part of the value. 22.682 | ISO/IEC 8824-3.18 The CONTAINING alternative can only be used if there is a contents constraint on the bitstring type which includes CONTAINING. 21. The "Value" shall then be value notation for a value of the "Type" in the "ContentsConstraint" (see ITU-T Rec.11 The "XMLIdentifierList" alternative shall not be used unless the bitstring has a "NamedBitList". clause 11).15 When using the "bstring" or "xmlbstring" notation. the "XMLTypedValue" shall be a value of the ASN. 21. 21. 22 22.

682 | ISO/IEC 8824-3." | ". 23 23." ".3 The value of a null type shall be referenced by the notation "NullValue". 22. or when used as an "XMLValue".. clause 11). X. These productions are: NullValue ::= NULL XMLNullValue ::= empty 24 24.1 type in the contents constraint. 22. the "XMLTypedValue" shall be a value of the ASN.. 22.9 The CONTAINING alternative can only be used if there is a contents constraint on the octetstring type which includes CONTAINING. If this alternative is used.682 | ISO/IEC 8824-3.6.. The "Value" shall then be value notation for a value of the "Type" in the "ContentsConstraint" (see ITU-T Rec." ExceptionSpec OptionalExtensionMarker ::= ". clause 11.8 If the "hstring" is an odd number of hexadecimal digits..10 The CONTAINING alternative shall be used if there is a contents constraint on the octetstring type which does not contain ENCODED BY..680 (07/2002) . the left-most bit of the "bstring" notation shall be the most significant bit of the first octet of the octetstring value.1 type and does not include an ENCODED BY. it shall be interpreted as if it contained additional zero trailing bits to make it the next multiple of eight. it shall be interpreted as if it contained a single additional trailing zero hexadecimal digit. 22.44) shall be referenced by the notation "NullType": NullType ::= NULL 23. 23. 22. The "xmlhstring" shall not be an odd number of hexadecimal digits..4 The "XMLTypedValue" alternative shall not be used unless the octetstring has a contents constraint which includes an ASN. X.60) shall be the "SequenceType": SequenceType ::= | | SEQUENCE "{" "}" SEQUENCE "{" ExtensionAndException OptionalExtensionMarker "}" SEQUENCE "{" ComponentTypeLists "}" ExtensionAndException ::= ". the left-most hexadecimal digit shall be the most significant semi-octet of the first octet. NOTE – This value notation can never appear in a subtype constraint because ITU-T Rec. number 5.5 In specifying the encoding rules for an octetstring. and the bits within an octet are referenced by the terms most significant bit and least significant bit.7 When using the "hstring" or "xmlhstring" notation. 22.2 This type has a tag which is universal class.ISO/IEC 8824-1:2003 (E) OctetStringValue ::= bstring | hstring CONTAINING Value | XMLOctetStringValue ::= XMLTypedValue | xmlhstring 22.1 Notation for sequence types The notation for defining a sequence type (see 3. the octets are referenced by the terms first octet and trailing octet.3 forbids further constraints after a "ContentsConstraint"." ExtensionAndException ExtensionAdditions 38 ITU-T Rec." | empty ComponentTypeLists ::= RootComponentTypeList | RootComponentTypeList ".6. by the notation "XMLNullValue".6 When using the "bstring" notation.1 Notation for the null type The null type (see 3. X. and the above text forbids its use unless the governor has a "ContentsConstraint". If the "bstring" is not a multiple of eight bits.

" RootComponentTypeList ExtensionAndException ExtensionAdditions ExtensionEndMarker ". b. NOTE 1 – The use of the "TaggedType" notation within the definition of the list of components for a sequence type gives control of tags to the specifier. b [1] BOOLEAN. as opposed to automatic assignment by the automatic tagging mechanism.4 "Type" in the "COMPONENTS OF Type" notation shall be a sequence type." ComponentType ComponentType ::= NamedType | NamedType OPTIONAL | NamedType DEFAULT Value | COMPONENTS OF Type 24. Therefore. of all the component types of the referenced type.680 (07/2002) 39 .7 to 24.2 When the "ComponentTypeLists" production occurs within the definition of a module for which automatic tagging is selected (see 12. extension markers and extension additions. X. NOTE 2 – Only those occurrences of the "ComponentTypeLists" production appearing within a module where automatic tagging is selected are candidates for transformation by automatic tagging.4. 24. as specified in 24.ISO/IEC 8824-1:2003 (E) | | | OptionalExtensionMarker RootComponentTypeList ". otherwise it is not. and none of the occurrences of "NamedType" in any of the first three alternatives for "ComponentType" contains a "TaggedType". even if this definition of sequence type T occurs within a module for which automatic tagging is selected. the automatic tagging transformation (if applied) is applied after the COMPONENTS OF transformation.3 The decision to apply the automatic tagging transformation is taken individually for each occurrence of "ComponentTypeLists" and prior to the COMPONENTS OF transformation specified by 24. at this point in the list of components.9.." ExtensionAdditions ::= ".5." "." RootComponentTypeList ExtensionAndException ExtensionAdditions OptionalExtensionMarker RootComponentTypeList ::= ComponentTypeList ExtensionEndMarker ::= ". ITU-T Rec.5 The following subclauses each identify a series of occurrences of "ComponentType" in either the root or the extension additions or both. However. 24. if any." ExtensionAndException ExtensionAdditions ExtensionEndMarker ". in the following case: T ::= SEQUENCE { a INTEGER..) Any subtype constraint applied to the referenced type is ignored by this transformation. then automatic tagging transformation is selected for the entire "ComponentTypeLists".1 shall apply to all such series. NOTE – The effect of this is that the application of automatic tags is suppressed by tags explicitly present in the "ComponentTypeLists"." ExtensionAdditionList | empty ExtensionAdditionList ::= ExtensionAddition | ExtensionAdditionList ". NOTE – This transformation is logically completed prior to the satisfaction of the requirements in the following subclauses." ExtensionAddition ExtensionAddition ::= ComponentType | ExtensionAdditionGroup ExtensionAdditionGroup ::= "[[" VersionNumber ComponentTypeList "]]" VersionNumber ::= empty | number ":" ComponentTypeList ::= ComponentType | ComponentTypeList ". but not by tags present in the "Type" following COMPONENTS OF. (Only the "RootComponentTypeList" of the "Type" in the "COMPONENTS OF Type" is included. The "COMPONENTS OF Type" notation shall be used to define the inclusion. c.3). except for any extension marker and extension additions that may be present in the "Type". are ignored by the "COMPONENTS OF Type" notation. c OCTET STRING } no automatic tagging is applied to the list of components a. The rule of 24. 24.

7 is satisfied. b SEQUENCE { b1 T1. 24. in the following case: T ::= SEQUENCE { a E ::= SEQUENCE { f1 Ta. Thus. the "ClassNumber" in the replacement "TaggedType" is tag value zero for the first "ComponentType" in the "RootComponentTypeList".) 24. with the next "ComponentType" in the "ExtensionAdditionList" having a "ClassNumber" one greater than the first. the tags of those "ComponentType"s and of any immediately following component type in the series shall be 24. automatic tagging is still applied to components a. If T is defined in an automatic tagging environment and E is not in an automatic tagging environment. b3 T3}. in which case it is explicit tagging.8 If automatic tagging is in effect and the "ComponentType"s in the extension root have no tags. NOTE 5 – When automatic tagging is in place. the "ClassNumber" in the replacement "TaggedType" of the first "ComponentType" in the "ExtensionAdditionList" is zero if the "RootComponentTypeList" is missing. the "Type" in the replacement "TaggedType" is the original "Type" being replaced.4. If automatic tagging was selected. the automatic tagging transformation is only applied once to a given "ComponentTypeLists". Thus. e) NOTE 1 – The rules governing specification of implicit tagging or explicit tagging for replacement "TaggedType"s are provided by 30.6.) 24. b2 T2. whatever the tagging environment of T. but only if 24.1 shall apply to the series of "ComponentType"s in the root. 24.. Automatic tagging is always implicit tagging unless the "Type" is a choice type or an open type notation.7 The automatic tagging transformation of an occurrence of "ComponentTypeLists" is logically performed after the transformation specified by 24. In other words.2 Subclause 24.683 | ISO/IEC 8824-4. and are not modified even when the sequence type is referenced in the definition of a component within another "ComponentTypeLists" for which automatic tagging transformation applies. 24. the tags of the components are completely determined.5. b. b f2 Tb. the requirement that tags be distinct applies only after automatic tagging has been performed. c Tc } COMPONENTS OF T. b and c of T. 8. each occurrence of "ComponentType" in it is duplicated by the application of 24.6 When the third or fourth alternative of "ComponentTypeLists" is used. b. one for the second.ISO/IEC 8824-1:2003 (E) Where there are one or more consecutive occurrences of "ComponentType" that are all marked OPTIONAL or DEFAULT.29) may result in changes to other components due to the side effect of modifying the tags thus causing interworking problems with an older version of the specification. in the following case: T ::= SEQUENCE { a W ::= SEQUENCE { x Ta.3 Subclause 24. (See also 48.5. Wx. if any.10 If OPTIONAL or DEFAULT are present.1 distinct (see clause 30). NOTE 3 – When a sequence type appears as the "Type" in "COMPONENTS OF Type". and so on. insertion of new components at any location other than the extension insertion point (see 3. and so on.680 (07/2002) . b2 and b3 are the same in both T and W.2 determines that it shall apply to that occurrence of "ComponentTypeLists". NOTE 2 – Once 24. b and c of T. the corresponding value may be omitted from a value of the new type.4 prior to the possible application of automatic tagging to the referencing sequence type.5.9.9 If automatic tagging is in effect. Automatic tagging transformation impacts each "ComponentType" of the "ComponentTypeLists" by replacing the "Type" originally in the "NamedType" production with a replacement "TaggedType" occurrence specified in 24. T.5. and c within T need not be the same as the tags of a. c f3 Tc } E3 } automatic tagging applied to the components of E never affects the tags attached to components a. tagging is context-specific). and c within W if W has been defined in an automatic tagging environment.e. E1. proceeding with increasing tag numbers. (See also 48. but the tags of b1. 24.7. the replacement "TaggedType" is specified as follows: a) b) c) d) the replacement "TaggedType" notation uses the "Tag Type" alternative. NOTE 4 – Subtyping has no impact on automatic tagging.5. X. 24. then no "ComponentType" within the "ExtensionAdditionList" shall be a "TaggedType".1 shall apply to the complete series of "ComponentType"s in the root or in the extension additions. or a "DummyReference" (see ITU-T Rec. 40 ITU-T Rec.7. in the textual order of their occurrence in the type definition (ignoring all version brackets and ellipsis notation).6. else it is one greater than the largest "ClassNumber" in the "RootComponentTypeList". proceeding with increasing tag numbers. and will always be satisfied. all "ComponentType"s in extension additions shall have tags which are distinct from the tags of the textually following "ComponentType"s up to and including the first such "ComponentType" that is not marked OPTIONAL or DEFAULT in the trailing "RootComponentTypeList". the "Class" of the replacement "TaggedType" is empty (i. y Wy } the tags of a.3). X.

NOTE 1 – Where the type has grown from the extension root (version 1) through version 2 to version 3 by the addition of extension additions. or when used as an "XMLValue".680 (07/2002) 41 . b) the syntax is more precise in that it clearly indicates that a value of a type defined in the "ExtensionAdditionList" and not marked OPTIONAL or DEFAULT should always be present in an encoding if the extension addition group in which it is defined is encoded (compare with Note 1). except when the abstract value is being relayed from a sender that is using an earlier version of the abstract syntax in which the "ComponentType" is not defined. an "ExtensionAdditionGroup" can be used with a single "ExtensionAddition". number 16.g." NamedValue XMLSequenceValue ::= XMLComponentValueList | empty XMLComponentValueList ::= XMLNamedValue | XMLComponentValueList XMLNamedValue 24. PER). These productions are: SequenceValue ::= "{" ComponentValueList "}" | "{" "}" ComponentValueList ::= NamedValue | ComponentValueList ". c) the syntax makes it clear which types in an "ExtensionAdditionList" must as a group be supported by an application. "XMLSequenceValue".16 All sequence types have a tag which is universal class. 24. 24. 24. NOTE 2 – "ComponentType"s that are extension additions but not contained within an "ExtensionAdditionGroup" should always be encoded if they are not marked OPTIONAL or DEFAULT. 24.14 A value for a given extension addition type shall not be specified unless there are values specified for all extension addition types not marked OPTIONAL or DEFAULT that lie logically between the extension addition type and the extension root.11 If DEFAULT occurs. However. which shall be a value notation for a value of the type defined by "Type" in the "NamedType" production sequence.ISO/IEC 8824-1:2003 (E) 24. NOTE – Sequence-of types have the same tag as sequence types (see 25.. 24. NOTE 1 – The convention used here is that the specification with no extension addition groups is version 1. Where a single "ExtensionAddition" is needed for an "ExtensionAdditions". if such a value is present. The "number" in each "VersionNumber" of an "ExtensionAdditionGroup" shall be greater than or equal to two. or the type notation was SEQUENCE{}. X. ITU-T Rec.2). and all values are omitted.17 The notation for defining a value of a sequence type shall be "SequenceValue".13 The "identifier"s in all "NamedType" production sequences of the "ComponentTypeLists" (together with those obtained by expansion of COMPONENTS OF) shall all be distinct. thus the first added extension addition group will have a number greater than or equal to 2.15 A "VersionNumber" shall be used only if all "ExtensionAdditions"s and "ExtensionAdditionAlternatives". within the module are "ExtensionAdditionGroup"s or "ExtensionAdditionAlternativesGroup"s with "VersionNumber"s. 24. NOTE 3 – Use of the "ExtensionAdditionGroup" production is recommended because: a) it can result in more compact encodings depending on the encoding rules (e. the presence in an encoding of any addition from version 3 requires the presence of an encoding of all additions in version 2 that are not marked OPTIONAL or DEFAULT.18 The "{" "}" or "empty" notation shall only be used if: a) b) all "ComponentType" sequences in the "SequenceType" are marked DEFAULT or OPTIONAL.12 The value corresponding to an "ExtensionAdditionGroup" (all components together) is optional. the omission of a value for that type shall be exactly equivalent to the insertion of the value defined by "Value". and shall be greater than the "number" in any preceding "ExtensionAdditionGroup" within an insertion point. then the value corresponding to the components within the bracketed "ComponentTypeList" that are not marked OPTIONAL or DEFAULT shall be present. NOTE 2 – The restrictions on use of "VersionNumber" apply only within a single module and impose no constraints on imported types.

It is also possible to specify use of "XMLValueList" instead of "XMLDelimitedItemList" for some instances of "SEQUENCE OF SEQUENCE" and "SEQUENCE OF SET". "RelativeOIDType". "XMLSequenceOfValue". or when used as an "XMLValue". SequenceOfType ::= SEQUENCE OF Type | SEQUENCE OF NamedType NOTE – If an initial letter which is upper-case is needed for an XML tag name used in XML Value Notation for the "SequenceOfType". X.16). "RealType".61) from another type shall be the "SequenceOfType". 25 25.1 Notation for sequence-of types The notation for defining a sequence-of type (see 3. NOTE – Sequence types have the same tag as sequence-of types (see 24.2 All sequence-of types have a tag which is universal class.680 (07/2002) . number 16. and the values shall be in the same order as the corresponding "NamedType" sequences." NamedValue XMLSequenceOfValue ::= XMLValueList | XMLDelimitedItemList | XMLSpaceSeparatedList | empty XMLValueList ::= XMLValueOrEmpty | XMLValueOrEmpty XMLValueList XMLValueOrEmpty ::= XMLValue | "<" & NonParameterizedTypeName "/>" XMLSpaceSeparatedList ::= XMLValueOrEmpty | XMLValueOrEmpty " " XMLSpaceSeparatedList XMLDelimitedItemList ::= XMLDelimitedItem | XMLDelimitedItem XMLDelimitedItemList XMLDelimitedItem ::= "<" & NonParameterizedTypeName ">" XMLValue "</" & NonParameterizedTypeName ">" | "<" & identifier ">" XMLValue "</" & identifier ">" The "{" "}" or "empty" notation is used when the "SequenceOfValue" or "XMLSequenceOfValue" is an empty list.19 There shall be one "NamedValue" or "XMLNamedValue" for each "NamedType" in the "SequenceType" which is not marked OPTIONAL or DEFAULT.ISO/IEC 8824-1:2003 (E) 24. "ObjectIdentifierType". 25. 42 ITU-T Rec. It is provided in order to allow specification of the use of "XMLSpaceSeparatedList" in encodings of the "IntegerType"." Value NamedValueList ::= NamedValue | NamedValueList ". (The XML tag name is then formed from the name of the "Type". then the first alternative should be used. NOTE 1 – Semantic significance may be placed on the order of these values.6. These productions are: SequenceOfValue ::= "{" ValueList "}" | "{" NamedValueList "}" | "{" "}" ValueList ::= Value | ValueList ". NOTE 2 – The "XMLSpaceSeparatedList" production is not used in this Recommendation | International Standard. and is not used in XML Value Notation. and the GeneralizedTime and UTCTime useful types.) 25.3 The notation for defining a value of a sequence-of type shall be the "SequenceOfValue".

14. where the "Type" of the component is listed in column 1. 25.5 The "XMLValueList" or "XMLDelimitedItemList" productions shall be used in accordance with column 2 of Table 5.1).10 and 14.11 If the first alternative of "XMLDelimitedItem" is used.ISO/IEC 8824-1:2003 (E) 25.6 shall be recursively applied. 25. If this is itself a "ConstrainedType". then if the component of the sequence-of type (after ignoring any tags) is a "typereference" or an "ExternalTypeReference". X. X. 15.4 If the"XMLValue" for the component is "empty".6 See ITU-T Rec. otherwise it shall be the "xmlasn1typename" specified in Table 4 corresponding to the built-in type of the component.1).8 If the "Type" of the component is a "SelectionType" then the type which determines the "XMLSequenceOfValue" notation shall be the type referenced by the "SelectionType" (see clause 29). determines the 25. then the "NonParameterizedTypeName" shall be that "typereference" or "ExternalTypeReference". 25.681 | ISO/IEC 8824-2. If this is itself a "TaggedType". and the "identifier" in the "XMLDelimitedItem" shall be that "identifier".7 If the "Type" of the component is a "ConstrainedType" then the type which determines the "XMLSequenceOfValue" notation shall be the "Type" in the "ConstrainedType" (see 45.6 If the "Type" of the component is a "TaggedType" then the type which determines the "XMLSequenceOfValue" notation shall be the "Type" in the "TaggedType" (see 30.7 See 25. Table 5 – "XMLSequenceOfValue" and "XMLSetOfValue" notation for ASN.6 XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList See ITU-T Rec.6 XML value notation 25.680 (07/2002) 43 .7 shall be recursively applied.9 If the "Type"of the component is a "DefinedType" then the type which "XMLSequenceOfValue" notation shall be the type referenced by the "DefinedType" (see 13.8 XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList See 25. then the second alternative of "XMLValueOrEmpty" shall be chosen to represent that value of the component.1). 25.9 XMLDelimitedItemList XMLValueList See ITU-T Rec. 25. then this subclause 25.11 XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList See 25.1 type BitStringType BooleanType CharacterStringType ChoiceType ConstrainedType DefinedType EmbeddedPDVType EnumeratedType ExternalType InstanceOfType IntegerType NullType ObjectClassFieldType ObjectIdentifierType OctetStringType RealType RelativeOIDType SelectionType SequenceType SequenceOfType SetType SetOfType TaggedType UsefulType (GeneralizedTime) UsefulType (UTCTime) UsefulType (ObjectDescriptor) TypeFromObject ValueSetFromObjects XMLDelimitedItemList XMLValueList XMLDelimitedItemList XMLValueList See 25. ITU-T Rec.681 | ISO/IEC 8824-2. then this subclause 25.9 XMLDelimitedItemList XMLValueList XMLDelimitedItemList See ITU-T Rec. C. X.1 types ASN. 15. X. X.10 The second alternative of "XMLDelimitedItem" shall be used if and only if the "SequenceOfType" contains an "identifier".681 | ISO/IEC 8824-2.681 | ISO/IEC 8824-2.

44 ITU-T Rec. and all values are omitted.13 also apply to set types. There shall be no semantics associated with the order of values in a set type.6 Subclauses 24. this is achieved regardless of the actual "ComponentType"s. 26. NOTE – This transformation is logically completed prior to the satisfaction of the requirements in the following subclauses.) Any subtype constraint applied to the referenced type is ignored by this transformation.2). extension markers and extension additions. at this point in the list of components.4 26.7. All set types have a tag which is universal class.ISO/IEC 8824-1:2003 (E) 25. NOTE – These "NamedValue"s or "XMLNamedValue"s may appear in any order.7 The notation for defining the value of a set type shall be "SetValue". if any. These productions are: SetValue ::= "{" ComponentValueList "}" | "{" "}" XMLSetValue ::= XMLComponentValueList | empty "ComponentValueList" and "XMLComponentValueList" are specified in 24.17. 26. 26 26. and each "NamedValue" in the "NamedValueList" shall contain a "Value" of the type specified in the "NamedType" of the "SequenceOfType".7 to 24. then the second alternative of "SequenceOfValue" shall be used.1. The tag of each new "ComponentType" added to the "ExtensionAdditions" shall be canonically greater (see 8. number 17.2 and 24. (Only the "RootComponentTypeList" of the "Type" in the "COMPONENTS OF Type" is included. The "COMPONENTS OF Type" notation shall be used to define the inclusion. The "identifier" in the "NamedValue"s shall be the "identifier" in the "NamedType" of the "SequenceOfType". 25. (See also 48. except for any extension marker and extension additions that may be present in the "Type". "ExtensionAndException" and "OptionalExtensionMarker" are specified in 24.64) from other types shall be the "SetType": SetType ::= | | SET "{" "}" SET "{" ExtensionAndException OptionalExtensionMarker "}" SET "{" ComponentTypeLists "}" "ComponentTypeLists". and each "XMLValue" in the alternatives of "XMLSequenceOfValue" shall be of the type specified in the "SequenceOfType". are ignored by the "COMPONENTS OF Type" notation.6. NOTE – Where the "TagDefault" for the module in which this notation appears is AUTOMATIC TAGS.2 "Type" in the "COMPONENTS OF Type" notation shall be a set type.1 Notation for set types The notation for defining a set type (see 3. or when used as an "XMLValue". 26.9 There shall be one "NamedValue" or "XMLNamedValue" for each "NamedType" in the "SetType" which is not marked OPTIONAL or DEFAULT. of all the component types of the referenced type. 26. NOTE – Set-of types have the same tag as set types (see 27. Each "Value" in the "ValueList" of "SequenceOfValue".8 The "SetValue" and "XMLSetValue" shall only be "{" "}" and "empty" respectively if: a) b) all "ComponentType" sequences in the "SetType" are marked DEFAULT or OPTIONAL.680 (07/2002) .3 The "ComponentType" types in a set type shall all have different tags (see clause 30).6) than those of the other components in the "ExtensionAdditions".7.5 26. X. 26.12 If the first alternative of "SequenceOfType" is used. as a result of the application of 24. then the first alternative of "SequenceOfValue" shall be used. or the type notation was SET{}.13 If the second alternative of "SequenceOfType" is used. "XMLSetValue".) 26.

NOTE 3 – The set-of type is not a mathematical set of values. The "identifier" in the "NamedValue"s shall be the "identifier" in the "NamedType" of the "SetOfType".6. 28 28. NOTE – Set types have the same tag as set-of types (see 26. 27.) 27." ExtensionAdditionAlternative ITU-T Rec. These productions are: SetOfValue ::= "{" ValueList "}" | "{" NamedValueList "}" | "{" "}" XMLSetOfValue ::= XMLValueList | XMLDelimitedItemList | XMLSpaceSeparatedList | empty "ValueList".1 Notation for choice types The notation for defining a choice type (see 3. as an example.65) from another type shall be the "SetOfType": SetOfType ::= | SET OF Type SET OF NamedType NOTE – If an initial letter which is upper-case is needed for an XML tag name used in XML Value Notation for the "SetOfType". 27. NOTE 2 – Encoding rules are not required to preserve the order of these values. then the second alternative of "SetOfValue" shall be used. "NamedValueList" and the alternatives of "XMLSetOfValue" are specified in 25.5 If the second alternative of "SetOfType" is used. The "{" "}" or "empty" notation is used when the "SetOfValue" or "XMLSetOfValue" is an empty list.2 All set-of types have a tag which is universal class. Each "Value" in the "ValueList" of "SetOfValue".6.3 The notation for defining a value of a set-of type shall be the "SetOfValue". number 17. X. thus. for SET OF INTEGER the values { 1 } and { 1 1 } are distinct." ExtensionAndException ExtensionAdditionAlternatives OptionalExtensionMarker RootAlternativeTypeList ::= AlternativeTypeList ExtensionAdditionAlternatives ::= ". (The XML tag name is then formed from the name of the "Type". "XMLSetOfValue".3." ExtensionAdditionAlternativesList | empty ExtensionAdditionAlternativesList ::= ExtensionAdditionAlternative | ExtensionAdditionAlternativesList ". and each "NamedValue" sequence in the "NamedValueList" shall contain a "Value" of the type specified in the "NamedType" of the "SetOfType".13) from other types shall be the "ChoiceType": ChoiceType ::= CHOICE "{" AlternativeTypeLists "}" AlternativeTypeLists ::= RootAlternativeTypeList | RootAlternativeTypeList ". then the first alternative of "SetOfValue" shall be used. and each "XMLValue" in the alternatives of "XMLSetOfValue" shall be of the type specified in the "SetOfType". or when used as an "XMLValue". then the first alternative should be used.1 Notation for set-of types The notation for defining a set-of type (see 3.ISO/IEC 8824-1:2003 (E) 27 27.680 (07/2002) 45 . 27.4 If the first alternative of "SetOfType" is used.5). NOTE 1 – Semantic significance should not be placed on the order of these values.

and the restrictions on consistent use of "VersionNumber" throughout a module that are specified in 24. 46 ITU-T Rec.3). 8.ISO/IEC 8824-1:2003 (E) ExtensionAdditionAlternative ::= ExtensionAdditionAlternativesGroup | NamedType ExtensionAdditionAlternativesGroup ::= "[[" VersionNumber AlternativeTypeList "]]" AlternativeTypeList ::= NamedType | AlternativeTypeList ". the "ClassNumber" in the replacement "TaggedType" of the first "NamedType" in the "ExtensionAdditionAlternativesList" is one greater than the largest "ClassNumber" in the "RootAlternativeTypeList".6 The tag of each new "NamedType" added to the "ExtensionAdditionAlternativesList" shall be canonically greater (see 8. otherwise it is not.15 shall apply to the use of "number"s within this production.3 The types defined in the "AlternativeTypeList" productions in an "AlternativeTypeLists" shall have distinct tags (see clause 30.29) may result in changes to other alternatives due to the side effect of modifying the tags thus causing interworking problems with an older version of the specification.5 "VersionNumber" is defined in 24. the requirement that tags be distinct applies only after automatic tagging has been performed. all possible tags of values of the choice type shall be considered in such requirement. NOTE 3 – Subtyping does not affect automatic tagging. automatic tagging is still applied to components a. c Tc } E ::= CHOICE {f1 E1. the tags of the components are completely determined. and so on. or an untagged "DummyReference" (see ITU-T Rec. and none of the occurrences of "NamedType" in any "AlternativeTypeList" contains a "TaggedType". If automatic tagging was selected. the "ClassNumber" in the replacement "TaggedType" is tag value zero for the first "NamedType" in the "RootAlternativeTypeList". in the following case: T ::= CHOICE { a Ta.2 When the "AlternativeTypeLists" production occurs within the definition of a module for which automatic tagging is selected (see 12. f2 T.6. 28. 28.8 When this type does not have an extension marker and is used in a place where this Recommendation | International Standard requires the use of types with distinct tags (see 28.683 | ISO/IEC 8824-4. b and c of T. 28. The following examples which assume that the "TagDefault" is not AUTOMATIC TAGS illustrate this requirement. the "Type" in the replacement "TaggedType" is the original "Type" being replaced. and 48.3). and shall be the last "NamedType" in the "ExtensionAdditionAlternativesList". tagging is context-specific).3).4 If automatic tagging is in effect and the "NamedType"s in the extension root have no tags. whatever the tagging environment of T. and will always be satisfied. Automatic tagging is always implicit tagging unless the "Type" is an untagged choice type or an untagged open type notation. the automatic tagging transformation is selected for the entire "AlternativeTypeLists".e. The replacement "TaggedType" is specified as follows: a) b) c) d) the replacement "TaggedType" notation uses the "Tag Type" alternative.680 (07/2002) . proceeding with increasing tag numbers. proceeding with increasing tag numbers.6) than those of the other alternatives in the "ExtensionAdditionAlternativesList".6. NOTE 4 – When automatic tagging is in place.1. (The tag depends on the alternative which contributed the value to the choice type. Thus. f3 E3} automatic tagging applied to the components of E never affects the tags attached to components a. 28. b and c of T. in which case it is explicit tagging. 28. If T is defined in an automatic tagging environment and E is not in an automatic tagging environment. X. 28.) 28. X. and so on. NOTE 2 – Once automatic tagging has been applied. 28.7).." NamedType NOTE – "T ::= CHOICE { a A }" and A are not the same type. insertion of new alternatives at any location other than the extension insertion point (see 3.5 The automatic tagging transformation impacts each "NamedType" of the "AlternativeTypeLists" by replacing the "Type" originally in the "NamedType" production with a replacement "TaggedType". then no "NamedType" within the "ExtensionAdditionAlternativesList" shall be a tagged type. with the next "NamedType" in the "ExtensionAdditionAlternativesList" having a "ClassNumber" one greater than the first. and may be encoded differently by encoding rules.7 The choice type contains values which do not all have the same tag. e) NOTE 1 – The rules governing specification of implicit tagging or explicit tagging for replacement "TaggedType"s are provided by 30. and are not modified even when the choice type is referenced in the definition of an alternative within another "AlternativeTypeLists" for which automatic tagging transformation applies. one for the second. the "Class" of the replacement "TaggedType" is empty (i. b Tb.

5 The notation for a value of a selection type shall be the notation for a value of the type referenced by the "SelectionType". as the tags for types d and f are identical. g [3] NULL} 3 (Incorrect) b c d e f g A ::= CHOICE { B. C} B ::= CHOICE { [0] NULL.680 (07/2002) 47 . the "identifier" of the "NamedType" is present. ignoring any subtype constraint on the parent type. 29. 28.3 Where the "SelectionType" is used as a "NamedType". as well as the "identifier" of the "SelectionType".6. X. e [1] NULL} C ::= CHOICE { f [2] NULL.9 The "identifier"s of all "NamedType"s in the "AlternativeTypeLists" shall differ from those of the other "NamedType"s in that list. 29. 29. 29 29. These productions are: ChoiceValue ::= identifier ":" Value XMLChoiceValue ::= "<" & identifier ">" XMLValue "</" & identifier ">" 28. c NULL} B ::= CHOICE { d [0] NULL. [1] NULL} C ::= CHOICE { [0] NULL. or when used as an "XMLValue". c C} B ::= CHOICE { d [0] NULL. the selection is performed on the parent type.11 "Value" or "XMLValue" shall be a notation for a value of the type in the "AlternativeTypeLists" that is named by the "identifier". Example 3 is incorrect without automatic tagging.4 Where the "SelectionType" is used as a "Type". e [1] NULL} 2 A ::= CHOICE { b B. and "identifier" is that of some "NamedType" appearing in the "AlternativeTypeLists" of the definition of that choice type. [1] NULL} Examples 1 and 2 are correct uses of the notation. the "identifier" is retained and the type denoted is that of the selected alternative.1 Notation for selection types The notation for defining a selection type (see 3.2 When "Type" denotes a constrained type. ITU-T Rec. "XMLChoiceValue". 29.10 The notation for defining the value of a choice type shall be the "ChoiceValue".59) shall be "SelectionType": SelectionType ::= identifier "<" Type where "Type" denotes a choice type.ISO/IEC 8824-1:2003 (E) EXAMPLES 1 A ::= CHOICE { b B. as well as for e and g. 28.

30.3). NOTE 2 – Subclause E.5 to 24. but has a tag with class "Class" and number "ClassNumber". except when "Class" is "empty".3. 30. other than those implied by the requirement for distinct tags in 24. in which case the tag is context-specific class and number is "ClassNumber". These productions are: TaggedValue ::= Value XMLTaggedValue ::= XMLValue where "Value" or "XMLValue" is a notation for a value of the "Type" in the "TaggedType".1 The notation for a tagged type shall be "TaggedType": TaggedType ::= Tag Type | Tag IMPLICIT Type | Tag EXPLICIT Type Tag ::= "[" Class ClassNumber "]" ClassNumber ::= number | DefinedValue Class ::= | | | UNIVERSAL APPLICATION PRIVATE empty 30.2. The use of a "TagDefault" of AUTOMATIC TAGS in a module allows this to be accomplished without the explicit appearance of tagged type notation in that module. 30.3 The new type is isomorphic with the old type. the "Tag Type" alternative is used and the value of "TagDefault" for the module is IMPLICIT TAGS or AUTOMATIC TAGS. and hence unambiguously identifies the old type without knowledge of the ASN.2 The "valuereference" in "DefinedValue" shall be of type integer. Implicit tagging indicates. distinct tags may be needed to enable the recipient to correctly decode the value. the "Tag Type" alternative is used and the value of "TagDefault" for the module is either EXPLICIT TAGS or is empty. NOTE – It can be useful to retain the old tag where this was universal class.5 to 24.5 All application of tags is either implicit tagging or explicit tagging. NOTE – Where a protocol determines that values from several data types may be transmitted at any moment in time. 30. X.7 If the "Class" is "empty". X.1 definition of the new type. An example of an encoding using IMPLICIT is given in ITU-T Rec. but which has a different tag.8 The IMPLICIT alternative shall not be used if the type defined by "Type" is an untagged choice type or an untagged open type or an untagged "DummyReference" (see ITU-T Rec. X.6. The tagged type is mainly of use where this Recommendation | International Standard requires the use of types with distinct tags (see 24.3). an untagged open type. X.9 The notation for a value of a "TaggedType" shall be "TaggedValue".680 (07/2002) .6.3 and 28.12 contains guidance and hints on stylistic use of tag classes. 30. 26. Minimum transfer octets is. 30. 26.683 | ISO/IEC 8824-4. NOTE 1 – Use of universal class tags are agreed from time-to-time by ITU-T and ISO. 48 ITU-T Rec. 8. or an untagged "DummyReference" (see ITU-T Rec. or when used as an "XMLValue". The tagging construction specifies implicit tagging otherwise. normally achieved by the use of IMPLICIT. "XMLTaggedValue". and assigned a non-negative value.683 | ISO/IEC 8824-4. 30. 30.4 The "Class" shall not be UNIVERSAL except for types defined in this Recommendation | International Standard. there are no restrictions on the use of "Tag". that explicit identification of the original tag of the "Type" in the "TaggedType" is not needed during transfer. 8.3). but the type defined by "Type" is an untagged choice type. however.6 The tagging construction specifies explicit tagging if any of the following holds: a) b) c) the "Tag EXPLICIT Type" alternative is used.ISO/IEC 8824-1:2003 (E) 30 Notation for tagged types A tagged type (see 3.3 and 28.6.70) is a new type which is isomorphic with an old type.690 | ISO/IEC 8825-1. for those encoding rules which provide the option.

This is why there is a restriction on the starting node. 31 31. Annexes A to C.7 The "NameForm" shall be used only for those object identifier components whose numeric value and identifier are specified in ITU-T Rec.6. number 6. X.48) shall be referenced by the notation "ObjectIdentifierType": ObjectIdentifierType ::= OBJECT IDENTIFIER 31. and later "ObjIdComponents"s (if any) identify arcs from the later node. X. nor a node immediately beneath the root.6 The "DefinedValue" of "ObjIdComponents" shall be of type relative object identifier. Annexes A to C (see also Annex D of this Recommendation | International Standard). 31. Object identifier values are required (see 31.ISO/IEC 8824-1:2003 (E) NOTE – The "Tag" does not appear in this notation. X. 31. The starting node is identified by the earlier "ObjIdComponents"s.3 The value notation for an object identifier shall be "ObjectIdentifierValue". and assigned a nonnegative value.1 Notation for the object identifier type The object identifier type (see 3. NOTE – A relative object identifier value has to be associated with a specific object identifier value so as to unambiguously identify an object. and shall identify an ordered set of arcs from some starting node in the object identifier tree to some later node in the object identifier tree. any synonym may be used with the ITU-T Rec. The starting node is required to be neither the root. and shall be one of the identifiers specified in ITU-T Rec.660 | ISO/IEC 9834-1.660 | ISO/IEC 9834-1 specifies synonymous identifiers. "XMLObjectIdentifierValue"." & XMLObjIdComponentList XMLObjIdComponent ::= NameForm | XMLNumberForm | XMLNameAndNumberForm XMLNumberForm ::= number XMLNameAndNumberForm ::= identifier & "(" & XMLNumberForm & ")" 31. or when used as an "XMLValue".10) to have at least two components.660 | ISO/IEC 9834-1.2 This type has a tag which is universal class.680 (07/2002) 49 . 31. 31. These productions are: ObjectIdentifierValue ::= "{" ObjIdComponentsList "}" | "{" DefinedValue ObjIdComponentsList "}" ObjIdComponentsList ::= ObjIdComponents | ObjIdComponents ObjIdComponentsList ObjIdComponents ::= NameForm | NumberForm | NameAndNumberForm | DefinedValue NameForm ::= identifier NumberForm ::= number | DefinedValue NameAndNumberForm ::= identifier "(" NumberForm ")" XMLObjectIdentifierValue ::= XMLObjIdComponentList XMLObjIdComponentList ::= XMLObjIdComponent | XMLObjIdComponent & ". X.5 The "valuereference" in "DefinedValue" of "ObjectIdentifierValue" shall be of type object identifier. Where ITU-T Rec.4 The "valuereference" in "DefinedValue" of "NumberForm" shall be of type integer.

660 | ISO/IEC 9834-1 identifier.1 in an "XMLObjectIdentifierValue".660 | ISO/IEC 9834-1 and an ASN.standard.660 | ISO/IEC 9834-1.11 The significant part of the object identifier component is the "NameForm" or "NumberForm" or "XMLNumberForm" which it reduces to. These productions are: RelativeOIDValue ::= "{" RelativeOIDComponentsList "}" RelativeOIDComponentsList ::= RelativeOIDComponents | RelativeOIDComponents RelativeOIDComponentsList 50 ITU-T Rec.pci(1) and 1. X. X. NOTE – ITU-T Rec. the numeric value of the object identifier component is always present in an instance of object identifier value notation.660 | ISO/IEC 9834-1.660 | ISO/IEC 9834-1. 31.10 The semantics associated with an object identifier value are specified in ITU-T Rec. the values: { iso standard 8571 pci (1) } and { 1 0 8571 1 } would each identify an object.660 | ISO/IEC 9834-1. X. 31. as would iso.6.660 | ISO/IEC 9834-1 recommends that whenever an object identifier value is assigned to identify an object. 32. 31. an object descriptor value is also assigned.9 The "identifier" in the "NameAndNumberForm" and "XMLNameAndNumberForm" shall be specified when a numeric value is assigned to the object identifier component. Where the same name is both an identifier specified in ITU-T Rec. 31.8571. defined in ISO 8571.8571. With the following additional definition: ftam OBJECT IDENTIFIER ::= { iso standard 8571 } the following value is equivalent to those above: { ftam pci(1) } 32 32.660 | ISO/IEC 9834-1 requires that an object identifier value shall contain at least two arcs.2 This type has a tag which is universal class. X. Except for the arcs specified in ITU-T Rec. NOTE – ITU-T Rec. or when used as "XMLValue". the name within the object identifier value shall be treated as an ITU-T Rec.1 value reference within the module containing the "NameForm". X. X.1 Notation for the relative object identifier type The relative object identifier type (see 3.ISO/IEC 8824-1:2003 (E) same semantics.57) shall be referenced by the notation "RelativeOIDType": RelativeOIDType ::= RELATIVE-OID 32. Annexes A to C (see also Annex D of this Recommendation | International Standard). X. "XMLRelativeOIDValue". the list of object identifier components to which it refers is prefixed to the components explicitly present in the value.8 The "number" in the "NumberForm" and "XMLNumberForm" shall be the numeric value assigned to the object identifier component. and which provides the numeric value for the object identifier component. number 13.3 The value notation for a relative object identifier shall be "RelativeOIDValue".680 (07/2002) . 31. X.12 Where the "ObjectIdentifierValue" includes a "DefinedValue" for an object identifier value. NOTE – The authorities allocating numeric values to object identifier components are identified in ITU-T Rec. X. EXAMPLES With identifiers assigned as specified in ITU-T Rec. pci.0.

2. and shall identify an ordered set of arcs from some starting node in the object identifier tree to some later node in the object identifier tree.11. X. but this expansion is not used today. it meant "Embedded Presentation Data Value" from its use in the OSI Presentation Layer. Historically.21) shall be referenced by the notation "EmbeddedPDVType": EmbeddedPDVType ::= EMBEDDED PDV NOTE – The term "Embedded PDV" means an abstract value from a possibly different abstract syntax (essentially. "NameAndNumberForm"." & XMLRelativeOIDComponentList XMLRelativeOIDComponent ::= XMLNumberForm | XMLNameAndNumberForm 32. nor a node immediately beneath the root. 33. number 11. the value and encoding of a message defined in a separate – and identified – protocol) that is embedded in a message. Object identifier values are required (see 31. then it needs to be transmitted as an object identifier value in an instance of communication (see E.32</OBJECT_IDENTIFIER> firstgroup ::= <RELATIVE_OID>4. are defined in subclauses 31.2. 4 3 4 6} if the current root 33 33. and later "RelativeOIDComponents"s (if any) identify arcs from the later nodes.5 The "DefinedValue" of "RelativeOIDComponents" shall be of type relative object identifier.3</RELATIVE_OID> the relative object identifier: relOID RELATIVE-OID ::= {firstgroup room(4) socket(6)} or in XML value notation: relOID ::= <RELATIVE_OID>4. The starting node is required to be neither the root.6 The first "RelativeOIDComponents" or "XMLRelativeOIDComponent" identifies one or more arcs from some starting node in the object identifier tree to some later node in the object identifier tree. The starting point can be defined by comments associated with the type definition. If there is no definition of the starting node within comments associated with the type definition.2 This type has a tag which is universal class. 32. 32. and their semantics.3 to 31. NOTE – A relative object identifier value has to be associated with a specific object identifier value so as to unambiguously identify an object.4.10) to have at least two components.1 Notation for the embedded-pdv type The embedded-pdv type (see 3.4 The productions "NumberForm". "XMLNameAndNumberForm". This is why there is a restriction on the starting node. EXAMPLE With the following definitions: thisUniversity OBJECT IDENTIFIER ::= {iso member-body country(29) universities(56) thisuni(32)} firstgroup RELATIVE-OID ::= {science-fac(4) maths-dept(3)} or in XML value notation: thisUniversity ::= <OBJECT_IDENTIFIER>1.3. and it should be interpreted as "embedded value".6</RELATIVE_OID> can be used instead of the OBJECT IDENTIFIER value {1 2 29 56 32 (known by the application or transmitted by the application) is thisUniversity.19).56.ISO/IEC 8824-1:2003 (E) RelativeOIDComponents ::= NumberForm | NameAndNumberForm | DefinedValue XMLRelativeOIDValue ::= XMLRelativeOIDComponentList XMLRelativeOIDComponentList ::= XMLRelativeOIDComponent | XMLRelativeOIDComponent & ". The starting node is identified by the earlier "RelativeOIDComponents"s (if any).680 (07/2002) 51 .29. ITU-T Rec.6. "XMLNumberForm".

presentation-context-id -. context-negotiation SEQUENCE { presentation-context-id INTEGER..680 (07/2002) . transfer-syntax OBJECT IDENTIFIER } -.Abstract and transfer syntax object identifiers --. the definition of the associated type provided here underlies the commonalities which exist between the embedded-pdv type. data-value OCTET STRING } ( WITH COMPONENTS { . 33. fixed NULL -. in which case it is not encoded in an instance of communication.the value of an ASN. The identification consists of either one or two object identifiers.case is provided primarily to support -.This provides human-readable identification of the class of the -. or (in an OSI environment) references an OSI presentation context identifier which specifies the abstract and transfer syntaxes.1 type) -.Context-negotiation in progress. but need not. This alternative shall not be used during OSI context negotiation.}.so the transfer syntax shall be specified --.ISO/IEC 8824-1:2003 (E) 33. when the integer value shall be an OSI presentation context identifier in the OSI defined context set. X. 52 ITU-T Rec. This associated type is used to support the value and subtype notations of the embedded-pdv type. However. for example. This -.and receiver) -.(Applicable only to OSI environments) -. 33.. 33.known to both sender -. be the encoding of a still image or a moving picture.sender and receiver). and identification (separately or together) of: 1) 2) an abstract syntax. NOTE 2 – The identification of the abstract syntax and/or the encoding may also be determined by the application designer as a fixed value.is fixed by the application designer (and hence known to both -.The negotiated OSI presentation context identifies the -. data-value-descriptor ObjectDescriptor OPTIONAL -.3 The type consists of values representing: a) b) an encoding of a single data value that may.abstract and transfer syntaxes --.4 The embedded-pdv type has an associated type. or may.The type of the value (for example. syntax OBJECT IDENTIFIER -. be the value of an ASN.1 type.1 type (and hence -.selective-field-encryption (or other encoding -. . specification that it is -.5 The associated type for value definition and subtyping. and the transfer syntax. transfer OBJECT IDENTIFIER } -. presentation-context-id INTEGER -.and transfer syntaxes --.6 The presentation-context-id alternative is only applicable in an OSI environment.transformations) of an ASN. assuming an automatic tagging environment. data-value-descriptor ABSENT } ) NOTE – The embedded-pdv type does not allow the inclusion of a data-value-descriptor value. is (with normative comments): SEQUENCE { identification CHOICE { syntaxes SEQUENCE { abstract OBJECT IDENTIFIER. NOTE 1 – The data value may be the value of an ASN.The data value is the value of a fixed ASN.1 type. transfer-syntax OBJECT IDENTIFIER -.value --.(Applicable only to OSI environments) -.identifies only the abstract syntax -. the external type and the unrestricted character string type.A single object identifier for identification of the abstract -.1 type --.

34. . where the value of the data-value component of type OCTET STRING represents an encoding using the transfer syntax specified in identification. EmbeddedPdvValue ::= SequenceValue XMLEmbeddedPDVValue ::= XMLSequenceValue -.1 Notation for the external type The external type (see 3. but need not. 33. assuming an automatic tagging environment.value of associated type defined in 33. For example. context-negotiation presentation-context-id transfer-syntax SEQUENCE { INTEGER. presentation-context-id INTEGER -.5 The associated type for value definition and subtyping.A single object identifier for identification of the abstract -.7 The context-negotiation alternative is only applicable in an OSI environment.value of associated type defined in 33. This type is used to give precision to the definition of the abstract values of the external type and is also used to support the value and subtype notations of the external type.5 -.(Applicable only to OSI environments) -.5 EXAMPLE – If a single option is to be enforced. or may specify encodings without reference to any associated type. syntax OBJECT IDENTIFIER -.abstract and transfer syntaxes --. is (with normative comments): SEQUENCE { identification CHOICE { syntaxes SEQUENCE { abstract OBJECT IDENTIFIER.and transfer syntaxes --. The optional object descriptor shall not be present unless explicitly permitted by comment associated with use of the "ExternalType" notation. and (optionally) an object descriptor which provides a human-readable description of the category of the data value.4 The external type has an associated type. NOTE – Encoding rules may define a different type which is used to derive encodings. be the value of an ASN.The negotiated OSI presentation context identifies the -.1 type. then this can be done by writing: EMBEDDED PDV (WITH COMPONENTS { . 34. The type consists of values representing: a) b) an encoding of a single data value that may. OBJECT IDENTIFIER } ITU-T Rec. identification syntaxes (WITH COMPONENTS { PRESENT } ) } ) 34 34. X. NOTE – Note 1 in 33... and identification of: 1) 2) c) an abstract syntax.37) shall be referenced by the notation "ExternalType": ExternalType ::= EXTERNAL 34. and the transfer syntax.Abstract and transfer syntax object identifiers --.ISO/IEC 8824-1:2003 (E) 33.8 The notation for a value of the embedded-pdv type shall be the value notation for the associated type defined in 33. and shall only be used during OSI context negotiation.6.2 34. transfer OBJECT IDENTIFIER } -.3 also applies to the external type. The object identifier transfer-syntax shall identify a proposed transfer syntax for that OSI presentation context which is to be used to encode the value. such as use of syntaxes. the encoding in BER uses a different sequence type for historical reasons. The integer value shall be an OSI presentation context identifier proposed for addition to the OSI defined context set.3 This type has a tag which is universal class.5.680 (07/2002) 53 . number 8.

5 -. specified formally below: a) A representation of the characters in the string using assigned graphic symbols.sender and receiver). specification that it is -. presentation-context-id identifies only the abstract syntax so the transfer syntax shall be specified --. identification. Such values cannot be represented in value notation using the above associated type.The type of the value (for example..1 type (and hence -.7 The notation for a value of the external type shall be the value notation for the associated type defined in 34. This -.value of associated type defined in 34.the value of an ASN.The data value is the value of a fixed ASN. It is normal to define a character repertoire and its encoding by use of cells in one or more tables.case is provided primarily to support -. this is the "cstring" notation.the value --. . fixed NULL -.known to both sender -. data-value OCTET STRING } ( WITH COMPONENTS { .1 value references that have been assigned the character.selective-field-encryption (or other encoding -. ExternalValue ::= SequenceValue XMLExternalValue ::= XMLSequenceValue -. 35 The character string types These types consist of strings of characters from some specified character repertoire. a set of such value references is defined in the module 54 ITU-T Rec. transfer-syntax ABSENT. b) A listing of the characters in the character string value by giving a series of ASN.1 type --. data-value-descriptor ObjectDescriptor OPTIONAL -. A graphic symbol and a character name are also usually assigned to each cell.1 type) -.5 NOTE – For historical reasons.5. where the value of the data-value component of type OCTET STRING represents an encoding using the transfer syntax specified in identification.680 (07/2002) . each cell corresponding to a character in the repertoire. The ASN.ISO/IEC 8824-1:2003 (E) ----(Applicable only to OSI environments) Context-negotiation in progress. 34.transformations) of an ASN. The definition of the associated type provided here underlies the commonalities which exist between the external type. transfer-syntax or fixed alternatives of Application designers requiring these options should use the embedded-pdv type.value of associated type defined in 34.1 basic value notation for character string types has three variants (which can be combined). identification (WITH COMPONENTS { .}. the external type does not allow the syntaxes..7 also applies to the external type.and receiver) -. cells are left empty. In general. encoding rules are able to transfer embedded values in EXTERNAL whose encodings are not an exact multiple of eight bits. NOTE 1 – Such a representation can be ambiguous in a printed representation when the same graphic symbol is used for more than one character in the repertoire. . transfer-syntax OBJECT IDENTIFIER -.6 and 33. X.6 The text of 33. fixed ABSENT } ) } ) NOTE – For historical reasons. NOTE 2 – Such a representation can be ambiguous in a printed representation when spacing characters of different widths are present in the repertoire or the specification is printed with a proportional-spacing font.This provides human-readable identification of the class of -. or have names but no shapes (examples of cells with names but no shape include control characters such as EOF in ISO/IEC 646 and spacing characters such as THIN-SPACE and EN-SPACE in ISO/IEC 10646-1).. the unrestricted character string type and the embedded-pdv type.. the information associated with a cell denotes a distinct abstract character in the repertoire even if that information is null (no graphic symbol or name is assigned to that cell). possibly including spacing characters. 34.is fixed by the application designer (and hence known to both -. although in some repertoires. syntaxes ABSENT.

6. UniversalString.11) shall be: CharacterStringType ::= RestrictedCharacterStringType | UnrestrictedCharacterStringType "RestrictedCharacterStringType" is the notation for a restricted character string type and is defined in clause 37. The ASN. 36 36.9 respectively. The tag of the unrestricted character string type is specified in 40. c) A listing of the characters in the character string value by identifying each abstract character by the position of its cell in the character repertoire table(s).1 Notation for character string types The notation for referencing a character string type (see 3. which includes the ability to use escape sequences for certain special characters.1. and for specification of characters using decimal or hexadecimal (see 11.. "UnrestrictedCharacterStringType" is the notation for the unrestricted character string type and is defined in 40. NumericString) by which the type is referenced.3 The notation for a character string value shall be: CharacterStringValue ::= RestrictedCharacterStringValue | UnrestrictedCharacterStringValue XMLCharacterStringValue ::= XMLRestrictedCharacterStringValue | XMLUnrestrictedCharacterStringValue "RestrictedCharacterStringValue" and "XMLRestrictedCharacterStringValue" are defined in 37.ISO/IEC 8824-1:2003 (E) ASN1-CHARACTER-MODULE in clause 38 for the ISO/IEC 10646-1 character repertoire and for the IA5String character repertoire. X.680 (07/2002) 55 .15).8 and 37. "UnrestrictedCharacterStringValue" and "XMLUnrestrictedCharacterStringValue" are notations for an unrestricted character string value and they are defined in 40.1 XML value notation for character string types uses the "xmlcstring" notation.7. 36.2 The tag of each restricted character string type is specified in 37.1. The notation for referencing a restricted character string type shall be "RestrictedCharacterStringType": RestrictedCharacterStringType ::= | | | | | | | | | | | | a) b) BMPString GeneralString GraphicString IA5String ISO646String NumericString PrintableString TeletexString T61String UniversalString UTF8String VideotexString VisibleString Each "RestrictedCharacterStringType" alternative is defined by specifying: the tag assigned to the type. this form is available only for IA5String. and a name (e. one or more characters from some specified collection of characters. 37 Definition of restricted character string types This clause defines types whose values are restricted to sequences of zero. and ITU-T Rec. UTF8String and BMPString. this form is not available for other character repertoires unless the user assigns to such value references using the value notation described in a) above or c) below.2. 36.g.

13. 153. 128. 126.1 Table 6 lists the name by which each restricted character string type is referenced. Table 7 – NumericString Name Digits Space Graphic 0. or by reference to ISO/IEC 10646-1.16 Table 7 Table 8 6. NOTE 2 – Register entries 6 and 156 can be used instead of 102 and 103. or other display characteristics are not significant.680 | ISO/IEC 8824-1 clause Subclause 37.1 encoding rules for the built-in type NumericString. 106. or the defining text clause.ISO/IEC 8824-1:2003 (E) c) the characters in the collection of characters used in defining the type. T. 72. 164. 164. 6 + SPACE + DELETE All G sets + SPACE 6 + SPACE All G and all C sets + SPACE + DELETE See 37. 87.680 (07/2002) . b) The ASN. 165. or ITU-T Rec. 103. colour. 56 ITU-T Rec. table number. In this case the character transfer syntax is identified by the object identifier associated with those rules in ISO/IEC 10646-1. .100 and ITU-T Rec. In this case the character transfer syntax is identified by the object identifier value {joint-iso-itu-t asn1(1) basic-encoding(1)}.101. 150. intensity. 89. 102.. 37. 168 + SPACE + DELETE 1. NOTE 1 – The type-style.6 See 37.. 37. identification of a Note relating to the entry in the table. T. 73. Annex N. by reference to a table listing the character graphics or by reference to a registration number in the ISO International Register of Coded Character Sets (see ISO International Register of Coded Character Sets to be used with Escape Sequences). 126. X. and. 102. 144.2 Table 7 lists the characters which can appear in the NumericString type and NumericString character abstract syntax. 108.15 Notes (Note 1) (Note 1) (Note 2) (Note 3) The defining registration numbers are listed in ISO International Register of Coded Character Sets to be used with Escape Sequences. 87. the number of the universal class tag assigned to the type. 129. NOTE 3 – The entries corresponding to these registration numbers provide the functionality of CCITT Rec. 9 (space) 37. 1. 150. where necessary. Where a synonymous name is defined in the notation. size. 156. NOTE 2 – A value of a NumericString character abstract syntax may be encoded by: a) One of the rules given in ISO/IEC 10646-1 for encoding the abstract characters.3 The following object identifier and object descriptor values are assigned to identify and describe the { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) numericString(0) } NumericString character abstract syntax: and "NumericString character abstract syntax" NOTE 1 – This object identifier value can be used in CHARACTER STRING values and in other cases where there is a need to carry the identification of the character string type separate from the value. 107. Table 6 – List of restricted character string types Name for referencing the type UTF8String NumericString PrintableString TeletexString (T61String) VideotexString IA5String GraphicString VisibleString (ISO646String) GeneralString UniversalString BMPString a) Universal class number 12 18 19 20 21 22 25 26 27 28 30 Defining registration numbera). 153. the defining registration number or table. 168 + SPACE + DELETE 1. 144. X. this is listed in parentheses. 165.

X.680 (07/2002) 57 .1 module containing a number of subtypes of this type for the "Collections of graphics characters for subsets" defined in ISO/IEC 10646-1. 1. / : = ? 37.8 The "RestrictedCharacterStringValue" notation for the restricted character string types shall be "cstring" (see 11. b) The ASN. Annex A. and can only be used in value notation for IA5String types.. UTF8String or BMPString types. "Quadruple" is only capable of defining a character string of length one. 37. "Tuple" is only capable of defining a character string of length one. "CharacterStringList". 37.6 The characters which can appear in the UniversalString type are any of the characters allowed by ISO/IEC 10646-1.14). "Quadruple".ISO/IEC 8824-1:2003 (E) 37. 37. NOTE – Clause 38 defines an ASN. .. z 0.1 encoding rules for the built-in type PrintableString.." CharsDefn ITU-T Rec. and can only be used in value notation for UniversalString.. . RestrictedCharacterStringValue ::= cstring | CharacterStringList | Quadruple | Tuple CharacterStringList ::= "{" CharSyms "}" CharSyms ::= CharsDefn | CharSyms ". Table 8 – PrintableString Name Latin capital letters Latin small letters Digits SPACE APOSTROPHE LEFT PARENTHESIS RIGHT PARENTHESIS PLUS SIGN COMMA HYPHEN-MINUS FULL STOP SOLIDUS COLON EQUALS SIGN QUESTION MARK Graphic A.4 Table 8 lists the characters which can appear in the PrintableString type and PrintableString character abstract syntax. . or "Tuple".. NOTE 2 – A value of a PrintableString character abstract syntax may be encoded by: a) One of the rules given in ISO/IEC 10646-1 for encoding the abstract characters.5 The following object identifier and object descriptor values are assigned to identify and describe the { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) printableString(1) } PrintableString character abstract syntax: and "PrintableString character abstract syntax" NOTE 1 – This object identifier value can be used in CHARACTER STRING values and in other cases where there is a need to carry the identification of the character string type separate from the value.. B. b.7 Use of this type invokes the conformance requirements specified in ISO/IEC 10646-1. 9 (space) ' ( ) + . Z a. In this case the character transfer syntax is identified by the object identifier { joint-iso-itu-t asn1(1) basic-encoding(1) }. In this case the character transfer syntax is identified by the object identifier associated with those rules in ISO/IEC 10646-1. Annex N. .

by the value mapping rules of Annex B. 'O'. 'P' and 'E' occur in the BASIC LATIN. EXAMPLE – Suppose that one wishes to specify a value of "abcΣdef" for a UniversalString where the character "Σ" is not representable on the available medium.10 There are characters which cannot be directly represented in "xmlcstring". "def" } NOTE 3 – When specifying the value of a UniversalString. and the "DefinedValue" alternative of "CharsDefn" is used (see 38. and only if the type is UniversalString.1. this value can also be expressed as: IMPORTS BasicLatin. 37.13 The "Group" specifies a group in the coding space of the UCS. UTF8String or BMPString type. the "cstring" notation should not be used unless ambiguities arising from different graphic characters with similar shapes have been resolved. The abstract character identified by this notation is the abstract character for the cell specified by the "Group". the set of permitted characters may be restricted by subtyping." Cell "}" Group Plane Row Cell Tuple ::= number ::= number ::= number ::= number ::= "{" TableColumn ". X. greekCapitalLetterSigma FROM ASN1-CHARACTER-MODULE { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0) }.ISO/IEC 8824-1:2003 (E) CharsDefn ::= cstring | Quadruple | Tuple | DefinedValue Quadruple ::= "{" Group ". "Row" and "Cell" productions shall be less than 256. These shall be represented using the escape sequences specified in 11. and "Cell" values.11 The "DefinedValue" in "CharsDefn" shall be a reference to a value of that type. and in the "Group" production it shall be less than 128. BasicGreek FROM ASN1-CHARACTER-MODULE { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0) }.9 The "XMLRestrictedCharacterStringValue" notation is: XMLRestrictedCharacterStringValue ::= xmlcstring 37. and the "Cell" specifies a cell within the row. 37. NOTE – If the restricted character string value contains characters which are not ISO/IEC 10646-1 characters specified in 11. but it can. In all cases. the only means of unambiguously specifying a character string value that uses such graphic symbols is by means of the "CharacterStringList" notation. these cannot be represented in "xmlcstring". and such values cannot be transferred using XML Encoding Rules (see ITU-T Rec. EXAMPLE – The following "cstring" notation should not be used because the graphic symbols 'H'. CYRILLIC and BASIC GREEK alphabets and thus are ambiguous. MyAlphabet ::= UniversalString (FROM (BasicLatin | greekCapitalLetterSigma)) mystring MyAlphabet ::= { "abc" . mystring is a value reference to a value of a subset of MyAlphabet.15. Conversely. 37. "Row".15. UTF8String. Cyrillic.693 | ISO/IEC 8825-4). NOTE 2 – Clause 38 defines a number of "valuereference"s which denote single characters (strings of size 1) of type BMPString (and hence UniversalString and UTF8String) and IA5String. the "Plane" specifies a plane within the group. BMPString or IA5String. greekCapitalLetterSigma ." Plane ".680 (07/2002) . 37. the "Row" specifies a row within the plane. be used wherever a value reference is needed to this value within MyAlphabet. "Plane". MyAlphabet ::= UniversalString (FROM (BasicLatin | Cyrillic | BasicGreek)) mystring MyAlphabet ::= "HOPE" An alternative unambiguous definition of mystring would be: mystring MyAlphabet(BasicLatin) ::= "HOPE" Formally. 58 ITU-T Rec." TableRow "}" TableColumn ::= number TableRow ::= number NOTE 1 – The "cstring" notation can only be used unambiguously on a medium capable of displaying the graphic symbols for the characters which are present in the value. X.2). IMPORTS BasicLatin.1." Row ".12 The "number" in the "Plane". if the medium has no such capability.

4} {0. 5} {0. 1} {0. BMPString is a subtype of UniversalString that has its own unique tag and contains only the characters in 37. GraphicString.11} {0. 0} {1.module are implicitly exported.12} {0. 1} The module is not printed here in full. Instead. where each name references a UniversalString value of size 1. Annex A. NOTE 2 – The purpose of defining BMPString as a built-in type is to enable encoding rules (such as BER) that do not take account of constraints to use 16-bit rather than 32-bit encodings. 0} {0. and for most text will be less verbose.14} {0.ISO/IEC 646 control characters: nul soh stx etx eot enq ack bel bs ht lf vt ff cr so si dle dc1 IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= {0. 8} {0.16 UTF8String is synonymous with UniversalString at the abstract level and can be used wherever UniversalString is used (subject to rules requiring distinct tags) but has a different tag and is a distinct type.ISO/IEC 8824-1:2003 (E) NOTE – Application designers should consider carefully the conformance implications when using open-ended character string types such as GeneralString. All of the value and type references defined in the module specified in 38. the means by which it is defined is specified. 38 Naming characters and collections defined in ISO/IEC 10646-1 This clause specifies an ASN.1 are exported and must be imported by any module that uses them.680 (07/2002) 59 . NOTE – The encoding of UTF8String used by BER and PER is different from that of UniversalString. 9} {0. less cells whose encoding is used to address characters outside the Basic Multilingual Plane) of ISO/IEC 10646-1. 37.1 Module "ASN1-CHARACTER-MODULE" The module begins as follows: ASN1-CHARACTER-MODULE { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0) } DEFINITIONS ::= BEGIN -.1 module ASN1-CHARACTER-MODULE (see clause 38) as the subtype of UniversalString corresponding to the "BMP" collection name defined in ISO/IEC 10646-1.15} {1. The "TableColumn" specifies a column and the "TableRow" specifies a row of a character code table in accordance with Figure 1 of ISO/IEC 2022.13} {0.10} {0.1 Specification of the ASN. 6} {0. where each name references a subset of the UniversalString type. and UniversalString without the application of constraints.14 The "number" in the "TableColumn" production shall be in the range zero to seven. 7} {0.All of the value references and type references defined within this -. -. 38. This notation is used only for IA5String when the code table contains Register Entry 1 in columns 0 and 1 and Register Entry 6 in columns 2 to 7 (see the ISO International Register of Coded Character Sets to be used with Escape Sequences). 2} {0.15 the Basic Multilingual Plane (those corresponding to the first 64K-2 cells.1.1 38. NOTE 3 – In the value notation all BMPString values are valid UniversalString and UTF8String values. 3} {0. It has an associated type defined as: UniversalString (Bmp) where Bmp is defined in the ASN. X. NOTE – These values are available for use in the value notation of the UniversalString type and types derived from it. ITU-T Rec. This module also contains the definition of a type reference name for each collection of characters from ISO/IEC 10646-1. Careful text on conformance is also needed for bounded but large character string types such as TeletexString. it is not defined in ASN1-CHARACTER-MODULE. and are available for import by any module. 37. NOTE 1 – Since BMPString is a built-in type. and the "number" in the "TableRow" production shall be in the range zero to fifteen.1 built-in module which contains the definition of a value reference name for each character from ISO/IEC 10646-1.

<namedcollectionstring>. 6} {1. 0.15} 38.3. 0.1. 0..14} {1. which is a collection of characters listed in ISO/IEC 10646-1. 2} {1.2 for each of the characters specified by ISO/IEC 10646-1.1. <alternativelist> is formed by using the <namedcharacter>s as generated in 38.see ISO/IEC 10646-1.3 For each name for a collection of graphic characters specified in ISO/IEC 10646-1. see ISO/IEC 10646-1 <iso10646name> is the character name derived from one listed in ISO/IEC 10646-1. 38. -.ISO/IEC 8824-1:2003 (E) dc2 dc3 dc4 nak syn etb can em sub esc is4 is3 is2 is1 del IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String IA5String ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= {1.and so on ::= {0.12} {1. 4} {1.15} {7. forms a limited subset.11} {1. The resulting type reference.2 For each entry in each list of character names for the graphic characters (glyphs) shown in clauses 24 and 25 of ISO/IEC 10646-1.2. 0. see ISO/IEC 10646-1 where: a) b) c) EXAMPLE latinCapitalLetterA BMPString ::= {0. 0.) NOTE – A limited subset is a list of characters in a specified subset.10} {1. 9} {1. -. where: a) b) c) <collectionstring> is the name for the collection of characters assigned in ISO/IEC 10646-1. ::= {0. (See the tutorial in Annex F. 5} {1. 0. X. 0. see ISO/IEC 10646-1 greekCapitalLetterSigma BMPString ::= {0. <namedcharacter> is a string obtained by applying to <iso10646name> the procedures specified in 38. 163} -. a statement is included in the module of the form: <namedcollectionstring> ::= BMPString (FROM (<alternativelist>)) -. 0. 7} {1. EXAMPLE (partial) space BMPString exclamationMark BMPString quotationMark BMPString .represents the collection of characters <collectionstring>.13} {1.represents the character <iso10646name>. ::= {0.represents the character GREEK CAPITAL LETTER SIGMA. <namedcollectionstring> is formed by applying to <collectionstring> the procedures of 38. 0. 8} {1.and so on | tilde) ) 60 ITU-T Rec. 0. plus the BASIC LATIN collection. <tablecell> is the glyph in the table cell in ISO/IEC 10646-1 corresponding to the list entry. Contrast this to a selected subset. 3.represents the character LATIN CAPITAL LETTER A.680 (07/2002) .. 3} {1. tilde BMPString ::= {0. 65} -. -.. 0.. Annex A. Annex A. 32} 33} 34} 126} BasicLatin ::= BMPString (FROM (space | exclamationMark | quotationMark | . the module includes a statement of the form: <namedcharacter> BMPString ::= <tablecell> -.

Thus.6 The module is terminated by the statement: END A user-defined equivalent of the example in 38.1.represents the collection of characters BASIC LATIN. (See E.1.5 38.The ellipsis in this example is used for brevity and means "and so on".7. each digit and each HYPHEN-MINUS is kept unchanged.1 type reference: BasicLatin 2) A character string type consisting of the characters in the BASIC LATIN collection. and Level3 indicates that implementation level 3 is required.3 A <namedcollectionstring> is the string obtained by taking <collectionstring> and applying the following algorithm: a) each upper-case letter of the ISO/IEC 10646-1 collection name is transformed into the corresponding lower-case letter. -. respectively. Level2 indicates that implementation level 2 is required. 38.4 ISO/IEC 10646-1 defines three levels of implementation. 38. b) c) EXAMPLES 1) The collection identified in Annex A of ISO/IEC 10646-1 as: BASIC LATIN has the ASN. By default all types defined in ASN1-CHARACTER-MODULE.2 A <namedcharacter> is the string obtained by taking an <iso10646name> (see 38.680 (07/2002) 61 . in which case the upper-case letter is kept unchanged.. together with the BASIC ARABIC collection.1. defined in ISO/IEC 10646-1. row 0.2.you cannot use this in an actual ASN. Annex A.) NOTE 3 – See F. see ISO/IEC 10646-1.3 is: BasicLatin ::= BMPString (FROM (space.see ISO/IEC 10646-1. each SPACE is deleted. 38. X. which is named "LESS-THAN SIGN" and has the graphic representation "<" can be referenced using the "DefinedValue" of: less-thanSign 38.2) and applying the following algorithm: a) each upper-case letter of the <iso10646name> is transformed into the corresponding lower-case letter. NOTE 2 – Level1 and Level2 will be used either following an "IntersectionMark" (see clause 46) or as the only constraint in a "ConstraintSpec". except for Level1 and Level2 conform to implementation level 3. each SPACE is deleted.represents the collection of characters BASIC LATIN. could be defined as follows: ITU-T Rec. the following are defined in ASN1-CHARACTER-MODULE: Level1 ::= BMPString (FROM (ALL EXCEPT CombiningCharacters)) Level2 ::= BMPString (FROM (ALL EXCEPT CombiningCharactersType-2)) Level3 ::= BMPString NOTE 1 – CombiningCharacters and CombiningCharactersType-2 are the <namedcollectionstring>s corresponding to "COMBINING CHARACTERS" and "COMBINING CHARACTERS B-2". unless the upper-case letter is preceded by a SPACE.ISO/IEC 8824-1:2003 (E) -. each digit and each HYPHEN-MINUS is kept unchanged. b) c) NOTE – The above algorithm.1 for an example. -. cell 60.2. since such types have no restriction on use of combining characters.1. Level1 indicates that implementation level 1 is required. taken in conjunction with the character naming guidelines in Annex K of ISO/IEC 10646-1 will always result in unambiguous value notation for every character name listed in ISO/IEC 10646-1. in which case the upper-case letter is kept unchanged.1 module. unless the upper-case letter is preceded by a SPACE or it is the first letter of the name.1.tilde)) -. -. EXAMPLE – The character from ISO/IEC 10646-1.5 for more information on this topic.

39 Canonical order of characters 39.ISO/IEC 8824-1:2003 (E) My-Character-String ::= BMPString (FROM (BasicLatin | BasicArabic) ) NOTE – The above construction is necessary because the apparently simpler construction of: My-Character-String ::= BMPString (BasicLatin | BasicArabic) would allow only strings which were entirely BASIC LATIN or BASIC ARABIC but not a mixture of both. 39. combining or non-combining character.6 For NumericString. it is referenced directly for each instance of use of the unrestricted character string type. the canonical ordering. is defined (see Table 7 of 37. 39. a character is in one-to-one correspondence with a cell in a code table. this abstract syntax may be part of the OSI defined context set. X.9 For IA5String.1.8. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring" or an ISO 646 control character value reference defined in 38.2) as: (space) 0 1 2 3 4 5 6 7 8 9 The entire character set contains precisely 11 characters. the canonical order is the same as the characters in cells 2/0-7/14 of the ISO/IEC 646 code table. NOTE – This order is the same as the order of the corresponding characters in the BASIC LATIN collection of ISO/IEC 10646-1.1) . BMPString.32 NOTE – That is. whether that cell has been assigned a character name or shape.8 For VisibleString. NumericString. increasing from left to right.1 OBJECT IDENTIFIERs.4 Endpoints of "ValueRanges" within "PermittedAlphabet" notations (or individual characters) can be specified using either the ASN. increasing from left to right and top to bottom.4) as: (SPACE) (APOSTROPHE) (LEFT PARENTHESIS) (RIGHT PARENTHESIS) (PLUS SIGN) (COMMA) (HYPHEN-MINUS) (FULL STOP) (SOLIDUS) 0123456789 (COLON) (EQUAL SIGN) (QUESTION MARK) ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz The entire character set contains precisely 74 characters.3 The canonical order of an abstract character is defined by the canonical order of its value in the 32-bit representation of ISO/IEC 10646-1.7 For PrintableString. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring". 62 ITU-T Rec. 39. 40 Definition of unrestricted character string types This clause defines a type whose values are the values of any character abstract syntax. 39. The entire character set contains precisely 95 characters.1 value reference defined in the module ASN1-CHARACTER-MODULE or (where the graphic symbol is unambiguous in the context of the specification and the medium used to represent it) by giving the graphic symbol in a "cstring" (ASN1-CHARACTER-MODULE is defined in 38. with low numbers appearing first and high numbers appearing last in the canonical order. UTF8String. Otherwise. and whether it is a control character or printing character. 39. NOTE – This order is the same as the order of the corresponding characters in the BASIC LATIN collection of ISO/IEC 10646-1. 39.1. the canonical order of the cells is defined from the ISO/IEC 646 encoding as follows: (ISO 646 ENCODING) The entire character set contains precisely 128 characters. VisibleString. 39. and IA5String. the canonical order of the cells is defined from the ISO/IEC 646 encoding (called ISO 646 ENCODING) as follows: (ISO 646 ENCODING) . NOTE 1 – A character abstract syntax (and one or more corresponding character transfer syntaxes) can be defined by any organization able to allocate ASN.680 (07/2002) . the canonical ordering. or by use of the "Quadruple" or "Tuple" notation of 37. PrintableString.1 For the purpose of "ValueRange" subtyping and for possible use by encoding rules. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring". a canonical ordering of characters is specified for UniversalString. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring".2 For the purpose of this clause only. is defined (see Table 8 of 37. In an OSI environment.

}. This -.5 The associated type for value definition and subtyping.Context-negotiation in progress. be the value of an ASN.the value of an ASN. presentation-context-id -.4 The unrestricted character string type has an associated type. transfer OBJECT IDENTIFIER } -.(Applicable only to OSI environments) -.Abstract and transfer syntax object identifiers --. fixed NULL -.. transfer-syntax OBJECT IDENTIFIER } -.This provides human-readable identification of the class of -. and the character transfer syntax.6 The text of 33. However.transformations) of an ASN.7 also applies to the unrestricted character string type.(Applicable only to OSI environments) -.2 40.designer (and hence known to both sender and receiver). This associated type is used to support its value and subtype notations.1 type --. is (with normative comments): SEQUENCE { identification CHOICE { syntaxes SEQUENCE { abstract OBJECT IDENTIFIER. and identification (separately or together) of: 1) 2) a character abstract syntax. 40.1 The unrestricted character "UnrestrictedCharacterStringType": string type (see 3.680 (07/2002) 63 . presentation-context-id INTEGER -. number 29. transfer-syntax OBJECT IDENTIFIER -. string-value OCTET STRING } ( WITH COMPONENTS { .known to both sender and receiver) -.6.The negotiated OSI presentation context identifies the -.ISO/IEC 8824-1:2003 (E) NOTE 2 – Profiles produced by a community of interest will normally determine the character abstract syntaxes and character transfer syntaxes that are to be supported for specific instances or groups of instances of CHARACTER STRING.The type of the value (for example.abstract-syntax. data-value-descriptor ABSENT } ) NOTE – The unrestricted character string type does not allow the inclusion of a data-value-descriptor value together with the identification.abstract and transfer syntaxes --.The data value is the value of a fixed ASN. context-negotiation SEQUENCE { presentation-context-id INTEGER.1 type) is fixed by the application -. the definition of the associated type provided here underlies the commonalities which exist between the embedded-pdv type. 40. but need not.3 This type has a tag which is universal class. X.1 type (and hence -. assuming an automatic tagging environment.selective-field-encryption (or other encoding -.76) shall be referenced by the notation UnrestrictedCharacterStringType ::= CHARACTER STRING 40. The type consists of values representing: a) b) a character string value that may.abstract and transfer syntaxes --. syntax OBJECT IDENTIFIER -. specification that it is -..1 character string type. data-value-descriptor ObjectDescriptor OPTIONAL -. the external type and the unrestricted character string type.A single object identifier for identification of the -. ITU-T Rec.the value --.6 and 33.identifies only the -.case is provided primarily to support -. . 40. 40. so the transfer syntax shall be specified --. It will be usual in OSI applications to include reference to supported syntaxes in an OSI Protocol Implementation Conformance Statement.

2 Generalized time This type shall be referenced by the name: GeneralizedTime The type consists of values representing: a) b) c) a calendar date. Case b) "19851106210627.7 The value notation shall be the value notation for the associated type. where the value of the string-value component of type OCTET STRING represents an encoding using the transfer syntax specified in identification. 42. without separators. a two-digit representation of the month and a two-digit representation of the day. 27. to any of the precisions defined in ISO 8601.1 Notation for types defined in clauses 42 to 44 The notation for referencing a type defined in clauses 42 to 44 shall be: UsefulType ::= typereference where "typereference" is one of those defined in clauses 42 to 44 using the ASN. as follows: GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString with the values of the VisibleString restricted to strings of characters which are either a) a string representing the calendar date. followed by a string representing the time of day.1. using ASN. In case b). and the time differential (t2) enables coordinated universal time to be determined as follows: coordinated universal time is t1 − t2 EXAMPLES Case a) "19851106210627. as specified in ISO 8601. In case c). the time shall represent coordinated universal time. as defined in ISO 8601. 41 41. and a time of day. or the characters in a) above followed by a string representing a local time differential.3 seconds after 9 pm on 6 November 1985. with a four-digit representation of the year.8. and with no terminating Z (as provided for in ISO 8601).ISO/IEC 8824-1:2003 (E) 40.1 notation.5 40.2 The tag of each "UsefulType" is specified in clauses 42 to 44.value of associated type defined in 40.3" local time 6 minutes. as specified in ISO 8601. 41.8 An example of the unrestricted character string type is given in E. or the characters in a) above followed by an upper-case letter Z. UnrestrictedCharacterStringValue ::= SequenceValue -. b) c) In case a). as specified in ISO 8601. X.5 XMLUnrestrictedCharacterStringValue ::= XMLSequenceValue -. 42 42. except for the hours value 24 which shall not be used. Case c) 64 ITU-T Rec. without use of separators.value of associated type defined in 40. without separators other than decimal comma or decimal period (as provided for in ISO 8601).3 The type is defined. and the local time differential factor as defined in ISO 8601.680 (07/2002) .1 42.2.3Z" coordinated universal time as above. the time shall represent the local time. the part of the string formed as in case a) represents the local time (t1).

3. EXAMPLE 2 – If local time is 7am on 2 January 2001 and coordinated universal time is 12 noon on 2 January 2001. using ASN. where hh is hour and mm is minutes. 44 44. In alternative c) 2).680 (07/2002) 65 . and either: 1) 2) c) 1) 2) the four digits hhmm where hh is hour (00 to 23) and mm is minutes (00 to 59).1 43. the time (t1) specified by a) and b) above is the local time. and time to a precision of one minute or one second. or "0101020700-0500".2 Universal time This type shall be referenced by the name: UTCTime The type consists of values representing: a) b) c) calendar date. The value notation shall be the value notation for the VisibleString defined in 43. but identical text for different objects is intended to be uncommon. the value of UTCTime is either of: – – "8201021200Z".3. 43.3-0500" local time as in example a).4 43. and DD is the day of the month (01 to 31). ITU-T Rec.2 The type consists of human-readable text which serves to describe an object. the time differential (t2) specified by c) 2) above enables the coordinated universal time to be determined as follows: Coordinated universal time is t1 − t2 EXAMPLE 1 – If local time is 7am on 2 January 1982 and coordinated universal time is 12 noon on 2 January 1982. or one of the characters + or -.5 "0101021200Z". followed by hhmm. and ss is seconds (00 to 59).ISO/IEC 8824-1:2003 (E) "19851106210627.5 The tag shall be as defined in 42. The tag shall be as defined in 43. as follows: UTCTime ::= [UNIVERSAL 23] IMPLICIT VisibleString with the values of the VisibleString restricted to strings of characters which are the juxtaposition of: a) b) the six digits YYMMDD where YY is the two low-order digits of the Christian year. with local time 5 hours retarded in relation to coordinated universal time. the value of UTCTime is either of: – – 43.3. 42. either: The alternatives in b) above allow varying precisions in the specification of the time. MM is the month (counting January as 01). or "8201020700-0500". and (optionally) a local time differential from coordinated universal time. 43 43. or the six digits hhmmss where hh and mm are as in 1) above. X.1 The object descriptor type This type shall be referenced by the name: ObjectDescriptor 44. The value notation shall be the value notation for the VisibleString defined in 42.3.4 42. the time is coordinated universal time.1. The text is not an unambiguous identification of the object.3 The type is defined. In alternative c) 1). and the character Z.

.. fourth. 45. not to the selected SEQUENCE type.1. b NULL } V ::= a < T (WITH COMPONENTS {. the interpretation of the overall notation is the same regardless of whether the "TaggedType" or the "Type" is considered as the parent type. a ABSENT}) applies to the CHOICE type T.64)) 45. ConstrainedType ::= Type Constraint | TypeWithConstraint In the first alternative. not to the set-of or sequence-of type. In the first.ISO/IEC 8824-1:2003 (E) NOTE – It is recommended that an authority assigning values of type OBJECT IDENTIFIER to an object should also assign values of type ObjectDescriptor to that object. it applies to the "Type" in the (innermost) set-of or sequence-of notation. The value notation shall be the value notation for the GraphicString defined in 44. sixth and eighth it is "SizeConstraint" (see 47. 45 Constrained types 45.6). either to restrict its set of values to some subtype of the parent or (within a set or sequence type) to specify that component relations apply to values of the parent type and to values of some other component in the same set or sequence value. and has no effect on the values of V. the constraint is "Constraint" (see 45.5 The tag shall be as defined in 44.4 When the "Constraint" notation follows a "TaggedType" notation. special notation is provided to allow a constraint to be applied to a set-of or sequence-of type. 45.2 When the "Constraint" notation follows a set-of or sequence-of type notation.2. NOTE – For example.3..1 The "ConstrainedType" notation allows a constraint to be applied to a (parent) type.4 44. b BOOLEAN }.2).5. fifth and seventh alternatives. a ABSENT}) 45.. T ::= CHOICE { a SEQUENCE { a INTEGER OPTIONAL. it applies to the choice type. 66 ITU-T Rec.5 As a consequence of the interpretation specified in 45.3 When the "Constraint" notation follows the selection type notation. 44. third. In the fifth and sixth alternatives the parent type is "SET OF NamedType"... It also allows an exception identifier to be associated with a constraint. in the following the constraint (SIZE(1.. and not to the type of the selected alternative.3.5). NOTE – In the following example. while in the second. using ASN. X. not the SEQUENCE OF: NamesOfMemberNations ::= SEQUENCE OF VisibleString (SIZE(1. as follows: ObjectDescriptor ::= [UNIVERSAL 7] IMPLICIT GraphicString The GraphicString contains the text describing the object. The second alternative is defined in 45. the parent type is "Type".6. and in the seventh and eighth is "SEQUENCE OF NamedType".64)) applies to the VisibleString. This is "TypeWithConstraint": TypeWithConstraint ::= SET Constraint OF Type | SET SizeConstraint OF Type | SEQUENCE Constraint OF Type | SEQUENCE SizeConstraint OF Type | SET Constraint OF NamedType | SET SizeConstraint OF NamedType | SEQUENCE Constraint OF NamedType | SEQUENCE SizeConstraint OF NamedType In the first and second alternatives the parent type is "SET OF Type".. Such a constraint is ignored (see 29. 44. the constraint (WITH COMPONENTS {. while in the third and fourth it is "SEQUENCE OF Type".3 The type is defined.680 (07/2002) . and the constraint is specified by "Constraint" as defined in 45.

ITU-T Rec.680 (07/2002) 67 ." ". X. NOTE 4 – Note that two EXCEPT operators must have either "|".g.g.683 | ISO/IEC 8824-4. X..ISO/IEC 8824-1:2003 (E) NOTE – Although the "Constraint" alternatives encompass the corresponding "SizeConstraint" alternatives.. NOTE 2 – The order of precedence from highest to lowest is: EXCEPT.682 | ISO/IEC 8824-3. clause 9). 45. NOTE 5 – Note that ((A EXCEPT B) EXCEPT C) is the same as (A EXCEPT (B | C)). "|".4)] or a parenthesized subtype constraint [e. In such cases." ". it shall only be present if the "ConstraintSpec" includes an occurrence of "DummyReference" (see ITU-T Rec. 45.. NOTE 6 – The elements that are referenced by "ElementSetSpecs" is the union of the elements referenced by the "RootElementSetSpec" and "AdditionalElementSetSpec" (when present). either the characters or the words be used throughout a user Specification. Unless it is used in conjunction with an "extension marker" (see clause 48). The character "|" and the word UNION are synonymous. either a constraint without parentheses [e. This must be changed to ((A EXCEPT B) EXCEPT C) or (A EXCEPT (B EXCEPT C))..3) or is a "UserDefinedConstraint" (see ITU-T Rec.. 8. Notice that ALL EXCEPT is specified so that it cannot be interspersed with the other constraints without the use of parentheses around "ALL EXCEPT xxx"... EXCEPT can be used with either style. There shall be at least one element in the set. The "GeneralConstraint" is defined in ITU-T Rec. 46 Element set specification 46.7 The notation "SubtypeConstraint" is the general-purpose "ElementSetSpecs" notation (see clause 46): SubtypeConstraint ::= ElementSetSpecs In this context. the notation "ElementSetSpec" is used: ElementSetSpecs ::= RootElementSetSpec | RootElementSetSpec ". NOTE 3 – Anywhere that "Elements" occurs." AdditionalElementSetSpec RootElementSetSpec ::= ElementSetSpec AdditionalElementSetSpec ::= ElementSetSpec ElementSetSpec ::= Unions ALL Exclusions | Unions ::= Intersections | UElems UnionMark Intersections UElems ::= Unions Intersections ::= IntersectionElements | IElems IntersectionMark IntersectionElements IElems ::= Intersections IntersectionElements ::= Elements | Elems Exclusions Elems ::= Elements Exclusions ::= EXCEPT Elements UnionMark ::= "|" | UNION IntersectionMark ::= "^" | INTERSECTION NOTE 1 – The caret character "^" and the word INTERSECTION are synonymous. as a stylistic matter. INTEGER (1. "^"." | RootElementSetSpec ".1 In some notations a set of elements of some identified type or information object class (the governor) can be specified.682 | ISO/IEC 8824-3. X. "(" or ")" separating them. INTEGER ((1. the "SizeConstraint" alternatives are provided for historical reasons.1. X.. so (A EXCEPT B EXCEPT C) is not permitted." ". the elements are values of the parent type (the governor of the element set is the parent type). "^".6 A constraint is specified by the notation "Constraint": Constraint ::= "(" ConstraintSpec ExceptionSpec ")" ConstraintSpec ::= SubtypeConstraint | GeneralConstraint "ExceptionSpec" is defined in clause 49. 8. It is recommended that.4 | 9))] can appear.

e. The extension additions can be determined by performing the set arithmetic using the root values augmented by the extension additions.680 (07/2002) . if the "ObjectSetElements" notation is used. 68 ITU-T Rec.ISO/IEC 8824-1:2003 (E) NOTE 7 – When the elements are information objects (i. 12. As described in ITU-T Rec. then those specified in the "Intersections" [see c)].681 | ISO/IEC 8824-2. NOTE – This applies even if all values of the parent are included in the root of the new constrained type. if the first alternative of "IntersectionElements" is selected. In this case.10. if the first alternative of "Unions" is selected. and then excluding values that were determined to be root values. The end-points of a range constraint are required to reference values that are present in the extension root of the governing type. This notation shall only be used when the governor is a type.681 | ISO/IEC 8824-2. X. only abstract values that are in the extension root of the governing type are used in the set arithmetic. 46. and the actual type involved will further constrain the notational possibilities.. 12. the root values can be determined by performing the set arithmetic using only root values of the sets of values involved in the set arithmetic. otherwise those specified in the "Elems" except those specified in the "Exclusions". If any of the information object sets contributing to the set arithmetic are extensible. the result of the set arithmetic is extensible. 46. for "Intersections": at least one of the "IElems" is extensible.2. and the range specification as a whole references all (and only) those values in the range that are within the extension root of the governing type.3 The set of values is defined to be extensible if the following conditions hold: a) b) c) d) for "Unions": at least one of the "UElems" is extensible. otherwise those specified at least once either in the "UElems" or "Intersections".5 The "Elements" notation is defined as follows: Elements ::= SubtypeElements | ObjectSetElements | "(" ElementSetSpec ")" The elements specified by this notation are: a) As described in clause 47 below if the "SubtypeElements" alternative is used. otherwise those specified by "IElems" which also are specified by "IntersectionElements". for each set of values involved in the set arithmetic. all instances of value notation (including value references) used in set arithmetic are required to reference an abstract value of the extension root of the governing type. if the first alternative of "Intersections" is selected.8 If a subtype constraint is serially applied to a parent type which is extensible through the application of an extensible constraint. those specified in the "IntersectionElements" [see d)]. b) c) d) 46. for "Elements": there is an extension marker at the outer level. X. all information objects are used in the set arithmetic. Otherwise. the governor is an information object class).4 If the set of values is extensible. This notation shall only be used when the governor is an information object class. the set of values is not extensible (see also G. 46. b) c) 46. or if there is an extension marker at the outermost level of an "ElementSetSpecs". X.6 When performing set arithmetic within a subtype constraint or a value set when the governing type is extensible. Those specified by the "ElementSetSpec" if the third alternative is used.7 When performing set arithmetic involving information object sets. as specified in 46. 46.4).3 is used. those specified in the "Unions" [see b)]. the notation "ObjectSetElements" as defined in ITU-T Rec. for "Exclusions": the set of elements preceding EXCEPT is extensible.2 The elements forming the set are: a) if the first alternative of the "ElementSetSpec" is selected. 46. In this context. value notation used within it shall not reference values that are not in the extension root of the parent type. otherwise all elements of the governor except those specified in the "Elements" notation of the "Exclusions". those specified in the "Elements". The result of the second (serially applied) constraint is defined to be the same as if the constraint had been applied to the parent type without its extension marker and possible extension additions. the governor is referred to as the parent type.

the example would have been legal.legal since it is value notation for Foo. . 47 47. not part of a constraint Bar is illegal since 73 is not in the extension root of Foo.. Table 9 summarizes which notations can be applied to which parent types. and their syntax and semantics are defined in the following subclauses...1 Subtype elements General A number of different forms of notation for "SubtypeElements" are provided.. SubtypeElements ::= SingleValue | ContainedSubtype | ValueRange | PermittedAlphabet | SizeConstraint | TypeConstraint | InnerTypeConstraints | PatternConstraint ITU-T Rec. X.80) Bar ::= Foo (73) -. 73. and Bar would have contained the single value of 73. They are identified below. If 73 had been in the extension root of Foo..680 (07/2002) 69 .ISO/IEC 8824-1:2003 (E) EXAMPLE Foo ::= INTEGER ( 1.6.illegal foo Foo ::= 73 -.

X.2 A "ContainedSubtype" specifies all of the values in the root of the parent type that are also in the root of "Type". UTF8String and UniversalString.1 Contained subtype The "ContainedSubtype" notation shall be: ContainedSubtype ::= Includes Type Includes ::= INCLUDES | empty The "empty" alternative of the "Includes" production shall not be used when "Type" in "ContainedSubtype" is the notation for the null type.2. IA5String. PrintableString.3. 47.680 (07/2002) . 47.ISO/IEC 8824-1:2003 (E) Table 9 – Applicability of subtype value sets Type (or derived from such a type by tagging or subtyping) Bit string Boolean Choice Embedded-pdv Enumerated External Instance-of Integer Null Object class field type Object descriptor Object identifier Octet string open type Real Relative object identifier Restricted character string types Sequence Sequence-of Set Set-of Time types Unrestricted character string type a) Single value Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yesb) Yes Yes Yes Yes Yes Yes Yes Contained subtype Yes Yes Yes No Yes No Yes Yes Yes Yes Yes Yes Yes No Yes Yesb) Yes Yes Yes Yes Yes Yes No Value range No No No No No No No Yes No No No No No No Yes No Yesa) No No No No No No Size constraint Yes No No No No No No No No No Yes No Yes No No No Yes No Yes No Yes No Yes Permitted alphabet No No No No No No No No No No Yes No No No No No Yes No No No No No No Type constraint No No No No No No No No No No No No No Yes No No No No No No No No No Inner subtyping No No Yes Yes No Yes Yes No No No No No No No Yes No No Yes Yes Yes Yes No Yes Pattern constraint No No No No No No No No No No No No No No No No Yes No No No No No No Allowed only within the "PermittedAlphabet" of BMPString. VisibleString. 47.2 47. NumericString.2 A "SingleValue" specifies the single value of the parent type specified by "Value". 70 ITU-T Rec. 47. b) The starting node for all relative object identifier types or values in constraints or valuesets shall be the same as the starting node for the governor.3.3 47.1 Single value The "SingleValue" notation shall be: SingleValue ::= Value where "Value" is the value notation for the parent type. "Type" is required to be derived from the same built-in type as the parent type.2.

5.680 (07/2002) 71 . All values specified in the "ValueRange" are required to be in the root of the parent type. 47. UniversalString and UTF8String only) and real types. octet string types. and takes the form of any constraint which can be applied to the following parent type: INTEGER (0 . PrintableString.5.1 Value range The "ValueRange" notation shall be: ValueRange ::= LowerEndpoint ". 47.4 The unit of measure depends on the parent type.5. the "PermittedAlphabet" of certain restricted character string types (IA5String. NOTE – The use of an extensible "Type" does not in itself make the constrained type extensible. 47. 47. character string types. as follows: Type bit string octet string character string set-of sequence-of Unit of measure bit octet character component value component value NOTE – The count of the number of characters specified in this subclause for determining the size of a character string value shall be clearly distinguished from a count of octets.ISO/IEC 8824-1:2003 (E) 47. When open.3 Each endpoint of the range is either closed (in which case that endpoint is specified) or open (in which case the endpoint is not specified).3 The set of values referenced by an extensible "Type" used in a contained subtype constraint does not inherit the extension marker from the "Type". ITU-T Rec. The count of characters shall be interpreted according to the definition of the collection of characters used in the type. NumericString.. set-of types or sequence-of types. in particular.4 47.5 47." UpperEndpoint 47.2 A "SizeConstraint" can only be applied to bit string types. in relation to references to the standards. 47. the specification of the endpoint includes a less-than symbol ("<"): LowerEndpoint ::= LowerEndValue | LowerEndValue "<" UpperEndpoint ::= UpperEndValue | "<" UpperEndValue 47. VisibleString. tables or registration numbers in a register which can appear in such a definition.5. BMPString.4.4. MAX) The "Constraint" shall use the "SubtypeConstraint" alternative of "ConstraintSpec".4.3 The "Constraint" specifies the permitted integer values for the length of the specified values. NOTE – For the purpose of subtyping.2 A "ValueRange" specifies the values in a range of values which are designated by specifying the values of the endpoints of the range. in which case the range extends in that direction as far as the parent type LowerEndValue ::= Value | MIN UpperEndValue ::= Value | MAX NOTE – When a "ValueRange" is used as a "PermittedAlphabet" constraint.4. "LowerEndValue" and "UpperEndValue" shall be of size 1.. PLUS-INFINITY exceeds all real values and MINUS-INFINITY is less than all real values. X.1 Size constraint The "SizeConstraint" notation shall be: SizeConstraint ::= SIZE Constraint 47. and do not contribute to the values of the constrained type.4 allows: An endpoint may also be unspecified. This notation can only be applied to integer types.3. Any values in "Type" that are not in the extension root of that type are ignored.

3 For the types which are defined in terms of a single other (inner) type (set-of and sequence-of).8.. The set of values in the root are those permitted by the root of "Constraint".2 This notation is only applied to an open type notation and restricts the open type to values of "Type". A value of the parent type is not specified unless it satisfies all of the constraints expressed or implied (see 47. 47.8. the constraints must appear in order.8." ".1 Permitted alphabet The "PermittedAlphabet" notation shall be: PermittedAlphabet ::= FROM Constraint 47. This notation can only be applied to restricted character string types.8 47.4 and 26.5 The "TypeConstraints" contains a list of constraints on the component types of the parent type. there shall be at most one "NamedConstraint".ISO/IEC 8824-1:2003 (E) 47. NOTE – An "InnerTypeConstraints" applied to a set or sequence type is ignored by the COMPONENTS OF transformation (see 24. sequence-of. This notation can be applied to the set-of. a number of constraints on these inner types can be provided. 47. sequence and choice types.6). then the set of values selected by the permitted alphabet constraint is extensible.3 The "Constraint" is any which could be applied to the parent type (see Table 9)." TypeConstraints NamedConstraint ::= identifier ComponentConstraint 47.7 47. a constraint taking the form of a subtype value specification is provided.8.8. except that it shall use the "SubtypeConstraint" alternative of "ConstraintSpec". 47.7.4 If "Constraint" is extensible.6 47. For a given component.4 For the types which are defined in terms of multiple other (inner) types (choice. set. The notation for this is "SingleTypeConstraint": SingleTypeConstraint ::= Constraint The "Constraint" defines a subtype of the single other (inner) type." TypeConstraints "}" TypeConstraints ::= NamedConstraint | NamedConstraint ".2 An "InnerTypeConstraints" specifies only those values which satisfy a collection of constraints on the presence and/or values of the components of the parent type. and the extension additions are those values permitted by the root together with the extension-additions of "Constraint". The sub-alphabet includes precisely those characters which appear in one or more of the values of the parent string type which are allowed by the "Constraint".. and sequence). For a sequence type.6.2 A "PermittedAlphabet" specifies all values which can be constructed using a sub-alphabet of the parent string.7. X. set. 47.2). excluding those values already in the root. 47.1 Type constraint The "TypeConstraint" notation shall be: TypeConstraint ::= Type 47. 72 ITU-T Rec. The inner type to which the constraint applies is identified by means of its identifier.8.7.6. The notation for this is "MultipleTypeConstraints": MultipleTypeConstraints ::= FullSpecification | PartialSpecification FullSpecification ::= "{" TypeConstraints "}" PartialSpecification ::= "{" ". 47.1 Inner subtyping The "InnerTypeConstraints" notation shall be: InnerTypeConstraints ::= | WITH COMPONENT SingleTypeConstraint WITH COMPONENTS MultipleTypeConstraints 47.680 (07/2002) . A value of the parent type is specified if and only if each inner value belongs to the subtype obtained by applying the "Constraint" to the inner type.7.

ellipsis. this is equivalent to a constraint of PRESENT for a set or sequence component marked OPTIONAL and imposes no further constraint otherwise. NOTE – "Value" is formally defined as a value of type UniversalString.8. The notation is "ComponentConstraint": ComponentConstraint ::= ValueConstraint PresenceConstraint 47.2 If the parent type is a choice.9 A constraint on the presence of an inner type shall be expressed by the notation "PresenceConstraint": PresenceConstraint ::= PRESENT | ABSENT | OPTIONAL | empty The meaning of these alternatives. or both.1 regular expression. its value. the "PatternConstraint" does not select values whose leading characters match the (entire) ASN. and any inner type can be omitted from the list.8 A constraint on the value of an inner type is expressed by the notation "ValueConstraint": ValueConstraint ::= Constraint | empty The constraint is satisfied by a value of the parent type if and only if the inner value belongs to the subtype specified by the "Constraint" applied to the inner type. no constraint is imposed. such as the Packed Encoding Rules.16). is an indication that extension additions are expected.9.8. a component type can be constrained to be ABSENT (in which case the constraint is satisfied if and only if the corresponding component type is not used in the value).8. 47.. Where "PartialSpecification" is employed.6 The "MultipleTypeConstraints" comprises either a "FullSpecification" or a "PartialSpecification".1 The extension marker. but the sets of values of type UniversalString and UTF8String are the same (see 37.9 47.3 The meaning of an empty "PresenceConstraint" depends on whether a "FullSpecification" or a "PartialSpecification" is being employed: a) b) in a "FullSpecification".9.8.9.1 to 47.9.2 The joint use of the extension marker and an exception identifier (see clause 49) is both an indication that extension additions are expected and also provides a means for identifying the action to be taken by the application if there is a constraint violation. the extension marker has no effect on some encoding rules of ASN.9) and which is not explicitly listed.6 for a clarifying example. It makes no statement as to how such additions should be handled other than that they shall not be treated as an error during the decoding process.3. 47.1.8. i. Thus a totally equivalent definition could have been to say that "Value" is a value of type UTF8String.680 (07/2002) 73 .1 If the parent type is a sequence or set.8. The entire value shall satisfy the entire ASN.4. 47. there are no implied constraints. there shall be at most one PRESENT keyword in a "MultipleTypeConstraints". but does on others. 47. a component type marked OPTIONAL may be constrained to be PRESENT (in which case the constraint is satisfied if and only if the corresponding component value is present) or to be ABSENT (in which case the constraint is satisfied if and only if the corresponding component value is absent) or to be OPTIONAL (in which case no constraint is placed upon the presence of the corresponding component value). It is recommended that this notation be used in those situations where store and forward or ITU-T Rec. 47.9.9.1 regular expression. 48.1 regular expression as defined in Annex A.ISO/IEC 8824-1:2003 (E) 47.1 regular expression but which contain further trailing characters. and the situations in which they are permitted are defined in 47. 48. X.8.8. there is an implied presence constraint of ABSENT on all inner types which can be constrained to be absent (see 47. The "PatternConstraint" selects those values of the parent type that satisfy the ASN.7 A particular inner type may be constrained in terms of its presence (in values of the parent type). such as the Basic Encoding Rules. in a "PartialSpecification".9.e.8.2 "Value" shall be a "cstring" of type UniversalString (or a reference to such a character string) which contains an ASN. When "FullSpecification" is used.8.1 Pattern constraint The "PatternConstraint" notation shall be: PatternConstraint ::= PATTERN Value 47. or PRESENT (in which case the constraint is satisfied if and only if the corresponding component type is used in the value). 48 The extension marker NOTE – Like the constraint notation in general. NOTE – See E. Its effect on encodings defined using ECN is determined by the ECN specification. 47.

7. or there is a single extension marker in a CHOICE or SEQUENCE or SET..5 If a type defined with an extensible constraint is further constrained with an "ElementSetSpecs". the newly defined type does not inherit the extension marker or any of its extension additions (see 47. 74 ITU-T Rec. 48.present in any of its values.10.4 If..ISO/IEC 8824-1:2003 (E) any other form of relaying is in use. C ::= INTEGER (A. For example: A ::= INTEGER (0.2. -. Note 2. and then the new element is added immediately before the second extension marker.6 Components of a set. and then an extension marker is added and the new element is added as the first addition after that extension marker.3 and 28.7.3 The conceptually-added element is defined to have a tag which is distinct from the tag of all normal ASN.3 and 28.3) are necessary and sufficient to ensure that: a) any unknown extension addition can be unambiguously attributed to a single insertion point when a BER encoding is decoded. and then the new element is added at the end of the CHOICE or SEQUENCE or SET immediately prior to the closing brace.3 The result of set arithmetic involving subtype constraints.2 This conceptually-added element is solely for the purposes of checking legality through the application of rules requiring distinct tags (see 24. the following transformation shall conceptually be applied before performing the check for tag uniqueness: 48.680 (07/2002) . …) -.7.B is inextensible and is constrained to 0-10. They are nonetheless imposed as rules of ASN.. B ::= INTEGER (A) -.3). X... so as to indicate (for example) that any unrecognized extension additions are to be returned to the application for possible re-encoding and relaying.3).7.5) C ::= A -. 26. NOTE – Inner type constraints have no effect on extensibility.C is extensible and is constrained to 0-10.1 A new element or alternative (called the conceptually-added element. 48.7 Where this Recommendation | International Standard requires distinct tags (see 24.3). but which matches the tag of all such conceptually-added elements and matches the indeterminate tag of the open type.C is extensible. 48. It is conceptually-added after the application of automatic tagging (if applicable) and the expansion of COMPONENTS OF.B is extensible. sequence or choice type is an extensible type.5 to 24. regardless of whether the set. 48. but 'b' shall not be -.1 to ensure independence of the notation from encoding rules.A is extensible.10.4 If a type defined with an extensible constraint is referenced in a "ContainedSubtype". 48. For example: A ::= SEQUENCE { a INTEGER b BOOLEAN OPTIONAL. .7.. NOTE – The rules concerning tag uniqueness relating to the conceptually added element and to the open type.. . 14. 26.3). with these conceptually-added elements. 26. together with the rules requiring distinct tags (see 24.5 to 24. sequence or choice type that are constrained to be absent shall not be present. 48.3. as specified in ITU-T Rec. or there are two extension markers in a CHOICE or SEQUENCE or SET. 48. 12) -.8).6. X.B is inextensible.6. see 48. and b) unknown extension additions can never be confused with OPTIONAL elements. -.) B ::= A (2. . the rules requiring distinct types are violated. In PER the above rules are sufficient but are not necessary to ensure these properties.6.2) is conceptually added at the extension insertion point if: a) b) c) there are no extension markers but extensibility is implied in the module heading.1 types.5 to 24. 48. The newly defined type can be made extensible by including an extension marker at the outermost level in its "ElementSetSpecs" (see also 46.681 | ISO/IEC 8824-2. value sets or information object sets that are extensible is specified in clause 46.. then the specification has made illegal use of the extensibility notation. } B ::= A (WITH COMPONENTS {b ABSENT}) -.. For example: A ::= INTEGER (0.3 and 28. the resulting type does not inherit the extension marker nor any extension additions that may be present in the former constraint (see 46..A is extensible.

1 specification in order to indicate the actions to be taken.. The identifier consists of a "!" character. d D } is illegal..8. X. b CHOICE { c C. These cases arise in particular from use of a constraint that is defined using a parameter of the abstract syntax (see ITU-T Rec. . then the implementors will either need to identify text that describes the action that they are to take..8. for added material may be part of b or d. . .8 48. d D.1 specification.3 If an "ExceptionSpec" is present. followed by an optional ASN. X.1 type and a value of that type. } . the application designer needs to identify the actions to be taken when some implementationdependent constraint is violated. 48. clause 10). The restrictions are designed to ensure that in BER. or extensible choices within elements of a sequence marked OPTIONAL or DEFAULT. 48. with extensible choices inside extensible choices. If it is absent. 49. The exception identifier is provided as an unambiguous means of referring to parts of an ASN.. 49. 48.2 In such cases. or will take implementation-dependent action when a constraint violation occurs. and a version 1 system cannot tell which. for added material may be part of b. ITU-T Rec. DER and CER it is possible to attribute an unknown element received by a version 1 system unambiguously to a specific insertion point.. INTEGER is assumed as the type of the value.2 Example 2 A ::= SET { a A.8.8.4 More complex examples can be constructed.. it indicates that there is text in the body of the standard saying how to handle the constraint violation associated with the "!" character.1 Examples Example 1 A ::= SET { a A. In the absence of the type. .. } } is also illegal.ISO/IEC 8824-1:2003 (E) NOTE – The purpose of the above rules is to make precise restrictions arising from the use of insertion points (particularly those which are not at the end of SEQUENCEs or SETs or CHOICEs). This would be important if the exception handling of such added elements was different for different insertion points.1 In a complex ASN. . . for there is no ambiguity as any added material must be part of b. there are a number of places where it is specifically recognized that decoders have to handle material that is not completely specified in it.. d D. but the above rules are necessary and sufficient to ensure that an element not present in version 1 can be unambiguously attributed by a version 1 system to precisely one insertion point.683 | ISO/IEC 8824-4. } } is legal. b CHOICE { c C. d CHOICE { e E.3 Example 3 A ::= SET { a A.680 (07/2002) 75 . }. b CHOICE { c C.. 49 The exception identifier 49. or may be at the outer level of A. 48..

The third alternative denotes an exception identifier ("Value") of arbitrary type ("Type"). the exception identifier is ignored and is not inherited by the type being constrained as a result of the set arithmetic.6 Where an exception marker is present on types that are used in set arithmetic.ISO/IEC 8824-1:2003 (E) 49.680 (07/2002) . X. 49.4 The "ExceptionSpec" notation is defined as follows: ExceptionSpec ::= "!" ExceptionIdentification | empty ExceptionIdentification ::= SignedNumber | DefinedValue | Type ":" Value The first two alternatives denote exception identifiers of type integer. more than one of which has an exception identifier.5 Where a type is constrained by multiple constraints. the exception identifier in the outermost constraint shall be regarded as the exception identifier for that type. 76 ITU-T Rec. 49.

it is constructed analogously to arithmetic expressions. A.r. are regular expressions that match themselves.1.1. which are (usually) made of one or two characters. A "^" after the opening bracket complements the set which follows it.m) Match any character in the set where ranges are denoted by "-".680 (07/2002) 77 . ITU-T Rec. A. Quadruple which identifies a character of ISO/IEC 10646-1 (see 37.1.1 Match any character (unless it is one of the newline characters defined in 11. A regular expression is itself a string.) #(n. \d \w \t \n \r \s \b \ \\ "" | ( ) * + ? #n #(n) #(n.1. Their meaning is explained in the following clauses.8) Match the named character (or any character of the named character set) 38.1 regular expression is a pattern that describes a set of strings whose format conforms to this pattern. [ ] {g.1 Definition A.m) #(.2 Most characters. EXAMPLE The regular expression "fred" matches only the string "fred". A.6) atch a word boundary Quote the next metacharacter and cause it to be interpreted literally Match the REVERSE SOLIDUS (92) character "\" Match the QUOTATION MARK (34) character (") Alternative between two expressions Grouping of the enclosed expression Match the previous expression zero. The smallest expressions. X.2.6 Match the CARRIAGE RETURN (13) character (see 11.6) Match any one of the newline characters defined in 11.1.1 An ASN. one or several times Match the previous expression one or several times Match the previous expression once or not at all Match the previous expression exactly n times (where n is a single digit) Match the previous expression exactly n times Match the previous expression at least n times Match the previous expression at least n but not more than m times Match the previous expression not more than m times (prefix) (infix) (postfix) (postfix) (postfix) (postfix) (postfix) (postfix) (postfix) (postfix) NOTE 1 – The characters CIRCUMFLEX ACCENT (94) "^" and HYPHEN-MINUS (45) "-" are additional metacharacters in certain positions of the string defined in A.2.6) Match any digit (equivalent to "[0-9]") Match any alphanumeric character (equivalent to "[a-zA-Z0-9]") Match the HORIZONTAL TABULATION (9) character (see 11.p.1.3 Two regular expressions may be concatenated. The following list contains all of the metacharacter sequences. where some other examples of use can be found. The regular expressions presented here are very similar to those of scripting languages like Perl and to those of XML Schema.2 Metacharacters A.1 A metacharacter sequence (or metacharacter) is a set of one or more contiguous characters that have a special meaning in the context of a regular expression.1 regular expressions (This annex forms an integral part of this Recommendation | International Standard) A. the resulting regular expression matches any string formed by concatenating two substrings that respectively match the concatenated subexpressions. including all letters and digits.1.2.c} \N{name} .1. are placeholders that stand for a set of characters. by using various operators to combine smaller expressions.ISO/IEC 8824-1:2003 (E) Annex A ASN.6) Match any one of the white-space characters (see 11. NOTE 2 – The value in round brackets after a character name in this annex is the decimal value of the character in ISO/IEC 10646-1.

A. A. A. any spacing characters that appear immediately prior to or following the newline have no significance and match nothing (see 11.680 (07/2002) .2.6 The symbol "\d" is a synonym for "[0-9]".ISO/IEC 8824-1:2003 (E) NOTE 3 – This notation does not provide the metacharacters "^" and "$" to match the beginning and the end of a string respectively..2 A list of characters enclosed by "[" and "]" matches any single character in that list.3 To avoid any ambiguity between two ISO/IEC 10646-1 characters which have the same glyph. NOTE 4 – The following metacharacter sequences cannot contain white-space (see 11. a hyphen or a period.2. All metacharacter sequences. EXAMPLES The regular expression "[0123456789]".4 A notation of the form "\N{valuereference}" matches the referenced character if "valuereference" is a reference to a restricted character string value of size 1 (see clause 37) which is defined or imported in the current module.2. or equivalently "(\N{BasicLatin} | \N{Cyrillic} | \N{BasicGreek})+".2. NOTE – In particular.c} \N{name} #n #(n) #(n.6) unless the white-space appears immediately prior to or following a newline: {g.7 can be used between the square brackets where they keep their meaning. two notations are provided. lose their special meaning inside a list. A notation of the form "{group. A notation of the form "\N{typereference}" matches any character of the referenced character set if "typereference" is a reference to a subtype of a "RestrictedCharacterStringType" which is defined in the current module. place it anywhere except in the first position or precede it with a backslash.1.1) and imported into the current module (see 37. To include a literal HYPHEN-MINUS (45) "-".e. except "]" and "\".*" at its beginning. A. or is one of the "RestrictedCharacterStringType"s defined in clause 37.r.m) #(.2. A.) #(n. The regular expression "[\d^.1. If the first character in the list is the caret "^".8.14. unless it is one of the newline characters defined in 11.-]" matches any single digit.3). at its end or at both sides. The symbol "\w" is a synonym for "[a-zA-Z0-9]".1.1). EXAMPLE The regular expression "\w+(\s\w+)*\. it matches any single (lower-case or upper-case) character or any single digit.cell}" references a (single) character according to the "Quadruple" production defined in 37.4. A.6 and A.5 The period ".3. To include a literal CIRCUMFLEX ACCENT (94) "^".e. "[\N{BasicLatin}\N{Cyrillic}\N{BasicGreek}]+". it matches any single digit. The words are separated by one white-space character as defined in 11. place it first or last in the list. A range of characters may be specified by giving the first and last characters. The regular expression "\N{BasicLatin}" matches any (single) character of the BASIC LATIN character set.p. EXAMPLES The regular expression "\N{greekCapitalLetterSigma}" matches GREEK CAPITAL LETTER SIGMA. The symbol "\t" matches the HORIZONTAL TABULATION (9) character." matches a sentence made of at least one (alphanumeric) word.6.8).m) If a regular expression contains a newline.plane. i. place it first.." matches any single character. To include a literal CLOSING SQUARE BRACKET (93) "]". or precede it with a backslash.2.2. are regular expressions that match a string made of any (non null) number of characters from the three character sets specified. A. There is no white-space character before the ending period. matches any single digit. The regular expression "[^0]" matches any single character except 0.row.2. or equivalently "[0-9]". 78 ITU-T Rec. then the characters "-" and "]" also match themselves when they immediately follow that caret. then it matches any character which is not in the list. separated by a hyphen (according to the order relation defined in 39. i. The metacharacter sequences defined in A. a caret.6. X. If the first character of the list is the caret "^". Hence a string shall match a regular expression in its entirety except if the latter includes ". "valuereference" or "typereference" can be one of the references defined in the module ASN1-CHARACTER-MODULE (see 38.2.

The regular expression """" matches the string which contains a single QUOTATION MARK.". X. A whole subexpression may be enclosed in parentheses to override these precedence rules. this character shall be represented by a pair of QUOTATION MARK characters. ITU-T Rec. A. If the regular expression includes a QUOTATION MARK (34).1.90" is matched by the regular expression "$\d#(1. "+". EXAMPLES A phone number like "555-1212" is matched by the regular expression "\d#3-\d#4". One such instance is the need to write text to document the regular expression within the ASN." matches the (single) string ".11 Repetition (see A. but not any string of any single character. each (non-quoted) opening parenthesis is successively assigned a distinct (strictly positive) integer from the left to the right of the regular expression. A. but not more than m times. the preceding item will be matched one or more times. but not strings like "My name is freddy" or "I am afred I don’t know how to spell ‘afraid’!". \3 the day -.6.12 When a regular expression contains subexpressions in parentheses. A. If it is of the form "#(. If the operator is "?". the parentheses can be omitted if n consists of one digit.2.\d#(1. EXAMPLES The regular expression "\. A price in dollars like "$12345.\1 is a date in which \2 is the month.2.)(\. If the operator is "+". EXAMPLE "((\d#2)(\d#2)(\d#4))" -. If the operator is of the form "#(n)".10 A regular expression may be followed by a repetition operator.680 (07/2002) 79 .2.9 Two or more regular expressions may be joined by the infix operator "|". the item is matched at least n times. which in turn takes precedence over alternation (see A. or equivalently "\d#(3)-\d#(4)".m)". If the operator is "*".2))?".3). NOTE – It is illegal to use the metacharacters "*". EXAMPLE The regular expression ".ISO/IEC 8824-1:2003 (E) A. the item is matched n or more times. it is delimited). If it is of the form "#(n.7 The symbol "\r" matches the CARRIAGE RETURN (13) character. NOTE – The fourth example shows that the backslash is allowed to precede characters that are not metacharacters.1 module. The symbol "\s" matches any one of the white-space characters defined in 11. NOTE – There is a requirement for formal reference to subexpressions of a regular expression for many purposes. the item is optional and is matched at most m times. It is also illegal to use the metacharacters "#" or "|" as the last character of a regular expression. but this use is deprecated (because other metacharacters could be allowed in future versions of this Recommendation | International Standard).and \4 the year. A. The regular expression "\a" matches the character "a". if it is of the form "#(n. the preceding item is matched exactly n times.6. The regular expression "\)" matches the string ")".8 A character that normally functions as a metacharacter can be interpreted literally by prefixing it with a "\".2. "?" or "#" as the first character of a regular expression. The symbol "\n" matches any one of the newline characters defined in 11.)". The resulting regular expression matches any string matching either subexpression. the preceding item will be matched zero or more times. The symbol "\b" matches the empty string at the beginning or at the end of a word. in this particular case. Finally.2. the preceding item is optional and matched at most once. A. A social security number like "123-45-5678" is matched by the regular expression "\d#3-?\d#2-?\d#4". Note that parentheses are requested after the "#" symbol when it is followed by a range.m)". Each subexpression can then be referenced inside a comment with a notation like "\1". This is a notation which can be used to provide such references.9).10) takes precedence over concatenation (see A.2.1. The empty subexpression "()" is not permitted.*\bfred\b. This notation is not used elsewhere in this Recommendation | International Standard.*" matches any string which includes the word "fred" (this word is not only a series of four characters.2. "\2" which uses the associated integer.2.1. Hence it matches strings like "fred" or "I am fred the first".

or D.1..680 (07/2002) . and f can be used in value notation governed by A. would the resulting statements be illegal? Similarly. D.. respectively. green(3). DEFAULT f} x INTEGER {red(0).. or E.3 A more sophisticated question would be to consider in each case replacement of the type reference by the explicit text to the right of its assignment.1 and what is not.2 It is clear that the value references a. e. or e. green(3).ISO/IEC 8824-1:2003 (E) Annex B Rules for type and value Compatibility (This annex forms an integral part of this Recommendation | International Standard) This annex is expected to be mainly of use to tool builders to ensure that they interpret the language identically. purple(4)} ::= green W ::= SEQUENCE { w1 INTEGER {red(0)..1 The need for the value mapping concept (tutorial introduction) Consider the following ASN.. For example: W ::= SEQUENCE {w1 A DEFAULT a} and: x A ::= a and: Y ::= A(1. or f.6. d.1. b.a) are all valid given the definitions in B.. or F. as they are at the least obscure and at worst confusing. however. It is present in order to clearly specify what is legal ASN. are the resulting statements legal? B..1 definitions: A ::= INTEGER B ::= [1] INTEGER C ::= [2] INTEGER (0. blue(2). and F. if the value reference a above were replaced in each of these cases by b. white(1). and to be able to specify the precise value that any value reference name identifies.1? B.1.1.4 Some of the above examples are cases which.1 B. or C. blue(2).. blue(2). or c. B. If.. blue(2). white(1). purple(4)} a A ::= 3 b B ::= 4 c C ::= 5 d D ::= 6 e E ::= 7 f F ::= green B.1.f) Y ::= INTEGER {red(0). users would be ill-advised to write similar text. B. X.) D ::= [2] INTEGER (0. green(3). even if legal (as most of them are – see later text).1 notations for any purpose other than those stated above.. white(1). C.20) F ::= INTEGER {red(0). there are frequent uses of a value reference to a value of some type (not necessarily just an INTEGER type) as the default value for that type 80 ITU-T Rec. white(1). and the precise set of values that any type or value set reference name identifies. blue(2). Consider for example: f INTEGER {red(0). or d.7) E ::= INTEGER (7. white(1).. green(3).1. green(3). However.. E. Would the above be legal ASN. A above were replaced by B.6. It is not intended to provide a definition of valid transformations of ASN. c. purple(4)} purple(4)} ::= f purple(4)}(1.

ISO/IEC 8824-1:2003 (E) with tagging or subtyping applied in the governor. This is illustrated for F and C in Figure B. M appings red(0) blue(2) white(1) .) E ::= INTEGER (7.6 Now when we have a value reference such as: c C ::= 5 to a value in C which is required in some context to identify a value in F. provided a value mapping exists between that value in C and a (single) value in F..1 B.6. The value mapping concept is introduced in order to provide a clear and precise means of determining which constructs such as the above are legal. X. green(3). B. because values in F.5 Again. we can clearly identify a 1-1 correspondence between the values in them and a subset of the values in the universal type INTEGER. blue(2). C. green(3) purple(4) C Derived mappings M appings [2]1 [2]0 [2]2 [2]3 [2]4 [2]5 [2]6 T0732160-99 F Figure B. C.680 (07/2002) 81 .20) F ::= INTEGER {red(0).. purple(4)} In each case a new type is being created.2. For F we can clearly identify a 1-1 correspondence between the values in it and the values in the universal type INTEGER. then....1.. we can (and do) define c to be a legal reference to the value in F. and E all have (1-1) mappings to values of INTEGER. ..1... and E themselves. where the value reference c is used to identify a value in F.. Moreover. consider: C ::= [2] INTEGER (0. and can be used in place of a direct reference f1 where we would otherwise have to define: f1 F ::= 5 ITU-T Rec. We call this relationship a value mapping between values in the two types. In the case of C and E.. .. Integer ....1.. we can use these mappings to provide mappings between the values of F. white(1). This is illustrated in Figure B..

the set of value mappings from values in X1 to values in X2 is a one-to-one relation.. The whole set of value mappings is a mathematical relation. it is symmetric (if a value mapping is defined to exist from a value x1 to a value x2. then: a) 82 there is no value mapping from x1 to another value in X2 different from x2. with other values in both types that are unmapped.1 value is related to itself).2. that is. It allows dummy and actual parameters to be typed using two textually separate "Type" constructs without violating the rules for compatibility of dummy and actual parameters. normal English text is used to specify legality in the above and similar cases. if there is a value mapping from x1 to x2. This relation possesses the following properties: it is reflexive (each ASN.2. EXAMPLE: Consider: X ::= INTEGER Y ::= INTEGER X and Y are type reference names (pointers) to two distinct types. recommended that advantage be taken of this freedom only for simple cases such as SEQUENCE OF INTEGER. This annex specifies when value mappings exist between such types.1. and ITU-T Rec.6 gives the precise requirements for legality and should be referenced whenever there is doubt about a complex construction. and not for more complex "Type" constructs.1 values. however.. there may be a subset of values in both types that have mappings.3 Furthermore. enabling a reference to a value in one type to be used where a reference to a value in some other type is needed.7 It should be noted that in some cases there will be values in one type (7 to 20 in A of B. (In this example.1 "Type" construct defining a distinct new type (see Figures B. then there automatically exists a value mapping from x2 to x1). that contain values. id OBJECT IDENTIFIER}.1 for example) that have value mappings to values in another type (7 to 20 in E of B. but other values (21 upwards of A) that have no such mapping. B. green(3) purple(4) F c C [2]1 [2]0 [2]2 [2]3 [2]4 [2]5 [2]6 T0732170-99 Figure B.ISO/IEC 8824-1:2003 (E) f red(0) white(1) . and x2 in X2. 5 f1 blue(2) . In the general case. B.1 standards.1. seen as sets of values.2).) It is..2 In the set of all possible ASN.680 (07/2002) . and a value mapping from x2 to x3. NOTE – The fact that value mappings are defined to exist between two occurrences of the "Type" construct permits the use of value references established using one "Type" construct to identify values in another "Type" construct which is sufficiently similar. Subclause B. or CHOICE {int INTEGER.2 Value mappings B.) B. A reference to such values in A would not provide a valid reference to a value in E. the whole of E has a value mapping to a subset of A.1 The underlying model is of types.2 B.2.8 In the body of the ASN. so any value reference to a value of X can be used when governed by Y (for example.. given any two types X1 and X2. X. then there automatically exists a value mapping from x1 to x3).1. and it is transitive (if there is a value mapping from a value x1 to x2. following DEFAULT).1 for example). It also allows fields of information object classes to be specified using one "Type" construct and the corresponding value in an information object to be specified using a distinct "Type" construct which is sufficiently similar..1 and B. but value mappings exist between these types.. with every occurrence of the ASN. as non-overlapping containers. (These examples are not intended to be exhaustive. B.1. a value mapping relates a pair of values. for all values x1 in X1.

"ExtensionAdditions". then the "RootEnumeration" is reordered so that the "identifiers" are in alphabetical order ("a" first. "z" last).3.3. a value reference to either one can automatically be used to reference the other if so required by some governing type. NOTE – The fact that value mappings are defined to exist between values in some "Type" constructs is solely for the purpose of providing flexibility in the use of the ASN.1 notation. the keyword IMPLICIT is added to all instances of "Tag" (see clause 30) unless either: • • • • it is already present. For each bitstring type: the "NamedBitList" (see 21. For each enumerated type: numbers are added.1). If "TagDefault" is IMPLICIT TAGS. the decision on whether to apply automatic tagging is taken according to 24.2. "z" last).2 Each occurrence of "Type" in an ASN.3 Identical type definitions B.12).2.. For each integer type: the "NamedNumberList" (see 18. if any. but it is recommended that ASN.3. If "ExtensionDefault" is EXTENSIBILITY "ComponentTypeLists" if it is not present.1 constructs. "z" last). and where the existence of these value mappings is never used in determining the legality of the total specification. The following transformations are not recursive and hence need only to be applied once. Note that value mappings will frequently exist in any large specification between two types that are identical ASN. if present. but which carry totally different application semantics.6 in that order. an ellipsis (".3. if present.3): each "RelativeOIDComponents" is transformed into its corresponding "NumberForm" in accordance with the semantics of clause 32. if any. h) IMPLIED.3 and 26. "OptionalExtensionMarker". as specified in 19. its definition is replaced by a "TypeAssignment" using the same "Type" and a subtype constraint which is the contents of the "ValueSet" as specified in 15. or the reserved word EXPLICIT is present. NOTE – Subclauses 24. is reordered so that the "identifiers" are in alphabetical order ("a" first. this subclause specifies a series of transformations which are applied to each of the instances of "Type" to produce a normal form for those instances of "Type". X.ISO/IEC 8824-1:2003 (E) b) there is no value mapping from any value in X1 (other than x1) to x2.6.2 (the automatic tagging will be performed later on).1 to B. and only if. For sequence types (see clause 24) and set types (see clause 26): any extension of the form "ExtensionAndException". B. their normal forms are identical ordered lists of the same lexical items (see clause 11).1).") is added after the For choice type (see clause 28): "RootAlternativeTypeList" is reordered so that the identifiers of the "NameType"s are in alphabetical order ("a" first. For each object identifier value: each "ObjIdComponents" is transformed into its corresponding "NumberForm" in accordance with the semantics of clause 31 (see the example in 31.1 constructs which would be illegal without value mappings are used only if the corresponding types do indeed carry the same application semantics..3.2 All the comments (see 11. The normal form is obtained by applying the transformations defined in B. B.1 specification is an ordered list of the lexical items defined in clause 11. in any order: a) For a type defined by a "ValueSetTypeAssignment".2. B.6) are removed. In order to give precision to the meaning of "sufficiently similar". or the type being tagged is a CHOICE type or.2. "z" last).680 (07/2002) 83 . is ITU-T Rec.1) that is an "identifier" (without a number). For each relative object identifier value (see 32. is removed.4 Where a value mapping exists between a value x1 and a value x2.2. is cut and pasted to the end of the "ComponentTypeLists". is reordered so that the "identifier"s are in alphabetical order ("a" first. The two instances of "Type" are defined to be identical type definitions if. "OptionalExtensionMarker". The existence of such mappings carries no implications whatsoever that the two types carry the same application semantics. to any "EnumerationItem" (see 19.3.3.1 B. it is an open type.2 specify that the presence of a "Tag" in a "ComponentType" which was inserted as a result of the replacement of "Components of Type" does not in itself prevent the automatic tagging transformation.1 The concept of identical type definitions is used to enable value mappings to be defined between two instances of "Type" which are either identical or sufficiently similar that one would normally expect their use to be interchangeable. b) c) d) e) f) g) If "TagDefault" is AUTOMATIC TAGS. B.

each UTF8String. if any. 26 and 28. the automatic tagging is applied according to clauses 24. If the replacing type is a sequence-of type or a set-of type. a value in its governing type.3. or it is an open type.5 The following transformations shall be applied to value definitions: a) b) c) d) e) f) g) If an integer value is defined with an identifier.2.. All type references are replaced by their definitions according to the following rules: • • • If the replacing type is a reference to the type being transformed. If "TagDefault" is AUTOMATIC TAGS.2 g) and h)). BMPString and UniversalString value is replaced by the equivalent value of type UniversalString written using the "Quadruple" notation (see clause 37. 11.2). set and choice types: if it has earlier been decided to tag automatically (see B. B.690 | ISO/IEC 8825-1.2. If the replaced type is a parameterized type or a parameterized value set (see ITU-T Rec.2.3.2).5 (the automatic tagging will be performed later on). IA5String. Each real value defined with base 2 is normalized so that the mantissa is odd. the "DefinedValue"s are replaced by their definition. After applying c).4 For set type: the "RootComponentTypeList" is reordered so that the "ComponentType"s are in alphabetical order ("a" first.ISO/IEC 8824-1:2003 (E) removed. every "DummyReference" is replaced by the corresponding "ActualParameter".683 | ISO/IEC 8824-4. X. and each real value defined with base 10 is normalized so that the last digit of the mantissa is not 0. the constraints following the replaced type. the keyword IMPLICIT is added to all instances of "Tags" (see clause 30) unless either: • • • • it is already present.8). it is replaced by the corresponding "bstring" with all trailing zero bits removed.2. 8. the decision on whether to apply automatic tagging is taken according to 28. For selection type: the construction is replaced by the selected alternative according to clause 29. If a bitstring value is defined using identifiers.. if the replaced value is a parameterized value (see ITU-T Rec.3): if the value definition begins with a "DefinedValue". NumericString. VisibleString (ISO646String). PrintableString. the "DefinedValue" is replaced by its definition.3. are moved in front of the keyword OF. For each relative object identifier value (see 32. For sequence types and set types: all instances of transformed according to clauses 24 and 26. If "ExtensionDefault" is EXTENSIBILITY IMPLIED. Each GeneralizedTime and UTCTime value is replaced by a string which conforms to the rules used when encoding in DER and CER (see ITU-T Rec. 8. X. the procedures of this annex shall be applied to ensure that the value reference identifies. or the reserved word EXPLICIT is present. 84 ITU-T Rec. through value mappings or directly.3. If "TagDefault" is IMPLICIT TAGS.8).3 The following transformations shall be applied recursively in the specified order.683 | ISO/IEC 8824-4. until a fix-point is reached: a) b) c) d) e) f) For each object identifier value (see 31. All white-space in "bstring" and "hstring" is removed. "z" last). B. or the type being tagged is a CHOICE type. "COMPONENTS OF Type" (see clause 24) are For sequence. B. that identifier is replaced by the associated number. X.680 (07/2002) . NOTE – Before replacing any value reference. g) All value references are replaced by their definitions. All white-space immediately before and after each newline (including the newline) in a "cstring" is removed.7 and 11. the type reference is replaced by a special item that matches no other item than itself.") is added after the "AlternativeTypeLists" if it is not present. an ellipsis (".3): if the value definition contains "DefinedValue"s. every "DummyReference" is replaced by the corresponding "ActualParameter". X.

5 between some of the character string types. X4.2 For a type.5. X2. Value mappings are defined to exist between all types in group A.4. B. The presence or absence of an extension marker has no effect on this rule.5 A value mapping is defined to exist between all the values of any type defined as an integer type with named values and any integer type defined without named values. or both. B.1).1 If two occurrences of "Type" are identical type definitions under the rules of B. etc. Any occurrence of the "RealValue" associated with "SequenceValue" shall be transformed to the associated "SequenceValue" of the same "base". value mappings never exist between these different types.1 There are two groups of restricted character string types.3). B. created by selecting values from any governing type.ISO/IEC 8824-1:2003 (E) B. nor between any type in group A and any type in group B. They can only be used in a scope governed by the type in which they are defined. created from any type.3 For a type.3. or by a typereference name to that type. specification for the normalization of all value notation and of set arithmetic notation has not been included at this time. Similarly. The concept of identical type definitions and of value mappings was introduced to ensure that simple ASN. when transformed to their normal form. by the element set construct or by subtyping.3. the resulting type definitions (the SEQUENCE or CHOICE types) will not be identical type definitions. 7. and there will be no value mappings between them. X. X. B. B.4 below) will not exist between them. or both. or with different names for named values. an "objectreference" (see ITU-T Rec. NOTE – The existence of the value mapping does not affect any scope rule requirements on the use of the names of named values. are identical lists of lexical items (see clause 11). NOTE – This exception was inserted to avoid the need to provide transformation rules to normal form for elements of syntax concerned with information object class.4.681 | ISO/IEC 8824-2. or with different names for named bits.4.5. X.5 Additional value mappings defined for the character string types B. information object.1 constructs could be used either by using reference names or by copying text. such that the last digit of the mantissa is not zero. then the two types are not defined to be identical type definitions. For the types in group B.4. if such types are embedded in otherwise identical but distinct type definitions (such as SEQUENCE or CHOICE type definitions).3.2) and group B (see B. value mappings are defined to exist between all the members of X1 and the corresponding members of X2.4.680 (07/2002) 85 . this could be provided in a future version of this Recommendation | International Standard.6 Any occurrence of "realnumber" shall be transformed to a "base" 10 associated "SequenceValue".4 Additional value mappings are specified in B.5.2. 7. NOTE – Whilst value mappings are defined to exist between the values of X1 and X2 in B.4. Should there prove to be a requirement for such specification. X.3) appears within the normalized form of the "Type". then value mappings exist between every value of one type and the corresponding value of the other type.681 | ISO/IEC 8824-2. by tagging (see clause 30). and information object set notation. and value references to values of these types can be used when governed by one of the other types. B.4.3 If two instances of "Type". B.2 above. NOTE – The existence of the value mapping does not affect any scope rule requirements on the use of the names of named bits. and between the values of X3 and X4 in B.5.3. X3. or with different named bits.6 A value mapping is defined to exist between all the values of any type defined as a bit string type with named bits and any bit string type defined without named bits. or with different named values. B. B. X1. or by a typereference name to that type. value mappings are defined to exist between the members of the new type and those members of the governing type that were selected by the element set or subtyping construct. 7.4 Specification of value mappings B.681 | ISO/IEC 8824-2. It was felt unnecessary to provide this functionality for more complex instances of "Type" that included information object classes. They can only be used in a scope governed by the type in which they are defined.2) or an "objectsetreference" (see ITU-T Rec. and value mappings (see B. then the two instances of "Type" are defined to be identical type definitions with the following exception: if an "objectclassreference" (see ITU-T Rec. group A (see B.2 Group A consists of: UTF8String NumericString PrintableString IA5String VisibleString (ISO646String) UniversalString BMPString ITU-T Rec.4.

5.6. V.ISO/IEC 8824-1:2003 (E) B.5. identifies the value. and Z1 is the set of values 29 and 30. The mapping for these types is defined using this mapping of glyphs. and in the last assignment the x-notation x is referencing the x-val 29 in X and.. that has a governing type.35) Z1 ::= V (W | 24) W contributes values 25-30 to the set arithmetic resulting in Z1 having the values 24-30.2 Any "Type" occurrence.. For example.7 UniversalString character that has the identical (32-bit) value in the BER encoding of UniversalString as the (8bit) value of the BER encoding of IA5String and VisibleString. consider the occurrence of x in the last line of the following: X ::= [0] INTEGER (0. IA5String and VisibleString are mapped into UniversalString by mapping each character into the B.680 (07/2002) . On the other hand. identifies the y-val 29 in Y. The x-notation 30 is referencing the y-val 30 in Y. BMPString is formally a subset of UniversalString. X. and each abstract value in UTF8String is defined to map to the corresponding abstract value in UniversalString.16).1 Any "Value" occurrence.1 constructs.5.6 Specific type and value compatibility requirements This subclause uses the value mapping concept to provide precise text for the legality of certain ASN.35) ::= Y (x | 30) These ASN.6 The glyphs (printed character shapes) for characters used to form the types NumericString and PrintableString have recognizable and unambiguous mappings to a subset of the glyphs assigned to the first 128 characters of ISO/IEC 10646-1.4 The value mappings in group A are specified by mapping the character string values of each type to UniversalString.1 constructs are legal. through value mapping.30) x X ::= 29 Y Z1 ::= [1] INTEGER (25. y-val. B. x-notation. t-notation. B. the string is replaced by a UniversalString of the same length with each character mapped as specified below.8 mappings. 86 ITU-T Rec. To map values from one of the group A types to UniversalString. consider the occurrence of W in the last line of the following: V W Y ::= [0] INTEGER (0. the assignment: Z2 ::= V (Y | 24) is illegal because there are no values in Y which map to a value in V.. B.5.5.. the assignment: Z2 ::= Y (x | 20) is illegal because there is no y-val to which the x-notation 20 can refer. and corresponding abstract values have value B. in the governing type Y that has a value mapping to the value x-val specified by x-notation.30) ::= [1] INTEGER (25. with a governing type.5. This set is required to contain at least one value. identifies the complete set of values in the root of the governing type V that have value mappings to any of the values in the root of the "Type" t-notation.3 Group B consists of: TeletexString (T61String) VideotexString GraphicString GeneralString B..6. B. the set of abstract values in UTF8String is the same set of abstract values that occur in UniversalString but with a different tag (see 37. It is a requirement that such a value exists. B. For example.35) ::= [2] INTEGER (31. Y. On the other hand. then using the transitivity property of value mappings.5 Formally.

version3(2)} ::= b1 is legal. that value of A can legally be applied in place of the dummy parameter. nor are either of them identical type definitions to either of B or B1.5 x z Example 4 INTEGER { y (2) } ::= 3 INTEGER ::= x is legal.3 The type of any value supplied as an actual parameter is required to have a value mapping from that value to one of the values in the type governing the dummy parameter.6. B. -. B. Similar examples can be written using CHOICE and ENUMERATED (using the "identifier" form of "EnumerationItem").3 and B.64)} are not identical type definitions. of a dummy parameter that is a value or a value set parameter.7. X2. Differences of white-space and comment are not visible. it is an illegal specification unless for all values of A.7 B. B. X1. and X3 are all identical type definitions..4.1 Examples This subclause provides examples to illustrate B. X. age INTEGER (1.6 Example 5 b1 BIT STRING ::= '101'B b2 BIT STRING {version1(0).ISO/IEC 8824-1:2003 (E) B. age INTEGER} X2 ::= [8] SEQUENCE {name VisibleString.7. B. version2(1). and assigns the value 3 to z through the value mapping defined in B.4 If a "Type" is supplied as an actual parameter for a dummy parameter which is a value set dummy parameter. A. Note. and there would be no value mappings between them. then all values of that "Type" are required to have value mappings to values in the governor of the value set dummy parameter. that if any of the identifiers for the elements of the sequence were changed.6. and value mappings will not exist between them.7.4 Example 3 C ::= SET {name [0]VisibleString. The actual parameter selects the total set of values in the governor which have mappings to the "Type". B. and it is a value of that governing type which is identified.3 Example 2 B ::= SET {name VisibleString. version3} to b2. age INTEGER} X1 ::= SEQUENCE {name VisibleString. B.5.7. B.2 Example 1 X ::= SEQUENCE {name VisibleString. and there are no value mappings between any of the values of C and C1. name VisibleString} are identical type definitions provided neither is in a module with AUTOMATIC TAGS in the module header. the types would cease to be identical definitions. nor between either of them and either of B or B1.5 In specifying the type. nor does the use of the AgeType type reference in X3 affect the type definition. B.7.680 (07/2002) 87 . age AgeType} AgeType ::= INTEGER X. and for every instance of use of A on the right-hand side of the assignment. ITU-T Rec.4.6. age INTEGER} C1 ::= SET {name VisibleString. and assigns the value {version1. otherwise they are not identical type definitions.comment -age INTEGER} X3 ::= SEQUENCE {name VisibleString.7. however. age INTEGER} B1 ::= SET {age INTEGER.

1. where X is any of A. c. and y is any of a. or any of the text to the right of the type assignments to these names. 88 ITU-T Rec. because in these cases there are no value mappings available from the defaulting value reference into the type being defaulted. e.7. with the following exceptions: E DEFAULT y is illegal for all of a. C. c. or f. and C DEFAULT e is illegal. SEQUENCE elements of the form: X DEFAULT y are legal. d. or F. b.680 (07/2002) . E.ISO/IEC 8824-1:2003 (E) B. B.7 Example 6 With the definitions of B. d.1. f. b. D. X.

1) -asn1CharacterModule OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0) } -.1 module which contains the definition of a value reference name for each object identifier value defined in the ASN.1 type (see 37.1 and encoding rules standards This clause specifies an ASN.1 Object Identifier Module" C.1 type" Subclause 38.2 Object identifiers in the ASN.NumericString ASN. and provides an ASN.ASN.680 (07/2002) 89 .5) -printableString OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) printableString(1) } -. ASN1-Object-Identifier-Module { joint-iso-itu-t asn1(1) specification(0) modules(0) object-identifiers(1) } DEFINITIONS ::= BEGIN -.1 Character Module" Subclause C. X.1 Character Module (see 38.3) -numericString OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) numericString(0) } -.1 Object Identifier Module (this module) -asn1ObjectIdentifierModule OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) modules(0) object-identifiers(1) } ITU-T Rec. X.ASN.PrintableString ASN.1 Object identifiers assigned in this Recommendation | International Standard The following values are assigned in this Recommendation | International Standard: Subclause 37.5 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) printableString(1) } Object Descriptor Value: "PrintableString ASN.1 type (see 37.1 module for use in referencing those object identifier values.3 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) numericString(0) } Object Descriptor Value: "NumericString ASN.2 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) modules(0) object-identifiers(1) } Object Descriptor Value: "ASN. X.1 series of Recommendations | International Standards. NOTE – These values are available for use in the value notation of the OBJECT IDENTIFIER type and types derived from it. All of the value references defined in the module specified in this clause are exported and have to be imported by any module that wishes to use them.ISO/IEC 8824-1:2003 (E) Annex C Assigned object identifier values (This annex forms an integral part of this Recommendation | International Standard) This annex records object identifier and object descriptor values assigned in the ASN.1 type" Subclause37.1 standards (ITU-T Rec.1 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0) } Object Descriptor Value: "ASN.693 | ISO/IEC 8825-4).680 | ISO/IEC 8824-1 to ITU-T Rec. C.

ISO/IEC 8824-1:2003 (E)
-- BER encoding of a single ASN.1 type -ber OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) basic-encoding(1) } -- CER encoding of a single ASN.1 type -cer OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) ber-derived(2) canonical-encoding(0) } -- DER encoding of a single ASN.1 type -der OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1) } -- PER encoding of a single ASN.1 type (basic aligned) -perBasicAligned OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) packed-encoding(3) basic(0) aligned(0) } -- PER encoding of a single ASN.1 type (basic unaligned) -perBasicUnaligned OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) packed-encoding(3) basic(0) unaligned(1) } -- PER encoding of a single ASN.1 type (canonical aligned) -perCanonicalAligned OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) packed-encoding(3) canonical(1) aligned(0) } -- PER encoding of a single ASN.1 type (canonical unaligned) -perCanonicalUnaligned OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) packed-encoding(3) canonical(1) unaligned(1) } -- XER encoding of a single ASN.1 type (basic) -xerBasic OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) xml-encoding(5) basic(0) } -- XER encoding of a single ASN.1 type (canonical) -xerCanonical OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) xml-encoding(5) canonical(1) } END -- ASN1-Object-Identifier-Module --

90

ITU-T Rec. X.680 (07/2002)

ISO/IEC 8824-1:2003 (E)

Annex D Assignment of object identifier component values
(This annex does not form an integral part of this Recommendation | International Standard) This annex describes the top-level arcs of the registration tree for object identifiers. No explanation is given on how new arcs are added, nor on the rules that registration authorities should follow. These are specified in ITU-T Rec. X.660 | ISO/IEC 9834-1.

D.1

Root assignment of object identifier component values

D.1.1 Three arcs are specified from the root node. The assignment of values and identifiers, and the authority for assignment of subsequent component values, are as follows: Value
0 1 2

Identifier
itu-t iso joint-iso-itu-t

Authority for subsequent assignments ITU-T (See D.2) ISO (See D.3) See D.4

D.1.2 31.3).

The identifiers itu-t, iso and joint-iso-itu-t, assigned above, may each be used as a "NameForm" (see

D.1.3 The identifiers ccitt and joint-iso-ccitt are synonyms for itu-t and joint-iso-itu-t, respectively, and thus may appear in object identifier values.

D.2
D.2.1

ITU-T assignment of object identifier component values
Five arcs are specified from the node identified by itu-t. The assignment of values and identifiers is: Value
0 1 2 3 4

Identifier
recommendation question administration network-operator identified-organization

Authority for subsequent assignments See D.2.2 See D.2.3 See D.2.4 See D.2.5 See D.2.6

These identifiers may be used as a "NameForm" (see 31.3). D.2.2 The arcs below recommendation have the value 1 to 26 with assigned identifiers of a to z. Arcs below these have the numbers of ITU-T (and CCITT) Recommendations in the series identified by the letter. Arcs below this are determined as necessary by the ITU-T (and CCITT) Recommendations. The identifiers a to z may be used as a "NameForm". D.2.3 The arcs below question have values corresponding to ITU-T Study Groups, qualified by the study period. The value is computed by the formula: study group number + (period * 32) where "period" has the value 0 for 1984-1988, 1 for 1988-1992, etc., and the multiplier is 32 decimal. The arcs below each study group have the values corresponding to the questions assigned to that study group. Arcs below this are determined as necessary by the group (e.g., working party or special rapporteur group) assigned to study the question. D.2.4 The arcs below administration have the values of X.121 DCCs. Arcs below this are determined as necessary by the Administration of the country identified by the X.121 DCC. D.2.5 The arcs below network-operator have the value of X.121 DNICs. Arcs below this are determined as necessary by the Administration or ROA identified by the DNIC. D.2.6 The arcs below identified-organization are assigned values by the ITU Telecommunication Standardization Bureau (TSB). Arcs below this are determined as necessary by the identified organizations.

ITU-T Rec. X.680 (07/2002)

91

ISO/IEC 8824-1:2003 (E)
NOTE – Organizations which may find this arc useful include: – recognized operating agencies not operating a public data network; – scientific and industrial organizations; – regional standards organizations; and – multi-national organizations.

D.3
D.3.1

ISO assignment of object identifier component values
Three arcs are specified from the node identified iso(1). The assignment of values and identifiers is: Value
0 2 3

Identifier
standard member-body identified-organization

Authority for subsequent assignments See D.3.2 See D.3.3 See D.3.4

These identifiers may be used as a "NameForm".
NOTE – The use of arc registration-authority(1) has been withdrawn.

D.3.2 The arcs below standard shall each have the value of the number of an International Standard. Where the International Standard is multi-part, there shall be an additional arc for the part number, unless this is specifically excluded in the text of the International Standard. Further arcs shall have values as defined in that International Standard. D.3.3 The arcs immediately below member-body shall have values of a three digit numeric country code, as specified in ISO 3166, that identifies the ISO National Body in that country. The "NameForm" of object identifier component is not permitted with these identifiers. D.3.4 The arcs immediately below identified-organization shall have values of an International Code Designator (ICD) allocated by the Registration Authority for ISO/IEC 6523 that identify an issuing organization specifically registered by that authority as allocating object identifier components. The arcs immediately below the ICD shall have values of an "organization code" allocated by the issuing organization in accordance with ISO/IEC 6523.

D.4

Joint assignment of object identifier component values

D.4.1 The arcs below joint-iso-itu-t have values which are assigned and agreed from time to time by a Registration Authority established by ISO/IEC and ITU-T to identify areas of joint ISO/IEC | ITU-T standardization activity, in accordance with ITU-T Rec. X.662 | ISO/IEC 9834-3.

92

ITU-T Rec. X.680 (07/2002)

ISO/IEC 8824-1:2003 (E)

Annex E Examples and hints
(This annex does not form an integral part of this Recommendation | International Standard) This annex contains examples of the use of ASN.1 in the description of (hypothetical) data structures. It also contains hints, or guidelines, for the use of the various features of ASN.1. Unless otherwise stated, an environment of AUTOMATIC TAGS is assumed.

E.1

Example of a personnel record

The use of ASN.1 is illustrated by means of a simple, hypothetical personnel record. E.1.1 Informal description of Personnel Record

The structure of the personnel record and its value for a particular individual are shown below. Name: Title: Employee Number: Date of Hire: Name of Spouse: Number of Children: Child Information Name: Date of Birth Child Information Name: Date of Birth E.1.2 Susan B Jones 17 July 1959 Ralph T Smith 11 November 1957 John P Smith Director 51 17 September 1971 Mary T Smith 2

ASN.1 description of the record structure

The structure of every personnel record is formally described below using the standard notation for data types.
PersonnelRecord ::= [APPLICATION 0] SET { name Name, title VisibleString, number EmployeeNumber, dateOfHire Date, nameOfSpouse Name, children SEQUENCE OF ChildInformation DEFAULT {} } ChildInformation ::= SET { name Name, dateOfBirth Date } Name ::= [APPLICATION 1] SEQUENCE { givenName VisibleString, initial VisibleString, familyName VisibleString }

ITU-T Rec. X.680 (07/2002)

93

ISO/IEC 8824-1:2003 (E)
EmployeeNumber ::= [APPLICATION 2] INTEGER Date ::= [APPLICATION 3] VisibleString -YYYY MMDD

This example illustrates an aspect of the parsing of the ASN.1 syntax. The syntactic construct DEFAULT can only be applied to a component of a SEQUENCE or a SET, it cannot be applied to an element of a SEQUENCE OF. Thus, the DEFAULT { } in PersonnelRecord applies to children, not to ChildInformation. E.1.3 ASN.1 description of a record value

The value of John Smith's personnel record is formally described below using the standard notation for data values.
{ name {givenName "John", initial "P", familyName "Smith"}, title "Director", number 51, dateOfHire "19710917", nameOfSpouse {givenName "Mary", initial "T", familyName "Smith"}, children { {name {givenName "Ralph", initial "T", familyName "Smith"} , dateOfBirth "19571111"}, {name {givenName "Susan", initial "B", familyName "Jones"} , dateOfBirth "19590717" } }

}

or in XML value notation:
person ::= <PersonnelRecord> <name> <givenName>John</givenName> <initial>P</initial> <familyName>Smith</familyName> </name> <title>Director</title> <number>51</number> <dateOfHire>19710917</dateOfHire> <nameOfSpouse> <givenName>Mary</givenName> <initial>T</initial> <familyName>Smith</familyName> </nameOfSpouse> <children> <ChildInformation> <name> <givenName>Ralph</givenName> <initial>T</initial> <familyName>Smith</familyName> </name> <dateOfBirth>19571111</dateOfBirth> </ChildInformation> <ChildInformation> <name> <givenName>Susan</givenName> <initial>B</initial> <familyName>Jones</familyName> </name> <dateOfBirth>19590717</dateOfBirth> </ChildInformation> </children> </PersonnelRecord>

E.2

Guidelines for use of the notation

The data types and formal notation defined by this Recommendation | International Standard are flexible, allowing a wide range of protocols to be designed using them. This flexibility, however, can sometimes lead to confusion, especially when the notation is approached for the first time. This annex attempts to minimize confusion by giving guidelines for, and examples of, the use of the notation. For each of the built-in data types, one or more usage guidelines are offered. The character string types (for example, VisibleString) and the types defined in clauses 42 to 44 are not dealt with here.

94

ITU-T Rec. X.680 (07/2002)

2.. ITU-T Rec.2.3.1 Boolean E. EXAMPLE DayOfTheMonth ::= INTEGER {first(1). for example. two-state) variable. EXAMPLE Employed ::= BOOLEAN E. one would write: DayOfTheMonth ::= INTEGER {first(1). the answer to a yes-or-no question.2.3 Enumerated E. and does not exclude the possibility of DayOfTheMonth having other values which may be less than 1.2. EXAMPLE CheckingAccountBalance ::= INTEGER -balance CheckingAccountBalance ::= 0 in cents.1. last(31)} (first | last) and to restrict the value of the DayOfTheMonth to all values between 1 and 31. EXAMPLE Married ::= BOOLEAN not MaritalStatus ::= BOOLEAN E. last) dayOfTheMonth DayOfTheMonth ::= 4 or using XML value notation: dayOfTheMonth ::= <DayOfTheMonth>4</DayOfTheMonth> E. unlimited in magnitude) of a cardinal or integer variable.2.2 When assigning a reference name to a boolean type. Assign values starting with zero if their only constraint is distinctness.2. greater than 31 or between 1 and 31.1 Use an integer type to model the values (for all practical purposes.2. one would write: DayOfTheMonth ::= INTEGER {first(1).2.2. choose one that describes the true state.ISO/IEC 8824-1:2003 (E) E.2. last(31)} today DayOfTheMonth ::= first unknown DayOfTheMonth ::= 0 or using XML value notation: today ::= <DayOfTheMonth><first/></DayOfTheMonth> unknown ::= <DayOfTheMonth>0</DayOfTheMonth> Note that the named numbers first and last were chosen because of their semantic significance to the reader. last(31)} (first . negative means overdrawn.1 Use a boolean type to model the values of a logical (that is. X. or using XML value notation: balance ::= <CheckingAccountBalance>0</CheckingAccountBalance> E.680 (07/2002) 95 . inclusive. To restrict the value of DayOfTheMonth to just first and last.1 Use an enumerated type to model the values of a variable with three or more states.2 Define the minimum and maximum allowed values of an integer type as named numbers.1.2 Integer E.

14159265358979323846264338327 </REAL> E. EXAMPLE AngleInRadians ::= REAL pi REAL ::= {mantissa 3141592653589793238462643383279. base 2. monday. DayOfTheWeek is restricted to assuming one of these values and no other. thursday(4).4.4. etc.. married.2. This can be achieved by the following: App-X-Real ::= REAL (WITH COMPONENTS { mantissa (−16777215. exponent (−125.Second version of MaritalStatus and later yet: MaritalStatus ::= ENUMERATED {single.16777215). Further. divorced} -. base (2).Third version of MaritalStatus E. married} -. X. saturday(6)} firstDay DayOfTheWeek ::= sunday or using XML value notation: firstDay ::= <DayOfTheWeek><sunday/></DayOfTheWeek> Note that while the enumerations sunday. friday(5). the equivalent integer values are not allowed. E.. */ girth App-X-Real ::= {mantissa 16. …. but that may have additional states in a future version of the protocol. wednesday(3)... etc. only the name sunday. …. married.2.2. widowed. monday(1).128) } ) /* Senders shall not transmit values outside these ranges and conforming receivers shall be capable of receiving and processing all values in these ranges. EXAMPLE MaritalStatus ::= ENUMERATED {single. exponent 1} or using XML value notation: girth ::= <App-X-Real> 32 </App-X-Real> 96 ITU-T Rec. tuesday(2).4 E. and in implementation decisions to use (for example) single or double length floating point for an application.1 Real Use a real type to model an approximate number. monday.14159265358979323846264338327 or using XML value notation: pi ::= <REAL> 3. can be assigned to a value. base 10.First version of MaritalStatus in anticipation of: MaritalStatus ::= ENUMERATED {single. exponent −30} or using the alternate value notation for REAL: pi REAL ::= 3.3.680 (07/2002) . were chosen because of their semantic significance to the reader.2 Use an extensible enumerated type to model the values of a variable that has just two states now.2. widowed} -.2 Application designers may wish to ensure full interworking with real values despite differences in floating point hardware.ISO/IEC 8824-1:2003 (E) EXAMPLE DayOfTheWeek ::= ENUMERATED {sunday(0).

680 (07/2002) 97 . DaysOfTheWeek ::= BIT STRING { sunday(0). wednesday} sunnyDaysLastWeek2 DaysOfTheWeek ::= '1101'B sunnyDaysLastWeek3 DaysOfTheWeek ::= '1101000'B sunnyDaysLastWeek4 DaysOfTheWeek ::= '11010000'B -. E.4.3 Use a bit string type to model the values of a bit map.2 Use a bit string type with a size constraint to model the values of a fixed sized bit field. friday(5). an ordered collection of logical variables indicating whether a particular condition holds for each of a correspondingly ordered collection of objects.1 Use a bit string type to model binary data whose format and length are unspecified.5.5. X.5 Bit string E.Illegal or using XML value notation: sunnyDaysLastWeek1 ::= <DaysOfTheWeek> <sunday/><monday/><wednesday/> </DaysOfTheWeek> ITU-T Rec. image G3FacsimilePage ::= '100110100100001110110'B trailer BIT STRING ::= '0123456789ABCDEF'H body1 G3FacsimilePage ::= '1101'B body2 G3FacsimilePage ::= '1101000'B or using XML value notation: image ::= <G3FacSimile>100110100100001110110</G3FacSimile> trailer ::= <BIT_STRING> 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 </BIT_STRING> body1 ::= <G3FacSimile>1101</G3FacSimile> body2 ::= <G3FacSimile>1101000</G3FacSimile> Note that body1 and body2 are distinct abstract values because trailing 0 bits are significant (due to there being no "NamedBitList" in the definition of G3FacsimilePage). thursday(4).a sequence of bits conforming to ITU-T Rec. saturday(6) } (SIZE (0.2.7)) sunnyDaysLastWeek1 DaysOfTheWeek ::= {sunday.. T. EXAMPLE BitField ::= BIT STRING (SIZE (12)) map1 BitField ::= '100110100100'B map2 BitField ::= '9A4'H map3 BitField ::= '1001101001'B -Illegal . or specified elsewhere. monday (1).2. and whose length in bits is not necessarily a multiple of eight. E.2.ISO/IEC 8824-1:2003 (E) E.5. wednesday(3). tuesday(2). monday. or using XML value notation: map1 ::= <BitField>100110100100</BitField> Note that map1 and map2 are the same abstract value. for the four trailing bits of map2 are not significant.2.violates size constraint. EXAMPLE G3FacsimilePage ::= BIT STRING -.

680 (07/2002) . EXAMPLE G4FacsimileImage ::= OCTET STRING -.Illegal -.6.ISO/IEC 8824-1:2003 (E) sunnyDaysLastWeek2 ::= <DaysOfTheWeek>1101</DaysOfTheWeek> sunnyDaysLastWeek3 ::= <DaysOfTheWeek>1101000</DaysOfTheWeek> Note that if the bit string value is less than 7 bits long.5 Use a bit string type with named bits to model the values of a collection of related logical variables.2 Use a restricted character string type in preference to an octet string type. EXAMPLE 98 ITU-T Rec. T. a fixed-size ordered collection of logical variables indicating whether a particular condition holds for each of a correspondingly ordered collection of objects.a sequence of octets conforming to ITU-T Rec. and whose length in bits is a multiple of eight. where an appropriate one is available. wednesday} sunnyDaysLastWeek2 DaysOfTheWeek ::= '1101'B -. then the missing bits indicate a cloudy day for those days. DaysOfTheWeek ::= BIT STRING { sunday(0).5. friday(5).2.Illegal -.violates size constraint. veteran(2). sunnyDaysLastWeek3 DaysOfTheWeek ::= '1101000'B sunnyDaysLastWeek4 DaysOfTheWeek ::= '11010000'B -.5 and CCITT Rec.2. monday (1). Note that the first and third values have the same abstract value. monday.2. X. saturday(6) } (SIZE (7)) sunnyDaysLastWeek1 DaysOfTheWeek ::= {sunday. hence the first three values above have the same abstract value. EXAMPLE PersonalStatus ::= BIT STRING {married(0). or specified elsewhere. employed(1). thursday(4). E. collegeGraduate(3)} billClinton PersonalStatus ::= {married.1 Use an octet string type to model binary data whose format and length are unspecified.2. E. tuesday(2).5.violates size constraint.6 Octet string E.6.6 image G4FacsimilePage ::= '3FE2EBAD471005'H or using XML value notation: image ::= <G4FacSimileImage>3FE2EBAD471005</G4FacSimileImage> E. T. E.4 Use a bit string type to model the values of a bit map.2. collegeGraduate} hillaryClinton PersonalStatus ::= '110100'B or using XML value notation: billClinton ::= <PersonalStatus> <married/> <employed/> <collegeGraduate/> </PersonalStatus> hillaryClinton ::= <PersonalStatus>110100</PersonalStatus> Note that billClinton and hillaryClinton have the same abstract values. wednesday(3). employed.

2. and UniversalString or UTF8String to model any string which consists of ISO/IEC 10646-1 characters not confined to the BMP. 0. E. 0. 0.680 (07/2002) 99 .2.1 Use Level1 or Level2 to denote that the implementation level places restrictions on the use of combining characters. infinity} or using XML value notation: property ::= <UTF8String>f &#x2192. EXAMPLE KatakanaAndBasicLatin ::= UniversalString (FROM (Katakana | BasicLatin)) E.2 A collection can be expanded to be a selected subset (i. &#x221E...</UTF8String> E. 30} property UTF8String ::= {"f ".ISO/IEC 8824-1:2003 (E) Surname ::= PrintableString president Surname ::= "Clinton" or using XML value notation: president ::= <Surname>Clinton</Surname> E.</BMPString> Representation of string "f → ∝": rightwardsArrow UTF8String ::= {0.100) ^ Level2) -. include all characters in the BASIC LATIN collection) by use of the "UnionMark" (see clause 46). BMPString and UTF8String Use the BMPString type or the UTF8String type to model any string of information which consists solely of characters from the ISO/IEC 10646-1 Basic Multilingual Plane (BMP). 146} infinity UTF8String ::= {0. Be sure to specify the repertoire of characters and their coding into octets. 34.2. EXAMPLE PackedBCDString ::= CHARACTER STRING (WITH COMPONENTS { identification COMPONENTS { fixed /* The abstract and transfer syntaxes shall be packedBCDString-AbstractSyntaxId and packedBCDString-TransferSyntaxId defined below.SaudiName uses a subset of combining characters.2.7 UniversalString.e. rightwardsArrow. " ". EXAMPLE RussianName ::= Cyrillic (Level1) -.7. */ PackedBCDString-AbstractSyntaxId OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) examples(123) packedBCD(2) charSet(0) } PRESENT }) (WITH ITU-T Rec. X. 33. Representation of letter Σ: greekCapitalLetterSigma BMPString ::= {0. 3.7. */ } ) /* object identifier value for a character abstract syntax (character set) whose alphabet is the digits 0 through 9. 163} or using XML value notation: greekCapitalLetterSigma ::= <BMPString>&#x03a3.8 CHARACTER STRING Use the unrestricted character string type to model any string of information which cannot be modelled using one of the restricted character string types.RussianName uses no combining characters. SaudiName ::= BasicArabic (SIZE (1.

using the optional identifier: 100 ITU-T Rec.examples(123). X. E. roomNumber outPatient : NULL } -- or using XML value notation: lastPatient ::= <PatientIdentifier> <name>Jane Doe</name> <roomNumber><outPatient/></roomNumber> </PatientIdentifier> E.asn1(1).10. EXAMPLE PatientIdentifier ::= SEQUENCE { name VisibleString. although they do guarantee that the abstract value is preserved in the encoding. and in the case of BER with a field carrying the tag.2.9 Null Use a null type to indicate the effective absence of a component of a sequence.0</OBJECT_IDENTIFIER> PackedBCDString-TransferSyntaxId ::= <OBJECT_IDENTIFIER>2. */ or using XML value notation: packedBCDString-AbstractSyntaxId ::= <OBJECT_IDENTIFIER> joint-iso-itu-t.ISO/IEC 8824-1:2003 (E) /* object identifier value for a character transfer syntax that packs two digits per octet.2. and whose order is significant.examples(123).1.asn1(1).2. roomNumber CHOICE { room INTEGER. each digit encoded as 0000 to 1001.1</OBJECT_IDENTIFIER> NOTE – Encoding rules do not necessarily encode values of the type CHARACTER STRING in a form that always includes the object identifier values. as "fixed" has been specified.if an out-patient } } lastPatient PatientIdentifier ::= { name "Jane Doe". EXAMPLE NamesOfMemberNations ::= SEQUENCE OF VisibleString -.680 (07/2002) .packedBCD(2).packedBCD(2). 11112 used for padding. */ PackedBCDString-TransferSyntaxId OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) examples(123) packedBCD(2) characterTransferSyntax(1) } /* The encoding of PackedBCDString will contain only the defined encoding of the characters. The object identifier values are not carried.10 Sequence and sequence-of E. outPatient NULL -.123.123. with any necessary length field.in alphabetical order firstTwo NamesOfMemberNations ::= {"Australia".1. "Austria"} or.charSet(0) </OBJECT_IDENTIFIER> packedBCDString-TransferSyntaxId ::= <OBJECT_IDENTIFIER> joint-iso-itu-t.characterTransferSyntax(1) </OBJECT_IDENTIFIER> or: packedBCDString-AbstractSyntaxId ::= <OBJECT_IDENTIFIER>2.2.2. whose number is large or unpredictable.1 Use a sequence-of type to model a collection of variables whose types are the same.

INTEGER. VisibleString. ITU-T Rec. whose number is known and modest. -. whose number currently is known and is modest. } -. but which is expected to be increased: EXAMPLE Record ::= SEQUENCE { userName password accountNumber .. in anticipation of: Record ::= SEQUENCE { userName password accountNumber .10. "John Doe". VisibleString} "Jane Doe". .2 Use a sequence type to model a collection of variables whose types are the same..2. EXAMPLE Credentials ::= SEQUENCE { userName password accountNumber VisibleString. INTEGER} E... VisibleString.4 Use an extensible sequence type to model a collection of variables whose order is significant.10.2. X. provided that the make-up of the collection is unlikely to change from one version of the protocol to the next. memberNation "Austria"} Using XML value notation. the above two values are as follows: firstTwo ::= <NamesOfMemberNations> <VisibleString>Australia</VisibleString> <VisibleString>Austria</VisibleString> </NamesOfMemberNations> firstTwo2 ::= <NamesOfMemberNations2> <memberNation>Australia</memberNation> <memberNation>Austria</memberNation> </NamesOfMemberNations2> E. "Joe Doe"} or using XML value notation: acmeCorp ::= <NamesOfOfficers> <president>Jane Doe</president> <vicePresident>John Doe</vicePresident> <secretary>Joe Doe</secretary> </NamesOfOfficers> E.ISO/IEC 8824-1:2003 (E) NamesOfMemberNations2 ::= SEQUENCE OF memberNation VisibleString -.First version of protocol containing "Record" VisibleString. INTEGER. whose number is known and modest...680 (07/2002) 101 .3 Use an inextensible sequence type to model a collection of variables whose types differ. VisibleString.2..Second version of protocol containing "Record" VisibleString. and whose order is significant. provided that the make-up of the collection is unlikely to change from one version of the protocol to the next.10.. EXAMPLE NamesOfOfficers ::= SEQUENCE { president vicePresident secretary acmeCorp NamesOfOfficers ::= { president vicePresident secretary VisibleString. VisibleString.in alphabetical order firstTwo2 NamesOfMemberNations2 ::= {memberNation "Australia". and whose order is significant.

the tags are not needed.. EXAMPLE 102 ITU-T Rec.defaults to that of the local organization -.defaults to that of the local country -. [2] VisibleString} "Nigeria".1 Use a set type to model a collection of variables whose number is known and modest and whose order is insignificant.2. Ltd...11 Set and set-of E. } Certificate. The following assumes AUTOMATIC TAGS was specified in the module definition.</organizationName> </UserName> E.3 Use an extensible set type to model a collection of variables whose make-up is likely to change from one version of the protocol to the next.Extension addition added in protocol version 2 lastLoggedIn GeneralizedTime OPTIONAL. "Jonas Maruba".680 (07/2002) . organizationName [1] VisibleString OPTIONAL -. accountNumber INTEGER.) EXAMPLE UserName ::= SET { personalName organizationName countryName user UserName ::= { countryName personalName organizationName [0] VisibleString. minutesLastLoggedIn INTEGER ]].11. identify each variable by context-specifically tagging it as shown below. [[4: -. } and later yet (version 3 of the protocol made no additions to Record): Record ::= SEQUENCE { -.) EXAMPLE UserName ::= SET { personalName [0] VisibleString. the tags are not needed.11.2. "Meteorology.11."} or using XML value notation: user ::= <UserName> <countryName>Nigeria</countryName> <personalName>Jonas Maruba</personalName> <organizationName>Meteorology.Extension addition added in protocol version 2 lastLoggedIn GeneralizedTime OPTIONAL... minutesLastLoggedIn INTEGER ]]... [[2: -. [1] VisibleString.2. identify each variable by context-specifically tagging it as shown below. password VisibleString.. Ltd.ISO/IEC 8824-1:2003 (E) [[2: -. (With automatic tagging. . . If automatic tagging is not in effect.Extension addition added in protocol version 3 certificate thumb ]]. countryName [2] VisibleString OPTIONAL -. (With automatic tagging.Third version of protocol containing "Record" userName VisibleString. If automatic tagging is not in effect. . X.2.2 Use a set type with OPTIONAL to model a collection of variables that is a (proper or improper) subset of another collection of variables whose number is known and reasonably small and whose order is insignificant.} E. ThumbPrint OPTIONAL E.

.Fifth version of protocol containing "UserName" personalName VisibleString. VisibleString OPTIONAL..ngo.First version of VisibleString OPTIONAL .Extension addition added in version 5 phoneNumber VisibleString OPTIONAL ]]. X.Extension addition added in protocol version 2 internetEmailAddress VisbleString. user UserName ::= { personalName "Jonas Maruba" } or using XML value notation: user ::= <UserName> <personalName>Jonas Maruba</personalName> </UserName> in anticipation of: UserName ::= SET { -. "jonas@meteor. "jonas@meteor.Second version of "UserName" personalName VisibleString.. } user UserName ::= { personalName internetEmailAddress "Jonas Maruba"... . [[2: -.. organizationName VisibleString OPTIONAL.....680 (07/2002) 103 . organizationName VisibleString OPTIONAL.ISO/IEC 8824-1:2003 (E) UserName ::= SET { personalName "UserName" organizationName countryName . faxNumber VisibleString OPTIONAL ]]. . } user UserName ::= { personalName internetEmailAddress "Jonas Maruba".com" } or using XML value notation: user ::= <UserName> <personalName>Jonas Maruba</personalName> <internetEmailAddress>jonas@meteor.com</internetEmailAddress> </UserName> and later yet (versions 3 and 4 of the protocol made no additions to UserName): UserName ::= SET { -.. faxNumber VisibleString OPTIONAL ]].com" } or using XML value notation: user ::= <UserName> <personalName>Jonas Maruba</personalName> <internetEmailAddress>jonas@meteor. . } VisibleString...com</internetEmailAddress> </UserName> ITU-T Rec. . -. [[5: -.ngo. countryName VisibleString OPTIONAL.. countryName VisibleString OPTIONAL.Extension addition added in version 2 internetEmailAddress VisbleString. [[2: -..ngo.ngo. .

however.3 Context-specific tagging is frequently applied in an algorithmic manner to all components of a SET.2. scattered.680 (07/2002) . X. keyword "REAL"} Using XML value notation. New users of the ASN.12 Tagged Prior to the introduction of the AUTOMATIC TAGS construct.12.4 Use a set-of type to model a collection of variables whose types are the same and whose order is insignificant. Applications produced by an enterprise will normally use application and context-specific tag classes. where an enterprise-specific specification seeks to extend an 104 ITU-T Rec. "BOOLEAN".1 notation are encouraged to use AUTOMATIC TAGS as this makes the notation more readable. The following subclauses describe the way in which tagging was typically applied.in cents VisibleString. that the AUTOMATIC TAGS facility does this easily for you. There may be occasional cases. INTEGER -.2. using the optional identifier: Keywords2 ::= SET OF keyword VisibleString -in arbitrary order someASN1Keywords2 Keywords2 ::= {keyword "INTEGER". An application class tag is also frequently used (once only) to tag the types in the outermost CHOICE of an application.in cents --} --} E. E. Note. VisibleString. ASN. INTEGER -. It should not be used elsewhere.1).4 Private class tagging should normally not be used in internationally standardized specifications (although this cannot be prohibited).2 A frequently encountered style for the use of tags is to assign an application class tag precisely once in the entire specification. or CHOICE. the above two values are as follows: someASN1Keywords ::= <Keywords> <VisibleString>INTEGER</VisibleString> <VisibleString>BOOLEAN</VisibleString> <VisibleString>REAL</VisibleString> </Keywords> someASN1Keywords2 ::= <Keywords2> <keyword>INTEGER</keyword> <keyword>BOOLEAN</keyword> <keyword>REAL</keyword> </Keywords2> E. although those modifying old notation may have to concern themselves with tags. providing identification of individual messages by the application class tag. With the introduction of AUTOMATIC TAGS. however. The notation [UNIVERSAL 30] (for example) is provided solely to enable precision in the definition of the "UsefulTypes" (see 41. "REAL"} or. use within the specification.12.2.12.1 Universal class tags are used only within this Recommendation | International Standard.1 specifications need make no use of the tag notation.ISO/IEC 8824-1:2003 (E) E. The following is an example use in the former case: EXAMPLE FileName ::= [APPLICATION 8] SEQUENCE { directoryName VisibleString. using it to identify a type that finds wide. keyword "BOOLEAN".2.2. EXAMPLE Keywords ::= SET OF VisibleString -in arbitrary order someASN1Keywords Keywords ::= {"INTEGER". EXAMPLE CustomerRecord ::= SET { name mailingAddress accountNumber balanceDue CustomerAttribute ::= CHOICE { name mailingAddress accountNumber balanceDue [0] [1] [2] [3] [0] [1] [2] [3] VisibleString. new ASN. INTEGER. VisibleString. SEQUENCE. E.12.11.2. directoryRelativeFileName VisibleString} E.1 specifications frequently contained tags. INTEGER.

6 Guidance on use of tags in new ASN.5 Textual use of IMPLICIT with every tag is generally found only in older specifications. for example. EXAMPLE FileIdentifier ::= CHOICE { relativeName VisibleString.system-assigned identifier for file --} file FileIdentifier ::= serialNumber : 106448503 or using XML value notation: fileIdentifier ::= <FileIdentifier> <serialNumber>106448503</serialNumber> </FileIdentifier> E. REAL.1 Use a CHOICE to model a variable that is selected from a collection of variables whose number are known and modest.(for example. In other applications. With BER and explicit tagging. BER produces a less compact representation when explicit tagging is used than when implicit tagging is used. Put AUTOMATIC TAGS in the module header. INTEGER -. This may.) in the encoded data.13. If you need to add new components to the SET. PER produces the same compact encoding in both cases.2. X. "MarchProgressReport") absoluteName VisibleString. VisibleString.2.in cents -- [0] [1] [2] [3] IMPLICIT IMPLICIT IMPLICIT IMPLICIT VisibleString. and in this case use of private class tags may give some benefits in partially protecting the enterprise-specific specification from changes to the internationally standardized specification. then forget about tags.2.680 (07/2002) 105 . EXAMPLE FileIdentifier ::= CHOICE { FileIdentifier relativeName VisibleString. These guidelines use implicit tagging in the examples whenever it is legal to do so. VisibleString. etc. the ability to carry out strong type-checking. add them to the end. INTEGER. -.1 specifications referencing this Recommendation | International Standard is quite simple: DON'T USE TAGS.name of file and containing directory -. explicit tagging can be used. result in a compact representation.13. In the latter case. "<Williams>MarchProgressReport") serialNumber INTEGER -.First version of ITU-T Rec.2 Use an extensible CHOICE to model a variable that is selected from a collection of variables whose make-up is likely to change from one version of the protocol to the next. depending on the encoding rules.ISO/IEC 8824-1:2003 (E) internationally standardized specification.2. BOOLEAN. EXAMPLE AcmeBadgeNumber ::= [PRIVATE 2] INTEGER badgeNumber AcmeBadgeNumber ::= 2345 or using XML value notation: badgeNumber ::= <AcmeBadgeNumber>2345</AcmeBadgeNumber> E. INTEGER. EXAMPLE CustomerRecord ::= SET { name mailingAddress accountNumber balanceDue } CustomerAttribute ::= CHOICE { name mailingAddress accountNumber balanceDue } [0] [1] [2] [3] IMPLICIT IMPLICIT IMPLICIT IMPLICIT VisibleString.2.12.12. there is more visibility of the underlying type (INTEGER. SEQUENCE or CHOICE in a later version.in cents -- E.name of file (for example. -.13 Choice E. compactness may be less important than. INTEGER -. -. which is highly desirable in some applications. E.

absoluteName VisibleString. } fileId1 fileId2 fileId3 FileIdentifier ::= relativeName : "MarchProgressReport.. VisibleString.doc</relativeName> </FileIdentifier> fileId2 ::= <FileIdentifier> <serialNumber>214</serialNumber> </FileIdentifier> and later yet: FileIdentifier ::= CHOICE { -.... .doc" .. serialNumber INTEGER.. .Third version of FileIdentifier relativeName VisibleString. X.. .Extension addition added in version 3 vendorSpecific VendorExt..doc</relativeName> </FileIdentifier> in anticipation of: FileIdentifier ::= CHOICE { -.Second version of FileIdentifier relativeName VisibleString. unidentified NULL ]].680 (07/2002) .Extension addition added in version 2 . -.. serialNumber INTEGER... } fileId1 fileId2 FileIdentifier ::= relativeName : "MarchProgressReport.Extension addition added in version 2 [[ -... -. } fileId1 FileIdentifier ::= relativeName : "MarchProgressReport.ISO/IEC 8824-1:2003 (E) absoluteName .doc</relativeName> </FileIdentifier> fileId2 ::= <FileIdentifier> <serialNumber>214</serialNumber> </FileIdentifier> fileId3 ::= <FileIdentifier> <unidentified/> 106 ITU-T Rec. or using XML value notation: fileId1 ::= <FileIdentifier> <relativeName>MarchProgressReport.doc" FileIdentifier ::= serialNumber : 214 or using XML value notation: fileId1 ::= <FileIdentifier> <relativeName>MarchProgressReport...doc" FileIdentifier ::= serialNumber : 214 FileIdentifier ::= unidentified : NULL or using XML value notation: fileId1 ::= <FileIdentifier> <relativeName>MarchProgressReport. absoluteName VisibleString.

First version of "Greeting" VisibleString.Extension addition added in version 2 E.. recording Voice } Voice ::= CHOICE { english swahili OCTET STRING. video Video ]].1 Use a selection type to model a variable whose type is that of some particular alternatives of a previously defined CHOICE.. } -..2.. X.Second version of "Greeting" -.13. EXAMPLE Greeting ::= CHOICE { postCard ...14 Selection type E.2 Consider the definition: FileAttribute ::= CHOICE { date-last-used file-name INTEGER.. .2. EXAMPLE Greeting ::= [APPLICATION 12] CHOICE { postCard VisibleString. VisibleString} then the following definition is possible: AttributeList ::= SEQUENCE { first-attribute date-last-used < FileAttribute.680 (07/2002) 107 . in anticipation of: Greeting ::= CHOICE { postCard VisibleString... [[2: audio Audio. second-attribute "PROGRAM" } or using XML value notation: listOfAttributes ::= <AttributeList> <first-attribute>27</first-attribute> <second-attribute>PROGRAM</second-attribute> </AttributeList> ITU-T Rec.. OCTET STRING } myGreeting Greeting ::= recording : english : '019838547E0'H or using XML value notation: myGreeting ::= <Greeting> <recording><english>019838547E0</english></recording> </Greeting> E.3 Use an extensible CHOICE of only one type where the possibility is envisaged of more than one type being permitted in the future. E.2.4 Multiple colons are required when a choice value is nested within another choice value.2. second-attribute file-name < FileAttribute } with a possible value notation of: listOfAttributes AttributeList ::= { first-attribute 27.13.2.ISO/IEC 8824-1:2003 (E) </FileIdentifier> E.14. . } -. .14.

&AttributeType can carry a value of any type defined using ASN. Annex A and Annex C).2.2.680 (07/2002) . fields of the information object class ATTRIBUTE may be used in defining a type.&AttributeType are object class field types. -. X. attributeValue ATTRIBUTE. Get-Invoke is then equivalent to: Get-Invoke ::= SEQUENCE { objectClass ObjectClass.1 Use an instance-of to specify a type containing an object identifier field and an open type value whose type is determined by the object identifier.ISO/IEC 8824-1:2003 (E) E.1 Use an embedded-pdv type to model a variable whose type is unspecified.constrained.2.&attributeId. ATTRIBUTE. since its type is not fixed in the definition of the information object class ATTRIBUTE. --attributeID ATTRIBUTE.&AttributeType is an open type. Attribute. accessControl [UNIVERSAL 8] IMPLICIT SEQUENCE { type-id ACCESS-CONTROL-CLASS. EXAMPLE ATTRIBUTE ::= CLASS { &AttributeType. EXAMPLE ACCESS-CONTROL-CLASS ::= TYPE-IDENTIFIER Get-Invoke ::= SEQUENCE { objectClass ObjectClass. &attributeId } OBJECT IDENTIFIER UNIQUE Attribute ::= SEQUENCE { attributeID ATTRIBUTE. The type ATTRIBUTE. the type because it is explicitly defined in ATTRIBUTE as an OBJECT IDENTIFIER.&attributeId is fixed However.this is normally Both ATTRIBUTE.16 Embedded-pdv E.17 External The external type is similar to the embedded-pdv type.&AttributeType constrained. } -- this is normally constrained. or specified elsewhere with no restriction on the notation used to specify the type. in that they are types defined by reference to an information object class (ATTRIBUTE). EXAMPLE FileContents ::= EMBEDDED PDV DocumentList ::= SEQUENCE OF document EMBEDDED PDV E.16. New specifications will generally prefer to use embedded-pdv because of its greater flexibility and the fact that some encoding rules encode its values more efficiently.2.15 Object class field type E. }. but has fewer identification options.18 Instance-of E.1.&attributeId } this is normally constrained. For example. E. objectInstance ObjectInstance.681 | ISO/IEC 8824-2). X.&attributeId and ATTRIBUTE.1 Use an object class field type to identify a type defined by means of an information object class (see ITU-T Rec. hence ATTRIBUTE. X.&id.2.18.681 | ISO/IEC 8824-2. E. accessControl INSTANCE OF ACCESS-CONTROL-CLASS.15.2.&Type -. Notations that possess this property of being able to carry a value of any type are termed "open type notation". 108 ITU-T Rec.2. -. value [0] ACCESS-CONTROL-CLASS.this is normally -. The instance-of type can only be used if the association between the object identifier value and the type is specified using an information object of a class derived from TYPE-IDENTIFIER (see ITU-T Rec.this is normally -. objectInstance ObjectInstance.constrained.

682 | ISO/IEC 8824-3 for the definition of information object set.2.. and all OIDs are relative to an OID allocated to the standardizing body... -This application defines the following abstract syntax: Abstract-Syntax ABSTRACT-SYNTAX ::= { Application-PDU IDENTIFIED BY application-abstract-syntax-object-id } ITU-T Rec.682 | ISO/IEC 8824-3 for how to use an information object set to constrain an instance-of type. X.The value is relative to {1 3 22}--.. This also serves to clearly identify the top-level type for the application. In this case use (for example): SEQUENCE {oid-root reloids OBJECT IDENTIFIER DEFAULT {1 3 22}. use: RELATIVE-OID --The relative object identifier value is relative to {iso identified-organization set(22)} b) The early part of the object identifier value is frequently a value that is known at specification time. (This ASN. data-pdu CHOICE { .3.Any object identifier value--} c) The early part of the object identifier value is not known until communications time.. E..&attributeId } The true utility of the instance-of type is not seen until it is constrained using an information object set. X..ISO/IEC 8824-1:2003 (E) attributeID ATTRIBUTE.680 (07/2002) 109 . . } ... and Annex A of ITU-T Rec......) This set of abstract values is formally called the abstract syntax for the application. and quite often will be a value known at specification time.. typically a choice type. . In this case.2 The assignment of an object identifier to an abstract syntax can be done using the built-in information object class ABSTRACT-SYNTAX which is defined in ITU-T Rec. E. X.2. See ITU-T Rec.3 The following is an example of text which might appear in an application specification: EXAMPLE Application-ASN1 DEFINITIONS ::= BEGIN EXPORTS Application-PDU.1 Use a relative object identifier type to transmit object identifier values in a more compact form in contexts where the early part of the object identifier value is known.1 It is common for protocols to be defined by associating semantics with each of the values of a single ASN.19. use: CHOICE {a b RELATIVE-OID -. END Abstract-Syntax-Module DEFINITIONS ::= BEGIN IMPORTS Application-PDU FROM Application-ASN1. but may occasionally be a more general value...19 Relative object identifier E. }..1 type object identifier. In this case.3. There are three situations that can arise: a) The early part of the object identifier value is fixed for a given specification (it is an industry-specific standard. X. but such an example goes beyond the scope of this Recommendation | International Standard. E.3 Identifying abstract syntaxes E. An abstract syntax can be identified by giving it an abstract syntax name of ASN.1 type. Application-PDU ::= CHOICE { connect-pdu .3. ... .681 | ISO/IEC 8824-2..1 type is sometimes referred to informally as "the top-level type for the application". SEQUENCE OF RELATIVE-OID --relative to oid-root--} E.. but will frequently be common to many values that need to be sent. OBJECT IDENTIFIER -.

63) OF Parameter ::= INTEGER (2|3|5|7|11|13|17|19|23|29) E.e.104) TouchToneString ::= IA5String (FROM ("0123456789" | "*" | "#")) (SIZE (1. typeB PRESENT.") and a less optimized encoding for subtype constraint extension addition values (i.")..... while in some other encoding rules (e. EXAMPLE Envelope ::= SET { typeA TypeA. . the standard may additionally identify a mandatory transfer syntax (typically one of those defined in the encoding rules of ITU-T Rec.3 Where two or more related types have significant commonality. values appearing before the ". typeB TypeB typeC TypeC the common parent OPTIONAL.. . but which is expected to increase..and ITU-T Rec.4.g.. typeC ABSENT}) 110 ITU-T Rec.1 Subtypes Use subtypes to limit the values of an existing type which are to be permitted in a particular situation.690 | ISO/IEC 8825-1 or ITU-T Rec.Third version of SmallPrime NOTE – For certain types. . 5 | 7 | 11) -. values appearing after the ".. OPTIONAL} -ABEnvelope ::= Envelope (WITH COMPONENTS {. some encoding rules (e. EXAMPLE SmallPrime ::= INTEGER (2 | 3.ISO/IEC 8824-1:2003 (E) application-abstract-syntax-object-id OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) examples(123) application-abstract-syntax(3) } The corresponding object descriptor is: application-abstract-syntax-descriptor ObjectDescriptor ::= "Example Application Abstract Syntax" -The ASN. BER) subtype constraints have no effect on the encoding.syntax identifier in conjunction with this transfer syntax.. It thus facilitates the use of common implementation approaches to the handling of values of these types. END -- E.encoding rule object identifier -..) SmallPrime -.691 | ISO/IEC 8825-2 or ITU-T Rec. EXAMPLES AtomicNumber ::= INTEGER (1. E. 5 | 7 | 11 | 13 | 17 | 19) -.e..692 | ISO/IEC 8825-3).Second version of SmallPrime and later yet: SmallPrime ::= INTEGER (2 | 3.3.4.680 (07/2002) ..... X.4. X.g. and encourages (though does not force) this to continue as the types evolve. consider explicitly defining their common parent as a type and use subtyping for the individual types.2 Use an extensible subtype constraint to model an INTEGER type whose set of permitted values is small and well defined.691 | ISO/IEC 8825-2 can be used as the transfer -. X. This approach makes clear the relationship and the commonality.assigned to encoding rules in ITU-T Rec. X..4 E.63)) ParameterList SmallPrime ::= SET SIZE (1. X..... .First version of in anticipation of: SmallPrime ::= INTEGER (2 | 3. X. E.1 object identifier and object descriptor values: -.encoding rule object descriptor -.4 In order to ensure interworking. PER) provide a highly optimized encoding for subtype constraint extension root values (i..690 | ISO/IEC 8825-1 -.

'd' or 'e' may be present in a value. beta.5 If a general-purpose data type has been defined as a SEQUENCE OF. B.. typeB}) ::= Envelope (WITH COMPONENTS {typeA.4. EXAMPLE Given: PDU ::= SET {alpha beta gamma delta INTEGER. and the number of those which are optional.ISO/IEC 8824-1:2003 (E) -ACEnvelope ::= where typeB must always appear and typeC must not Envelope (WITH COMPONENTS {.4.32))) E. ..680 (07/2002) 111 .<0)}) and if. where the test is concerned only with some components of the PDU. for example. X. further. delta (FALSE). and the likely evolution strategy. . typeC}) The choice between the alternatives would be made upon such factors as the number of components in the parent type.. a ITU-T Rec. alpha (MIN. BOOLEAN} then in composing a test which requires the Boolean to be false and the integer to be negative. is to be present and either 5 or 12 characters in length. .. A.be absent. use subtyping to define a restricted subtype of the general type... C.4 Use subtyping to partially define a value. b ABSENT }) -'a' and 'b' V ::= Z (WITH COMPONENTS { . D.6)) (WITH COMPONENT (SIZE (1. the IA5String. E ABSENT.. write: FurtherTestPDU ::= TestPDU (WITH COMPONENTS {. typeB ABSENT... use subtyping to define a restricted subtype of the general type. SEQUENCE OF Parameter.. the extent of the difference between the individual types. a protocol data unit to be tested for in a conformance test. E. IA5String OPTIONAL. EXAMPLE Z ::= CHOICE { a b c d e } must -. EXAMPLE Text-block ::= Address ::= SEQUENCE OF VisibleString Text-block (SIZE (1. typeC PRESENT}) where typeC must always appear and typeB must not -- The latter definitions could alternatively be expressed as: ABEnvelope ACEnvelope ::= Envelope (WITH COMPONENTS {typeA.. -.4.6 If a general-purpose data type had been defined as a CHOICE.. either 'c'. beta (SIZE (5|12)) PRESENT } ) E. write: TestPDU ::= PDU (WITH COMPONENTS {.

8..2). (6). either 'b' or 'c' may -.2).only 'a' can be present -.ISO/IEC 8824-1:2003 (E) W ::= Z (WITH COMPONENTS { . (10).9.(see 47.be present in a value. (12) } | march ) First-quarter ::= Months ( january | february Second-quarter ::= Months ( april | may | june ) Third-quarter ::= Months ( july | august | september ) Fourth-quarter ::= Months ( october | november | december ) First-half ::= Months ( First-quarter | Second-quarter ) Second-half ::= Months ( Third-quarter | Fourth-quarter ) 112 ITU-T Rec.8. PRESENT }) -. a present X ::= Z (WITH COMPONENTS { a Y ::= Z (WITH COMPONENTS { a must be PRESENT }) -only 'a' can be -. EXAMPLE Months ::= ENUMERATED { january february march april may june july august september october november december (1).9. (3). ABSENT. NOTE – W and X are semantically identical.absent.(see 47. E. (7).7 Use contained subtypes to form new subtypes from existing subtypes. (8). (11).680 (07/2002) .. b. c }) -'a'.. 'd' and 'e' -.4. (2). (4). (9). (5). X.

including those of ISO International Register of Coded Character Sets to be used with Escape Sequences. and GeneralString. and hence. in ASN. F. The Basic Multilingual Plane is normally subsetted to a combination of the standard collections of characters in Annex A of ISO/IEC 10646-1.2 The UniversalString.2. UTF8String and BMPString types F.1. Use of the type CHARACTER STRING.1 character strings and printed characters in a physical rendition of the string. b) c) d) F. In implementation level 1.1 Character string support in ASN.ISO/IEC 8824-1:2003 (E) Annex F Tutorial annex on ASN. and should normally be subsetted to a combination of the standard collections of characters in Annex A of ISO/IEC 10646-1. and private collections of characters and encodings (profiles may impose requirements or restrictions on the character sets – the character abstract syntaxes – to be used). and there is normally a one-to-one correspondence between abstract characters in ASN. Character string types based on ISO/IEC 10646-1.1.1 F. F. F.2. The implementation level relates to the extent to which support is given for combining characters in the character repertoire. this permits an implementation to use any collection of characters and encodings for which OBJECT IDENTIFIERs have been assigned. defines a subset of the UniversalString and BMPString restricted character string types. GraphicString. UTF8String or BMPString with subsets defined in ISO/IEC 10646-1 or by using named characters. there are type references defined in the built-in ASN. and provided by subsetting the type UniversalString. X.4 Examples of type references defined in ASN1-CHARACTER-MODULE and their corresponding ISO/IEC 10646-1 collection names are: BasicLatin Latin-1Supplement LatinExtended-a LatinExtended-b IpaExtensions SpacingModifierLetters BASIC LATIN LATIN-1 SUPPLEMENT LATIN EXTENDED-A LATIN EXTENDED-B IPA EXTENSIONS SPACING MODIFIER LETTERS CombiningDiacriticalMarks COMBINING DIACRITICAL MARKS F. ITU-T Rec. based on the structure of ISO/IEC 646) and the associated International Register of Coded Character Sets. these are the NumericString and PrintableString types. VideotexString.2 The BMPString type carries any character from the Basic Multilingual Plan of ISO/IEC 10646-1.1 module ASN1-CHARACTER-MODULE (see clause 38).2. ISO/IEC 10646-1. ISO/IEC 7350. IA5String. combining characters are not allowed. The set of characters in ISO/IEC 10646-1 is generally too large for meaningful conformance to be required. The "subtype constraint" mechanism allows new subtypes of UniversalString that are combinations of existing subtypes to be defined.5 ISO/IEC 10646-1 specifies three "levels of implementation". TeletexString. with negotiation of the character set to be used (or announcement of the set being used). and provided by the types VisibleString.1 terms.1 character strings (This annex does not form an integral part of this Recommendation | International Standard) F.1 There are four groups of character string support in ASN.2.3 For the collections defined in Annex A of ISO/IEC 10646-1. Character string types providing a simple small collection of characters specified in this Recommendation | International Standard. The four groups are: a) Character string types based on ISO International Register of Coded Character Sets to be used with Escape Sequences (that is.1 The UniversalString and UTF8String types carry any character from ISO/IEC 10646-1. and intended for specialized use.680 (07/2002) 113 . and requires that all uses of ISO/IEC 10646-1 specify the implementation level.2.

2. These conformance requirements demand that implementors of a standard (X say) using such ASN.4 Recommendations for ASN.. Annex B) are available for use.0.159})) -.0. the OSI Protocol Implementation Conformance Statement would then contain a simple statement that the adopted subset of ISO/IEC 10646-1 is the limited subset (and the level) defined by ISO-10646-String. The -.31})) -...0. The case where a parameter of the abstract syntax is present is discussed below.128}. This can conveniently be done by defining an ASN. with an implementation level of 2.0. and hence that (at least) those characters be present in the adopted subset for the implementation..0. EXAMPLE ISO-10646-String ::= BMPString (FROM (Level2 INTERSECTION (BasicLatin UNION HebrewExtended UNION Hiragana))) -.3 On ISO/IEC 10646-1 conformance requirements Use of UniversalString.128} .1 type definition requires that the conformance requirements of ISO/IEC 10646-1 be addressed.0.0.1 specification (in the absence of parameters of the abstract syntax and exception specifications) determines both the (maximum) set of characters that can be transmitted and the (minimum) set of characters that have to be handled on receipt.{0.latin letters only 114 ITU-T Rec.{0. In implementation level 3. UTF8String or BMPString that contains all the characters needed for the standard.This is the type that defines the minimum set of characters in -.0.0. A convenient name for this type might be ISO-10646-String. F.6 A BMPString or UniversalString can be restricted to exclude all control functions by use of the subtype notation as follows: VanillaBMPString ::= BMPString (FROM (ALL EXCEPT ({0. latinSmallLetterZ)).0. EXAMPLE USE IN PROTOCOL Message ::= SEQUENCE { first-field ISO-10646-String. F.subset can appear second-field ISO-10646-String (FROM (latinSmallLetterA .1 should make clear the set of ISO/IEC 10646-1 characters that will form the adopted subset of implementations (and the required implementation level) if the requirements of their standard are to be met.1 subtype of UniversalString. UTF8String or BMPString in a specification requires that an implementation support all the ISO/IEC 10646-1 characters that are included in that ASN..0. and that all characters within this set be supported on receipt. The use of an ASN. but there are others whose use is prohibited. -.31} | {0.1 subtypes.C1 control functions VanillaBMPString ::= BMPString (FROM (ALL EXCEPT (C0 | C1))) F.all characters in the adopted -. {0. The adopted set of ISO/IEC 10646-1 requires that characters beyond this set not be transmitted. X. It is also a requirement that the stated level be supported for all such ASN. and by restricting it to Level1 or Level2 if appropriate. -.0}.159}))) or equivalently: C0 ::= BMPString (FROM ({0. and of the level (support for combining characters) of the implementation. NOTE – An ASN. In an OSI environment.1 users on ISO/IEC 10646-1 conformance Users of ASN.implementation level is required to be at least level 2.1 types provide (in the Protocol Implementation Conformance Statement) a statement of the adopted subset of ISO/IEC 10646-1 for their implementation of standard X. BMPString or UTF8String (or subtypes of these) in an ASN.ISO/IEC 8824-1:2003 (E) In implementation level 2.0.1 specification. The adopted set therefore needs to be precisely the set of all characters permitted by the ASN. there are no restrictions on the use of combining characters.0} .0.C0 control functions C1 ::= BMPString (FROM ({0.0. certain combining characters (listed in ISO/IEC 10646-1.the adopted subset for an implementation of this standard. and ISO-10646-String (possibly subtyped) would be used throughout the standard where ISO/IEC 10646-1 strings were to be included.lower case -.0.1 subtype of UniversalString. {0.1 type ISO-10646-String defined in module <your module name goes here>.680 (07/2002) .1 subtype.0. EXAMPLE CONFORMANCE STATEMENT The adopted subset of ISO/IEC 10646-1 is the limited subset consisting of all the characters in the ASN.

680 (07/2002) 115 .5 Adopted subsets as parameters of the abstract syntax ISO/IEC 10646-1 requires that the adopted subset and level of an implementation be explicitly defined. In this case the exception handling specified in -.The adopted subset of ISO/IEC 10646-1 shall include "BasicLatin".implementation level.5 In ISO/IEC 10646-1. There are also two character transfer syntaxes defined to identify the various options (particularly 16-bit and 32-bit) in ISO/IEC 10646-1. BMPString or UTF8String with a subtype constraint consisting of (or including) ImplementorsSubset which is left as a parameter of the abstract syntax. F..1 The CHARACTER STRING type The CHARACTER STRING type gives complete flexibility in the choice of character set and encoding method. F.). Level2 } F. etc. and for every possible combination of the defined collections of characters. and additional character abstract syntaxes (and/or character transfer syntaxes) can be defined by any organization able to allocate object identifiers.ISO/IEC 8824-1:2003 (E) third-field ISO-10646-String (FROM (digitZero . Otherwise.1 are warned that in this case a conforming sender may transmit to a conforming receiver characters that cannot be handled by the receiver because they fall outside the (implementation-dependent) adopted subset or level of the receiver.3 The encoding of CHARACTER STRING announces the abstract and transfer syntax of the character repertoire in use (that is. BASIC SYMBOLS. negotiation of both these syntaxes is possible.4 Character abstract syntaxes (and corresponding character transfer syntaxes) have been defined in a number of ITU-T Recommendations and International Standards."ImplementorsSubset".6. there is a character abstract syntax defined (and object identifiers assigned) for the entire collection of characters. X. ITU-T Rec.1 user does not wish to constrain the range of ISO/IEC 10646-1 characters in some part of the standard being defined. My-Level2-String ::= ISO-10646-String { { HebrewExtended UNION Hiragana }.6. a character abstract syntax is an ordinary abstract syntax with some restrictions on the possible values (they are all character strings. NOTE – Where a single connection provides end-to-end data transfer (no relaying). Note that this can never be invoked by a conforming -. which is a parameter of the abstract -. In OSI environments. this can be expressed by defining ISO-10646-String (for example) as a subtype of UniversalString. Thus allocation of object identifier values for character abstract and transfer syntaxes is performed in the normal way.invoked. F. Users of ASN."ImplementationLevel". Where an ASN. character set and encoding). which is a parameter of the abstract syntax. the abstract and transfer character syntaxes (character repertoire and encodings) are announced by a pair of object identifier values. ImplementationLevel} ::= UniversalString (FROM((ImplementorsSubset UNION BasicLatin) INTERSECTION ImplementationLevel) !characterSetProblem) -. and the OSI protocols are in use. A conforming receiver must be -.6 F.6. for each of the defined collection of characters for subsets (BASIC LATIN.prepared to recieve characters outside of its adopted subset and -.2 In formal terms. then negotiation of the character sets to be used and their encoding can be accomplished as part of the definition of the OSI presentation contexts for character abstract syntaxes.may also include any additional characters specified in -. digitNine)) -} digits only F. and it is recommended that an exception-handling specification be included in the definition of ISO-10646-String in this case. and indeed are all the character strings formed from some collection of characters).6.are restricted to "BasicLatin".receiver if the actual characters used in an instance of communication -. EXAMPLE ISO-10646-String {UniversalString : ImplementorsSubset. -.syntax defines the implementation level.6. but -.clause <add your clause number here> for "characterSetProblem" is -. F.

NOTE – The sender may be using a type that is either earlier or later in the series of extension additions..3 The ASN. h BMPString. 116 ITU-T Rec. in such cases all extension additions are inserted at the end of the type.. d SEQUENCE { e INTEGER. in which case a matching extension marker is assumed to exist just before the closing brace of the type..1. X. or it can be nested within a type in an extension root.1 type definitions in this series are said to be extension-related (see 3.680 (07/2002) . or just before the second extension marker if a pair of extension markers is used) can appear in any specific construct. G.32 for a more precise definition of "extension-related"). The third extension defines an extension addition group in which h must be present in a value of type A whenever the newly added extension addition group is present in a value.1 model of type extension (This annex does not form an integral part of this Recommendation | International Standard) G. } 1st extension A ::= SEQUENCE { a INTEGER. In the following example the first extension defines an extension addition group where b and c must either be both present or both absent in a value of type A.7 A new extension addition in the extension series is defined in terms of a single extension addition group (one or more types nested within "[[" "]]") or a single type added at the extension insertion point. provided the same transfer syntax is used.. . transmissions between the two systems will successfully transfer the information content of those parts of the extension-related types that are common to the two systems.. d SEQUENCE { e INTEGER. . G. c INTEGER.. . It is also required that those parts that are not common to both systems can be delimited and retransmitted (perhaps to a third party) on a subsequent transmission.6 A type that has an extension marker can be nested inside a type that has none...1.. ....1. c INTEGER } 2nd extension A ::= SEQUENCE { a INTEGER. and encoding rules are required to encode extension-related types in a such a way that if two systems are using two different types which are extension-related..1 Overview G..4 The series of types obtained by progressively adding to a root type is called an extension series. G.. b BOOLEAN.. EXAMPLE Extension root type A ::= SEQUENCE { a INTEGER. f IA5String } } G. Each such ASN. The flag is an ellipsis (.1. The second extension defines a single component type.. G..1 type available to a particular implementation may be the extension root type. such types (including the extension root type) need to be syntactically flagged.1 It can happen that an ASN.ISO/IEC 8824-1:2003 (E) Annex G Tutorial annex on the ASN. . set. or may be the extension root type plus one or more extension additions. b BOOLEAN.1 type evolves over time from an extension root type by means of a series of extensions called extension additions. c INTEGER. g BOOLEAN OPTIONAL.2 An ASN. A single extension marker is allowed if (in the extension root type) it appears as the last item in the type. .).. and the nested type with the extension marker has no impact on the type within which it is nested.. and is called an extension marker. Only one extension insertion point (the end of the type if a single extension marker is used..6. . and choice types are inserted between pairs of extension markers..1 type that contains an extension addition also contains all previously defined extension additions..1. b BOOLEAN. In order for encoding rules to make appropriate provision for transmissions of extension-related types (which may require more bits on the line).1.. d. In such cases the extension series are treated independently. G..5 All extension additions in sequence. which may be absent in a value of type A. . or it can be nested in an extension addition type. f IA5String } } 3rd extension A ::= SEQUENCE { a INTEGER.1.

or together as an extension group)... and still retain interworking between versions 1 and 2. one contains all the components of the other. [[ b BOOLEAN. CHOICE Constraint notation G.. but only if it is present on all brackets within a module. [[ b BOOLEAN.9 While the normal practice will be for extension additions to be added over time. not to an individual type. with an enumeration value greater than that of any enumeration already added. [[ b BOOLEAN. Addition of a single type or extension addition group to the end of the "ExtensionAdditionList"..1 Version numbers are not used in BER or PER encodings.ISO/IEC 8824-1:2003 (E) EXAMPLE Extension root type A ::= SEQUENCE { a INTEGER. There may be types that have to be "grown" in the opposite direction (although this is unlikely)..1 – Extension additions Extension root type ENUMERATED SEQUENCE and SET Nature of extension addition Addition of a single further enumeration at the end of the "AdditionalEnumeration"s.8 It is also possible to add the version number to version brackets. The ability to omit numbers and version brackets is for historical reasons.1. "ComponentType"s that are extension additions (not contained in an extension addition group) are not required to be marked OPTIONAL or DEFAULT. X. the underlying ASN.. Their use (if any) in ECN encodings is determined by the ECN specification.. [[ g BOOLEAN OPTIONAL.1.... .3. . c INTEGER ]]..1.. .2. it can be possible to add extensions in version 2 at places that did not have extension markers in version 1. It could even be that.2 Meaning of version numbers G... Addition of a single "NamedType" to the end of the "ExtensionAdditionAlternativesList". d SEQUENCE { e INTEGER. c INTEGER ]]. however. If they are. h BMPString ]].1.. d SEQUENCE { e INTEGER.10 We start with a type and then decide whether we are going to want interworking with implementations of earlier versions if we later have to extend it. NOTE – When ECN is used.. a type starts with a lot of extension additions which were progressively removed! All that ASN.. Two types are extension-related if one can be "grown" from the other by extension additions.) (See also G. It is recommended that version numbers be used.680 (07/2002) 117 . over time. It is.2. G. . We can then add later extension additions to the type with defined handling of the extended values by earlier systems.1 encoding rules will ensure interworking between their users. If so. we include the extension marker now. Table G.1 extension series. .1 types that can form the extension root type of an ASN. G.2 Version numbers are most useful when they relate to the means of decoding a complete PDU.) G. and only if all extensions in the module are within version brackets.11 Table G.1 shows the ASN. and the nature of the single extension addition that is permitted for that type (multiple extension additions can of course be made in succession. f IA5String } } G... important to note that adding an extension marker to a type that was previously without one (or removing an extension marker) may prevent interworking.. . c INTEGER ]] } 2nd extension A ::= SEQUENCE { a INTEGER.. although this will often be the case.. Addition of a single "AdditionalElementSetSpec" to the "ElementSetSpecs" notation.1 model and specification does not involve time. Where a type which is used as a component of several protocols and hence contributes to different ITU-T Rec. . G. f IA5String } } 3rd extension A ::= SEQUENCE { a INTEGER. then all ASN.. That is. (Version brackets and version numbers were not allowed in earlier versions of this Recommendation | International Standard. . } 1st extension A ::= SEQUENCE { a INTEGER.1 and its encoding rules care about is whether a pair of type specifications are extension-related or not.

3 The definition of the procedures for transforming an abstract value into an encoding for transfer. . The use of a typereference (a contained subtype) in the set arithmetic of a constraint. when the typereference de-references to an extensible type (perhaps with actual extension additions – see G.5 The encoding rules shall ensure that where the sender has a type specification that is later in the extension series than that of the receiver.2).3).5.2.1. Consider: A ::= INTEGER (MIN .4.1.4. Such an abstract syntax is called an extension-related abstract syntax.1 The basic ASN.1 Combination of (possibly extensible) constraints Model G. there is one feature to clarify: A type may be formally extensible.1 standard has been left simple and general. X. G. G.1 type that is an extensible type. G.4.2. with the full range of integer values in the root. values of the sender shall be transferred in such a way that the receiver can determine that extension additions are not present.4.3 to G.. occur when a type has multiple constraints directly applied to it in a serial fashion. but which tool vendors have to write code for because the ASN. and a constraint applied to it selects a subset of those abstract values.3 Requirements on encoding rules G. version numbers should be used on extension addition groups in such a way that deployed systems have knowledge of the syntax and semantics for all extension addition groups with a given version number (no matter where they appear within the protocol).4. this is something that nobody would ever write. G.3 Complexities arise from three main sources: – – – G.2 The application of a constraint to a type that has already had an extensible constraint applied to it (serial application of constraints – see G. and for transforming a received encoding into an abstract value shall recognize the possibility that the sender and receiver are using abstract syntaxes that are not identical. but less commonly.1.10) As with many examples in this annex. G.3.3.2 A set of well-formed encoding rules for an extension-related abstract syntax satisfies the additional requirements stated in G. A is formally an extensible INTEGER. but are extension-related. G. ..ISO/IEC 8824-1:2003 (E) complete PDUs.1.680 (07/2002) . The combination of extensible constraints using UNION and INTERSECTION and EXCEPT (set arithmetic – see G. the encoding rules shall ensure that where the sender has a type specification that is earlier in the extension series than that of the receiver. and of all extension addition groups with an earlier version number.1 model for applying constraints is simple: A type is a set of abstract values. G.3. In this example.1 Serial application of constraints occurs when a type is constrained (in an assignment to a typereference) and the typereference is subsequently used with a further constraint applied to it. even though there can never be any extension additions.4. G.3.2 Even in this simple case. If the unconstrained type was not extensible.4.3. It then contains all the values that can be obtained by the addition or removal of extension-additions. NOTE – All ASN. G.2.4 In this case.2 It can also.4.1 encoding rules satisfy these requirements. then the resulting type is defined to be extensible if and only if the applied constraint is defined to be extensible. Serial application of constraints G. and this example is therefore legal ASN. MAX.4 G.3 When used to provide interworking between deployed systems.3. but the case where a typereference links the two (or more) constraints is the form in which serial application normally occurs in real specifications.1 An abstract syntax can be defined as the values of a single ASN. 118 ITU-T Rec. transfer of values of that type to the receiver shall be possible.4. G. ECN specifiers will normally assume that version numbers have been allocated (to all parts of types to which ECN is applied) in accordance with this principle.4. 1.3. an addition to that type will normally require that the version number for all the PDUs to which it contributes be incremented.4)... This latter form is used for many of the examples in this annex (for simplicity of exposition).

and obey the normal mathematical rules for intersection.3 Use of set arithmetic G.3.or equivalently B1 ::= INTEGER (1.. – NOTE – Use of a range such as 20..32) (MIN . that is: ( <some set 1 of values> INTERSECTION <some set 2 of values> ) is the same as ( <some set 2 of values> INTERSECTION <some set 1 of values> ) similarly for UNION. the range 20... .32.128) -. This is similar to the case of INTEGER (MIN.. the environment in which MIN and MAX are interpreted.ISO/IEC 8824-1:2003 (E) G.. even when there is no extensibility involved. Here are some examples: A1 ::= INTEGER (1.2.This is legal.)..28 in a constraint on an integer type is legal if (and only if) both 20 and 28 are in the (root of the) parent type. and the contents of the result are shown for each case.3. 33.32.. as 128 is not in the parent. . 63) -. and no matter what extension additions are present.These are illegal. union and set difference (EXCEPT)...32) INTERSECTION (MIN. and secondly the abstract values that can be referenced in the second constraint are very different in serial application from the situation where the two constraints are specified as an intersection of values from a common parent.B contains.4 For example: A ::= INTEGER ((1.. and contains 1 to 16.3 There are two key points in the serial application of constraints: – If a constrained type is extensible (and perhaps extended). The serial application of constraints is (for complex cases) not the same as a set arithmetic intersection.. B) INTERSECTION (1. .4. which -. but the values referenced by this range specification are only those in (the root of) the parent. and do not depend on whether the set arithmetic makes actual extension additions possible or not..16) -.3.3 Misunderstandings can arise if an intersection makes it impossible for extension addition values ever to occur.3. but is nonetheless formally extensible G.lost its extension additions when it was further constrained B2 ::= A1 (1.4. X. Values included in the root or the extension additions of the resulting type can only be values that are in the root of the parent type.4. no matter what sets of values are extensible.256)) -. .3. The values in the root of each set are denoted by R. In particular..A always contains (only) the values 1.256.5 It is also important to remember that while parents lose their extensibility and extension additions when further constrained. and the extension additions (if any) by X. and 63 is illegal A3 ::= INTEGER ( (1. no matter what values -.6 The rules for extensibility of sets of values produced by set arithmetic are clearly stated in 46.4..2 The commutativity is true. B1 ::= A1 (1.. which can reference only values in the root of the type that is being further constrained (the parent type).. . the "extensible" flag and all extension additions are discarded if a further constraint is subsequently serially applied. G. So if the parent has already been constrained to exclude the values 24 and 25. and contained subtypes lose their extensibility and extension additions..MAX.4.1 The results are largely intuitive.7 The rules are summarized here for completeness.4. .3. MIN is minus infinity and A3 contains 1 to 32 G. ITU-T Rec.4.This is legal. G. B2 is not extensible..28 is referencing only 20 to 23 and 26 to 28.4. G.... 33.128) (1. . using E to denote a set of values with the "extensible" flag set and N to denote a set values which are formally non-extensible. The extensibility of a constrained type (and any extension additions) depends solely on the last constraint that is applied.MIN is 1. sets of values directly specified in set arithmetic lose neither their extensibility nor their extension additions..A1 is extensible. both intersection and union are commutative.256.. and contains values 1 to 128 with 1 to 32 -.4.in the root and 33 to 128 as extension additions.3 and 46..680 (07/2002) 119 .128) -. G. Firstly.4.63) ) -. A2 ::= INTEGER (1. G.128) -.3.

3. and all its extension additions are discarded. but when it is used in set arithmetic it is always treated as not extensible. Extensions: (X1 EXCEPT R2) EXCEPT (R1 EXCEPT R2) E1 EXCEPT E2 => E Root: R1 EXCEPT R2. X.. Extensions: R2 UNION X2 EXCEPT R1 E1 .. Extensions: (X1 EXCEPT (R2 UNION X2) ) EXCEPT (R1 EXCEPT R2) N1 . E2 => E Root: R1.. N2 => E Root: R1.4..680 (07/2002) . Extensions: X1 UNION R2 UNION E2 EXCEPT R1 NOTE – If the result of set arithmetic on extensible sets of values does not have actual extension additions. the result is still formally defined to be extensible for results E above.4.. Extensions: R1 INTERSECTION X2 E1 INTERSECTION E2 => E Root: R1 INTERSECTION R2.ISO/IEC 8824-1:2003 (E) NOTE 1 – For the purposes of this annex and for simplicity of exposition. if a set of values is not extensible. "Extensions" is used in place of the more correct "Extension additions". Extensions: X2 E1 UNION E2 => E Root: R1 UNION R2. Extensions: R2 EXCEPT R1 E1 . E2 => E Root: R1. we describe all its values as root values... G. 120 ITU-T Rec. Extensions: ((R1 UNION X1) INTERSECTION (R2 UNION X2)) EXCEPT (R1 INTERSECTION R2) N1 UNION N2 => N Root: R1 UNION R2 N1 UNION E2 => E Root: R1 UNION R2.. Extensions: X1 UNION R2 EXCEPT R1 N1 . Extensions: (R1 UNION X1 UNION R2 UNION X2) EXCEPT (R1 UNION R2) N1 EXCEPT N2 => N Root: R1 EXCEPT R2 N1 EXCEPT E2 => N Root: R1 EXCEPT R2 E1 EXCEPT N2 => E Root: R1 EXCEPT R2. NOTE 2 – It is an illegal specification if the root of any resulting set of values used in a serially applied constraint is empty.8 The rules are: N1 INTERSECTION N2 => N Root: R1 INTERSECTION R2 N1 INTERSECTION E2 => E Root: R1 INTERSECTION R2. NOTE 3 – To avoid verbosity below.4 Use of the Contained Subtype notation A contained subtype may or may not be extensible. or even can never have actual extension additions (no matter what extension additions are added to the extensible inputs). G. N2 => E Root: R1.

" "</" "/>" "{" "}" "<" ">" "." "@" "|" "!" "^" ABSENT ABSTRACT-SYNTAX ALL APPLICATION AUTOMATIC BEGIN BIT BMPString BOOLEAN BY CHARACTER CHOICE CLASS COMPONENT COMPONENTS CONSTRAINED CONTAINING DEFAULT DEFINITIONS EMBEDDED ENCODED END ENUMERATED EXCEPT EXPLICIT EXPORTS EXTENSIBILITY EXTERNAL FALSE FROM GeneralizedTime GeneralString GraphicString IA5String IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INSTANCE INTEGER INTERSECTION ISO646String MAX MIN MINUS-INFINITY NULL NumericString OBJECT ObjectDescriptor OCTET OF OPTIONAL PATTERN PDV PLUS-INFINITY PRESENT PrintableString PRIVATE REAL RELATIVE-OID SEQUENCE SET SIZE STRING SYNTAX ITU-T Rec." ".680 (07/2002) 121 .1 notation (This annex does not form an integral part of this Recommendation | International Standard) The following lexical items are defined in clause 11: typereference identifier valuereference modulereference comment empty number realnumber bstring hstring cstring xmlbstring xmlhstring xmlcstring xmlasn1typename "true" "false" "::=" "[[" "]]" "..ISO/IEC 8824-1:2003 (E) Annex H Summary of the ASN." ".." "(" ")" "[" "]" "-" ":" "=" """ (QUOTATION MARK) "'" (APOSTROPHE) " " (SPACE) ".. X.

X.ISO/IEC 8824-1:2003 (E) T61String TAGS TeletexString TRUE TYPE-IDENTIFIER UNION UNIQUE UNIVERSAL UniversalString UTCTime UTF8String VideotexString VisibleString WITH 122 ITU-T Rec.680 (07/2002) .

" Symbol ITU-T Rec." empty SymbolsExported ::= SymbolList | empty Imports ::= | IMPORTS SymbolsImported ". with the above lexical items as terminal symbols: ModuleDefinition ::= ModuleIdentifier DEFINITIONS TagDefault ExtensionDefault "::=" BEGIN ModuleBody END ModuleIdentifier ::= modulereference DefinitiveIdentifier DefinitiveIdentifier ::= "{" DefinitiveObjIdComponentList "}" | empty DefinitiveObjIdComponentList ::= DefinitiveObjIdComponent | DefinitiveObjIdComponent DefinitiveObjIdComponentList DefinitiveObjIdComponent ::= NameForm | DefinitiveNumberForm | DefinitiveNameAndNumberForm DefinitiveNumberForm ::= number DefinitiveNameAndNumberForm ::= identifier "(" DefinitiveNumberForm ")" TagDefault ::= | | | EXPLICIT TAGS IMPLICIT TAGS AUTOMATIC TAGS empty EXTENSIBILITY IMPLIED | empty ExtensionDefault ::= ModuleBody ::= Exports Imports AssignmentList | empty Exports ::= | | EXPORTS SymbolsExported ".680 (07/2002) 123 ." empty SymbolsImported ::= SymbolsFromModuleList | empty SymbolsFromModuleList ::= SymbolsFromModule | SymbolsFromModuleList SymbolsFromModule SymbolsFromModule ::= SymbolList FROM GlobalModuleReference GlobalModuleReference ::= modulereference AssignedIdentifier AssignedIdentifier ::= ObjectIdentifierValue | DefinedValue | empty SymbolList ::= Symbol | SymbolList ". X." EXPORTS ALL ".ISO/IEC 8824-1:2003 (E) The following productions are used in this Recommendation | International Standard.

" ItemSpec ItemSpec ::= typereference | ItemId "." valuereference AbsoluteReference ::= "@" ModuleIdentifier ".680 (07/2002) ." typereference NonParameterizedTypeName ::= ExternalTypeReference | typereference | xmlasn1typename DefinedValue ::= ExternalValueReference | valuereference | ParameterizedValue ExternalValueReference ::= modulereference ".ISO/IEC 8824-1:2003 (E) Symbol ::= Reference | ParameterizedReference Reference ::= typereference | valuereference | objectclassreference | objectreference | objectsetreference AssignmentList ::= Assignment | AssignmentList Assignment Assignment ::= TypeAssignment | ValueAssignment | XMLValueAssignment | ValueSetTypeAssignment | ObjectClassAssignment | ObjectAssignment | ObjectSetAssignment | ParameterizedAssignment DefinedType ::= ExternalTypeReference | typereference | ParameterizedType | ParameterizedValueSetType ExternalTypeReference ::= modulereference ". X." ComponentId ItemId ::= ItemSpec ComponentId ::= identifier | number | "*" TypeAssignment ::= typereference "::=" Type ValueAssignment ::= valuereference Type 124 ITU-T Rec.

ISO/IEC 8824-1:2003 (E) "::=" Value XMLValueAssignment ::= valuereference "::=" XMLTypedValue XMLTypedValue ::= "<" & NonParameterizedTypeName ">" XMLValue "</" & NonParameterizedTypeName ">" | "<" & NonParameterizedTypeName "/>" ValueSetTypeAssignment ::= typereference Type "::=" ValueSet ValueSet ::= "{" ElementSetSpecs "}" Type ::= BuiltinType | ReferencedType | ConstrainedType BuiltinType ::= BitStringType | BooleanType | CharacterStringType | ChoiceType | EmbeddedPDVType | EnumeratedType | ExternalType | InstanceOfType | IntegerType | NullType | ObjectClassFieldType | ObjectIdentifierType | OctetStringType | RealType | RelativeOIDType | SequenceType | SequenceOfType | SetType | SetOfType | TaggedType NamedType ::= identifier Type ReferencedType ::= DefinedType | UsefulType | SelectionType | TypeFromObject | ValueSetFromObjects Value ::= BuiltinValue | ReferencedValue | ObjectClassFieldValue XMLValue ::= XMLBuiltinValue | XMLObjectClassFieldValue BuiltinValue ::= BitStringValue | BooleanValue | CharacterStringValue | ChoiceValue | EmbeddedPDVValue | EnumeratedValue | ExternalValue ITU-T Rec. X.680 (07/2002) 125 .

ISO/IEC 8824-1:2003 (E) | | | | | | | | | | | | InstanceOfValue IntegerValue NullValue ObjectIdentifierValue OctetStringValue RealValue RelativeOIDValue SequenceValue SequenceOfValue SetValue SetOfValue TaggedValue XMLBuiltinValue ::= XMLBitStringValue | XMLBooleanValue | XMLCharacterStringValue | XMLChoiceValue | XMLEmbeddedPDVValue | XMLEnumeratedValue | XMLExternalValue | XMLInstanceOfValue | XMLIntegerValue | XMLNullValue | XMLObjectIdentifierValue | XMLOctetStringValue | XMLRealValue | XMLRelativeOIDValue | XMLSequenceValue | XMLSequenceOfValue | XMLSetValue | XMLSetOfValue | XMLTaggedValue ReferencedValue ::= DefinedValue | ValueFromObject NamedValue ::= identifier Value XMLNamedValue ::= "<" & identifier ">" XMLValue "</" & identifier ">" BooleanType ::=BOOLEAN BooleanValue::= TRUE | FALSE XMLBooleanValue ::= "<" & "true" "/>" | "<" & "false" "/>" IntegerType ::= | INTEGER INTEGER "{" NamedNumberList "}" NamedNumberList ::= NamedNumber | NamedNumberList ". X." NamedNumber NamedNumber ::= identifier "(" SignedNumber ")" | identifier "(" DefinedValue ")" SignedNumber ::= number | "-" number IntegerValue ::= SignedNumber | identifier 126 ITU-T Rec.680 (07/2002) .

" Enumeration EnumerationItem ::= identifier | NamedNumber EnumeratedValue ::= identifier XMLEnumeratedValue ::= "<" & identifier "/>" RealType ::= REAL RealValue ::= NumericRealValue | SpecialRealValue NumericRealValue ::= realnumber | "-" realnumber | SequenceValue SpecialRealValue ::= PLUS-INFINITY | MINUS-INFINITY -." ".." ".ISO/IEC 8824-1:2003 (E) XMLIntegerValue ::= SignedNumber | "<" & identifier "/>" EnumeratedType ::= ENUMERATED "{" Enumerations "}" Enumerations ::= RootEnumeration | RootEnumeration ".Value of the associated sequence type XMLRealValue ::= XMLNumericRealValue | XMLSpecialRealValue XMLNumericRealValue ::= realnumber | "-" realnumber XMLSpecialRealValue ::= "<" & PLUS-INFINITY "/>" | "<" & MINUS-INFINITY "/>" BitStringType ::= BIT STRING | BIT STRING "{" NamedBitList "}" NamedBitList::= NamedBit | NamedBit | NamedBitList ".680 (07/2002) 127 ." NamedBit ::= identifier "(" number ")" identifier "(" DefinedValue ")" bstring | hstring | "{" IdentifierList "}" | "{" "}" | CONTAINING Value identifier | IdentifierList "." identifier BitStringValue ::= IdentifierList ::= XMLBitStringValue ::= XMLTypedValue | xmlbstring | XMLIdentifierList | empty XMLIdentifierList ::= "<" & identifier "/>" | XMLIdentifierList "<" & identifier "/>" OctetStringType ::= OCTET STRING OctetStringValue ::= bstring | hstring | CONTAINING Value ITU-T Rec..." AdditionalEnumeration RootEnumeration ::= Enumeration AdditionalEnumeration ::= Enumeration Enumeration ::= EnumerationItem | EnumerationItem "." ExceptionSpec | RootEnumeration "." ExceptionSpec ". X..

" ExceptionSpec OptionalExtensionMarker ::= "." ComponentType ComponentType ::= NamedType | NamedType OPTIONAL | NamedType DEFAULT Value | COMPONENTS OF Type SequenceValue ::= "{" ComponentValueList "}" | "{" "}" ComponentValueList ::= NamedValue | ComponentValueList "." ExtensionAndException ExtensionAdditions OptionalExtensionMarker | RootComponentTypeList "." RootComponentTypeList | ExtensionAndException ExtensionAdditions OptionalExtensionMarker RootComponentTypeList ::= ComponentTypeList ExtensionEndMarker ::= "." ExtensionAdditionList | empty ExtensionAdditionList ::= ExtensionAddition | ExtensionAdditionList "." ExtensionAdditions ::= "." | empty ComponentTypeLists ::= RootComponentTypeList | RootComponentTypeList "." "." ExtensionAddition ExtensionAddition ::= ComponentType | ExtensionAdditionGroup ExtensionAdditionGroup ::= "[[" VersionNumber ComponentTypeList "]]" VersionNumber ::= empty | number ":" ComponentTypeList ::= | ComponentType ComponentTypeList ".ISO/IEC 8824-1:2003 (E) XMLOctetStringValue ::= XMLTypedValue | xmlhstring NullType NullValue ::= ::= NULL NULL XMLNullValue ::= empty SequenceType ::= | | SEQUENCE "{" "}" SEQUENCE "{" ExtensionAndException OptionalExtensionMarker "}" SEQUENCE "{" ComponentTypeLists "}" ExtensionAndException ::= "..680 (07/2002) .." ".." | ".." ExtensionAndException ExtensionAdditions ExtensionEndMarker ".. X." NamedValue XMLSequenceValue ::= XMLComponentValueList | empty XMLComponentValueList ::= XMLNamedValue | XMLComponentValueList XMLNamedValue SequenceOfType ::= SEQUENCE OF Type | SEQUENCE OF NamedType SequenceOfValue ::= "{" ValueList "}" | "{" NamedValueList "}" | "{" "}" 128 ITU-T Rec." RootComponentTypeList | ExtensionAndException ExtensionAdditions ExensionEndMarker "....

" Value XMLSequenceOfValue ::= XMLValueList | XMLDelimitedItemList | XMLSpaceSeparatedList | empty XMLValueList ::= XMLValueOrEmpty | XMLValueOrEmpty XMLValueList XMLValueOrEmpty ::= XMLValue | "<" & NonParameterizedTypeName "/>" XMLSpaceSeparatedList ::= XMLValueOrEmpty | XMLValueOrEmpty " " XMLSpaceSeparatedList XMLDelimitedItemList ::= XMLDelimitedItem | XMLDelimitedItem XMLDelimitedItemList XMLDelimitedItem ::= "<" & NonParameterizedTypeName ">" XMLValue "</" & NonParameterizedTypeName ">" | "<" & identifier ">" XMLValue "</" & identifier ">" SetType ::= SET "{" "}" | SET "{" ExtensionAndException OptionalExtensionMarker "}" | SET "{" ComponentTypeLists "}" SetValue ::= "{" ComponentValueList "}" | "{" "}" | empty XMLSetValue ::= XMLComponentValueList SetOfType ::= SET OF Type | SET OF NamedType SetOfValue ::= "{" ValueList "}" | "{" NamedValueList "}" | "{" "}" XMLSetOfValue ::= XMLValueList | XMLDelimitedItemList | XMLSpaceSeparatedList | empty ChoiceType ::= CHOICE "{" AlternativeTypeLists "}" AlternativeTypeLists ::= RootAlternativeTypeList | RootAlternativeTypeList ".680 (07/2002) 129 ." ExtensionAdditionAlternativesList | empty ExtensionAdditionAlternativesList ::= ExtensionAdditionAlternative | ExtensionAdditionAlternativesList "." ExtensionAdditionAlternative ExtensionAdditionAlternative ::= ExtensionAdditionAlternativesGroup | NamedType ExtensionAdditionAlternativesGroup ::= "[[" VersionNumber AlternativeTypeList "]]" AlternativeTypeList ::= | ChoiceValue ::= NamedType AlternativeTypeList "." NamedType identifier ":" Value XMLChoiceValue ::= "<" & identifier ">" XMLValue "</" & identifier ">" ITU-T Rec.ISO/IEC 8824-1:2003 (E) ValueList ::= Value | ValueList "." ExtensionAndException ExtensionAdditionAlternatives OptionalExtensionMarker RootAlternativeTypeList ::= AlternativeTypeList ExtensionAdditionAlternatives ::= ". X.

X.680 (07/2002) .ISO/IEC 8824-1:2003 (E) SelectionType TaggedType | | Tag ::= ::= identifier "<" Type ::= Tag Type Tag IMPLICIT Type Tag EXPLICIT Type "[" Class ClassNumber "]" ClassNumber ::= number | DefinedValue Class | | | ::= UNIVERSAL APPLICATION PRIVATE empty TaggedValue ::= Value XMLTaggedValue ::= XMLValue EmbeddedPDVType ::= EmbeddedPDVValue ::= EMBEDDED PDV SequenceValue XMLEmbeddedPDVValue ::= XMLSequenceValue ExternalType ::= EXTERNAL ExternalValue ::= SequenceValue XMLExternalValue ::= XMLSequenceValue ObjectIdentifierType ::= OBJECT IDENTIFIER ObjectIdentifierValue ::= "{" ObjIdComponentsList "}" | "{" DefinedValue ObjIdComponentsList "}" ObjIdComponentsList ::= ObjIdComponents | ObjIdComponents ObjIdComponentsList ObjIdComponents ::= NameForm | NumberForm | NameAndNumberForm | DefinedValue NameForm NumberForm ::= ::= identifier number | DefinedValue identifier "(" NumberForm ")" NameAndNumberForm ::= XMLObjectIdentifierValue ::= XMLObjIdComponentList XMLObjIdComponentList ::= XMLObjIdComponent | XMLObjIdComponent & "." & XMLObjIdComponentList XMLObjIdComponent ::= NameForm | XMLNumberForm | XMLNameAndNumberForm XMLNumberForm ::= number XMLNameAndNumberForm ::= identifier & "(" & XMLNumberForm & ")" RelativeOIDType ::= RELATIVE-OID RelativeOIDValue ::= "{" RelativeOIDComponentsList "}" 130 ITU-T Rec.

" Cell "}" ::= number ::= number ::= number ::= number Tuple ::= "{" TableColumn "." CharsDefn CharsDefn ::= cstring | Quadruple | Tuple | DefinedValue Quadruple Group Plane Row Cell ::= "{" Group ".680 (07/2002) 131 . X." TableRow "}" TableColumn ::= number TableRow ::= number XMLRestrictedCharacterStringValue ::= xmlcstring UnrestrictedCharacterStringType ::= CHARACTER STRING CharacterStringValue ::= RestrictedCharacterStringValue | UnrestrictedCharacterStringValue XMLCharacterStringValue ::= XMLRestrictedCharacterStringValue |XMLUnrestrictedCharacterStringValue UnrestrictedCharacterStringValue ::= SequenceValue ITU-T Rec.ISO/IEC 8824-1:2003 (E) RelativeOIDComponentsList ::= RelativeOIDComponents | RelativeOIDComponents RelativeOIDComponentsList RelativeOIDComponents ::= | | NumberForm NameAndNumberForm DefinedValue XMLRelativeOIDValue ::= XMLRelativeOIDComponentList XMLRelativeOIDComponentList ::= XMLRelativeOIDComponent | XMLRelativeOIDComponent & "." Plane "." & XMLRelativeOIDComponentList XMLRelativeOIDComponent ::= XMLNumberForm | XMLNameAndNumberForm CharacterStringType ::= RestrictedCharacterStringType | UnrestrictedCharacterStringType RestrictedCharacterStringType ::= | | | | | | | | | | | | BMPString GeneralString GraphicString IA5String ISO646String NumericString PrintableString TeletexString T61String UniversalString UTF8String VideotexString VisibleString RestrictedCharacterStringValue ::= cstring | CharacterStringList | Quadruple | Tuple CharacterStringList ::= "{" CharSyms "}" CharSyms ::= CharsDefn | CharSyms "." Row ".

680 (07/2002) .1: NumericString PrintableString TeletexString T61String VideotexString UniversalString VisibleString ISO646String IA5String GraphicString GeneralString BMPString The following useful types are defined in clauses 42 to 44: GeneralizedTime UTCTime ObjectDescriptor The following productions are used in clauses 45 to 47: ConstrainedType ::= Type Constraint | TypeWithConstraint TypeWithConstraint ::= SET Constraint OF Type | SET SizeConstraint OF Type | SEQUENCE Constraint OF Type | SEQUENCE SizeConstraint OF Type | SET Constraint OF NamedType | SET SizeConstraint OF NamedType | SEQUENCE Constraint OF NamedType | SEQUENCE SizeConstraint OF NamedType Constraint ::= "(" ConstraintSpec ExceptionSpec ")" ConstraintSpec ::= | SubtypeConstraint GeneralConstraint ExceptionSpec ::= "!" ExceptionIdentification | empty ExceptionIdentification ::= SignedNumber | DefinedValue | Type ":" Value SubtypeConstraint ::= ElementSetSpecs ElementSetSpecs ::= RootElementSetSpec | RootElementSetSpec ".ISO/IEC 8824-1:2003 (E) XMLUnrestrictedCharacterStringValue ::= XMLSequenceValue UsefulType ::= typereference The following character string types are defined in 37.." | RootElementSetSpec "." AdditionalElementSetSpec RootElementSetSpec ::= ElementSetSpec AdditionalElementSetSpec ::= ElementSetSpec ElementSetSpec ::= Unions | ALL Exclusions Unions ::= | Intersections UElems UnionMark Intersections UElems ::= Unions Intersections ::= IntersectionElements | IElems IntersectionMark IntersectionElements 132 ITU-T Rec." ".. X.." ".." ".

X." TypeConstraints NamedConstraint ::= identifier ComponentConstraint ComponentConstraint ::= ValueConstraint PresenceConstraint ValueConstraint ::= Constraint | empty PresenceConstraint ::= PRESENT | ABSENT | OPTIONAL | empty PatternConstraint ::= PATTERN Value ITU-T Rec..680 (07/2002) 133 ." UpperEndpoint LowerEndpoint ::= LowerEndValue | LowerEndValue "<" UpperEndpoint ::= UpperEndValue | "<" UpperEndValue LowerEndValue ::= Value | MIN UpperEndValue ::= Value | MAX SizeConstraint ::= SIZE Constraint PermittedAlphabet ::= FROM Constraint TypeConstraint ::= Type InnerTypeConstraints ::= | WITH COMPONENT SingleTypeConstraint WITH COMPONENTS MultipleTypeConstraints SingleTypeConstraint::= Constraint MultipleTypeConstraints ::= FullSpecification | PartialSpecification FullSpecification ::= "{" TypeConstraints "}" PartialSpecification ::= "{" "." "..ISO/IEC 8824-1:2003 (E) IElems ::= Intersections IntersectionElements ::= Elements | Elems Exclusions Elems ::= Elements Exclusions ::= EXCEPT Elements UnionMark ::= "|" | UNION INTERSECTION IntersectionMark ::= "^" | Elements ::= SubtypeElements | ObjectSetElements | "(" ElementSetSpec ")" SubtypeElements ::= SingleValue | ContainedSubtype | ValueRange | PermittedAlphabet | SizeConstraint | TypeConstraint | InnerTypeConstraints | PatternConstraint SingleValue ::= Value ContainedSubtype ::= Includes Type Includes ::= INCLUDES | empty ValueRange ::= LowerEndpoint "." TypeConstraints "}" TypeConstraints ::= | NamedConstraint NamedConstraint "..

.

.

telephone service. sound programme and other multimedia signals Protection against interference Construction. local line networks Switching and signalling Telegraph transmission Telegraph services terminal equipment Terminals for telematic services Telegraph switching Data communication over the telephone network Data networks and open system communications Global information infrastructure and Internet protocol aspects Languages and general software aspects for telecommunication systems Printed in Switzerland Geneva. 2003 . symbols. telegraphy.SERIES OF ITU-T RECOMMENDATIONS Series A Series B Series C Series D Series E Series F Series G Series H Series I Series J Series K Series L Series M Series N Series O Series P Series Q Series R Series S Series T Series U Series V Series X Series Y Series Z Organization of the work of ITU-T Means of expression: definitions. installation and protection of cables and other elements of outside plant TMN and network maintenance: international transmission systems. digital systems and networks Audiovisual and multimedia systems Integrated services digital network Cable networks and transmission of television. classification General telecommunication statistics General tariff principles Overall network operation. facsimile and leased circuits Maintenance: international sound programme and television transmission circuits Specifications of measuring equipment Telephone transmission quality. service operation and human factors Non-telephone telecommunication services Transmission systems and media. telephone installations. telephone circuits.

Sign up to vote on this title
UsefulNot useful