ISO/IEC 8824-1:1995/Amd 1:1996
(Amendment)Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation — Amendment 1: Rules of extensibility
Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation — Amendment 1: Rules of extensibility
Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1): Spécification de la notation de base — Amendement 1: Règles d'extensibilité
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 8824-l
First edition
1995-l O-l 5
AMENDMENT 1
1996-05-01
Information technology - Abstract Syntax
Notation One (ASN.l): Specification of
basic notation
AMENDMENT 1: Rules of extensibility
Technologies de /‘information - Notation de syntaxe abstraite numkro ?
(ASN. 7): Spkifications des notations de base
AMENDEMENT 7: R&g/es pour I’extensibilitk
Reference number
ISO/I EC 8824-l : 1995/Amd. 1: 1996(E)
---------------------- Page: 1 ----------------------
ISOLIEC 8824-1:1995/Amd.l:1996(E)
Contents
1 Scope . . .
2 Normative references . .
1
2.1 Identical Recommendations I International Standards .
.................................... 1
3 Changes to Introduction .
4
Changes to Definitions . . 2
..................................... 2.
5 The ASN. 1 model of type extension .
2
6 Extensibility requirements on encoding rules. .
-l
.................. .... 3
7 Changes to Module Definition . .
4
8 Change to production for ValueSet . . .
......................... 4
9 Change to definition of types and values .
4
10 Changes to ENUMERATED . .
4
....... ..........................................
41 Changes to SEQUENCE .
Changes to SET 5
12 .
5
13 Changes to CHOICE .
Changes to Const:*ained Types 4
14 .
6
15 Changes to exception identifier .
Changes to element set specification . 6
16
8
Annex A - Tutorial annex on the ASN. 1 model of type extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . .“.“.)I
0 ISO/IEC 1996
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 the publisher.
ISO/IEC Copyright Office l Case Postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
11
---------------------- Page: 2 ----------------------
@ ISOIIEC ISO/IEC 8824-l : 199YAmd. 1: 1996(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of IS0 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. IS0 and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 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.
Amendment 1 to International Standard ISO/IEC 8824- 1: 1995 was prepared by Joint Technical Committee ISOLIEC JTC 1,
Information technology, Subcommittee SC 21, Open systems interconnection, data management and open distributed
processing, in collaboration with ITU-T. The identical text is published as ITU-T Rec. X,68O/Amd. 1.
iii
---------------------- Page: 3 ----------------------
ISO/IEC 8824-l: 199YAmd.l: 1996(E)
Qsl ISQ/IEC
Introduction
This Recommendation I International Standard documents the changes to ITU-T Rec. X.680 I ISO/IEC 8824-l needed to
support the ASN.1 Rules of Extensibility.
The ASN. 1 Rules of Extensibility describes how to write an ASN. 1 module in such a way as to allow a phased migration
to a new version of an ASN. 1 specification. The new version may differ from the previous version by new components
being added to a SET, SEQUENCE or CHOICE, new enumerations being added to an enumerated type, and constraints
on a subtype specification being relaxed. A phased migration to the new version of the ASN.1 specification allows
communicating peers throughout a network to simultaneously have differing knowledge of the set of values allowed in
the abstract syntax, yet be able to communicate without the knowledge by any peer that its peer has a different
understanding of what the set of values in the abstract syntax is.
For example, initially peers A, B, C and D may have identical views of the types of values that can be exchanged.
Assuming that the ASN.l specification that describes these values was originally defined with extensibility in mind, it
can be extended by adding new components to a SEQUENCE, for example, thereby creating a new version of the
ASN. 1 specification. Peers A and B may immediately adopt the new version, while peers C and D continue using the old
version, yet all four peers can continue communicating with one another without difficulty because the SEQUENCE was
originally defined as being extensible. When peers A and B exchange a value of the newly extended SEQUENCE they
will both see values for the new components that were added to the SEQUENCE (provided they are sent). When peer A
(or B) sends a message containing the newly added components to peer C (or D), the message will appear to C at the
abstract level (i.e. after the message has been decoded) without any of the newly added components; only the original
components in the SEQUENCE will be seen. When peer C (or D) sends a message to peer A (or B), the message will (of
course) not contain any of the new components, however, it will appear to A as though a peer using the same version of
the ASN.l specification as A (e.g. B) had sent the message with all of the new components missing. Peers C and D
continue to exchange messages with each other the way they always did.
---------------------- Page: 4 ----------------------
ISO/IEC 8824-1:1995/Amd.l:1996(E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY - ABSTRACT SYNTAX NOTATION ONE (ASN.1):
SPECIFICATION OF BASIC NOTATION
AMENDMENT 1
(to Rec. X.680 I ISO/IEC 8824-l)
Rules of extensibility
1 Scope
This Recommendation I International Standard documents the changes to ITU-T Rec. X.680 1 ISO/IEC 8824-l needed to
support the ASN. 1 Rules of Extensibility.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation I International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
editions of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently
valid International Standards. The Telecommunications Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
21 . Identical Recommendations I International Standards
-
ITU-T Recommendation X.680 (1994) I ISO/IEC 8824- 1: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Specification of basic notation.
-
ITU-T Recommendation X.682 (1994) I ISO/IEC 8824-3: 1995, Information technology - Abstract Syntax
Notation One (ASN. 1): Constraint specification.
-
ITU-T Recommendation X.683 (1994) I ISO/IEC 8824-4: 1995, Information technology - Abstract Syntax
Notation One (ASN. I ): Parameterization of ASN. I specifications.
-
ITU-T Recommendation X.690 (1994) I ISO/IEC 8825 1: 1995, Information technology - ASN. I encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).
-
ITU-T Recommendation X.691 (1995) I ISO/IEC 8825-2: 1996, Information technology - ASN. I encoding
rules - Specification of Packed Encoding Rules (PER).
3 Changes to Introduction
{Add the following text to the Zntroduction of ITU-T Rec. X.680 I ISO/IEC 8824-l immediately before the existing
paragraph which begins “Clauses 8 to 31”:/
An ASN. 1 specification will initially be produced with a set of fully defined ASN.l types. At a later stage, however, it
may be necessary to change those types (usually by the addition of extra components in a sequence or set type ). If this is
to be possible in such a way that implementations using the old type definitions can interwork with implementations
using the new type definitions in a defined way, encoding rules need to provide appropriate support. The ASN. 1 notation
supports the inclusion of an extension marker on a number of types. This signals to encoding rules the intention of the
designer that this type is one of a series of related types (i.e. versions of the same initial type) called an extension series,
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.
ITU-T Rec. X.680 (1994)/Amd.l(1995 E) 1
---------------------- Page: 5 ----------------------
ISO/IEC 8824-1:1995/Amd.l:1996(E)
4 Changes to Definitions
(Add the following new definitions to ITU-T Rec. X.680 I ISO/IEC 8824-1, maintaining the alphabetical order of
definitions in ITU-T Rec. X.680 I ISO/IEC 8824-l. Note that the alphabetic character appearing in the clause numbers
below will be changed to an appropriate numeric character when the definitions are added to the base document:}
3.8.a extension series: A series of ASN.l types which can be ordered in such a way that each successive type in the
series is formed by the addition of text to the end of the type notation of the immediately preceding type in the series.
NOTE - Both nested and unnested types can be extended.
3.8.b extension marker: A syntactic flag (an ellipsis) that is included in all types that form part of an extension
series.
3.8.~ extension root: An extensible type that is the first type in an extension series. It carries the extension marker
with no additional notation other than comments and whitespace between the extension marker and the matching “1”
or “)“O
NOTE - Only an extension root can be the first type in an extension series.
3.8.d extension addition: One of the added notations in an extension series. For set types and sequence types, each
extension addition is the addition of a single element. For enumerated types it is the addition of a single further
enumeration. For choice types it is the addition of a single further choice. For a constraint it is the addition of a subtype
element.
NOTE - Extension additions are both textually ordered (following the extension marker) and logically ordered (having
increasing tags or enumeration values).
that have the same extension root, and where one was created by adding zero or
3.8.e extension-related: Two types
more extension additions to the other,
3.8.f extensible type: A type with an extension marker.
extensible constraint: A subtype constraint with an extension marker.
3.8.g
The ASN.1 model of type extension
5
(Add this text as a new clause before clause 6 of ITU-T Rec. X. 680 I ISO/IEC 8824-I, using the same clause heading as
this clause.)
When decoding an extensible type, a decoder may detect:
the absence of expected extension additions in a sequence or set type; or
a>
b) the presence of arbitrary unexpected extension additions above those defined (if any) in a sequence or set
type, or of an unknown alternative in a choice type, or an unknown enumeration in an enumerated type, or
of an unexpected length or value of a type whose constraint is extensible.
In formal terms, an abstract syntax defined by the extensible type “X” contains not only the values of type “X”, but also
the values of all types that are extension-related to “X”. Thus, the decoding process never signals an error when either of
the above situations (a or b) is detected. The action that is taken in each situation is a matter for the application layer
designer to specify.
NOTE - Frequently the action will be to ignore the presence of unexpected additional extensions, and to use a default
value or a “missing” indicator for expected extension additions that are absent.
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, or to some third party), provided that the same transfer syntax
is used on the subsequent transmission.
Extensibility requirements on encoding rules
6
(Add this text as a new clause to ITU-T Rec. X.680 I ISO/IEC 8824-l before clause 6 and after the newly added clause
above, using the same clause heading as this clause:)
ITU-T Rec. X.680 (1994)/Amd.l(1995 E)
2
---------------------- Page: 6 ----------------------
ISOnEC 8824-1:1995/Amd.l:1996(E)
6.1 All ASN. 1 encoding rules shall allow the encoding of values of an extensible type “X” in such a way that they
can be decoded using an extensible type “Y” that is extension-related to “X”. Further, 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 “2” that is
extension related to “Y” (and hence “X” also).
NOTE - Types “X”, “Y” and “2” may appear in any order in the extension series.
If a value of an extensible type ‘IX” is encoded and then relayed (directly or through a relaying application using
extension-related type “2”) to another application that decodes the value using extensible type “Y” that is extension-
related to “X”, then the decoder using type “Y” obtains an abstract value composed of:
n abstract value of the extension root type;
a>
n abstract value of each extension addition that is present in both “X” and “Y”;
W
delimited encoding for each extension addition (if any) that is in “X” but not in “Y”,
C)
The encodings in c) shall be capable of being included in a later encoding of a value of “Y”, if so required by the
application. That encoding shall be a valid encoding of a value of “X”.
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, while system B is using an extension-related type (type “Y”) that has two
extension additions where each is an optional integer type, 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. Moreover, A must be able to re-encode the value of “X” with a
value present for the first integer type, followed by the second integer value received from B, if so required by the
application protocol.
6.2 All ASN.l 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, then it is successfully decoded, otherwise 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.
63 . All ASN.l 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, then
it is successfully decoded, 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.
In all cases, 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 - All variants of the Basic Encoding Rules of ASN.1 and the Packed Encoding Rules of ASN.l satisfy all these
requirements.
7 Changes to Module Definition
{Change the productions in IO. I of ITU-T Rec. X.680 I ISO/IEC 8824-l to read:]
ModuleDefinition : :=
ModuleIdentifier
DEFINITIONS
TagDefault
ExtensionDefault
11
::=lf
BEGIN
ModuleBody
END
ExtensionDefault : :=
EXTENSIBILITY IMPLIED I empty
[All other productions in IO.1 remain the same]
{Insert a new clause after 10.3 in ITU-T Rec. X.680 I ISO/IEC 8824-l:/
10.3bis 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 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.
ITU-T Rec. X.680 (1994)/Amd.l(1995 E)
---------------------- Page: 7 ----------------------
ISO/IEC 8824-1:1995/Amd.l:1996(E)
8 Change to production for ValueSet
{Replace the production for ValueSet in 13.5 of ITU-T Rec. X.6
...
ISO/CEI
NORME
I NTER NATIONALE 8824- I
Première édition
1995-1 0-1 5
AMENDEMENT 1
1996-05-01
Technologies de l'information - Notation
de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base
AMENDEMENT 1 : Règles d'extensibilité
Information technology - Abstract Syntax Notation One (ASN. 1):
Specification of basic notation
AMENDMENT I: Rules of extensibility
Numéro de référence
ISO/CEI 8824-1:1995/Amd.l:1996(F)
---------------------- Page: 1 ----------------------
ISO/CEI 8824-1: 1995/Amd.l:1996(F)
Sommaire
Page
....................................................................................................................................
1 Domaine d'application 1
2 Références normatives . 1
1
2.1 Recommandations I Normes internationales identiques .
1
3 Modifications apportées à l'introduction .
2
4 Modifications apportées aux définitions .
2
5 Modèle ASN.l de l'extension de type .
Prescriptions d'extensibilité sur les règles de codage . 3
6
Modifications apportées à la définition de module . 3
7
8 Modifications apportées à la production d'ensemble d'éléments ValueSet . 4
Modifications apportées à la définition des types et valeurs . 4
9
10 Modifications apportées à la notation du type énuméré (ENUMERATED) . 4
11 Modifications apportées à la notation des types séquence . 5
12 Modifications apportées à la notation des types ensemble (SET) . 5
13 Modifications apportées à la notation des types choix (CHOICE) . 6
Modifications apportées à la notation des types contraints . 6
14
Modifications apportées à la notation des identificateurs d'exception . 6
15
16 Modifications apportées à la spécification des ensembles d'éléments . 7
Annexe A . Annexe didactique sur le modèle ASN . 1 d'extension de type . 8
O ISOKEI 1996
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'éditeur .
ISO/CEI Copyright Office Case postale 56 CH-121 I Genève 20 Suisse
Imprimé en Suisse
..
11
---------------------- Page: 2 ----------------------
~
O ISO/CEI ISO/CEI 8824- 1: 1995lAmd.l: 1996(F)
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de 1’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de 1’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec I’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
L‘Amendement 1 à la Norme internationale ISO/CEI 8824-1:1995 a été élaboré par
Technologies de l’information, sous-
le comité technique mixte ISO/CEI JTC 1,
comité SC 21, Interconnexion des systèmes ouverts, gestion des données et
traitement distribué ouvert, en collaboration avec I’UIT-T. Le texte identique est
publié en tant que Rec. UIT-T X.680/Amd.l.
...
111
---------------------- Page: 3 ----------------------
ISOKEI 8824-1: 1995/Amd.l:1996(F) 0 ISOKEI
l
Introduction
I
La présente Recommandation I Norme internationale explicite les modifications apportées à la Rec. UT-T X.680 I
ISOKEI 8824-1 pour prendre en charge les règles d'extensibilité ASN.l.
Les règles d'extensibilité ASN.1 précisent comment écrire un module ASN.l de façon à permettre une évolution
progressive vers une nouvelle version de spécification ASN.l. La nouvelle version peut différer de l'ancienne par l'ajout
de nouvelles composantes à une production de type ensemble, séquence ou choix, par l'ajout de nouveaux éléments à un
type énuméré, par la relaxation de contraintes imposées à la spécification dun sous-type. Une migration par étapes vers
une nouvelle version dune spécification ASN. 1 devra permettre à des entités homologues en communication à travers le
réseau d'avoir une connaissance différente de l'ensemble des valeurs permises par la syntaxe abstraite, et d'être quand
même capables de communiquer entre elles sans qu'aucune d'elles ne sache si l'entité homologue a une connaissan
"O
différente de l'ensemble des valeurs considérées par la spécification de syntaxe abstraite.
Des entités A, B, C et D initialement homologues pourront par exemple avoir des vues identiques des types de valeurs
pouvant être échangés. En supposant que la spécification ASN.l qui décrit ces valeurs a été définie à l'origine en gardant
à l'esprit la possibilité d'extension de cette spécification, il sera possible d'effectuer une telle extension en ajoutant par
exemple de nouvelles composantes à une production du type séquence, créant ainsi une nouvelle version de spécification
ASN.l. Les entités homologues A et B adopteront par exemple immédiatement la nouvelle version, alors que les entités
C et D continueront à utiliser l'ancienne, les quatre entités continuant à communiquer entre elles sans difficulté du fait
que la production du type séquence a été déclarée à l'origine comme étant extensible. Lorsque les deux entités A et B
échangent une valeur du type séquence étendu, elles verront toutes deux les nouvelles composantes ajoutées au type
séquence (si celles-ci sont transmises). Si l'entité A (ou B) transmet un message contenant la nouvelle composante à
l'entité C (ou D), le message apparaiîa à C au niveau abstrait (c'est-à-dire après décodage) sans les composantes
nouvelles; seules les composantes de la structure séquence d'origine seront vues. Si l'entité C (ou D) transmet un
message à l'entité A (ou B), le message ne contiendra (bien sûr) aucune des nouvelles composantes; un tel message
apparaîîa à l'entité A comme si une entité homologue disposant de la même version de la spécification ASN.l (l'entité B
par exemple) lui avait transmis un message sans aucune des composantes nouvelles. Les entités C et D continueront
quant à elles à échanger les messages de la même façon qu'auparavant.
iv
---------------------- Page: 4 ----------------------
ISO/CEI 8824-1 : 1995/Amd.l: 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION - NOTATION DE SYNTAXE ABSTRAITE
NUMÉRO UN (ASN.l): SPÉCIFICATION DE LA NOTATION DE BASE
AMENDEMENT 1
(à la Rec. X.680 I ISO/CEI 8824-1)
Règles d'extensibilité
Domaine d'application
La présente Recommandation I Norme internationale précise les modifications à apporter à la Rec. UIT-T X.680 I
ISOKEI 8824-1 pour prendre en charge les règles d'extensibilité ASN. 1.
2 Références normatives
Les Recommandations et les Normes internationales suivantes contiennent des dispositions qui, par suite de la référence
qui y est faite dans le présent document, constituent des dispositions valables pour la présente Recommandation I Norme
internationale. Au moment de la publication, les éditions indiquées étaient en vigueur. Toute Recommandation et
Norme internationale étant sujettes à révision, les utilisateurs de la présente Recommandation I Norme internationale
à étudier la possibilité d'appliquer les éditions les plus récentes des Recommandations et Normes indiquées
sont invités
ci-après. Les membres de la CE1 et de 1ïSO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de WIT tient à jour une liste des Recommandations UIT-T en vigueur.
2.1 Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.680 (1994) I ISO/CEI 8824-1:1995, Technologies de l'information - Notation
de syntaxe abstraite numéro un: Spécification de la notation de base.
-
Recommandation UIT-T X.682 (1994) I ISOKEI 8824-3: 1995, Technologies de l'information - Notation
a
de syntaxe abstraite numéro un: Spécification des contraintes.
-
Recommandation UIT-T X.683 (1994) I ISO/CEI 8824-4: 1995, Technologies de l'information - Notation
de syntaxe abstraite numéro un: Paramétrage des spécifications de la notation de syntaxe abstraite
numéro un.
I
-
Recommandation UIT-T X.690 (1994) I ISOKEI 8825-1:1995, Technologies de l'infomuztion - Règles de
codage de l'ASN.1: Spécification des règles de codage de base, des règles de codage canoniques et des
I règles de codage distinctives.
-
Recommandation UIT-T X.691 (1995) 1 ISOKEI 8825-2:1996, Technologies de l'information - Règles de
codage de l'ASN.l: Règles de codage en paquets.
3 Modifications apportées à l'introduction
[Ajouter le texte suivant à l'introduction de la Rec. UIT-T X.680 I ISOKEI 8824-1 juste avant le paragraphe
commençantpar «Les articles 8 à 31 inclus . >>:}
Une spécification ASN. 1 sera établie initialement avec un ensemble de types ASN. 1 complètement définis.
Ultérieurement, il pourra s'avérer nécessaire de modifier ces types (généralement en ajoutant une nouvelle composante à
un type séquence ou ensemble). Si une telle modification doit conserver la possibilité pour les applications utilisant les
---------------------- Page: 5 ----------------------
ISO/CEI 8824-1 : 1999Amd.l : 1996 (F)
anciennes définitions de types dinterfonctionner de manière parfaitement définie avec les applications utilisant les
nouvelles définitions de types, les règles de codage doivent en fournir les moyens. La notation ASN.l prend en charge
l'inclusion d'un marqueur d'extension sur un certain nombre de types. Un tel marqueur signale aux règles de codage
l'intention du concepteur de considérer ce type comme un élément appartenant à une suite de types liés (les versions du
même type initial) appelée suite d'extension, et que les règles d'extension doivent permettre le transfert d'informations
entre applications utilisant des types différents mais faisant partie de la même suite d'extension.
4 Modifications apportées aux définitions
{Ajouter les nouvelles définitions suivantes à celles de la Rec. UIT-T X.680 I ISO/CEI 8824-1. Le caractère alphabétique
apparaissant après le numéro d'article sera remplacé par le numéro approprié une fois les définitions insérées dans le
document de base:)
suite d'extension: Suite de types ASN. 1 qui peuvent être ordonnés de telle manière que chaque type de la suite
3.8.a
soit formé par l'ajout dun texte à la fin de la notation du type qui le précède immédiatement dans la suite.
NOTE - I1 est possible d'étendre les types aussi bien imbriqués que non imbriqués.
3.8.b marqueur d'extension: Indicateur syntaxique (points de suspension) inclus dans tous les types faisant partie
d'une suite d'extension.
racine d'extension: Type extensible qui est le premier dune suite d'extension. I1 comporte le marqueur
3.8.c
d'extension sans autre notation supplémentaire que des commentaires ou des espacements entre le marqueur et la.
«)» ou l'accolade a}>> de fermeture de la déclaration de type.
parenthèse
NOTE - Seule une racine d'extension peut être le premier élément d'une suite d'extension.
3.8.d addition d'extension: Une des notations ajoutées dans une série d'extension. Pour les types ensemble et les
un type énuméré, il s'agit de
types séquence, chaque addition d'extension est l'addition dun élément simple. Pour
l'addition d'un seul élément d'énumération. Pour le type choix, il s'agit de l'addition dun seul élément de choix
supplémentaire. Pour une contrainte, il s'agit de l'addition dun élément de sous-type.
NOTE - Les additions d'extension sont ordonnées à la fois textuellement (à la suite du marqueur d'extension) et
logiquement (leurs valeurs d'étiquetage vont croissant).
3.8.e de même extension: Deux types ayant la même racine d'extension et dont l'un a été créé en ajoutant zéro, une
ou plusieurs additions d'extension h l'autre.
Type comportant un marqueur d'extension.
3.8.f type extensible:
contrainte extensible: Contrainte de sous-type comportant un marqueur d'extension.
3.8.g
5 Modèle ASN.l de l'extension de type
e
{Ajouter le texte suivant comme nouvel article avant l'article 6 de la Rec. UIT-T X.680 I ISO/CEI 8824-1, en utilisant
l'en-tête du présent article.}
Lors du décodage d'un type extensible, un décodeur peut détecter:
l'absence d'additions d'extension prévues dans le type séquence ou ensemble;
a)
la présence d'additions d'extension imprévues quelconques venant éventuellement s'ajouter au type
b)
séquence ou ensemble, ou une alternative inconnue dans un type choix, ou un élément inconnu dans un
type énuméré, ou une longueur ou valeur imprévue dans un type de contrainte extensible.
Formellement, une syntaxe abstraite définie par le type extensible «X» ne contient pas seulement les valeurs du
type «X», mais aussi les valeurs de tous les types de même extension que «X». Le processus de décodage ne signale
donc jamais d'erreur lorsqu'il détecte une des situations ci-dessus a) ou b). Les mesures à prendre dans chacune de ces
situations doivent être spécifiées par le concepteur au niveau de la couche d'application.
NOTE -La mesure prise sera fréquemment d'ignorer la présence d'extensions imprévues, et d'utiliser une valeur par défaut
ou un indicateur «absent» pour les extensions prévues manquantes.
Les additions d'extension imprévues détectées par le décodeur dans un type extensible peuvent être incluses
ultérieurement dans le codage de ce type (pour le renvoyer à l'expéditeur ou le retransmettre à une tierce partie), sous
réserve que la même syntaxe de transfert soit utilisée dans la transmission suivante.
2 Rec. UIT-T X.680 (1994)/Amd.l(1995 F)
---------------------- Page: 6 ----------------------
ISO/CEI 8824-1 : 1999Amd.l: 1996 (F)
Prescriptions d'extensibilité sur les règles de codage
6
[Ajouter le texte suivant comme nouvel article de la Rec. UIT-T X.680 I ISOKEI 8824-1 avant l'article 6 et après
l'article nouvellement créé ci-dessus, en utilisant l'en-tête du présent article.}
6.1 Toutes les règles de codage ASN.l permettront le codage des valeurs dun type extensible «X» de telle façon
qu'elles puissent être décodées en utilisant un type extensible «Y» de même extension que le type «X». Les règles de
codage permettront en outre de recoder par le type «Y» les valeurs de type «X» précédemment décodées avec le
type «Y», puis de les décoder avec un troisième type extensible «Z» de même extension que «Y» (et donc que «X»).
NOTE - Les types «X», «Y» et «Z» peuvent apparaître dans un ordre quelconque dans la suite d'extension.
Si une valeur dun type extensible «X» est codée puis relayée (directement ou par l'intermédiaire d'une application relais
utilisant un type «Z» de même extension) vers une autre application qui la décode en utilisant le type extensible «Y» de
même extension que «X», le décodeur utilisant le type «Y» obtiendra une valeur abstraite composée des éléments
suivants:
une valeur abstraite du type racine d'extension;
a)
une valeur abstraite de chaque addition d'extension présente à la fois dans les types «X» et «Y»;
b)
un codage déterminé de chaque addition d'extension (s'il y en a) présente dans «X» mais pas dans «Y».
c)
Les codages de l'alinéa c) pourront être inclus dans un codage ultérieur de la valeur de type «Y» si l'application le
nécessite. Un tel codage sera un codage valide dune valeur du type ex».
Exemple: supposons qu'un système A utilise un type racine extensible (le type «X») de type séquence ou ensemble avec
une extension de type entier optionnel, alors que le système B utilise un type de même extension (le type «Y») ayant
deux extensions de type entier optionnel. Si le système B transmet alors une valeur du type «Y» omettant la valeur
entière de la première extension et comprenant celle de la seconde, le système A ne doit pas confondre le codage reçu
avec celui d'une valeur de type «X» comprenant la première (et unique) addition d'extension. De plus, Adoit être
capable de recoder la valeur de «X» avec une valeur présente pour le premier entier, suivi de la deuxième valeur entière
reçue de B si le protocole d'application le nécessite.
6.2 Toutes les règles de codage ASN. 1 spécifieront le codage et le décodage dune valeur de type énuméré ou de
type choix de telle manière que si la valeur transmise appartient à l'ensemble des additions d'extension possédées en
I
commun par le codeur et le décodeur, elle puisse être décodée avec succès, et si elle n'appartient pas à cet ensemble, que
le décodeur puisse en délimiter le codage et l'identifier comme une valeur appartenant à une addition d'extension
(inconnue).
I 6.3 Toutes les règles de codage ASN.l spécifieront le codage et le décodage de types soumis à des contraintes
extensibles de telle manière que si la valeur transmise appartient à l'ensemble des additions d'extension possédées en
commun par le codeur et le décodeur, elle puisse être décodée avec succès, et si elle n'appartient pas à cet ensemble, que
le décodeur puisse en délimiter le codage et l'identifier comme une valeur appartenant à une addition d'extension
(inconnue).
Dans tous les cas, la présence d'additions d'extension n'affectera en rien la possibilité de reconnaître les derniers éléments
lorsqu'un type muni dun marqueur d'extension est imbriqué dans un autre type quelconque.
NOTE - Toutes les variantes des règles de codage de base BER et des règles de codage compactes PER de I'ASN. 1
satisfont à ces prescriptions.
7 Modifications apportées à la définition de module
[Modifer les productions du paragraphe 10.1 de la Rec. UIT-T X.680 I ISO/CEI 8824-1 de la manière suivante:)
ModuleDefinition ::=
Moduleldentifier
DEFINITIONS
TagDefault
ExtensionDefault
ll.-ll
. .-
Rec. UIT-T X.680 (1994)/Amd.l(1995 F)
3
---------------------- Page: 7 ----------------------
ISO/CEI 8824-1 : 1995/Amd.l: 1996 (F)
BEGIN
ModuleBody
END
ExtensionDefault ::=
EXTENSIBILITY IMPLIED I empty
{Les autres productions du paragraphe I O. 1 restent inchangées.]
{Insérer un nouveau paragraphe après le paragraphe 10.3 de la Rec. UIT-T X.680 I ISO/CEI 8824-1:)
10.3 bis L'option «EXTENSIBILITY IMPLIED» est équivalente à l'insertion dun marqueur d'extension (.) dans le
texte de la définition de chaque type, dans un module pour lequel cette option est permise. Si «EXTENSIBILITY
IMPLIED» ne figure pas, l'extensibilité n'est assurée que pour les types du module où figure explicitement un marqueur
d'extension.
NOTE - L'option «EXTENSIBILITY IMPLIED» ne s'applique qu'à des types. Elle n'a pas dincidence sur les ensembles
d'objets.
8 Modifications apportées à la production d'ensemble d'éléments ValueSet
{Remplacer la production ValueSet du paragraphe 13.5 de la Rec. UIT-T X.680 I ISO/CEI 8824-1 par:)
ValueSet ::= "{" ElementSetSpecs "}"
9 Modifications apportées à la définition des types et valeurs
{Insérer le (nouveau) paragraphe 14.12 dans la Rec. UIT-T X.680 I ISOKEI 8824-1:)
14.12 La présence implicite ou explicite dun marqueur d'extension dans la définition dun type n'a aucun ef
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.