ISO/IEC 8824-1:1998/Amd 2:2000
(Amendment)Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation — Part 1: — Amendment 2: ASN.1 Semantic Model
Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation — Part 1: — Amendment 2: ASN.1 Semantic Model
Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1): Spécification de la notation de base — Partie 1: — Amendement 2: Modèle sémantique d'ASN.1
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 8824-1
Second edition
1998-12-15
AMENDMENT 2
2000-10-15
Information technology — Abstract Syntax
Notation One (ASN.1): Specification of
basic notation
AMENDMENT 2: ASN.1 Semantic Model
Technologies de l'information — Notation de syntaxe abstraite numéro un
(ASN.1): Spécification de la notation de base
AMENDEMENT 2: Modèle sémantique ASN.1
Reference number
ISO/IEC 8824-1:1998/Amd.2:2000(E)
©
ISO/IEC 2000
---------------------- Page: 1 ----------------------
ISO/IEC 8824-1:1998/Amd.2:2000(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2000
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2000 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 8824-1:1998/Amd.2:2000(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this Amendment may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 2 to International Standard ISO/IEC 8824-1:1998 was prepared by ITU-T (as ITU-T Recommendation
X.680/Amd.2) and was adopted as common text, under a special “fast-track procedure”, by Joint Technical
Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national bodies of ISO and IEC.
© ISO/IEC 2000 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 8824-1 : 1998/Amd.2 : 2000 (E)
INTERNATIONAL STANDARD
ISO/IEC 8824-1 : 1998/Amd.2 : 1999 (E)
ITU-T Rec. X.680 (1997)/Amd.2 (1999 E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – ABSTRACT SYNTAX NOTATION ONE (ASN.1):
SPECIFICATION OF BASIC NOTATION
AMENDMENT 2
ASN.1 semantic model
1) Subclause 3.8
Add the definitions 3.8.39 bis and 3.8.71 bis to subclause 3.8 and replace the definition of governing; governor with the
new 3.8.39 below:
3.8.39 governing; governor (type): A type definition or reference which affects the interpretation of a part of the
ASN.1 syntax, requiring that part of the ASN.1 syntax to reference values in the governor type.
3.8.39 bis identical type definitions: Two instances of the ASN.1 "Type" production (see clause 16) are defined as
identical type definitions if, after performing the transformations specified in Annex F, they are identical ordered lists of
ASN.1 items (see clause 11).
3.8.71 bis 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. This can, for example, be used in specifying subtypes and default
values (see Annex F).
Append to clause 3.8.50:
, and which governs the subtype notation.
2) New subclause 5.9
Add a new subclause 5.9 as follows:
5.9 Value references and the typing of values
5.9.1 ASN.1 defines a value assignment notation which enables a name to be given to a value of a specified type.
This name can be used wherever a reference to that value is needed. Annex F describes and specifies the value mapping
mechanism which allows a value reference name for a value of one type to identify a value of a second type. Thus, a
reference to the first value can be used where a reference to a value in the second type is required.
5.9.2 In the body of the ASN.1 standards, normal English text is used to specify legality (or otherwise) of constructs
where more than one type is involved, but where the two types must be "compatible". For example, the type used in
defining a value reference is required to be "compatible with" the governor type when the value reference is used. The
normative Annex F uses the value mapping concept to give a precise statement about whether any given ASN.1
construct is legal or not.
ITU-T Rec. X.680 (1997)/Amd.2 (1999 E) 1
---------------------- Page: 4 ----------------------
ISO/IEC 8824-1 : 1998/Amd.2 : 2000 (E)
3) New subclause 13.6
Add a new subclause 13.6 as follows:
13.6 Where a "DefinedType" is used as part of notation governed by a "Type" (for example, in a
"SubtypeElementSpec"), then the "DefinedType" shall be compatible with the governing "Type" as specified in F.6.2.
4) New subclause 13.7
Add a new subclause 13.7 as follows:
13.7 Every occurrence within an ASN.1 specification of a "DefinedValue" is governed by a "Type", and that
"DefinedValue" shall reference a value of a type that is compatible with the governing "Type" as specified in F.6.2.
5) Subclause 15.2
In 15.2, change the sentence after the BNF by inserting immediately before "shall" the text:
is governed by "Type" and
6) Subclause 36.7
Add the following to the Note 3 example in 36.7:
An alternative unambiguous definition of "mystring" would be:
Q]WXVMRK1]%PTLEFIX &EWMG0EXMR !,34)
Formally, "mystring" is a value reference to a value of a subset of "MyAlphabet", but it can, by the value mapping rules
of Annex F, be used wherever a value reference is needed to this value within "MyAlphabet".
7) Subclause 48.3.2
Replace 48.3.2 with the following text:
48.3.2 A "ContainedSubtype" specifies all of the values in the parent type that are also in "Type". "Type" is required
to be compatible with the parent type as specified in F.6.3.
8) Subclause 48.5.2
In 48.5.2, delete the text ", or types formed from any of those types by tagging".
9) Subclause 48.8.2
In 48.8.2, delete the text ", or types formed from any of those types by tagging".
2 ITU-T Rec. X.680 (1997)/Amd.2 (1999 E)
---------------------- Page: 5 ----------------------
ISO/IEC 8824-1 : 1998/Amd.2 : 2000 (E)
10) New Annex F
Add a new Annex F as follows:
Annex F
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. It is
present in order to clearly specify what is legal ASN.1 and what is not, and to be able to specify the precise value that
any value reference name identifies, and the precise set of values that any type or value set reference name identifies. It
is not intended to provide a definition of valid transformations of ASN.1 notations for any purpose other than those
stated above.
F.1 The need for the value mapping concept (Tutorial introduction)
F.1.1 Consider the following ASN.1 definitions:
% !-28)+)6
& !?A-28)+)6
' !?A-28)+)6
( !?A-28)+)6
) !-28)+)6
* !-28)+)6_VIH [LMXI FPYI KVIIR TYVTPI a
E% !
F& !
G' !
H( !
I) !
J* !KVIIR
F.1.2 It is clear that the value references a, b, c, d, e, and f can be used in value notation governed by A, B, C, D, E,
and F, respectively. For example:
; !7)59)2')_[%()*%908Ea
and:
\% !E
and:
= !% E
are all valid given the definitions in F.1.1. If, however, A above were replaced by B, or C, or D, or E, or F, would the
resulting statements be illegal? Similarly, if the value reference a above were replaced in each of these cases by b, or c,
or d, or e, or f, are the resulting statements legal?
F.1.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. Consider for example:
J-28)+)6_VIH [LMXI FPYI KVIIR TYVTPI a !KVIIR
; !7)59)2')_
[ -28)+)6_VIH [LMXI FPYI KVIIR TYVTPI a
()*%908Ja
\-28)+)6_VIH [LMXI FPYI KVIIR TYVTPI a !J
= !-28)+)6_VIH [LMXI FPYI KVIIR TYVTPI a J
Would the above be legal ASN.1?
F.1.4 Some of the above examples are cases which, even if legal (as most of them are – see later text), users would
be ill-advised to write similar text, as they are at the least obscure and at worst confusing. However, 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 with tagging or subtyping applied in the governor. 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.
ITU-T Rec. X.680 (1997)/Amd.2 (1999 E) 3
---------------------- Page: 6 ----------------------
ISO/IEC 8824-1 : 1998/Amd.2 : 2000 (E)
F.1.5 Again, consider:
' !?A-28)+)6
) !-28)+)6
* !-28)+)6_VIH [LMXI FPYI KVIIR TYVTPI a
In each case a new type is being created. For F we can clearly identify a 1-1 correspondence between the values in it and
the values in the universal type "INTEGER". In the case of C and E, we can clearly identify a 1-1 correspondence
between the values in them and a subset of the values in the universal type "INTEGER". We call this relationship a
value mapping between values in the two types. Moreover, because values in F, C, and E all have (1-1) mappings to
values of "INTEGER", we can use these mappings to provide mappings between the values of F, C, and E themselves.
This is illustrated for F and C in Figure F.1.
Integer
. . .
. . .
Mappings
Mappings
red(0)
[2]1
[2]0
blue(2)
[2]2 [2]3
white(1)
Derived
. . .
Mappings
green(3)
[2]5
[2]4
. . .
[2]6
purple(4)
T0732160-99/d01
F
C
Figure F.1
F.1.6 Now when we have a value reference such as:
G' !
to a value in "C" which is required in some context to identify a value in "F", then, provided a value mapping exists
between that value in "C" and a (single) value in "F", we can (and do) define "c" to be a legal reference to the value
in "F". This is illustrated in Figure F.2, where the value reference "c" is used to identify a value in "F", and can be used
in place of a direct reference f1 where we would otherwise have to define:
J* !
F.1.7 It should be noted that in some cases there will be values in one type (7 to 20 in A of F.1.1 for example) that
have value mappings to values in another type (7 to 20 in E of F.1.1 for example), but other values (21 upwards of A)
that have no such mapping. A reference to such values in A would not provide a valid reference to a value in E. (In this
example, the whole of E has a value mapping to a subset of A. In the general case, there may be a subset of values in
both types that have mappings, with other values in both types that are unmapped.)
4 ITU-T Rec. X.680 (1997)/Amd.2 (1999 E)
---------------------- Page: 7 ----------------------
ISO/IEC 8824-1 : 1998/Amd.2 : 2000 (E)
F
f
red(0)
blue(2)
c
white(1)
C
. . .
green(3)
. . .
purple(4)
5
[2]1
[2]0
f1 [2]2 [2]3
[2]5
[2]4
[2]6
T0732170-99/d02
Figure F.2
FIGURE F.2/X.680.[D02]
F.1.8 In the body of the ASN.1 standards, normal English text is used to specify legality in the above and similar
cases. Subclause F.6 gives the precise requirements for legality and should be referenced whenever there is doubt about
a complex construction.
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. 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. 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. (These examples are not intended to be exhaustive.) It is, however, recommended that advantage be taken
of this freedom only for simple cases such as "SEQUENCE OF INTEGER", or "CHOICE {int INTEGER, id OBJECT
IDENTIFIER}", and not for more complex "Type" constructs.
F.2 Value mappings
F.2.1 The underlying model is of types, as non-overlapping containers, that contain values, with every occurrence of
the ASN.1 "Type" construct defining a distinct new type (see Figures F.1 and F.2). This annex specifies when value
mappings exist between such 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.
Example: Consider:
< !-28)+)6
= !-28)+)6
X and Y are type reference names (pointers) to two distinct types, but value mappings exist between these types, so any
value reference to a value of X can be used when governed by Y (for example, following DEFAULT).
F.2.2 In the set of all possible ASN.1 values, a value mapping relates a pair of values. The whole set of value
mappings is a mathematical relation. This relation possesses the following properties: it is reflexive (each ASN.1 value is
related to itself), it is symmetric (if a value mapping is defined to exist from a value x1 to a value x2, then there
automatically exists a value mapping from x2 to x1), and it is transitive (if there is a value mapping from a value x1
to x2, and a value mapping from x2 to x3, then there automatically exists a value mapping from x1 to x3).
F.2.3 Furthermore, given any two types X1 and X2, seen as sets of values, the set of value mappings from values
in X1 to values in X2 is a one-to-one relation, that is, for all values x1 in X1, and x2 in X2, if there is a value mapping
from x1 to x2, then:
a) there is no value mapping from x1 to another value in X2 different from x2; and
b) there is no value mapping from any value in X1 (other than x1) to x2.
ITU-T Rec. X.680 (1997)/Amd.2 (1999 E) 5
---------------------- Page: 8 ----------------------
ISO/IEC 8824-1 : 1998/Amd.2 : 2000 (E)
F.2.4 Where a value mapping exists between a value x1 and a value x2, a value reference to either one can
automatically be used to reference the other if so required by some governor type.
NOTE – The fact that value mappings are defined to exist between values in some "Type" constructs is solely for the purpose of
providing flexibility in the use of the ASN.1 notation. The existence of such mappings carries no implications whatsoever that
the two types carry the same application semantics, but it is recommended that ASN.1 constructs which would be illegal
without value mappings are used only if the corresponding types do indeed carry the same application semantics. Note that value
mappings will frequently exist in any large specification between two types that are identical ASN.1 constructs, but which carry
totally different application semantics, and where the existence of these value mappings is never used in determining the legality
of the total specification.
F.3 Identical type definitions
F.3.1 The concept of identical type definitions is used to enable value mappings to be
...
NORME ISO/CEI
INTERNATIONALE 8824-1
Deuxième édition
1998-12-15
AMENDEMENT 2
2000-10-15
Technologies de l'information — Notation
de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base
AMENDEMENT 2: Modèle sémantique
d'ASN.1
Information technology — Abstract Syntax Notation One (ASN.1):
Specification of basic notation
AMENDMENT 2: ASN.1 Semantic Model
Numéro de référence
ISO/CEI 8824-1:1998/Amd.2:2000(F)
©
ISO/CEI 2000
---------------------- Page: 1 ----------------------
ISO/CEI 8824-1:1998/Amd.2:2000(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO/CEI 2000
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2002
Imprimé en Suisse
ii © ISO/CEI 2000 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO/CEI 8824-1:1998/Amd.2:2000(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou de la
CEI participent au développement de Normes internationales par l'intermédiaire des comités techniques créés par
l'organisation concernée afin de s'occuper des domaines particuliers de l'activité technique. Les comités
techniques de l'ISO et de la CEI collaborent dans des domaines d'intérêt commun. D'autres organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et la CEI participent également
aux travaux. Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé un comité technique mixte,
l'ISO/CEI JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des organismes nationaux
votants.
L'attention est appelée sur le fait que certains des éléments du présent Amendement peuvent faire l'objet de droits
de propriété intellectuelle ou de droits analogues. L'ISO et la CEI ne sauraient être tenues pour responsables de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'Amendement 2 à la Norme internationale ISO/CEI 8824-1:1998 a été élaboré par l'UIT-T (en tant que
Recommandation UIT-T X.680/Amd.2) et a été adopté selon une procédure spéciale par «voie express», par le
comité technique mixte ISO/CEI JTC 1, Technologies de l'information, parallèlement à son approbation par les
organismes nationaux de l'ISO et de la CEI.
© ISO/CEI 2000 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO/CEI 8824-1 : 1998/Amd.2 : 2000 (F)
NORME INTERNATIONALE
ISO/CEI 8824-1 : 1998/Amd.2 : 1999 (F)
Rec. UIT-T X.680 (1997)/Amd.2 (1999 F)
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION –
NOTATION DE SYNTAXE ABSTRAITE NUMÉRO UN:
SPÉCIFICATION DE LA NOTATION DE BASE
AMENDEMENT 2
Modèle sémantique d'ASN.1
1) Paragraphe 3.8
Ajouter les définitions 3.8.39 bis et 3.8.71 bis au paragraphe 3.8 et remplacer la définition de gouvernant; gouverneur
par le nouveau paragraphe 3.8.39 ci-dessous:
3.8.39 gouvernant; gouverneur (type): référence ou définition de type qui affecte l'interprétation d'une partie de la
syntaxe ASN.1, exigeant qu'elle fasse référence à des valeurs du type gouvernant.
3.8.39 bis définitions de types identiques: deux instances de la production "Type" ASN.1 (voir article 16) sont définies
comme des définitions de types identiques si, après application des transformations spécifiées dans l'Annexe F, elles sont
constituées des listes ordonnées identiques d'unités lexicales ASN.1 (voir article 11).
3.8.71 bis correspondance entre valeurs: relation biunivoque entre des valeurs de deux types, qui permet d'utiliser une
référence à une valeur d'un type comme référence à une valeur de l'autre type. On peut l'utiliser, par exemple, pour
spécifier des sous-types et des valeurs par défaut (voir Annexe F).
Ajouter au paragraphe 3.8.50:
{texte existant}, et qui gouverne la notation de sous-type.
2) Nouveau paragraphe 5.9
Ajouter un nouveau paragraphe 5.9 comme suit:
5.9 Références de valeurs et typage de valeurs
5.9.1 L'ASN.1 décrit une notation de définition de valeur qui permet de donner un nom à une valeur d'un type
spécifié. Ce nom peut être utilisé chaque fois qu'il est nécessaire de faire référence à cette valeur. L'Annexe F décrit et
spécifie le mécanisme de correspondance entre valeurs qui permet à un nom de référence de valeur affecté à une
valeur d'un type d'identifier une valeur d'un second type. Ainsi, on peut utiliser une référence à une valeur du premier
type lorsqu'une référence à une valeur du second type est nécessaire.
5.9.2 Dans le corps des normes ASN.1, un texte définit la légalité (ou non) des constructions mettant en jeu
plusieurs types, mais qui doivent être compatibles. Par exemple, le type utilisé pour définir une référence de valeur doit
être compatible avec le type qui gouverne l'utilisation de cette référence de valeur. L'Annexe F normative utilise le
concept de correspondance entre valeurs pour donner une indication précise sur la légalité ou non d'une construction
ASN.1 donnée.
Rec. UIT-T X.680 (1997)/Amd.2 (1999 F) 1
---------------------- Page: 4 ----------------------
ISO/CEI 8824-1 : 1998/Amd.2 : 2000 (F)
3) Nouveau paragraphe 13.6
Ajouter un nouveau paragraphe 13.6 comme suit:
13.6 Lorsqu'un type "DefinedType" est utilisé dans une notation gouvernée par un "Type" (par exemple un
"SubtypeElementSpec"), le type "DefinedType" doit être compatible avec le "Type" gouvernant, comme spécifié au
paragraphe F.6.2.
4) Nouveau paragraphe 13.7
Ajouter un nouveau paragraphe 13.7 comme suit:
13.7 Chaque occurrence d'une valeur "DefinedValue" dans une spécification ASN.1 est gouvernée par un "Type" et
cette valeur "DefinedValue" doit faire référence à une valeur d'un type compatible avec le "Type" gouvernant, comme
spécifié au paragraphe F.6.2.
5) Paragraphe 15.2
Au paragraphe 15.2, modifier la phrase suivant le formalisme BNF en insérant immédiatement avant "sera" le texte
suivant:
est gouvernée par le "Type" et
6) Paragraphe 36.7
Ajouter à l'exemple de la Note 3 du paragraphe 36.7 ce qui suit:
Autre définition non ambiguë de "mystring":
P\VWULQJ 0\$OSKDEHW %DVLF/DWLQ 32,17
Formellement, "mystring" est une référence de valeur à une valeur d'un sous-ensemble de "MyAlphabet", mais elle peut,
en vertu des règles de correspondance entre valeurs de l'Annexe F, être utilisée pour référencer la même chaîne mais en
tant que valeur du type "MyAlphabet".
7) Paragraphe 48.3.2
Remplacer le paragraphe 48.3.2 par le texte suivant:
48.3.2 La notation "ContainedSubtype" spécifie toutes les valeurs du type parent qui sont aussi des valeurs du
"Type", qui doit lui-même être compatible avec le type parent, comme spécifié au paragraphe F.6.3
8) Paragraphe 48.5.2
Au paragraphe 48.5.2, supprimer le passage suivant: ", ou aux types obtenus à partir de ces derniers par étiquetage".
9) Paragraphe 48.8.2
Au paragraphe 48.8.2, supprimer le passage suivant: ", ainsi qu'aux types qui en dérivent par étiquetage".
2 Rec. UIT-T X.680 (1997)/Amd.2 (1999 F)
---------------------- Page: 5 ----------------------
ISO/CEI 8824-1 : 1998/Amd.2 : 2000 (F)
10) Nouvelle Annexe F
Ajouter une nouvelle Annexe F comme suit:
Annexe F
Règles applicables à la compatibilité de types et de valeurs
(Cette annexe fait partie intégrante de la présente Recommandation | Norme internationale)
La présente annexe s'adresse principalement aux concepteurs d'outils en vue de leur permettre d'interpréter la notation
ASN.1 de la même façon. Elle a pour objet de spécifier clairement ce qu'est une définition ASN.1 légale et non légale, et
d'indiquer la valeur précise identifiée par un nom de référence de valeur ainsi que l'ensemble de valeurs précis identifié
par un nom de référence d'ensemble de valeurs ou par un nom de référence de type. Elle ne vise pas à donner une
définition des transformations valides des définitions ASN.1 à d'autres fins que celles indiquées ci-dessus.
F.1 Nécessité du concept de correspondance entre valeurs (introduction didactique)
F.1.1 Considérons les définitions ASN.1 suivantes:
A ::= INTEGER
B ::= [1] INTEGER
C ::= [2] INTEGER (0.6,.)
D ::= [2] INTEGER (0.6,.,7)
E ::= INTEGER (7.20)
F ::= INTEGER {rouge(0), blanc(1), bleu(2), vert(3), violet(4)}
a A ::= 3
b B ::= 4
c C ::= 5
d D ::= 6
e E ::= 7
f F ::= vert
F.1.2 Il est clair que les références de valeurs "a", "b", "c", "d", "e" et "f" peuvent être utilisées dans la notation de
valeur gouvernée respectivement par "A", "B", "C", "D", "E" et "F". Par exemple:
W ::= SEQUENCE {w1 A DEFAULT a}
et:
x A ::= a
et:
Y ::= A(1.a)
sont toutes des expressions valables compte tenu des définitions données au paragraphe F.1.1. Toutefois, si le type "A"
ci-dessus était remplacé par "B", "C", "D", "E" ou "F", les déclarations qui en découlent seraient-elles illégales? De
même, si la référence de valeur "a" ci-dessus était remplacée dans chacun de ces cas par "b", "c", "d", "e" ou "f", les
déclarations qui en découlent seraient-elles légales?
F.1.3 Il serait plus délicat d'envisager dans chaque cas de remplacer la référence de type par le texte explicite à droite
de sa définition, par exemple:
f INTEGER {rouge(0), blanc(1), bleu(2), vert(3), violet(4)} ::= vert
W ::= SEQUENCE {
w1 INTEGER {rouge(0), blanc(1), bleu(2), vert(3), violet(4)}
DEFAULT f}
x INTEGER {rouge(0), blanc(1), bleu(2), vert(3), violet(4)} ::= f
Y ::= INTEGER {rouge(0), blanc(1), bleu(2), vert(3), violet(4)}(1.f)
La notation ci-dessus serait-elle une notation ASN.1 légale?
Rec. UIT-T X.680 (1997)/Amd.2 (1999 F) 3
---------------------- Page: 6 ----------------------
ISO/CEI 8824-1 : 1998/Amd.2 : 2000 (F)
F.1.4 Les utilisateurs seraient mal avisés de rédiger un texte semblable à certains des exemples donnés ci-dessus,
même si la plupart sont légaux (voir le dernier exemple), car ces exemples sont pour le moins obscurs, voire au pire
confus. Toutefois, on utilise souvent une référence de valeur d'un type (pas nécessairement un type "INTEGER") comme
valeur par défaut pour un type gouverneur déduit du premier par étiquetage ou sous-typage. Le concept de
correspondance entre valeurs est introduit en vue de donner un moyen clair et précis de déterminer les constructions
qui, comme celles citées ci-dessus, sont légales.
F.1.5 Examinons de nouveau:
C ::= [2] INTEGER (0.6,.)
E ::= INTEGER (7.20)
F ::= INTEGER {rouge(0), blanc(1), bleu(2), vert(3), violet(4)}
Dans chaque cas, un nouveau type est créé. Pour le type "F", nous pouvons clairement identifier une correspondance
biunivoque entre les valeurs qu'il contient et les valeurs du type prédéfini "INTEGER". Pour les types "C" et "E", nous
pouvons identifier clairement une correspondance biunivoque entre les valeurs qu'ils contiennent et un sous-ensemble de
valeurs du type prédéfini "INTEGER". Nous appelons cette relation une correspondance entre valeurs des deux types.
En outre, étant donné que les valeurs des types "F", "C" et "E" sont toutes en correspondance biunivoque avec les
valeurs de sous-ensembles du type "INTEGER", nous pouvons utiliser ces correspondances pour définir des
correspondances entre les valeurs des types "F", "C" et "E". La Figure F.1 illustre cet exemple pour les types "F" et "C".
F.1.6 Lorsque nous avons une référence à une valeur du type "C":
c C ::= 5
qui, dans un certain contexte doit être utilisée pour identifier une valeur du type "F", s'il existe une correspondance entre
cette valeur du type "C" et une (seule) valeur du type "F", nous pouvons définir (et nous définissons) "c" comme une
référence légale à une valeur du type "F". Ce cas est illustré par la Figure F.2, où la référence de valeur "c" sert à
identifier une valeur du type "F", et peut être utilisée à la place d'une référence directe "f1" qu'il serait sans cela
nécessaire de définir:
f1 F ::= 5
F.1.7 Il convient de noter que dans certains cas, des valeurs d'un type (les valeurs 7 à 20 du type "A" du paragraphe
F.1.1 par exemple) seront en correspondance avec des valeurs d'un autre type (les valeurs 7 à 20 du type "E" du
paragraphe F.1.1 par exemple), mais que d'autres valeurs du même type (à partir de la valeur 21 du type "A") ne le
seront pas. Une référence à ces valeurs du type "A" ne serait pas une référence valable à une valeur du type "E". (Dans
cet exemple, l'ensemble des valeurs du type "E" est en correspondance avec les valeurs d'un sous-ensemble de
l'ensemble des valeurs du type "A". En règle générale, il peut y avoir un sous-ensemble de valeurs du premier type, pour
lesquelles il existe une correspondance avec les valeurs d'un sous-ensemble du second type, les valeurs appartenant à ces
sous-ensembles n'étant pas en correspondance.)
F.1.8 Dans le corps des normes ASN.1, un texte est utilisé pour spécifier la légalité concernant les cas présentés
ci-dessus ou des cas similaires. Le paragraphe F.6 indique les conditions précises de légalité et il convient de s'y référer
en cas de doute au sujet d'une construction complexe.
NOTE – Le fait qu'une correspondance entre valeurs soit définie entre deux occurrences de constructions de "Type" permet
d'utiliser des références de valeur établies à l'aide d'une construction de "Type" pour identifier des valeurs dans une autre
construction de "Type" suffisamment semblable. Cela permet de typer les paramètres fictifs et réels en utilisant deux constructions
de "Type" textuelles distinctes sans enfreindre les règles de compatibilité des paramètres fictifs et réels. Cela permet aussi de
spécifier les champs de classes d'objets informationnels en utilisant une construction de "Type" et la valeur correspondante dans la
définition d'un objet informationnel à l'aide d'une construction de "Type" distincte suffisamment similaire. (La liste de ces
exemples n'est pas exhaustive.) Il est toutefois recommandé de n'avoir recours à ces possibilités que pour des cas simples comme
"SEQUENCE OF INTEGER", ou "CHOICE {int INTEGER, id OBJECT IDENTIFIER}", et non pour des constructions de
"Type" plus complexes.
4 Rec. UIT-T X.680 (1997)/Amd.2 (1999 F)
---------------------- Page: 7 ----------------------
ISO/CEI 8824-1 : 1998/Amd.2 : 2000 (F)
Entier
. . . .
. . . .
Correspondance
Correspondance
rouge(0)
[2]1
[2]0
bleu(2)
[2]2 [2]3
blanc(1)
. . . .
vert(3)
[2]5
[2]4
. . . .
violet(4)
[2]6
T0732160-99/d01
F
C
Figure F.1
FIGURE F.1
F
f
rouge(0)
bleu(2)
c
blanc(1)
C
. . . .
vert(3)
. . . .
violet(4)
5
[2]1
[2]0
[2]2 [2]3
f1
[2]5
[2]4
[2]6
T0732170-99/d02
Figure F.2
FIGURE F.2
Rec. UIT-T X.680 (1997)/Amd.2 (1999 F) 5
Correspondance
dérivée
---------------------- Page: 8 ----------------------
ISO/CEI 8824-1 : 1998/Amd.2 : 2000 (F)
F.2 Correspondances entre valeurs
F.2.1 Le modèle sous-jacent est constitué de types, considérés comme des conteneurs qui ne se chevauchent pas et
qui contiennent des valeurs, chaque occurrence de la construction de "Type" ASN.1 définissant un nouveau type distinct
(voir Figures F.1 et F.2). La présente annexe indique dans quelles conditions des correspondances existent entre les
valeurs de ces types, ce qui permet d'utiliser une référence de valeur d'un type lorsqu'une référence de valeur à un autre
type est nécessaire.
Exemple:
X ::= INTEGER
Y ::= INTEGER
"X" et "Y" sont des noms de référence (pointeurs) vers deux types distincts, mais une correspondance existe entre les
valeurs de ces types, de sorte que l'on peut utiliser n'importe quelle référence à une valeur de "X" pour une valeur
gouvernée par "Y" (par exemple, après le mot-clé DEFAULT).
F.2.2 Dans l'ensemble de toutes les valeurs possibles de la notation ASN.1, une correspondance entre valeurs se
rapporte à une paire de valeurs. Une correspondance entre valeurs est une relation mathématique qui a les propriétés
suivantes: elle est réflexive (chaque valeur ASN.1 est en correspondance avec elle-même), symétrique (si une valeur
"x1" est en correspondance avec une valeur "x2", la valeur "x2" est automatiquement en correspondance avec la valeur
"x1") et transitive (s'il y a, d'une part, une correspondance entre une valeur "x1" et une valeur "x2", d'autre part, une
correspondance entre une valeur "x2" et une valeur "x3", il existe automatiquement une correspondance entre "x1" et
"x3").
F.2.3 En outre, étant donné deux types "X1" et "X2", considérés comme des ensembles de valeurs, la
correspondance entre des valeurs dans "X1" et des valeurs dans "X2" est une relation univoque, c'est-à-dire que pour
tout couple de valeurs "x1" de "X1", et "x2" de "X2", s'il y a une correspondance entre "x1" et "x2", alors:
a) il n'y a pas de correspondance entre "x1" et une autre valeur de "X2" différente de "x2";
b) il n'y a pas de correspondance entre une valeur quelconque de "X1" (autre que "x1") et "x2".
F.2.4 Lorsqu'il y a une correspondance entre une valeur "x1" et une valeur "x2", une référence à l'une de ces valeurs
peut automatiquement servir de référence à l'autre si le type gouverneur l'exige.
NOTE – Le fait que des correspondances entre valeurs soient définies dans certaines constructions de "Type" vise simplement à
accorder une plus grande souplesse dans l'utilisation de la notation ASN.1. L’existence de ces correspondances entre valeurs
n'implique en aucune façon que les deux types acheminent les mêmes sémantiques du point de vue de l'application, mais il
est recommandé de n'utiliser des constructions ASN.1 qui seraient illégales sans correspondances entre valeurs, que si les types
correspondants ont réellement la même sémantique du point de vue de l'application. A noter que l'on trouvera souvent, dans des
spécifications comportant de nombreuses définitions, des correspondances entre valeurs de types qui sont des constructions
ASN.1 identiques, mais qui ont une sémantique totalement différente du point de vue de l'application; toutefois, ces
correspondances entre valeurs ne sont jamais utilisées pour déterminer la légalité de l'ensemble de la spécification.
F.3 Définition de types identiques
F.3.1 Le concept de définition de types identiques permet de définir des correspondances entre valeurs entre deux
instances de "Type" identiques ou suffisamment similaires pour être normalement interchangea
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.