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

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

......... 47.................................................................................................................................................................................................................................................................................................................................................................................................................................. Notation for the embedded-pdv type ............................................................................................................................................ Constrained Types...................... Reserved words ............................................................................................................................................................. Notation for the external type................................................................................................................................................................1 components ..........20 11............................................................................................. Notation for the relative object identifier type ............................................................................................................................22 11..................................................................................................................................................................................................................................... Notation for set types ...............................................2 Single Value.................................................................................................................................................................................................................... X........................................................................................................................................................................................ Referencing type and value definitions ........................................................................................ Subtype elements........................ Single character lexical items...........3 Contained Subtype ............................................................................................................................................... Naming characters and collections defined in ISO/IEC 10646-1...................................................................... XML single tag end item...................................................................................... Generalized time....................................................................................................................................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 enumerated type ....................... Notation for sequence-of types........................................................... The character string types................................................................................................................................................................................ Notation to support references to ASN......................................................................... Notation for character string types .................................................................................................................... Definition of unrestricted character string types ..................................................................... XML boolean true item .... Notation for types defined in clauses 42 to 44 ................................................................................... Notation for the integer type.............................................................................................. Definition of types and values ............................ Notation for choice types................................ 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 selection types................... XML end tag start item .................................................................................... 47.....23 11...................................................................... XML boolean false item................................................... The object descriptor type .................11........................................................................................................................................................................................................................................................................ Definition of restricted character string types ........................................................ Notation for the bitstring type ...................... Notation for the real type........................................................................................................................................................................... Universal time .................. Notation for set-of types............................................................ Assigning types and values .............................................................................................................................................21 11..............................................................................................19 11.....25 11............................................................................................................................................................................................................................................................ XML tag names for ASN..........................................................................24 11........................................................................................................................................................................ 47.........................................................................1 General ........... Right version brackets.......................................................................................................................... Notation for sequence types ............................................................................................................ Notation for the octetstring type.................................... Canonical order of characters ..........................................................1 types....................................................................................................................................... iv ITU-T Rec...........................26 11................................ Notation for the boolean type ............. Notation for tagged types ................................. Notation for the null type .......................................................................................... Element set specification...............................................................................................680 (07/2002) ........................................................................................................................................... Notation for the object identifier type ....................

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

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

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

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

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

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

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

4.6.6.6. or that specified procedures are to be used to produce and process the contents. and can identify that version with a simple integer. 3.6. SEQUENCE. NOTE – Governing class is defined in ITU-T Rec. NOTE – ASN.6.1 does not support character transfer syntaxes which do not encode all character strings as an integral multiple of 8 bits.6. are not relevant.6. 3.1 module.28 extensible constraint: A subtype constraint with an extension marker at the outer level.6.13 choice types: Types defined by referencing a list of distinct types.6.681 | ISO/IEC 8824-2. 3.25 extension addition: One of the added notations in an extension series. SET. NOTE 1 – The source of this definition is ITU-R Rec.1 specification.6.19 element: A value of a governing type or an information object of a governing information object class. given knowledge of the type.14 3. 3. NOTE – Extension additions are both textually ordered (following the extension marker) and logically ordered (having increasing enumeration values.6. For set. It carries an identification of the abstract syntax (the type) of the abstract value being carried. as well as an identification of the encoding rules used to encode that abstract value. the various referenced type (and value) notations. 3. X. distinguable from all other values of the same type or information objects of the same class. respectively. 3.1 types. 3.26 extension addition group: One or more components of a set. or that is extensible through the use of set arithmetic with extensible sets of values. or constraint: A notation which can be used in association with a type. SET OF. 3.7. TF.460-5. to define a subtype of that type. or information objects of a governing class. ITU-R has also defined the acronym for Coordinated Universal Time as UTC.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.1 type. increasing tags). NOTE – For the purpose of specifying encoding rules.29 extension insertion point (or insertion point): The location within a type definition where extension additions are inserted. 3.21 embedded-pdv type: A type whose set of values is formally the union of the sets of values in all possible abstract syntaxes. 3. sequence or choice type that were added in a particular version of an ASN.6.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. and.1 specification that wishes to carry in its protocol an abstract value whose type may be defined externally to that ASN.6.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).12 character transfer syntax: Any transfer syntax for a character abstract syntax. 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. NOTE 2 – UTC and Greenwich Mean Time (GMT) are two alternative time standards which for most practical purposes determine the same time. which can provide alternative notations for built-in types (and values). 3.23 (ASN. sequence or choice type grouped within version brackets. 3. 3. An extension addition group is used to clearly identify the components of a set.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. DATA LINK ESCAPE (16) is an example of a control character that has been assigned a function in a communication environment. For enumerated types it is the addition of a single further enumeration. in the case of CHOICE alternatives.6.6.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. 3. X.15 component type: One of the types referenced when defining a CHOICE. 3.22 encoding: The bit-pattern resulting from the application of a set of encoding rules to an abstract value. This type can be used in an ASN. and which are not spacing characters. 3. each value of the choice type is derived from the value of one of the component types. Encoding rules also enable the values to be recovered from the representation.24 enumerated types: Simple types whose values are given distinct identifiers as part of the type notation.680 (07/2002) . sequence and choice types.ISO/IEC 8824-1:2003 (E) 3. For a constraint it is the addition of (only) one subtype element. all of which are values of a governing type.1) encoding rules: Rules which specify the representation during transfer of the values of ASN.6.6.20 element set: A set of elements. SEQUENCE OF. 3. each extension addition is the addition of either a single extension addition group or a single component type.

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

47).6.62 serial application (of constraints): The application of a constraint to a parent type which is already constrained.6.200 series and equivalent ISO/IEC Standards if needed.60 sequence types: Types defined by referencing a fixed. 3.1 definitions which cannot be reordered so that all types used in a construction are defined before the definition of the construction. a value of the set type need not contain a value of that component type.1 type. each value in the sequence-of type is an ordered list of zero.6.55 recursive definition (of a type): A set of ASN.1 types that are not normally determined at specification time. ordered list of types (some of which may be declared to be optional).6.680 (07/2002) . where the "FieldName" denotes either a type field or a variable-type value field. They do not necessarily provide unambiguous encodings for "open type notation". 3. 6 ITU-T Rec. 3. 3. list of types (some of which may be declared to be optional).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". 3.57 relative object identifier type: A simple type whose values are the set of all possible relative object identifiers. a value of the sequence type need not contain a value of that component type. 3. NOTE 2 – All ASN.54 real type: A simple type whose distinguished values (specified in clause 20) are members of the set of real numbers. one or more values of the component type. which carries values from ASN.1 encoding rules provide unambiguous encodings for the values of a single ASN.6. clause 14. NOTE – Where a component type is declared to be optional. unordered. 3.1 type.6.6. each value of the sequence type is an ordered list of values. NOTE – Recursive definitions are allowed in ASN. 3. X. and which governs the subtype notation. NOTE – The meaning of such terms can be obtained from the ITU-T Rec.1 is used in an OSI environment. NOTE – Where a component type is declared to be optional.58 restricted character string type: A character string type whose characters are taken from a fixed character repertoire identified in the type specification.6.681 | ISO/IEC 8824-2.6. X.6. NOTE – The result of serial application of constraints is not covered by the term "set arithmetic". X.660 | ISO/IEC 9834-1 permit a wide range of authorities to independently associate object identifiers with objects. BNF) used to specify ASN. one or more octets. 3.6. one from each component type.ISO/IEC 8824-1:2003 (E) NOTE – The rules of ITU-T Rec. and whose values are precisely the values of that component type. 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.52 parent type (of a subtype): The type that is being constrained when defining a subtype.1.6.6.6.6.59 selection types: Types defined by reference to a component type of a choice type.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. NOTE – The parent type may itself be a subtype of some other type.6. 3.49 octetstring type: A simple type whose distinguished values are an ordered sequence of zero. 3.56 relative object identifier: A value which identifies an object by its position relative to some known object identifier (see 3. X.51 open type notation: An ASN. NOTE 1 – The term "open type" is used synonymously with "open type notation" in the body of this Recommendation | International Standard. The terms are only applicable if ASN. 3.53 production: A part of the formal notation (also called grammar or Backus-Naur Form.2.6. one from each component type. intersection and set difference (use of EXCEPT) as specified in 46. 3. 3. 3. each value in the set type is an unordered list of values.64 set types: Types defined by referencing a fixed.1 notation used to denote a set of values from more than one ASN. 3. each octet being an ordered sequence of eight bits. NOTE 3 – The only notation in this Recommendation | International Standard which is an open type notation is the "ObjectClassFieldType" specified in ITU-T Rec.61 sequence-of types: Types defined by referencing a single component type.63 set arithmetic: The formation of new sets of values or information objects using the operations of union.

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

The new permitted sequence of lexical items is referenced in this Recommendation | International Standard by the name in 5. in order: a) b) c) a name for the new permitted sequence of lexical items. in combination with (and followed 8 ITU-T Rec.2.2. separated by the character | 5. 5.1 semantics of each sequence.3 Each production consists of the following parts. 5.ISO/IEC 8824-1:2003 (E) ECN ICD IEC ISO ITU-T OID OSI PER ROA UCS UTC XML Encoding Control Notation of ASN. and names each item. this Recommendation | International Standard uses a formal notation defined in the following subclauses. X. the characters ::= one or more alternative sequences of lexical items.2 5. 5.1 notation contains characters from the ASN.680 (07/2002) . NOTE – If the same sequence of lexical items appears in more than one alternative.1 Productions All lexical items are named (see clause 11).1.1. on one or several lines. and by specifying the ASN.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.1 Each alternative in a production (see 5. Each name is either the name of a lexical item.3 a) above. or is the name of a permitted sequence of lexical items defined and named by some other production.1 Recognized Operating Agency Universal Multiple-Octet Coded Character Set Coordinated Universal Time Extensible Markup Language 5 5.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. 5. Clause 11 specifies all the sequences of characters forming lexical items.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.1 character set specified in clause 10.2 A new (more complex) permitted sequence of lexical items is defined by means of a production. any semantic ambiguity in the resulting notation is resolved by associated text. as defined in 5.1. 5.2 Each use of the ASN. 5.c) is specified by a list of names.1 notation. This uses the names of lexical items and of permitted sequences of lexical items and forms a new named permitted sequence of lexical items. 5. and permitted sequences of lexical items are named.1.3.3.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.2.2.1 notation consists of a sequence of characters from the ASN.1 5.2.3 The alternative collections 5.3.1 character set grouped into lexical items.3.1 Notation General The ASN.3 The ASN.4 In order to specify the permitted sequences of lexical items.

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

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

then the decoder using type Y obtains an abstract value composed of: a) b) c) an abstract value of the extension root type. 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. The action that is taken in each situation is determined by the ASN. the decoding process never signals an error when either of the above situations (a or b) is detected. or of an unknown alternative in a choice type.1 and the Packed Encoding Rules of ASN. 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. NOTE – Frequently the action will be to ignore the presence of unexpected additional extensions.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. but may do so. The encodings in c) shall be capable of being included in a later encoding of a value of Y.1 satisfy all these requirements. X. while system B is using an extension-related type (type Y) that has two extension additions where each is an optional integer type. X. Y and Z may appear in any order in the extension series. 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. Further. then it is successfully decoded. or of an unexpected length or value of a type whose constraint is extensible.680 (07/2002) 11 . NOTE 1 – All variants of the Basic Encoding Rules of ASN. if so required by the application protocol.2 All ASN. That encoding shall be a valid encoding of a value of X. provided that the same transfer syntax is used on the subsequent transmission. delimited encoding for each extension addition (if any) that is in X but not in Y. 7 Extensibility requirements on encoding rules NOTE – These requirements apply to standardized encoding rules. Encodings specified using ECN may or may not provide such identification. 7. 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. 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.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 All ASN. NOTE 2 – PER and BER do not identify the version number in the encoding of an extension addition. In formal terms. Moreover. but also the values of all types that are extension-related to X. 7. if so required by the application. 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).692 | ISO/IEC 8825-3).3 All ASN. an abstract value of each extension addition that is present in both X and Y. an abstract syntax defined by the extensible type X contains not only the values of type X. A must be able to re-encode the value of X with a value present for the first integer type. and to use a default value or a "missing" indicator for expected extension additions that are absent. otherwise. or to some third party). then it is successfully decoded.1 specifier. 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. In all cases.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. NOTE – Types X. 7. followed by the second integer value received from B. ITU-T Rec. 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. Thus.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. or an unknown enumeration in an enumerated type. Encoding rules defined using ECN do not necessarily satisfy all these requirements.

To provide uniformity.1 specifications. There is no formal difference between use of tags from the other three classes. The presence of the three classes is largely for historical reasons.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.1 notation for a type definition shall be "Type" (see 16.2 8.ISO/IEC 8824-1:2003 (E) 8 8. Where application class tags are employed. followed by those with application class tags.1 Tags A tag is specified by giving a class and a number within the class.4 Table 1 summarizes the assignment of tags in the universal class which are specified in this Recommendation | International Standard. NOTE – It is not in general possible to interpret the value notation without knowledge of the type. followed by those with context-specific tags.2 Use of the ASN. 25-30 UNIVERSAL 23-24 UNIVERSAL 31-.5 Some encoding rules require a canonical order for tags. as a matter of user choice and style. within each class of tags. but guidance is given in E. the elements or alternatives shall appear in ascending order of their tag numbers. 8.3 The number is a non-negative integer.1 notation The ASN.12 on the way in which the classes are usually employed. 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.1 notation for a value of a type shall be "Value" (see 16. X. a canonical order for tags is defined in 8.7). Restrictions on tags assigned by the user of ASN.1 are specified in clause 30. NOTE – Clause 30 includes the restriction that users of this notation are not allowed to explicitly specify universal class tags in their ASN..6. b) 9 9. 12 ITU-T Rec. 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. The ASN. 8.1 9. specified in decimal notation. 8. private.680 (07/2002) .1). application.. context-specific.2. a private or context-specific class tag could generally be applied instead. The class is one of: – – – – universal. followed by those with private class tags.

ITU-T Rec.680 (07/2002) 13 . identifier (see 11. 9.1). This is to allow valid ASN. . "ParameterizedTypeAssignment" (see ITU-T Rec. Table 2 – ASN. additional characters may appear in the following lexical items: – – – typereference (see 11.6).1). X. 9.14).2). 10.4).1 notation for assigning a value to a value reference name shall be either "ValueAssignment" (see 15. 10 The ASN. 10.2 Where the notation is used to specify the value of a character string type. all characters for the defined character set can appear in the ASN. In Table 2.2).683 | ISO/IEC 8824-4. characters are identified by the names they are given in ISO/IEC 10646-1. – modulereference (see 11.3).2 and 10. surrounded by the QUOTATION MARK (34) characters (") (see 11. or "ParameterizedValueSetTypeAssignment" (see ITU-T Rec. / : .1 character set 10.2). 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.683 | ISO/IEC 8824-4.4 The ASN. 8.1 A lexical item shall consist of a sequence of the characters listed in Table 2 except as specified in 10.683 | ISO/IEC 8824-4. X. valuereference (see 11.2) or "ParameterizedValueAssignment" (see ITU-T Rec. 8.1 notation for assigning a type to a type reference name shall be either "TypeAssignment" (see 15.3.1 characters A to Z a to z 0 to 9 ! " & ' ( ) * .2). X.1 specifications to be written in various languages.3 The ASN.5 The production alternatives of the notation "Assignment" shall only be used within the notation "ModuleDefinition" (except as specified in NOTE 2 of 12.3 Additional (arbitrary) graphic symbols may appear in the "comment" lexical item (see 11. When additional characters are introduced to accommodate a language in which the distinction between upper-case and lowercase letters is without meaning. "ValueSetTypeAssignment" (see 15.1 notation.6). 8. X. < = > @ [ ] ^ _ { | } (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.ISO/IEC 8824-1:2003 (E) 9.5).

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

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

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. ones or white-space. an "xmlbstring" is distinguished from an "xmlhstring" or "xmlcstring" by the context in which it appears.12. In analysing an instance of use of this notation. EXAMPLE – Ab0196 11. 11.1 An "xmlhstring" shall consist of an arbitrary number (possibly zero) of the characters: 0123456789ABCDEFabcdef or white-space. EXAMPLE – 01101100 This sequence of characters is also a valid instance of "xmlhstring" and "xmlcstring".13. The leading digit of the exponent shall not be zero unless the exponent is a single digit. The decimal point can optionally be followed by a fractional part which is one or more digits. 11.680 (07/2002) .12 Hexadecimal strings Name of lexical item – hstring 11.). X.2 Each character is used to denote the value of a semi-octet using a hexadecimal representation. 11. The integer part. and optionally a decimal point (. 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. Any white-space characters that appear within a binary string item have no significance. 11.11 XML binary string item Name of item – xmlbstring An "xmlbstring" shall consist of an arbitrary number (possibly zero) of zeros.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.12.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.13 XML hexadecimal string item Name of item – xmlhstring 11.13.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. 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. 16 ITU-T Rec. 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. 11. Any white-space characters that appear within a hexadecimal string item have no significance.

any character whose ISO/IEC 10646-1 character code is in the range 65536 (10000 hex) to 1114111 (10FFFF hex).1 syntax is available (see clause 35). 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. (This ensures that the order of combining characters in the string value is unambiguously defined in the printed version. any character whose ISO/IEC 10646-1 character code is in the range 57344 (E000 hex) to 65533 (FFFD hex). 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). ITU-T Rec. Any spacing characters that appear immediately prior to or following the end of line in the "cstring" have no significance.14. 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". 11.680 (07/2002) 17 . Where spacing characters are included in the "cstring". or where the graphic symbols in the character repertoire are not unambiguous in a printed representation. 11.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. 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. or is a spacing character. or if the character repertoire contains multiple spacing characters of different widths. and thus a corresponding "cstring" should be printed as two characters and not as the single character é. Where a character string containing control characters needs to be denoted in a printed representation. inclusive. inclusive.15 XML character string item Name of item – xmlcstring 11.14 Character strings Name of lexical item – cstring 11.ISO/IEC 8824-1:2003 (E) 11. X. If the character set includes a QUOTATION MARK (34) 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. CARRIAGE RETURN (13). The "cstring" may span more than one line of text. the character string denoted by "cstring" may be ambiguous in that printed representation.13. In analysing an instance of use of this notation. any character whose ISO/IEC 10646-1 character code is in the range 32 (20 hex) to 55295 (D7FF hex). LINE FEED (10). NOTE 2 – The character string represented by a "cstring" consists of the characters associated with the graphic symbols and spacing characters. 11. inclusive. preceded and followed by a QUOTATION MARK (34) character ("). It shall not be overprinted with the characters with which it combines. 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. EXAMPLE 1 – " EXAMPLE 2 – The "cstring": "ABCDE " FGH IJK""XYZ" can be used to represent a character string value of type IA5String.3 Some instances of "xmlhstring" are also valid instances of "xmlbstring" and "xmlcstring".) EXAMPLE – Lower case "e" and the accent combining character are two characters in ISO/IEC 10646-1. an "xmlhstring" is distinguished from an "xmlbstring" or "xmlcstring" by the context in which it appears. alternative ASN.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).14.15.

15.9).15. NOTE – This does not include characters with decimal character codes 9.1 module. and can be used to represent all combinations of ISO/IEC 10646-1 characters.2 The characters "&" (AMPERSAND).8. If this character sequence is present in an abstract character string value being represented by the "xmlcstring".15. either directly.15.6). These escape sequences shall not contain white-space (see 11. 11.15. If this character sequence is present in an abstract character string value being represented by the "xmlcstring" in an ASN. When used within an instance of XML value notation in an ASN.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. shall contain only characters permitted by the governing character string type.693 | ISO/IEC 8825-4).680 (07/2002) .9)." respectively. it shall be represented by the character sequence in column 2 of Table 3. and all the letters in these character sequences are lowercase.1.5. they shall be represented in the "xmlcstring" by either a) b) the escape sequences specified in 11.6).15.1 module. When used within an instance of XML value notation in an ASN. or by using the escape sequences specified below. 18 ITU-T Rec.693 | ISO/IEC 8825-4).15. it may contain adjacent ASTERISK (42) and SOLIDUS (47) characters in any order. "<" (LESS-THAN SIGN) or ">" (GREATER-THAN SIGN) shall appear only as part of one of the character sequences specified in 11. then at least one of the adjacent HYPHEN-MINUS characters shall be represented by the escape sequences specified in 11.8.ISO/IEC 8824-1:2003 (E) NOTE – Additional restrictions are imposed by the requirement that the "xmlcstring".9). 10.7 When "xmlcstring" is used within an "XMLTypedValue" forming part of an XER encoding (see ITU-T Rec." or "&gt.4 or 11. and 13.8.4 If the characters "&" (AMPERSAND).". it shall not contain two adjacent HYPHEN-MINUS characters. These character sequences shall not contain white-space (see 11.15. NOTE 1 – An "xmlcstring" cannot be used to represent characters that are not present in ISO/IEC 10646-1. it may contain adjacent HYPHEN-MINUS (45) characters. X. then at least one of the adjacent ASTERISK and SOLIDUS characters shall be represented by the escape sequences specified in 11. 11.15. such as some of the control characters which can appear in GeneralString. 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.1.2) forming part of an XER encoding (see ITU-T Rec. "<" (LESS-THAN SIGN) or ">" (GREATER-THAN SIGN) are present in an abstract character string value being represented by "xmlcstring" (see 37.15. 11. X.6 When "xmlcstring" is used within an "XMLTypedValue" (see 15. nor can it represent characters which might be defined with ISO/IEC 10646-1 character codes above 10FFFF hex. X.3 An "xmlcstring" is used to represent the value of a restricted character string (see 37. in an instance of use. 11. it shall not contain adjacent ASTERISK and SOLIDUS characters (in any order).1 module. "&lt.15. or the escape sequences "&amp. 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. 11.

EXAMPLE – The "xmlcstring": ABCD&#233.1. 11.2)." (where n is the ISO/IEC 10646-1 character code in decimal notation) or of the form "&#xn.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.21 XML end tag start item Name of item – "</" This item shall consist of the sequence of characters: ITU-T Rec. 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.18 Ellipsis Name of lexical item – ".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. 11. the value of "n" will be greater than 65535 (FFFF hex). FGH&#xEE.1.1.. 11. 11.2).XYZ can be used to represent a character string value of type UTF8String. NOTE – This sequence does not contain white-space (see 11.2).1. These escape sequences shall not contain white-space (see 11." This lexical item shall consist of the sequence of characters: . 11. 11.JK&amp.6).15. X.2). 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. NOTE – This sequence does not contain white-space (see 11.17 Range separator Name of lexical item – ".1.2)." (where n is the ISO/IEC 10646-1 character code in hexadecimal notation)...680 (07/2002) 19 .." This lexical item shall consist of the sequence of characters: .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.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.. 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).ISO/IEC 8824-1:2003 (E) 11..

11. NOTE – This sequence does not contain any white-space characters (see 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.25.25.2).4 The character sequence in the "xmlasn1typename" item for the "ObjectClassFieldType" and for the "InstanceOfType" are specified in ITU-T Rec.1 types Name of item – xmlasn1typename 11.23 XML boolean true item Name of item – "true" 11.1 built-in type is a "TaggedType" then the type which determines the "xmlasn1typename" shall be "Type" in the "TaggedType" (see 30. If this is itself a "TaggedType".5 If the ASN.2 In analysing an instance of use of this notation.2 Table 4 lists the character sequences that are to form the "xmlasn1typename" for each of the ASN.681 | ISO/IEC 8824-2.1. 11.25 XML tag names for ASN.23.24. 11.5 shall be recursively applied.3 The "xmlasn1typename" for the "UsefulType"s (see 41. 11.1 This item shall consist of the sequence of characters: false 11. 11.2 In analyzing an instance of use of this notation. NOTE – This sequence does not contain any white-space characters (see 11. 11.24 XML boolean false item Name of item – "false" 11.1 and Annex C.1.1 built-in types listed in 16. 20 ITU-T Rec. The ASN.1 built-in type is identified in column 1 of Table 4 by its production name.1 This item shall consist of the sequence of characters: true 11.2. then this subclause 11. a "true" is distinguished from a "valuereference" or an "identifier" by the context in which it appears. 11.2). 11. 14.2). with no white-space before or after these character sequences.680 (07/2002) .23. The character sequence which shall be used for "xmlasn1typename" is identified in column 2 of Table 4.25.1) shall be the "typereference" used in their definition. X.24.1).1.1 This Recommendation | International Standard uses the item "xmlasn1typename" when ASN. a "false" is distinguished from a "valuereference" or an "identifier" by the context in which it appears.25.25.1 built-in types are to be used as XML tag names.ISO/IEC 8824-1:2003 (E) </ NOTE – This sequence does not contain any white-space characters (see 11.1.25. X.

25. 14. X." "@" "|" "!" "^" 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.10 and 14. IA5String) SEQUENCE SEQUENCE_OF SET SET_OF See 11." ".681 | ISO/IEC 8824-2.26 Single character lexical items "{" "}" "<" ">" ".g. ITU-T Rec." "(" ")" "[" "]" "-" ":" "=" """ "'" "" ".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. X.ISO/IEC 8824-1:2003 (E) Table 4 – Characters in xmlasn1typename ASN.5 SEQUENCE Characters in xmlasn1typename 11.680 (07/2002) 21 .

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)

11 When the referenced module has a non-empty "DefinitiveIdentifier". 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". when non-empty.ISO/IEC 8824-1:2003 (E) 12.15 When the "SymbolsImported" alternative of "Imports" is selected: a) Each "Symbol" in "SymbolsFromModule" shall either be defined in the module body. of the module denoted by the "GlobalModuleReference" in "SymbolsFromModule".10 When both a "modulereference" and a non-empty "AssignedIdentifier" are used in referencing a module. 12. c) 12.16 When the "empty" alternative of "Imports" is selected. or be present in the "Imports" clause. or "Objectset").13). 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. 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 "AssignedIdentifier". However. 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. and if there are no such "Symbol"s. NOTE 2 – An effect of c) and d) is that the statement IMPORTS.15).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. except that if it includes a non-empty "DefinitiveIdentifier". the "GlobalModuleReference" referencing that module shall not have an empty "AssignedIdentifier". and the "Symbol" is not defined in the referenced module.9 The "GlobalModuleReference" in a "SymbolsFromModule" shall appear in the "ModuleDefinition" of another module. then the empty alternative of "SymbolsExported" (not of "Exports") shall be selected.12 a).6). 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. NOTE 1 – This does not prohibit the same symbol name defined in two different modules from being imported into another module. NOTE – The "empty" alternative of "Imports" is included for backwards compatibility. every "Symbol" defined in the module or imported by the module may be referenced from other modules subject to the restriction specified in 12. 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. that "Symbol" name cannot be exported from A for import to another module B. 12. The use of alternative distinct names makes these names available for use in the body of the module (see 12. 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". ITU-T Rec. NOTE – The "empty" alternative of "Exports" is included for backwards compatibility. 12. "Object". "Type". the latter shall be considered definitive. then the "empty" alternative of "SymbolsImported" shall be selected.13 When either the "empty" alternative or the EXPORTS ALL alternative of "Exports" is selected.680 (07/2002) 25 . 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. 12. implies that the module cannot contain an "External<X>Reference". X. If there are no such "Symbol"s. "Objectclass".14 Identifiers that appear in a "NamedNumberList". if the same "Symbol" name appears more than once in the "Imports" clause of module A. or appears exactly once in the "SymbolsImported" alternative of "Imports". 12.

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

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

7 The "ComponentId" in each "ItemSpec" identifies a component of the type which has been identified by the "ItemId". set-of.1. It is provided for the purposes stated in 14. 14.1 module (or in a comment).T. sequence.9 The number form of "ComponentId" can be used only if the "ItemId" is a sequence-of or set-of type.* shall be an odd integer) which is used to state that if the number of components in b is odd. 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. and is required to be one of the "identifier"s of the "NamedType" in the "ComponentTypeLists" of that set or sequence. 14. 14.8 The "identifier" form of "ComponentId" can be used if the parent "ItemId" is a set or sequence type.1 module (see 12.ISO/IEC 8824-1:2003 (E) ComponentId ::= identifier | number | "*" NOTE – The AbsoluteReference production is not used elsewhere in this Recommendation | International Standard. It can also be used if the "ItemId" identifies a choice type.6 The "typereference" references any ASN. or choice type. 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. It cannot be used in any other circumstance.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. with the value "1" identifying the first instance of the type. 14.680 (07/2002) . the "DefinitiveIdentifier" unambiguously and uniquely identifies the module from which a name is being referenced. 14.5 When the first altenative of "DefinitiveIdentifier" is used as part of the "ModuleIdentifier". 14. b SET OF INTEGER } END the components of "T" could be referenced by text outside an ASN.if (@M.b. NOTE – In the following example: M DEFINITIONS ::= BEGIN T ::= SEQUENCE { a BOOLEAN. 15.0 is odd) then: -(@M.1 type defined in the module identified by "ModuleIdentifier". all components of b must be odd.10 The "*" form of "ComponentId" can be used only if the "ItemId" is a sequence-of or set-of. sequence-of.4 The "ModuleIdentifier" identifies an ASN.T.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.27). X.1 reserved word (see 11. It shall be the last "ComponentId" if the component it identifies is not a set. and is then required to be one of the "identifier"s of a "NamedType" in the "AlternativeTypeLists" of that choice type.b.1). such as: -. 15 15.

this would not be empty.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. If this is the "xmlasn1typename" item.3). specified by "ElementSetSpecs" (see clause 46). "ValueSet" is defined in 15. this is defined to be exactly equivalent to the use of the production: typereference "::=" Type "(" ElementSetSpecs ")" with the same "Type" and "ElementSetSpecs" specifications.3).1 reserved word (see 11.680 (07/2002) 29 . 15.4). 15. X.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". and shall be a notation for a value of the type defined by "NonParameterizedTypeName" (as specified in 15.7). 15. The "typereference" shall not be an ASN.8 The "ValueSetTypeAssignment" production expands into: typereference Type "::=" "{" ElementSetSpecs "}" For all purposes. and is governed by "Type" and shall be a notation for a value of the type defined by "Type" (as specified in 15. ITU-T Rec. and may be referenced as a type. of which there shall be at least one. and the second alternative could not be used.27).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. NOTE – If the "XMLValue" production was an "xmlcstring" containing only white-space. The value being assigned to the "valuereference" in the "XMLValueAssignment" is "XMLValue" (see 16. 15.1 built-in type in the corresponding row of Table 4 (see also 13.4 "XMLValue" is a notation for a value of a type if "XMLValue" is an "XMLBuiltinValue" notation for the type (see 16. then it identifies the ASN.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". 15.10).7.7.3 "Value" is a notation for a value of a type as specified in 16. including the application of encoding rules.

1 Definition of types and values A type shall be specified by the notation "Type": Type ::= BuiltinType | ReferencedType | ConstrainedType 16.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). X. Annex C 18 23 ITU-T Rec. are specified in the following places in this Recommendation | International Standard unless otherwise stated: 30 ITU-T Rec. The various "ReferencedType" notations.1 31 22 20 32 24 25 26 27 30 The referenced types of ASN.1 are specified by the notation "BuiltinType".680 (07/2002) . X. 14.681 | ISO/IEC 8824-2.681 | ISO/IEC 8824-2.3 21 17 36 28 33 19 34 ITU-T Rec. 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.2 The built-in types of ASN. X.ISO/IEC 8824-1:2003 (E) 16 16. and the way in which the type to which they refer is determined.

4 (for example. NOTE 2 – "XMLValue" is only used in "XMLTypedValue". <field1></field1>).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.1 41.1 can be specified by the notation "XMLBuiltinValue" (see 16.1.10) or "BuiltinValue".682 | ISO/IEC 8824-3). can be replaced by a single XML empty-element tag (<field1/>). in inner subtype constraints and in component relation constraints (see ITU-T Rec. sequence type or choice type in the value notation.5 This Recommendation | International Standard requires the use of the notation "NamedType" in specifying the components of the set types. X. except white-space inserted as permitted by 11.681 | ISO/IEC 8824-2. 14. clause 15 The "ConstrainedType" is defined in clause 45. The notation for "NamedType" is: NamedType ::= identifier Type 16. these two XML tags. 16. 16.4.6. 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.4 13.680 (07/2002) 31 . X. NOTE – If any white-space character.681 | ISO/IEC 8824-2. sequence types and choice types.2.ISO/IEC 8824-1:2003 (E) DefinedType UsefulType SelectionType TypeFromObject ValueSetFromObjects 16. and has no effect on the type. 16. is present between the final ">" character of the start tag and the initial "<" character of the end-tag. and any intervening white-space. X. clause 15 ITU-T Rec.1.8 If any part of the "XMLValue" production results in an XML start-tag immediately followed by an XML endtag. as listed in 16. X. 16.1 29 ITU-T Rec.6 The "identifier" is used to unambiguously refer to components of a set type.681 | ISO/IEC 8824-2. X. possibly separated by white-space inserted as permitted by 11. ITU-T Rec. the condition above is not satisfied. It is not part of the type.9 Values of the built-in types of ASN.

12 Regardless of whether or not a type is a "BuiltinType". 17 17. sequence type or choice type. It is used to unambiguously refer to the components of a set type. by the notation "XMLNamedValue". "ReferencedType" or "ConstrainedType". These productions are: NamedValue ::= identifier Value XMLNamedValue ::= "<" & identifier ">" XMLValue "</" & identifier ">" where the "identifier" is the same as that used in the "NamedType" notation. are specified in the following places (in this Recommendation | International Standard unless otherwise stated): DefinedValue ValueFromObject 13.680 (07/2002) . X.1 Notation for the boolean type The boolean type (see 3.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).1 ITU-T Rec. NOTE – The "identifier" is part of the notation.8 prohibits value notation used in a subtype constraint from referencing a value that is not in the extension root of the parent type. 32 ITU-T Rec. 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. NOTE – Subclause 46. number 1.6. as listed in 16. clause 15 16.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.681 | ISO/IEC 8824-2. its values can be specified by either a "BuiltinValue" or "ReferencedValue" of that type. 16.4) or explicit presence of an extension marker (see clause 6) in the definition of a type has no effect on the value notation. and the way in which the value to which they refer is determined.2 above. That is. The various "ReferencedValue" notations.11 The referenced values of ASN. X.2 The tag for types defined by this notation is universal class. or when used as part of an "XMLValue".14 The implied (see 12. it does not form part of the value itself. 16. 16.13 The value of a type referenced using the "NamedType" notation shall be defined by the notation "NamedValue".ISO/IEC 8824-1:2003 (E) 16.

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

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

B the base. ITU-T Rec.. In particular. the encoding in BER and PER provides a Binary-Coded Decimal (BCD) encoding if "base" is 10. any occurrence of a name that is both an "identifier" from the "Enumeration" and a reference name shall be interpreted as the "identifier".The associated mathematical real number is "mantissa" -. 20.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 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. 20.680 (07/2002) 35 . M.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. 20. NOTE – Encoding rules may define a different type which is used to specify encodings.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. base INTEGER (2|10). B and E: M x BE where M is called the mantissa. exponent INTEGER -. or may specify encodings without reference to the associated type. 20 20. and an encoding which permits efficient transformation to and from hardware floating point representations if "base" is 2.6 The value of a real type shall be defined by the notation "RealValue".Value of the associated sequence type The second and third alternatives of "NumericRealValue" shall not be used for zero values. base (10)}) can be used to restrict the set of values to base 10 abstract values (and similarly for base 2 abstract values).54) shall be referenced by the notation "RealType": RealType ::= REAL 20. .5 The associated type for value definition and subtyping purposes is (with normative comments): SEQUENCE { mantissa INTEGER. NOTE 2 – The notation REAL (WITH COMPONENTS { . X.6.ISO/IEC 8824-1:2003 (E) 19.10 Within an instance of value notation for an enumerated type.2 The real type has a tag which is universal class. XMLRealValue ::= XMLNumericRealValue | XMLSpecialRealValue XMLNumericRealValue ::= realnumber | "-" realnumber The second alternative of "XMLNumericRealValue" shall not be used for zero values. by the notation "XMLRealValue": RealValue ::= NumericRealValue | SpecialRealValue NumericRealValue ::= realnumber | "-" realnumber | SequenceValue SpecialRealValue ::= | PLUS-INFINITY MINUS-INFINITY -. number 9. and of any number with a finite character-decimal representation. or when used in an "XMLValue"..1 Notation for the real type The real type (see 3. 20. and E the exponent.

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

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

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

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

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

24. However. 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. "XMLSequenceValue".11 If DEFAULT occurs.680 (07/2002) 41 . which shall be a value notation for a value of the type defined by "Type" in the "NamedType" production sequence. an "ExtensionAdditionGroup" can be used with a single "ExtensionAddition". and all values are omitted. or the type notation was SEQUENCE{}.18 The "{" "}" or "empty" notation shall only be used if: a) b) all "ComponentType" sequences in the "SequenceType" are marked DEFAULT or OPTIONAL. 24. ITU-T Rec. Where a single "ExtensionAddition" is needed for an "ExtensionAdditions".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. X. These productions are: SequenceValue ::= "{" ComponentValueList "}" | "{" "}" ComponentValueList ::= NamedValue | ComponentValueList ". and shall be greater than the "number" in any preceding "ExtensionAdditionGroup" within an insertion point.15 A "VersionNumber" shall be used only if all "ExtensionAdditions"s and "ExtensionAdditionAlternatives"." NamedValue XMLSequenceValue ::= XMLComponentValueList | empty XMLComponentValueList ::= XMLNamedValue | XMLComponentValueList XMLNamedValue 24. number 16. then the value corresponding to the components within the bracketed "ComponentTypeList" that are not marked OPTIONAL or DEFAULT shall be present. thus the first added extension addition group will have a number greater than or equal to 2.. NOTE 1 – The convention used here is that the specification with no extension addition groups is version 1. 24. NOTE 2 – The restrictions on use of "VersionNumber" apply only within a single module and impose no constraints on imported types. NOTE – Sequence-of types have the same tag as sequence types (see 25. within the module are "ExtensionAdditionGroup"s or "ExtensionAdditionAlternativesGroup"s with "VersionNumber"s.17 The notation for defining a value of a sequence type shall be "SequenceValue". PER). 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. 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.16 All sequence types have a tag which is universal class.12 The value corresponding to an "ExtensionAdditionGroup" (all components together) is optional. 24. if such a value is present. NOTE 3 – Use of the "ExtensionAdditionGroup" production is recommended because: a) it can result in more compact encodings depending on the encoding rules (e. 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. 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). 24. 24. or when used as an "XMLValue".g. The "number" in each "VersionNumber" of an "ExtensionAdditionGroup" shall be greater than or equal to two. c) the syntax makes it clear which types in an "ExtensionAdditionList" must as a group be supported by an application. the omission of a value for that type shall be exactly equivalent to the insertion of the value defined by "Value".ISO/IEC 8824-1:2003 (E) 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.2).

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

and the "identifier" in the "XMLDelimitedItem" shall be that "identifier".8 XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList See 25. 25.ISO/IEC 8824-1:2003 (E) 25. then the second alternative of "XMLValueOrEmpty" shall be chosen to represent that value of the component.1).10 and 14. 25.1 types ASN. 14. 15.4 If the"XMLValue" for the component is "empty".6 shall be recursively applied. then this subclause 25.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. 15. then the "NonParameterizedTypeName" shall be that "typereference" or "ExternalTypeReference". X.681 | ISO/IEC 8824-2.681 | ISO/IEC 8824-2. Table 5 – "XMLSequenceOfValue" and "XMLSetOfValue" notation for ASN.680 (07/2002) 43 .5 The "XMLValueList" or "XMLDelimitedItemList" productions shall be used in accordance with column 2 of Table 5.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.6 XML value notation 25.9 XMLDelimitedItemList XMLValueList See ITU-T Rec.6 See ITU-T Rec. X. X.1).9 XMLDelimitedItemList XMLValueList XMLDelimitedItemList See ITU-T Rec. 25. If this is itself a "TaggedType". then this subclause 25. X.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. If this is itself a "ConstrainedType". X. 25. ITU-T Rec.681 | ISO/IEC 8824-2.10 The second alternative of "XMLDelimitedItem" shall be used if and only if the "SequenceOfType" contains an "identifier".6 XMLDelimitedItemList XMLDelimitedItemList XMLDelimitedItemList See ITU-T Rec.7 See 25.681 | ISO/IEC 8824-2.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).1). otherwise it shall be the "xmlasn1typename" specified in Table 4 corresponding to the built-in type of the component.11 If the first alternative of "XMLDelimitedItem" is used. C. where the "Type" of the component is listed in column 1. then if the component of the sequence-of type (after ignoring any tags) is a "typereference" or an "ExternalTypeReference".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.7 shall be recursively applied. 25. determines the 25.

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

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

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

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

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

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

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

the value and encoding of a message defined in a separate – and identified – protocol) that is embedded in a message. 32.ISO/IEC 8824-1:2003 (E) RelativeOIDComponents ::= NumberForm | NameAndNumberForm | DefinedValue XMLRelativeOIDValue ::= XMLRelativeOIDComponentList XMLRelativeOIDComponentList ::= XMLRelativeOIDComponent | XMLRelativeOIDComponent & ". number 11.1 Notation for the embedded-pdv type The embedded-pdv type (see 3. The starting point can be defined by comments associated with the type definition. and their semantics.2 This type has a tag which is universal class. 32.2. "NameAndNumberForm". "XMLNameAndNumberForm".32</OBJECT_IDENTIFIER> firstgroup ::= <RELATIVE_OID>4.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 node is identified by the earlier "RelativeOIDComponents"s (if any).6.2." & XMLRelativeOIDComponentList XMLRelativeOIDComponent ::= XMLNumberForm | XMLNameAndNumberForm 32. If there is no definition of the starting node within comments associated with the type definition. but this expansion is not used today. "XMLNumberForm".5 The "DefinedValue" of "RelativeOIDComponents" shall be of type relative object identifier.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. nor a node immediately beneath the root.3. This is why there is a restriction on the starting node.3</RELATIVE_OID> the relative object identifier: relOID RELATIVE-OID ::= {firstgroup room(4) socket(6)} or in XML value notation: relOID ::= <RELATIVE_OID>4.680 (07/2002) 51 . The starting node is required to be neither the root.19).4.3 to 31. Historically. and later "RelativeOIDComponents"s (if any) identify arcs from the later nodes. 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. 4 3 4 6} if the current root 33 33.56. Object identifier values are required (see 31. 33.10) to have at least two components. it meant "Embedded Presentation Data Value" from its use in the OSI Presentation Layer.11.29. X. and it should be interpreted as "embedded value". are defined in subclauses 31. 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. then it needs to be transmitted as an object identifier value in an instance of communication (see E. ITU-T Rec. NOTE – A relative object identifier value has to be associated with a specific object identifier value so as to unambiguously identify an object.4 The productions "NumberForm".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.

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

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

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

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.g. The ASN.1 Notation for character string types The notation for referencing a character string type (see 3.7. 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. "UnrestrictedCharacterStringValue" and "XMLUnrestrictedCharacterStringValue" are notations for an unrestricted character string value and they are defined in 40.3 The notation for a character string value shall be: CharacterStringValue ::= RestrictedCharacterStringValue | UnrestrictedCharacterStringValue XMLCharacterStringValue ::= XMLRestrictedCharacterStringValue | XMLUnrestrictedCharacterStringValue "RestrictedCharacterStringValue" and "XMLRestrictedCharacterStringValue" are defined in 37. 36 36.2. one or more characters from some specified collection of characters.15). 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).6.1.9 respectively. X. and for specification of characters using decimal or hexadecimal (see 11. The tag of the unrestricted character string type is specified in 40. 36. UTF8String and BMPString.11) shall be: CharacterStringType ::= RestrictedCharacterStringType | UnrestrictedCharacterStringType "RestrictedCharacterStringType" is the notation for a restricted character string type and is defined in clause 37.2 The tag of each restricted character string type is specified in 37. and ITU-T Rec. 37 Definition of restricted character string types This clause defines types whose values are restricted to sequences of zero.680 (07/2002) 55 .. and a name (e.8 and 37. which includes the ability to use escape sequences for certain special characters. "UnrestrictedCharacterStringType" is the notation for the unrestricted character string type and is defined in 40. UniversalString. this form is available only for IA5String.1.1 XML value notation for character string types uses the "xmlcstring" notation. NumericString) by which the type is referenced. 36. 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.

size. 156. 106. Where a synonymous name is defined in the notation. 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). 150. 153. In this case the character transfer syntax is identified by the object identifier value {joint-iso-itu-t asn1(1) basic-encoding(1)}. table number. 144. intensity. 56 ITU-T Rec. 165. 168 + SPACE + DELETE 1. NOTE 3 – The entries corresponding to these registration numbers provide the functionality of CCITT Rec. X. b) The ASN. 128.ISO/IEC 8824-1:2003 (E) c) the characters in the collection of characters used in defining the type. 6 + SPACE + DELETE All G sets + SPACE 6 + SPACE All G and all C sets + SPACE + DELETE See 37.2 Table 7 lists the characters which can appear in the NumericString type and NumericString character abstract syntax. Table 7 – NumericString Name Digits Space Graphic 0. 164. 165. T. X. 150.101.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. 102.100 and ITU-T Rec. 144. In this case the character transfer syntax is identified by the object identifier associated with those rules in ISO/IEC 10646-1. or the defining text clause. 87. 129. or other display characteristics are not significant. or by reference to ISO/IEC 10646-1. 164. 89. the defining registration number or table. this is listed in parentheses.16 Table 7 Table 8 6. 103. 73..680 | ISO/IEC 8824-1 clause Subclause 37. 126. NOTE 1 – The type-style. 153. 108. 13. 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. 107. Annex N.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. identification of a Note relating to the entry in the table. T. colour. the number of the universal class tag assigned to the type.6 See 37. 102. NOTE 2 – Register entries 6 and 156 can be used instead of 102 and 103. 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). where necessary. 168 + SPACE + DELETE 1. or ITU-T Rec. 72.680 (07/2002) . 37. 9 (space) 37. ..1 Table 6 lists the name by which each restricted character string type is referenced. 37.1 encoding rules for the built-in type NumericString. 87. 1. 126. and.

1 encoding rules for the built-in type PrintableString.. and can only be used in value notation for IA5String types. z 0.. Z a. "CharacterStringList". 37. 37. "Tuple" is only capable of defining a character string of length one. X. In this case the character transfer syntax is identified by the object identifier { joint-iso-itu-t asn1(1) basic-encoding(1) }. B. or "Tuple". 9 (space) ' ( ) + . In this case the character transfer syntax is identified by the object identifier associated with those rules in ISO/IEC 10646-1. RestrictedCharacterStringValue ::= cstring | CharacterStringList | Quadruple | Tuple CharacterStringList ::= "{" CharSyms "}" CharSyms ::= CharsDefn | CharSyms ". Annex A. 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. 1. UTF8String or BMPString types.ISO/IEC 8824-1:2003 (E) 37.. NOTE – Clause 38 defines an ASN.4 Table 8 lists the characters which can appear in the PrintableString type and PrintableString character abstract syntax. b. 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.. and can only be used in value notation for UniversalString. . b) The ASN.14).6 The characters which can appear in the UniversalString type are any of the characters allowed by ISO/IEC 10646-1. "Quadruple" is only capable of defining a character string of length one. . .680 (07/2002) 57 . 37.8 The "RestrictedCharacterStringValue" notation for the restricted character string types shall be "cstring" (see 11.7 Use of this type invokes the conformance requirements specified in ISO/IEC 10646-1..1 module containing a number of subtypes of this type for the "Collections of graphics characters for subsets" defined in ISO/IEC 10646-1. . "Quadruple".. Annex N. / : = ? 37." CharsDefn ITU-T Rec.

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

1 are exported and must be imported by any module that uses them.12} {0. 0} {0.1 38. 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.11} {0.All of the value references and type references defined within this -.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. 6} {0. 37. 38. 5} {0. 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. NOTE – These values are available for use in the value notation of the UniversalString type and types derived from it. it is not defined in ASN1-CHARACTER-MODULE. GraphicString. Annex A. where each name references a UniversalString value of size 1. 8} {0. 2} {0.680 (07/2002) 59 .15} {1. BMPString is a subtype of UniversalString that has its own unique tag and contains only the characters in 37. All of the value and type references defined in the module specified in 38. and the "number" in the "TableRow" production shall be in the range zero to fifteen. This module also contains the definition of a type reference name for each collection of characters from ISO/IEC 10646-1.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.10} {0. 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).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. and are available for import by any module. 38 Naming characters and collections defined in ISO/IEC 10646-1 This clause specifies an ASN. 4} {0. NOTE – The encoding of UTF8String used by BER and PER is different from that of UniversalString. 1} {0. 7} {0.14 The "number" in the "TableColumn" production shall be in the range zero to seven. 3} {0. NOTE 3 – In the value notation all BMPString values are valid UniversalString and UTF8String values. X. Careful text on conformance is also needed for bounded but large character string types such as TeletexString.1 built-in module which contains the definition of a value reference name for each character from ISO/IEC 10646-1. It has an associated type defined as: UniversalString (Bmp) where Bmp is defined in the ASN. and UniversalString without the application of constraints. -.module are implicitly exported. and for most text will be less verbose. 1} The module is not printed here in full. Instead. less cells whose encoding is used to address characters outside the Basic Multilingual Plane) of ISO/IEC 10646-1.14} {0.1 Specification of the ASN. 9} {0. NOTE 1 – Since BMPString is a built-in type.15 the Basic Multilingual Plane (those corresponding to the first 64K-2 cells.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. the means by which it is defined is specified.13} {0.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. 0} {1. where each name references a subset of the UniversalString type. 37. ITU-T Rec.

2} {1. (See the tutorial in Annex F.and so on | tilde) ) 60 ITU-T Rec..represents the character LATIN CAPITAL LETTER A. see ISO/IEC 10646-1 greekCapitalLetterSigma BMPString ::= {0. <namedcharacter> is a string obtained by applying to <iso10646name> the procedures specified in 38. The resulting type reference. 5} {1. 0.. X.and so on ::= {0.) NOTE – A limited subset is a list of characters in a specified subset. 0.11} {1. where: a) b) c) <collectionstring> is the name for the collection of characters assigned in ISO/IEC 10646-1.15} 38. ::= {0. see ISO/IEC 10646-1 <iso10646name> is the character name derived from one listed in ISO/IEC 10646-1. 9} {1. 0.represents the character <iso10646name>..14} {1. 8} {1. which is a collection of characters listed in ISO/IEC 10646-1. 0. -..10} {1.1. <namedcollectionstring>. plus the BASIC LATIN collection.2. 0. Annex A.represents the character GREEK CAPITAL LETTER SIGMA. <alternativelist> is formed by using the <namedcharacter>s as generated in 38.2 for each of the characters specified by ISO/IEC 10646-1. Contrast this to a selected subset. EXAMPLE (partial) space BMPString exclamationMark BMPString quotationMark BMPString . forms a limited subset. <namedcollectionstring> is formed by applying to <collectionstring> the procedures of 38.represents the collection of characters <collectionstring>.1. 0. 0. 38. -. 3.680 (07/2002) . 3} {1. 7} {1. 0.15} {7. 0. -. ::= {0. Annex A. <tablecell> is the glyph in the table cell in ISO/IEC 10646-1 corresponding to the list entry.12} {1.see ISO/IEC 10646-1. 0. 163} -. 32} 33} 34} 126} BasicLatin ::= BMPString (FROM (space | exclamationMark | quotationMark | .3.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.13} {1. see ISO/IEC 10646-1 where: a) b) c) EXAMPLE latinCapitalLetterA BMPString ::= {0. the module includes a statement of the form: <namedcharacter> BMPString ::= <tablecell> -. 65} -. 4} {1. a statement is included in the module of the form: <namedcollectionstring> ::= BMPString (FROM (<alternativelist>)) -. tilde BMPString ::= {0.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. 0.3 For each name for a collection of graphic characters specified in ISO/IEC 10646-1. 6} {1.

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

PrintableString. the canonical ordering. 39. a character is in one-to-one correspondence with a cell in a code table.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. the canonical order of the cells is defined from the ISO/IEC 646 encoding (called ISO 646 ENCODING) as follows: (ISO 646 ENCODING) .1. VisibleString. 39. and whether it is a control character or printing character. is defined (see Table 7 of 37.1 For the purpose of "ValueRange" subtyping and for possible use by encoding rules. 39. 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. Otherwise. BMPString. increasing from left to right. a canonical ordering of characters is specified for UniversalString. this abstract syntax may be part of the OSI defined context set.32 NOTE – That is. 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. with low numbers appearing first and high numbers appearing last in the canonical order. whether that cell has been assigned a character name or shape. it is referenced directly for each instance of use of the unrestricted character string type. X.1) . the canonical order is the same as the characters in cells 2/0-7/14 of the ISO/IEC 646 code table.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.1 OBJECT IDENTIFIERs. NOTE – This order is the same as the order of the corresponding characters in the BASIC LATIN collection of ISO/IEC 10646-1. the canonical ordering. combining or non-combining character. or by use of the "Quadruple" or "Tuple" notation of 37.4 Endpoints of "ValueRanges" within "PermittedAlphabet" notations (or individual characters) can be specified using either the ASN. 62 ITU-T Rec. and IA5String. NOTE 1 – A character abstract syntax (and one or more corresponding character transfer syntaxes) can be defined by any organization able to allocate ASN. NOTE – This order is the same as the order of the corresponding characters in the BASIC LATIN collection of ISO/IEC 10646-1.680 (07/2002) . 40 Definition of unrestricted character string types This clause defines a type whose values are the values of any character abstract syntax. increasing from left to right and top to bottom.8. 39. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring".7 For PrintableString. 39. UTF8String. 39 Canonical order of characters 39.6 For NumericString. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring". is defined (see Table 8 of 37.1. The entire character set contains precisely 95 characters. In an OSI environment. The endpoint of a "ValueRange" (or individual characters) can be specified using the graphic symbol in a "cstring".8 For VisibleString.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.9 For IA5String.2 For the purpose of this clause only.2) as: (space) 0 1 2 3 4 5 6 7 8 9 The entire character set contains precisely 11 characters. 39. 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. NumericString.

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

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

the value of UTCTime is either of: – – 43. and ss is seconds (00 to 59).1. the time (t1) specified by a) and b) above is the local time.3.5 "0101021200Z". 44 44. where hh is hour and mm is minutes.680 (07/2002) 65 .3. using ASN. either: The alternatives in b) above allow varying precisions in the specification of the time. and the character Z. MM is the month (counting January as 01).3 The type is defined. 42. and DD is the day of the month (01 to 31). or "0101020700-0500".1 The object descriptor type This type shall be referenced by the name: ObjectDescriptor 44.4 43. with local time 5 hours retarded in relation to coordinated universal time. or "8201020700-0500". 43 43. The value notation shall be the value notation for the VisibleString defined in 42. or the six digits hhmmss where hh and mm are as in 1) above.3. followed by hhmm. In alternative c) 1). ITU-T Rec.1 43. 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 text is not an unambiguous identification of the object. EXAMPLE 2 – If local time is 7am on 2 January 2001 and coordinated universal time is 12 noon on 2 January 2001. 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.2 Universal time This type shall be referenced by the name: UTCTime The type consists of values representing: a) b) c) calendar date. 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 -. and time to a precision of one minute or one second. and (optionally) a local time differential from coordinated universal time. the value of UTCTime is either of: – – "8201021200Z". The tag shall be as defined in 43.4 42.3.5 The tag shall be as defined in 42. 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). 43.2 The type consists of human-readable text which serves to describe an object. X. In alternative c) 2).ISO/IEC 8824-1:2003 (E) "19851106210627.3-0500" local time as in example a). the time is coordinated universal time.

5. the constraint is "Constraint" (see 45. not the SEQUENCE OF: NamesOfMemberNations ::= SEQUENCE OF VisibleString (SIZE(1.6. T ::= CHOICE { a SEQUENCE { a INTEGER OPTIONAL. 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". and in the seventh and eighth is "SEQUENCE OF NamedType". 45. It also allows an exception identifier to be associated with a constraint. while in the second. the interpretation of the overall notation is the same regardless of whether the "TaggedType" or the "Type" is considered as the parent type..680 (07/2002) . using ASN. in the following the constraint (SIZE(1..3 When the "Constraint" notation follows the selection type notation. 44. b BOOLEAN }. fifth and seventh alternatives.64)) applies to the VisibleString. third.4 44. Such a constraint is ignored (see 29.2 When the "Constraint" notation follows a set-of or sequence-of type notation. 66 ITU-T Rec. it applies to the "Type" in the (innermost) set-of or sequence-of notation.3. it applies to the choice type. b NULL } V ::= a < T (WITH COMPONENTS {.. ConstrainedType ::= Type Constraint | TypeWithConstraint In the first alternative. not to the set-of or sequence-of type.64)) 45. The second alternative is defined in 45. NOTE – In the following example. 45.2. the constraint (WITH COMPONENTS {.1.1 The "ConstrainedType" notation allows a constraint to be applied to a (parent) type. In the fifth and sixth alternatives the parent type is "SET OF NamedType".5).. sixth and eighth it is "SizeConstraint" (see 47.5 The tag shall be as defined in 44.. a ABSENT}) 45.5 As a consequence of the interpretation specified in 45. NOTE – For example.6). 44. and has no effect on the values of V. 45 Constrained types 45. and the constraint is specified by "Constraint" as defined in 45.4 When the "Constraint" notation follows a "TaggedType" notation. and not to the type of the selected alternative. while in the third and fourth it is "SEQUENCE OF Type". a ABSENT}) applies to the CHOICE type T... The value notation shall be the value notation for the GraphicString defined in 44. In the first. not to the selected SEQUENCE type.. special notation is provided to allow a constraint to be applied to a set-of or sequence-of type. the parent type is "Type".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.3 The type is defined. 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.2).3. X. fourth. as follows: ObjectDescriptor ::= [UNIVERSAL 7] IMPLICIT GraphicString The GraphicString contains the text describing the object.

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

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

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

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.680 (07/2002) . 47. NumericString. IA5String. "Type" is required to be derived from the same built-in type as the parent type. 47. 47. UTF8String and UniversalString.3. VisibleString. 47.3 47.1 Single value The "SingleValue" notation shall be: SingleValue ::= Value where "Value" is the value notation for the parent type.2 A "SingleValue" specifies the single value of the parent type specified by "Value".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.3. PrintableString.2.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. X.2 47.2 A "ContainedSubtype" specifies all of the values in the root of the parent type that are also in the root of "Type". 70 ITU-T Rec.

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

680 (07/2002) .7 47.7. The set of values in the root are those permitted by the root of "Constraint". X. NOTE – An "InnerTypeConstraints" applied to a set or sequence type is ignored by the COMPONENTS OF transformation (see 24. sequence-of.8.8.1 Type constraint The "TypeConstraint" notation shall be: TypeConstraint ::= Type 47." ".1 Inner subtyping The "InnerTypeConstraints" notation shall be: InnerTypeConstraints ::= | WITH COMPONENT SingleTypeConstraint WITH COMPONENTS MultipleTypeConstraints 47. a number of constraints on these inner types can be provided. then the set of values selected by the permitted alphabet constraint is extensible. The inner type to which the constraint applies is identified by means of its identifier.4 and 26.8 47. set.7.2 This notation is only applied to an open type notation and restricts the open type to values of "Type".6. there shall be at most one "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. This notation can only be applied to restricted character string types. except that it shall use the "SubtypeConstraint" alternative of "ConstraintSpec".3 The "Constraint" is any which could be applied to the parent type (see Table 9).7. 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". For a sequence type.. excluding those values already in the root. and the extension additions are those values permitted by the root together with the extension-additions of "Constraint". 47. The notation for this is "MultipleTypeConstraints": MultipleTypeConstraints ::= FullSpecification | PartialSpecification FullSpecification ::= "{" TypeConstraints "}" PartialSpecification ::= "{" ".. For a given component. 47. 47. a constraint taking the form of a subtype value specification is provided. set.5 The "TypeConstraints" contains a list of constraints on the component types of the parent type. A value of the parent type is not specified unless it satisfies all of the constraints expressed or implied (see 47. sequence and choice types.8. 72 ITU-T Rec.8." TypeConstraints "}" TypeConstraints ::= NamedConstraint | NamedConstraint ".1 Permitted alphabet The "PermittedAlphabet" notation shall be: PermittedAlphabet ::= FROM Constraint 47.4 If "Constraint" is extensible. the constraints must appear in order.2 A "PermittedAlphabet" specifies all values which can be constructed using a sub-alphabet of the parent string.7." TypeConstraints NamedConstraint ::= identifier ComponentConstraint 47.6.6 47. 47.6).ISO/IEC 8824-1:2003 (E) 47. This notation can be applied to the set-of. and sequence). 47. 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.8.8. 47. The notation for this is "SingleTypeConstraint": SingleTypeConstraint ::= Constraint The "Constraint" defines a subtype of the single other (inner) type.2).3 For the types which are defined in terms of a single other (inner) type (set-of and sequence-of).4 For the types which are defined in terms of multiple other (inner) types (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.2 "Value" shall be a "cstring" of type UniversalString (or a reference to such a character string) which contains an ASN.ISO/IEC 8824-1:2003 (E) 47. the extension marker has no effect on some encoding rules of ASN.1 regular expression.8.3 The meaning of an empty "PresenceConstraint" depends on whether a "FullSpecification" or a "PartialSpecification" is being employed: a) b) in a "FullSpecification". 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). 47.8.1 If the parent type is a sequence or set. and any inner type can be omitted from the list. Thus a totally equivalent definition could have been to say that "Value" is a value of type UTF8String. NOTE – "Value" is formally defined as a value of type UniversalString.8. such as the Basic Encoding Rules.8.8. and the situations in which they are permitted are defined in 47.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. 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). its value. Its effect on encodings defined using ECN is determined by the ECN specification.3. there is an implied presence constraint of ABSENT on all inner types which can be constrained to be absent (see 47.1 regular expression.9) and which is not explicitly listed.. 47. 48. but the sets of values of type UniversalString and UTF8String are the same (see 37.1 regular expression as defined in Annex A. or both.9.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). i.7 A particular inner type may be constrained in terms of its presence (in values of the parent type). The "PatternConstraint" selects those values of the parent type that satisfy the ASN.8.680 (07/2002) 73 . It is recommended that this notation be used in those situations where store and forward or ITU-T Rec. there shall be at most one PRESENT keyword in a "MultipleTypeConstraints". in a "PartialSpecification". but does on others. ellipsis.8.1 The extension marker.9. 47. 47. X. The notation is "ComponentConstraint": ComponentConstraint ::= ValueConstraint PresenceConstraint 47.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.9.9. The entire value shall satisfy the entire ASN.6 for a clarifying example. 47.6 The "MultipleTypeConstraints" comprises either a "FullSpecification" or a "PartialSpecification".9. such as the Packed Encoding Rules. no constraint is imposed. the "PatternConstraint" does not select values whose leading characters match the (entire) ASN. When "FullSpecification" is used. there are no implied constraints.1 to 47.16).9 47. 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.8. Where "PartialSpecification" is employed.e. this is equivalent to a constraint of PRESENT for a set or sequence component marked OPTIONAL and imposes no further constraint otherwise. 47. 48 The extension marker NOTE – Like the constraint notation in general.2 If the parent type is a choice.1.1 regular expression but which contain further trailing characters.8. 48. NOTE – See E.9.9.4. is an indication that extension additions are expected.8.

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

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

ISO/IEC 8824-1:2003 (E) 49. 49. 76 ITU-T Rec. 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. the exception identifier in the outermost constraint shall be regarded as the exception identifier for that type. more than one of which has an exception identifier. X.680 (07/2002) . 49.5 Where a type is constrained by multiple constraints.6 Where an exception marker is present on types that are used in set arithmetic.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.

6 Match the CARRIAGE RETURN (13) character (see 11. \d \w \t \n \r \s \b \ \\ "" | ( ) * + ? #n #(n) #(n. ITU-T Rec. are regular expressions that match themselves.m) #(. A "^" after the opening bracket complements the set which follows it. it is constructed analogously to arithmetic expressions. A.2. 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. including all letters and digits.c} \N{name} . EXAMPLE The regular expression "fred" matches only the string "fred".1.) #(n.3 Two regular expressions may be concatenated.1. The following list contains all of the metacharacter sequences. where some other examples of use can be found. Quadruple which identifies a character of ISO/IEC 10646-1 (see 37.8) Match the named character (or any character of the named character set) 38.1. A.1.p.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.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. A regular expression is itself a string.6) Match any one of the newline characters defined in 11. by using various operators to combine smaller expressions.1.1.r.1.1 Definition A.1 regular expression is a pattern that describes a set of strings whose format conforms to this pattern. are placeholders that stand for a set of characters. [ ] {g.2 Metacharacters A.1 Match any character (unless it is one of the newline characters defined in 11.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. which are (usually) made of one or two characters. The regular expressions presented here are very similar to those of scripting languages like Perl and to those of XML Schema.ISO/IEC 8824-1:2003 (E) Annex A ASN.m) Match any character in the set where ranges are denoted by "-".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. 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. A. Their meaning is explained in the following clauses. The smallest expressions.2 Most characters.680 (07/2002) 77 .2.1.6) Match any one of the white-space characters (see 11.1 An ASN.2. X.

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

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

1? B. D. d. or C. white(1).a) are all valid given the definitions in B. or F. It is not intended to provide a definition of valid transformations of ASN.4 Some of the above examples are cases which. however.1 The need for the value mapping concept (tutorial introduction) Consider the following ASN.. blue(2). green(3). white(1)..1 and what is not.1 definitions: A ::= INTEGER B ::= [1] INTEGER C ::= [2] INTEGER (0.. b. It is present in order to clearly specify what is legal ASN.1. purple(4)} ::= green W ::= SEQUENCE { w1 INTEGER {red(0). are the resulting statements legal? B. 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. would the resulting statements be illegal? Similarly.1 B. B. However. purple(4)} a A ::= 3 b B ::= 4 c C ::= 5 d D ::= 6 e E ::= 7 f F ::= green B. white(1).. green(3). and F. blue(2).1 notations for any purpose other than those stated above. E. Would the above be legal ASN. or E. C.1. green(3).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. or e. even if legal (as most of them are – see later text)..1.20) F ::= INTEGER {red(0). users would be ill-advised to write similar text. white(1).6..1.f) Y ::= INTEGER {red(0).1. green(3). or D.. as they are at the least obscure and at worst confusing. For example: W ::= SEQUENCE {w1 A DEFAULT a} and: x A ::= a and: Y ::= A(1.. X. blue(2).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. and to be able to specify the precise value that any value reference name identifies. respectively.2 It is clear that the value references a. If. blue(2).680 (07/2002) . green(3). c.. DEFAULT f} x INTEGER {red(0).1. or d. blue(2).. if the value reference a above were replaced in each of these cases by b. and the precise set of values that any type or value set reference name identifies. Consider for example: f INTEGER {red(0).. or f.7) E ::= INTEGER (7. purple(4)} purple(4)} ::= f purple(4)}(1.. e. or c. and f can be used in value notation governed by A. white(1).) D ::= [2] INTEGER (0. A above were replaced by B. B.6.

..680 (07/2002) 81 .. and can be used in place of a direct reference f1 where we would otherwise have to define: f1 F ::= 5 ITU-T Rec..20) F ::= INTEGER {red(0). M appings red(0) blue(2) white(1) . provided a value mapping exists between that value in C and a (single) value in F. purple(4)} In each case a new type is being created. blue(2)..) E ::= INTEGER (7.. 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.2.. C.. Moreover. 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.. consider: C ::= [2] INTEGER (0. X.ISO/IEC 8824-1:2003 (E) with tagging or subtyping applied in the governor.1.5 Again.. . B. white(1)..6. then. and E all have (1-1) mappings to values of INTEGER. C. where the value reference c is used to identify a value in F. Integer . This is illustrated for F and C in Figure B. .1.1 B. and E themselves. we can clearly identify a 1-1 correspondence between the values in them and a subset of the values in the universal type INTEGER.... In the case of C and E.. For F we can clearly identify a 1-1 correspondence between the values in it and the values in the universal type INTEGER. we can use these mappings to provide mappings between the values of F. We call this relationship a value mapping between values in the two types. because values in F.1. we can (and do) define c to be a legal reference to the value in F.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.. green(3).. This is illustrated in Figure B.

for all values x1 in X1.1 for example) that have value mappings to values in another type (7 to 20 in E of B.1 for example). Subclause B. then there automatically exists a value mapping from x2 to x1). and a value mapping from x2 to x3. with other values in both types that are unmapped. 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. if there is a value mapping from x1 to x2.2. id OBJECT IDENTIFIER}. following DEFAULT). but other values (21 upwards of A) that have no such mapping.2 In the set of all possible ASN. and x2 in X2. however. normal English text is used to specify legality in the above and similar cases. In the general case. or CHOICE {int INTEGER.2 Value mappings B. This annex specifies when value mappings exist between such types. The whole set of value mappings is a mathematical relation.1. B. given any two types X1 and X2. and it is transitive (if there is a value mapping from a value x1 to x2. so any value reference to a value of X can be used when governed by Y (for example.. (These examples are not intended to be exhaustive. This relation possesses the following properties: it is reflexive (each ASN. and not for more complex "Type" constructs. as non-overlapping containers. a value mapping relates a pair of values. but value mappings exist between these types.2 B.) It is. B.ISO/IEC 8824-1:2003 (E) f red(0) white(1) .1 standards.8 In the body of the ASN...7 It should be noted that in some cases there will be values in one type (7 to 20 in A of B.1 values...2). A reference to such values in A would not provide a valid reference to a value in E.) B.2.1. the set of value mappings from values in X1 to values in X2 is a one-to-one relation. and ITU-T Rec.1 value is related to itself).3 Furthermore. with every occurrence of the ASN. there may be a subset of values in both types that have mappings.2. then there automatically exists a value mapping from x1 to x3).6 gives the precise requirements for legality and should be referenced whenever there is doubt about a complex construction..1 and B. (In this example.1.1 "Type" construct defining a distinct new type (see Figures B. recommended that advantage be taken of this freedom only for simple cases such as SEQUENCE OF INTEGER.1 The underlying model is of types.680 (07/2002) .1. it is symmetric (if a value mapping is defined to exist from a value x1 to a value x2. 5 f1 blue(2) . then: a) 82 there is no value mapping from x1 to another value in X2 different from x2. that is. 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. that contain values. X. seen as sets of values. 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. the whole of E has a value mapping to a subset of A. 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. B. EXAMPLE: Consider: X ::= INTEGER Y ::= INTEGER X and Y are type reference names (pointers) to two distinct types. enabling a reference to a value in one type to be used where a reference to a value in some other type is needed.

if any. is reordered so that the "identifiers" are in alphabetical order ("a" first. the keyword IMPLICIT is added to all instances of "Tag" (see clause 30) unless either: • • • • it is already present. "ExtensionAdditions".3.2.3. their normal forms are identical ordered lists of the same lexical items (see clause 11). to any "EnumerationItem" (see 19.3. "OptionalExtensionMarker". X. b) c) d) e) f) g) If "TagDefault" is AUTOMATIC TAGS.1).2 (the automatic tagging will be performed later on). it is an open type. if present. B. For each relative object identifier value (see 32. and where the existence of these value mappings is never used in determining the legality of the total specification.3 and 26. and only if. is ITU-T Rec. but it is recommended that ASN. as specified in 19.2. in any order: a) For a type defined by a "ValueSetTypeAssignment". h) IMPLIED. B.. 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".1 B. 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.3. is removed. a value reference to either one can automatically be used to reference the other if so required by some governing type. "OptionalExtensionMarker". "z" last). For sequence types (see clause 24) and set types (see clause 26): any extension of the form "ExtensionAndException". For each bitstring type: the "NamedBitList" (see 21. The two instances of "Type" are defined to be identical type definitions if.3.6 in that order.1 notation.6) are removed. In order to give precision to the meaning of "sufficiently similar".4 Where a value mapping exists between a value x1 and a value x2.2. "z" last).1 constructs. "z" last). 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.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. is reordered so that the "identifier"s are in alphabetical order ("a" first.2 All the comments (see 11.ISO/IEC 8824-1:2003 (E) b) there is no value mapping from any value in X1 (other than x1) to x2.1 to B..6.1). 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. B. or the type being tagged is a CHOICE type or.3.12).3 Identical type definitions B. For each integer type: the "NamedNumberList" (see 18. then the "RootEnumeration" is reordered so that the "identifiers" are in alphabetical order ("a" first. The existence of such mappings carries no implications whatsoever that the two types carry the same application semantics. Note that value mappings will frequently exist in any large specification between two types that are identical ASN.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.1) that is an "identifier" (without a number).3.") 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. "z" last). but which carry totally different application semantics. The normal form is obtained by applying the transformations defined in B. the decision on whether to apply automatic tagging is taken according to 24. NOTE – Subclauses 24.2.680 (07/2002) 83 .1 specification is an ordered list of the lexical items defined in clause 11. For each enumerated type: numbers are added. If "TagDefault" is IMPLICIT TAGS. if present.2 Each occurrence of "Type" in an ASN. is cut and pasted to the end of the "ComponentTypeLists". an ellipsis (". B. if any. or the reserved word EXPLICIT is present.2.3): each "RelativeOIDComponents" is transformed into its corresponding "NumberForm" in accordance with the semantics of clause 32. The following transformations are not recursive and hence need only to be applied once. If "ExtensionDefault" is EXTENSIBILITY "ComponentTypeLists" if it is not present.

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

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

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

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

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

3 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) numericString(0) } Object Descriptor Value: "NumericString ASN.ASN.3) -numericString OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) numericString(0) } -.1 type" Subclause37.2 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) modules(0) object-identifiers(1) } Object Descriptor Value: "ASN.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.PrintableString ASN. NOTE – These values are available for use in the value notation of the OBJECT IDENTIFIER type and types derived from it.1 module for use in referencing those object identifier values.1 type" Subclause 38.680 (07/2002) 89 .1 Object identifiers assigned in this Recommendation | International Standard The following values are assigned in this Recommendation | International Standard: Subclause 37. ASN1-Object-Identifier-Module { joint-iso-itu-t asn1(1) specification(0) modules(0) object-identifiers(1) } DEFINITIONS ::= BEGIN -. X.1 series of Recommendations | International Standards.1 Character Module (see 38.1 standards (ITU-T Rec.1 module which contains the definition of a value reference name for each object identifier value defined in the ASN.1 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(0) } Object Descriptor Value: "ASN.1 Object Identifier Module" C.1 type (see 37.5 Object Identifier Value: { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) printableString(1) } Object Descriptor Value: "PrintableString ASN. X. X. and provides an ASN.693 | ISO/IEC 8825-4).680 | ISO/IEC 8824-1 to ITU-T Rec. C.ASN.2 Object identifiers in the ASN.1 type (see 37. 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.1) -asn1CharacterModule OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) modules(0) iso10646(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.5) -printableString OBJECT IDENTIFIER ::= { joint-iso-itu-t asn1(1) specification(0) characterStrings(1) printableString(1) } -.1 Character Module" Subclause C.1 and encoding rules standards This clause specifies an ASN.NumericString ASN.

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)

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

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

Illegal or using XML value notation: sunnyDaysLastWeek1 ::= <DaysOfTheWeek> <sunday/><monday/><wednesday/> </DaysOfTheWeek> ITU-T Rec. EXAMPLE G3FacsimilePage ::= BIT STRING -. wednesday(3). X.2. or specified elsewhere. or using XML value notation: map1 ::= <BitField>100110100100</BitField> Note that map1 and map2 are the same abstract value. tuesday(2). saturday(6) } (SIZE (0.3 Use a bit string type to model the values of a bit map. and whose length in bits is not necessarily a multiple of eight. EXAMPLE BitField ::= BIT STRING (SIZE (12)) map1 BitField ::= '100110100100'B map2 BitField ::= '9A4'H map3 BitField ::= '1001101001'B -Illegal . thursday(4). DaysOfTheWeek ::= BIT STRING { sunday(0). for the four trailing bits of map2 are not significant. 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).2.5. an ordered collection of logical variables indicating whether a particular condition holds for each of a correspondingly ordered collection of objects.violates size constraint.2.680 (07/2002) 97 .2.4. E. monday. friday(5).2 Use a bit string type with a size constraint to model the values of a fixed sized bit field.5 Bit string E. monday (1).a sequence of bits conforming to ITU-T Rec.. wednesday} sunnyDaysLastWeek2 DaysOfTheWeek ::= '1101'B sunnyDaysLastWeek3 DaysOfTheWeek ::= '1101000'B sunnyDaysLastWeek4 DaysOfTheWeek ::= '11010000'B -. E.ISO/IEC 8824-1:2003 (E) E. T.1 Use a bit string type to model binary data whose format and length are unspecified.5.7)) sunnyDaysLastWeek1 DaysOfTheWeek ::= {sunday.5.

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

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

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

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

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

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

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

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

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

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

X.&attributeId is fixed However. -.681 | ISO/IEC 8824-2). For example.this is normally Both ATTRIBUTE. or specified elsewhere with no restriction on the notation used to specify the type.680 (07/2002) .1 Use an object class field type to identify a type defined by means of an information object class (see ITU-T Rec. ATTRIBUTE. E. 108 ITU-T Rec.2. value [0] ACCESS-CONTROL-CLASS. X. but has fewer identification options.15 Object class field type E.constrained.&id.this is normally -.1 Use an embedded-pdv type to model a variable whose type is unspecified. }.&AttributeType constrained. Attribute.ISO/IEC 8824-1:2003 (E) E.this is normally -. objectInstance ObjectInstance.&AttributeType can carry a value of any type defined using ASN. Notations that possess this property of being able to carry a value of any type are termed "open type notation".&attributeId and ATTRIBUTE.&AttributeType is an open type. in that they are types defined by reference to an information object class (ATTRIBUTE).2.16 Embedded-pdv E.2. Get-Invoke is then equivalent to: Get-Invoke ::= SEQUENCE { objectClass ObjectClass. hence ATTRIBUTE. E.2. The type ATTRIBUTE.16. attributeValue ATTRIBUTE. since its type is not fixed in the definition of the information object class ATTRIBUTE. } -- this is normally constrained.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.&attributeId. --attributeID ATTRIBUTE. 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.1. EXAMPLE ATTRIBUTE ::= CLASS { &AttributeType.17 External The external type is similar to the embedded-pdv type.2. the type because it is explicitly defined in ATTRIBUTE as an OBJECT IDENTIFIER.constrained. accessControl [UNIVERSAL 8] IMPLICIT SEQUENCE { type-id ACCESS-CONTROL-CLASS.2.&attributeId } this is normally constrained. -. X. fields of the information object class ATTRIBUTE may be used in defining a type.18.18 Instance-of E. objectInstance ObjectInstance.&Type -. Annex A and Annex C). EXAMPLE ACCESS-CONTROL-CLASS ::= TYPE-IDENTIFIER Get-Invoke ::= SEQUENCE { objectClass ObjectClass. accessControl INSTANCE OF ACCESS-CONTROL-CLASS. 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. &attributeId } OBJECT IDENTIFIER UNIQUE Attribute ::= SEQUENCE { attributeID ATTRIBUTE.2.15.&AttributeType are object class field types. EXAMPLE FileContents ::= EMBEDDED PDV DocumentList ::= SEQUENCE OF document EMBEDDED PDV E.681 | ISO/IEC 8824-2.

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

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

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

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

and provided by the types VisibleString.2.1 terms. The Basic Multilingual Plane is normally 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). with negotiation of the character set to be used (or announcement of the set being used). based on the structure of ISO/IEC 646) and the associated International Register of Coded Character Sets. and there is normally a one-to-one correspondence between abstract characters in ASN.2 The BMPString type carries any character from the Basic Multilingual Plan of ISO/IEC 10646-1. b) c) d) F. and provided by subsetting the type UniversalString. TeletexString. and intended for specialized use. Use of the type CHARACTER STRING.3 For the collections defined in Annex A of ISO/IEC 10646-1.1 module ASN1-CHARACTER-MODULE (see clause 38). ISO/IEC 7350.680 (07/2002) 113 . these are the NumericString and PrintableString types. The set of characters in ISO/IEC 10646-1 is generally too large for meaningful conformance to be required.2 The UniversalString. In implementation level 1.2. GraphicString.2.1 character strings (This annex does not form an integral part of this Recommendation | International Standard) F. combining characters are not allowed. UTF8String or BMPString with subsets defined in ISO/IEC 10646-1 or by using named characters. VideotexString. in ASN.1 F. F. and requires that all uses of ISO/IEC 10646-1 specify the implementation level. UTF8String and BMPString types F.1 character strings and printed characters in a physical rendition of the string. F.ISO/IEC 8824-1:2003 (E) Annex F Tutorial annex on ASN. including those of ISO International Register of Coded Character Sets to be used with Escape Sequences.2.1 The UniversalString and UTF8String types carry any character from ISO/IEC 10646-1. Character string types based on ISO/IEC 10646-1.2. 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. IA5String.5 ISO/IEC 10646-1 specifies three "levels of implementation". and hence. Character string types providing a simple small collection of characters specified in this Recommendation | International Standard. and GeneralString.1. The "subtype constraint" mechanism allows new subtypes of UniversalString that are combinations of existing subtypes to be defined. F. there are type references defined in the built-in ASN. X.1 There are four groups of character string support in ASN.1 Character string support in ASN. 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.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. ISO/IEC 10646-1.1. and should normally be subsetted to a combination of the standard collections of characters in Annex A of ISO/IEC 10646-1. The implementation level relates to the extent to which support is given for combining characters in the character repertoire. ITU-T Rec.

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

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

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

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

G. 1.2 Even in this simple case. values of the sender shall be transferred in such a way that the receiver can determine that extension additions are not present.1 An abstract syntax can be defined as the values of a single ASN. but which tool vendors have to write code for because the ASN.2).3. If the unconstrained type was not extensible.1. this is something that nobody would ever write.4. In this example.3).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. .2 It can also. Such an abstract syntax is called an extension-related abstract syntax. MAX.3.3 The definition of the procedures for transforming an abstract value into an encoding for transfer.3. when the typereference de-references to an extensible type (perhaps with actual extension additions – see G. Consider: A ::= INTEGER (MIN .3 When used to provide interworking between deployed systems.1. G.5. and a constraint applied to it selects a subset of those abstract values..680 (07/2002) .3. G. G.2.1. and of all extension addition groups with an earlier version number.10) As with many examples in this annex. 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). Serial application of constraints G.ISO/IEC 8824-1:2003 (E) complete PDUs. G. transfer of values of that type to the receiver shall be possible.4. with the full range of integer values in the root.4 In this case. This latter form is used for many of the examples in this annex (for simplicity of exposition).1 model for applying constraints is simple: A type is a set of abstract values.1 type that is an extensible type. 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.3. 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. then the resulting type is defined to be extensible if and only if the applied constraint is defined to be extensible. even though there can never be any extension additions.4.4).4. but are extension-related. 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..4. The use of a typereference (a contained subtype) in the set arithmetic of a constraint.2.4 G. . G.4.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.4.3.2. A is formally an extensible INTEGER.3 Requirements on encoding rules G.4. G. X.3.4.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.3 Complexities arise from three main sources: – – – G.1 standard has been left simple and general.1 Combination of (possibly extensible) constraints Model G. there is one feature to clarify: A type may be formally extensible. NOTE – All ASN. but the case where a typereference links the two (or more) constraints is the form in which serial application normally occurs in real specifications. 118 ITU-T Rec. G. The combination of extensible constraints using UNION and INTERSECTION and EXCEPT (set arithmetic – see G. G.. G.3 to G.. It then contains all the values that can be obtained by the addition or removal of extension-additions.1 encoding rules satisfy these requirements. but less commonly.2 A set of well-formed encoding rules for an extension-related abstract syntax satisfies the additional requirements stated in G.1. and this example is therefore legal ASN.4.1 The basic ASN. an addition to that type will normally require that the version number for all the PDUs to which it contributes be incremented. occur when a type has multiple constraints directly applied to it in a serial fashion.

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

if a set of values is not extensible. NOTE 2 – It is an illegal specification if the root of any resulting set of values used in a serially applied constraint is empty. we describe all its values as root values. and all its extension additions are discarded. G.8 The rules are: N1 INTERSECTION N2 => N Root: R1 INTERSECTION R2 N1 INTERSECTION E2 => E Root: R1 INTERSECTION R2. Extensions: (X1 EXCEPT (R2 UNION X2) ) EXCEPT (R1 EXCEPT R2) N1 ... Extensions: X2 E1 UNION E2 => E Root: R1 UNION R2.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). 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. 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. G. Extensions: R2 EXCEPT R1 E1 . the result is still formally defined to be extensible for results E above.3.4. NOTE 3 – To avoid verbosity below. Extensions: R1 INTERSECTION X2 E1 INTERSECTION E2 => E Root: R1 INTERSECTION R2... X. Extensions: R2 UNION X2 EXCEPT R1 E1 . 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.ISO/IEC 8824-1:2003 (E) NOTE 1 – For the purposes of this annex and for simplicity of exposition.680 (07/2002) . "Extensions" is used in place of the more correct "Extension additions". N2 => E Root: R1.4.. E2 => E Root: R1. 120 ITU-T Rec. Extensions: (X1 EXCEPT R2) EXCEPT (R1 EXCEPT R2) E1 EXCEPT E2 => E Root: R1 EXCEPT R2. N2 => E Root: R1. E2 => E Root: R1... but when it is used in set arithmetic it is always treated as not extensible. Extensions: X1 UNION R2 EXCEPT R1 N1 ..

X.680 (07/2002) 121 ." "@" "|" "!" "^" 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..." "." "</" "/>" "{" "}" "<" ">" "." "." "(" ")" "[" "]" "-" ":" "=" """ (QUOTATION MARK) "'" (APOSTROPHE) " " (SPACE) ".ISO/IEC 8824-1:2003 (E) Annex H Summary of the ASN.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" "::=" "[[" "]]" "..

680 (07/2002) . 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) 123 .ISO/IEC 8824-1:2003 (E) The following productions are used in this Recommendation | International Standard." 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 "." EXPORTS ALL "." empty SymbolsImported ::= SymbolsFromModuleList | empty SymbolsFromModuleList ::= SymbolsFromModule | SymbolsFromModuleList SymbolsFromModule SymbolsFromModule ::= SymbolList FROM GlobalModuleReference GlobalModuleReference ::= modulereference AssignedIdentifier AssignedIdentifier ::= ObjectIdentifierValue | DefinedValue | empty SymbolList ::= Symbol | SymbolList "." Symbol ITU-T Rec. X.

" ComponentId ItemId ::= ItemSpec ComponentId ::= identifier | number | "*" TypeAssignment ::= typereference "::=" Type ValueAssignment ::= valuereference Type 124 ITU-T Rec.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 "." typereference NonParameterizedTypeName ::= ExternalTypeReference | typereference | xmlasn1typename DefinedValue ::= ExternalValueReference | valuereference | ParameterizedValue ExternalValueReference ::= modulereference "." valuereference AbsoluteReference ::= "@" ModuleIdentifier ".680 (07/2002) . X." ItemSpec ItemSpec ::= typereference | ItemId ".

680 (07/2002) 125 . X.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.

680 (07/2002) .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 "." NamedNumber NamedNumber ::= identifier "(" SignedNumber ")" | identifier "(" DefinedValue ")" SignedNumber ::= number | "-" number IntegerValue ::= SignedNumber | identifier 126 ITU-T Rec. X.

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

." 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 OptionalExtensionMarker RootComponentTypeList ::= ComponentTypeList ExtensionEndMarker ::= "..." ExtensionAndException ExtensionAdditions ExtensionEndMarker "." ExtensionAndException ExtensionAdditions OptionalExtensionMarker | RootComponentTypeList "..." ComponentType ComponentType ::= NamedType | NamedType OPTIONAL | NamedType DEFAULT Value | COMPONENTS OF Type SequenceValue ::= "{" ComponentValueList "}" | "{" "}" ComponentValueList ::= NamedValue | ComponentValueList ".680 (07/2002) . X." "." | "." ExtensionAdditions ::= "..." ExtensionAddition ExtensionAddition ::= ComponentType | ExtensionAdditionGroup ExtensionAdditionGroup ::= "[[" VersionNumber ComponentTypeList "]]" VersionNumber ::= empty | number ":" ComponentTypeList ::= | ComponentType ComponentTypeList "." RootComponentTypeList | ExtensionAndException ExtensionAdditions ExensionEndMarker "." ExtensionAdditionList | empty ExtensionAdditionList ::= ExtensionAddition | ExtensionAdditionList ".." | empty ComponentTypeLists ::= RootComponentTypeList | RootComponentTypeList "." ExceptionSpec OptionalExtensionMarker ::= ".ISO/IEC 8824-1:2003 (E) XMLOctetStringValue ::= XMLTypedValue | xmlhstring NullType NullValue ::= ::= NULL NULL XMLNullValue ::= empty SequenceType ::= | | SEQUENCE "{" "}" SEQUENCE "{" ExtensionAndException OptionalExtensionMarker "}" SEQUENCE "{" ComponentTypeLists "}" ExtensionAndException ::= "." ".

" ExtensionAdditionAlternativesList | empty ExtensionAdditionAlternativesList ::= ExtensionAdditionAlternative | ExtensionAdditionAlternativesList ". X." ExtensionAndException ExtensionAdditionAlternatives OptionalExtensionMarker RootAlternativeTypeList ::= AlternativeTypeList ExtensionAdditionAlternatives ::= ".680 (07/2002) 129 ." 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 "." NamedType identifier ":" Value XMLChoiceValue ::= "<" & identifier ">" XMLValue "</" & identifier ">" ITU-T Rec." ExtensionAdditionAlternative ExtensionAdditionAlternative ::= ExtensionAdditionAlternativesGroup | NamedType ExtensionAdditionAlternativesGroup ::= "[[" VersionNumber AlternativeTypeList "]]" AlternativeTypeList ::= | ChoiceValue ::= NamedType AlternativeTypeList ".ISO/IEC 8824-1:2003 (E) ValueList ::= Value | ValueList ".

680 (07/2002) . X.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.

" CharsDefn CharsDefn ::= cstring | Quadruple | Tuple | DefinedValue Quadruple Group Plane Row Cell ::= "{" Group "." 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 & "." Row ".680 (07/2002) 131 ." Cell "}" ::= number ::= number ::= number ::= number Tuple ::= "{" TableColumn "." & 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 "." Plane ". X.

." "." | RootElementSetSpec ".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 ".." "." 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...680 (07/2002) ." ".ISO/IEC 8824-1:2003 (E) XMLUnrestrictedCharacterStringValue ::= XMLSequenceValue UsefulType ::= typereference The following character string types are defined in 37. X.

... X." "." 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 ::= "{" "." TypeConstraints "}" TypeConstraints ::= | NamedConstraint NamedConstraint ".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 NamedConstraint ::= identifier ComponentConstraint ComponentConstraint ::= ValueConstraint PresenceConstraint ValueConstraint ::= Constraint | empty PresenceConstraint ::= PRESENT | ABSENT | OPTIONAL | empty PatternConstraint ::= PATTERN Value ITU-T Rec.680 (07/2002) 133 .

.

.

installation and protection of cables and other elements of outside plant TMN and network maintenance: international transmission systems. 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.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. facsimile and leased circuits Maintenance: international sound programme and television transmission circuits Specifications of measuring equipment Telephone transmission quality. telegraphy. symbols. service operation and human factors Non-telephone telecommunication services Transmission systems and media. digital systems and networks Audiovisual and multimedia systems Integrated services digital network Cable networks and transmission of television. telephone service. sound programme and other multimedia signals Protection against interference Construction. classification General telecommunication statistics General tariff principles Overall network operation. 2003 . telephone circuits. telephone installations.

Sign up to vote on this title
UsefulNot useful