La couche présentation La syntaxe ASN.1

(1)

La couche présentation La syntaxe ASN.1

Michel Gardie

(2)

Informations

Ce document a subi de nombreuses révisions au cours de sa longue carrière. Mais, comme je ne suis qu’un simple humain avec plein de défauts, je ne peux prétendre à la perfection. En conséquence de quoi, j’affirme que ce document risque de comporter certaines erreurs techniques, ou bien certaines données obsolètes, et enfin, j’affirme qu’il est probable que kelkes fôtes d’ortografes puysse enkorre tréner.

Pour l’historique du document :

Les premières versions du document ont été écrites en LaTeX.

Puis, FrameMaker^® 5.1 a servi de plateforme pour la rédaction des versions subséquentes.

StarOffice^® 5.2 est l’outil qui a servi à produire cette version à partir des sources FrameMaker^®, suivi par OpenOffice 1.0.1 comme plateforme finale de rédaction.

Imprimatur: jeudi 5 février 2004 à 11:49

(3)

Table des matières

Chapitre 1. La couche présentation... 6

1.1. Rôle...6

1.1.1. Préservation de la sémantique... 6

1.1.2. Négociation des syntaxes de transfert... 8

1.1.3. Accès aux services fournis par la couche session... 9

1.2. Mise en œuvre...9

1.3. Syntaxes... 9

1.3.1. Syntaxe abstraite... 9

1.3.2. Syntaxe de transfert...9

1.4. Contexte de présentation...10

1.5. Négociation des contextes de présentation... 10

1.6. Accès aux services session... 11

Chapitre 2. Introduction à ASN.1...13

2.1. Nécessité d’une syntaxe commune...13

2.2. Définition d’ASN.1... 14

2.3. Types de base ASN.1...14

2.4. Construction de nouveaux types... 15

2.4.1. Etiquetage... 15

2.4.2. Outils de construction... 16

2.4.2.1. Outil SEQUENCE...16

2.4.2.2. Outil SET...16

2.4.2.3. Outil CHOICE...17

2.5. Informations représentées en ASN.1...18

2.6. Codage des valeurs... 18

2.7. Usages d’ASN.1...19

Chapitre 3. Codage de base ASN.1... 20

3.1. Codage des octets de type...21

3.1.1. Etiquette d’un type...21

3.1.2. Classe d’un type... 22

3.1.3. Forme d’un type... 23

3.2. Codage des octets de longueur... 23

3.2.1. Longueur indéfinie...23

3.2.2. Longueur définie... 23

3.3. Codage des octets de valeur...24

Chapitre 4. Principaux types ASN.1... 25

4.1. BOOLEAN... 25

4.2. INTEGER... 25

4.3. ENUMERATED...26

4.4. REAL... 27

4.5. BITSTRING... 28

4.6. OCTETSTRING...29

4.7. NULL...30

4.8. SEQUENCE... 30

4.9. SEQUENCE OF... 32

4.10. SET... 32

(4)

4.11. SET OF... 33

4.12. CHOICE... 33

4.13. TYPE SELECTION (<)... 34

4.14. ANY / ANY DEFINED BY... 35

4.15. OBJECTIDENTIFIER...35

4.16. TYPES CHAINES DE CARACTERES... 37

4.17. TYPES TEMPORELS...38

4.17.1. GENERALIZEDTIME... 38

4.17.2. UTCTIME...39

4.18. TYPES UTILES... 39

4.18.1. OBJECTDESCRIPTOR... 39

4.18.2. EXTERNAL...39

4.19. SOUS-TYPES... 40

4.19.1. Valeurs simples...40

4.19.2. Sous-types inclus...40

4.19.3. Intervalles... 40

4.19.4. Contraintes sur les tailles...40

4.19.5. Alphabets autorisés...40

Chapitre 5. Le protocole X.226... 41

5.1. Présentation du protocole X.226... 41

5.1.1. Relations avec la couche application... 41

5.1.2. Relations avec la couche session... 41

5.1.3. Fonctions de la couche présentation...42

5.1.4. Négociation de la syntaxe...42

5.1.5. Définition de contextes de présentation... 42

5.1.6. Gestion de l’ensemble des contextes définis (DCS)... 42

5.2. Le protocole et le service de présentation...42

5.2.1. Les primitives... 43

5.2.2. Les PPDU...44

5.2.3. Structure des PPDU... 45

5.2.4. Particularités du protocole... 45

5.2.4.1. Transfert d’informations... 45

5.2.4.2. Gestion des contextes... 45

5.2.4.3. Restauration des contextes... 46

5.2.4.4. Unités fonctionnelles de session... 46

5.2.4.5. Unités fonctionnelles de session nécessaires...46

5.2.4.6. Données utilisateur... 46

Chapitre 6. Tableau récapitulatif des types ASN.1... 48

Chapitre 7. Structure des PPDU du protocole X226...49

(5)

Index des figures

Figure 1. Enchaînement des syntaxes... 8

Figure 2. Négociation des contextes de présentation... 8

Figure 3. Accès aux services session... 12

Figure 4. Principe de fonctionnement d'ASN.1... 13

Figure 5. Indépendance offerte par ASN.1... 14

Figure 6. Format avec longueur définie... 20

Figure 7. Format avec longueur indéfinie... 20

Figure 8. Codage du type sur plusieurs octets... 22

Figure 9. Champ de longueur indiquant une longueur inférieure à 128 ... 24

Figure 10. Champ de longueur indiquant une longueur supérieure à 127... 24

(6)

Chapitre 1. La couche présentation

La couche présentation est complètement normalisée. Les deux organismes de normalisation internationale (ITU-T et ISO) ont proposé des textes communs décrivant, d’une part l’accès aux services fournis par la couche présentation ainsi que le protocole de cette couche, et d’autre part une notation de syntaxe abstraite et une syntaxe de transfert (règles de codage).

Tableau 1. Normes utilisées

Nature Norme ISO Recommandation ITU-T

Service de présentation 8822 X.216

Protocole de présentation 8823-1 X.226

Syntaxe abstraite ASN.1 8824 X.680

Syntaxes de transfert BER, CER et DER 8825-1 X.690

Syntaxe de transfert PER 8825-2 X.691

1.1. Rôle

La couche présentation se charge de la représentation des informations échangées entre systèmes ouverts.

Il peut y avoir un problème d’interfonctionnement lorsque, par exemple, deux calculateurs ayant une gestion des bits de poids forts et de poids faibles différentes (« big-endian » opposé à « little- endian ») doivent échanger des données. La couche présentation a été conçue pour remédier à ce type de problème.

La couche présentation va par conséquent offrir plusieurs fonctionnalités, parmi lesquelles les plus caractéristiques sont :

1. la préservation de la sémantique des données échangées, 2. la négociation des syntaxes de transfert,

3. l'accès des applications aux services de la couche session.

1.1.1. Préservation de la sémantique

Ce point est important. Cela signifie qu’il n’est pas obligatoire que la représentation (syntaxe) des données soit préservée, tant que la sémantique reste inchangée.

En effet, les applications désirant communiquer, peuvent fonctionner sur des équipements informatiques :

1. de constructeurs différents (environnement matériel différent) ; 2. gérés de façon différentes (systèmes d’exploitation différents) ; 3. de niveaux de complexité différents (processeurs différents) ;

4. les applications peuvent avoir été développés à l’aide de langages de programmation différents.

(7)

Ceci conduit naturellement à ce que la représentation des données particulières à chaque application soit dépendante des systèmes réels ; ce type de représentation de données est appelée syntaxe réelle.

Pour communiquer, les applications vont par contre être contraintes de convenir d’une représentation commune des données qu’elles échangeront. Une telle représentation commune des données est appelée syntaxe de transfert.

Il est tout à fait possible que plusieurs syntaxes de transfert puissent coexister au sein d'une même application.

Une syntaxe de transfert doit permettre de coder l’information indépendamment de la manière dont celle-ci est représentée dans un système réel.

Lors du développement d’une application, il est alors nécessaire d’écrire des fonctions permettant de passer de la syntaxe réelle à la syntaxe de transfert (et réciproquement).

De façon à pouvoir écrire facilement les fonctions de codage et de décodage qui permettent de passer d’une syntaxe réelle à une syntaxe de transfert (et vice-versa), les données applicatives qui seront échangées sont alors représentées à l’aide d’une notation particulière. Par exemple, on peut convenir d’utiliser le langage C pour représenter des données (c’est le cas lorsque les applications utiliseront la syntaxe de transfert XDR¹). Le langage C permet en effet de représenter des données en étant indépendant du processeur et du système d’exploitation. Par contre, cette représentation est évidemment dépendante du langage de programmation !! C’est le moins qu’on puisse dire. On peut également souhaiter s’abstraire du langage de programmation ; dans ce cas, il faut utiliser une autre notation ; ASN.1 est un exemple de notation qui répond à ces trois critères : indépendance vis-à-vis du processeur, du système d’exploitation et enfin du langage de programmation.

On appelle syntaxe abstraite les données applicatives représentées à l’aide d’une notation indépendante des critères réels. La notation est alors appelée notation de syntaxe abstraite.

Une syntaxe abstraite préserve donc le contenu sémantique des données, tout en étant indépendante de critères tels que : processeurs, systèmes d’exploitation, langages de programmation, etc.

La couche présentation a pour charge de déterminer par négociation, le plus souvent au début d’une connexion, la syntaxe de transfert qui sera utilisée pour la représentation commune des données applicatives. Cette négociation fait donc appel à la notion de syntaxe de transfert (c’est-à-dire les données telles qu’elles circuleront sur les réseaux de communication) et à la notion de syntaxe abstraite (c’est-à-dire les données que l’on cherche à échanger). Le lien entre une syntaxe abstraite et une syntaxe de transfert s’appelle un contexte de présentation.

La figure 1 présente les différents types de syntaxes utilisées et les associations possibles entre syntaxes.

Prenons un exemple dans cette figure : l’application A3 possède deux groupes de données réprésentées respectivement par les syntaxes abstraites SA4 et SA5. Chacun de ces groupes possède bien évidemment une représentation réelle SR4 et SR5. Le concepteur de l’application a seulement décrit les données sous leur forme abstraite, puis a utilisé un compilateur pour générer automatiquement les syntaxes réelles correspondantes ainsi que les fonctions de codage et de décodage qui permettent de passer d’une syntaxe réelle vers une syntaxe de transfert. Toutefois, le compilateur a généré pour le groupe SA4 deux ensembles de fonctions de codage et de décodage vers les syntaxes de transfert ST2 et ST3. Autrement dit, il existe deux contextes de présentation possibles pour les données SA4 : un contexte SA4-ST2 et un contexte SA4-ST3. C’est la responsabilité de la couche présentation de déterminer lequel des contextes est à utiliser. Les deux contextes peuvent en outre être utilisés simultanément.

1 XDR : eXternal Data Representation ; RFC 1014, RFC 1832

(8)

1.1.2. Négociation des syntaxes de transfert

Il est possible qu’une syntaxe abstraite puisse être représentée à l’aide de plusieurs syntaxes de transfert. Il faut donc que les deux entités de présentation se mettent d’accord sur la syntaxe de transfert qui sera finalement utilisée pour représenter une syntaxe abstraite.

La figure 2 ci-dessous donne un exemple de négociation des syntaxes. Le système A est capable de coder des données (représentées abstraitement à l’aide de la syntaxe abstraite SA1) selon deux syntaxes de transfert ST1 et ST2. Le système A propose donc au système B de choisir le mode de codage.

Le système B ne sait coder que selon la syntaxe de transfert ST1. Il répond par conséquent que le codage des données sera ST1. Le système A codera dorénavant les données selon cette syntaxe de transfert.

Figure 1. Enchaînement des syntaxes

Figure 2. Négociation des contextes de présentation

7 6

SR1 SR2 SR3 SR4 SR5 SR6

ST1

A1 A2 A3 A4

SA1 SA2 SA3 SA4 SA5 SA6

ST2 ST3 ST4 ST5

Contexte de présentation SR = syntaxe réelle SA = syntaxe abstraite ST = syntaxe de transfert

7

6

[sa1, (st1, st2)]

[sa1, st1]

SR2

SA1 SA1

ST1 ou ST2

ST1

SR1

(9)

L’association d’une syntaxe abstraite et d’une syntaxe de transfert forme ce que l’on appelle un contexte de présentation.

1.1.3. Accès aux services fournis par la couche session

Ceci est fondamental. En effet, la couche session offre aux applications des services facilitant la synchronisation de données. La couche présentation ne doit pas interdire l’accès à ces services. Il en résulte que la couche présentation offre l’intégralité des services de session.

1.2. Mise en œuvre

La réalisation concrète des concepts présentés ci-dessus se fait généralement de la manière suivante.

La syntaxe abstraite est utilisée lors de la conception des applications pour décrire la structure des données manipulées par ces applications. Ceci permet de générer automatiquement les structures réelles (le plus souvent dépendantes du système d’exploitation, du processeur et du langage de programmation utilisés) ainsi que les procédures de codage et de décodage permettant de passer de la syntaxe réelle à la syntaxe de transfert (et réciproquement). Un contexte de présentation se matérialise alors sous la forme d’interfaces programmatiques et de bibliothèques.

1.3. Syntaxes

1.3.1. Syntaxe abstraite

Définition 1. Une syntaxe abstraite est la représentation sous forme abstraite, indépendante de la représentation réelle, des données de chaque application ; c’est une spécification de données de la couche application (ou d’informations de contrôle d’un protocole d’application) en appliquant des règles de notation indépendantes de la technique de codage utilisée pour représenter ces données.

Une syntaxe abstraite est identifiée par un nom ; ceci est nécessaire car il peut arriver qu’une application gère plusieurs syntaxes abstraites.

ASN.1 est un langage de description permettant de noter des syntaxes abstraites.

Un nom de syntaxe est un OBJECTIDENTIFIER.

Quelques exemples :

le nom de la syntaxe abstraite utilisée par l’élément de service applicatif ACSE (X.227) est :

{joint-iso-ccitt (2), contrôle-association (2), syntaxe-abstraite (1), apdus (0), version (1)}

Celle de RTSE (X.228) est :

{joint-iso-ccitt (2), transfert-fiable (3), syntaxe-abstraite (2)}

Celle de ROSE (X.229) est :

{joint-iso-ccitt (2), opérations-distantes (4), apdus (1)}

(10)

1.3.2. Syntaxe de transfert

Définition 2. Une syntaxe de transfert est un ensemble de règles de codage (et de décodage) permettant de générer un flot d’octets (ou binaire) à partir d’une syntaxe réelle ou abstraite.

Le codage de base d’ASN.1 (BER²) est une syntaxe de transfert.

Une syntaxe de transfert est également identifiée par un nom qui est, bien sûr, un OBJECTIDENTIFIER. Ceci est également nécessaire car une application peut éventuellement utiliser plusieurs syntaxes de transfert.

Exemple de nom de syntaxe de transfert : le nom de la syntaxe BER est :

{joint-iso-ccitt (2), asn1 (1), codage-base (1)}

1.4. Contexte de présentation

Un contexte de présentation est l’association d’une syntaxe abstraite et d’une syntaxe de transfert.

Du point de vue de l’utilisateur du service de présentation (autrement dit, du point de vue d’une application), un contexte de présentation représente un environnement selon lequel les valeurs de données de la syntaxe abstraite peuvent être transférées (sous forme d’une chaîne binaire) sans ambiguïté.

Du même point de vue, un contexte de présentation représente une utilisation spécifique distincte d’une syntaxe abstraite. Plusieurs contextes de présentation peuvent être définis pour la même syntaxe abstraite ; des valeurs de données de présentation transmises exprimées selon des contextes de présentation séparés, sont remises exprimées selon ces contextes de présentation séparés.

1.5. Négociation des contextes de présentation

La couche présentation se charge de négocier la syntaxe de transfert. Cette négociation a lieu entre deux entités de présentation lorsqu’un utilisateur (application) fournit le nom d’une syntaxe abstraite qui nécessite une syntaxe de transfert. L’entité de présentation appelante propose pour chaque syntaxe abstraite une liste de syntaxes de transfert compatibles. La négociation réussit si l’entité de présentation appelée fournit comme résultat l’association de la syntaxe abstraite nommée avec une des syntaxes de transfert compatibles. C’est à partir de cet instant qu’est constitué le contexte de présentation.

En général donc, la combinaison d’une syntaxe abstraite et d’une syntaxe de transfert n’est pas nécessairement unique. Il peut être possible de représenter une syntaxe abstraite spécifique par une ou plusieurs syntaxe de transfert ; il peut être également possible d’utiliser une syntaxe de transfert unique pour représenter plusieurs syntaxes abstraites.

Les usagers de la couche présentation manipulent les contextes de présentation. Le service de présentation fournit par conséquent les facilités nécessaires à la définition de contextes de présentation.

Deux services permettent de définir des contextes de présentation :

2 BER : Basic Encoding Rules = règles d'encodage de base

(11)

1. le service de connexion de présentation, 2. le service de modification de contextes.

Lorsque des contextes de présentation sont définis, ils sont ajoutés à un ensemble de contextes définis³ Le service de connexion permet de définir une liste initiale de contextes ; le service de modification permet quant à lui d’ajouter ou de supprimer des contextes, et cela au cours d’une communication.

Un ensemble de contextes de présentation consiste en une liste d’un ou plusieurs éléments ; chaque élément comprend deux composants :

 une identification de contexte de présentation ;

 un nom de syntaxe abstraite.

La raison d’être du composant « identification de contexte » est de permettre la distinction entre les différents contextes de présentation. La couche présentation, bien entendu, doit ajouter à chaque élément de cette liste le nom d’une syntaxe de transfert.

Le tableau suivant résume les définitions concernant les contextes de présentation.

Tableau 2. Contextes de présentation contexte de présentation

identifiant de contexte nom de syntaxe abstraite nom de syntaxe de transfert défini par l’usager (couche application) en tant que paramètre

de service de connexion ou de modifica tion de contexte défini par la couche présentation lors d’une négociation

1.6. Accès aux services session

Les services de session sont fournis aux entités d’application sous la forme de services de présentation. Ceci signifie que les entités d’application doivent gérer et synchroniser les dialogues, et que la couche présentation se comportera comme simple relais pour ce type de services.

Une autre manière de présenter ceci est de dire que la couche présentation est partiellement transparente à certains services.

On peut ainsi, par exemple, définir trois types de service entre la couche application et la couche présentation :

Service de type 1. Ces services sont exclusivement de nature syntaxique (gestion de la syntaxe par exemple). Généralement, la couche présentation transforme ces services en des éléments de protocole de la couche présentation (autrement dit, des PPDU⁴) qui transitent en tant que données au niveau de la couche session⁵.

Service de type 2. Ces services génèrent également des PPDU, mais celles-ci sont complétées et par conséquent véhiculées par des services de session autres que le simple transfert de données (exemple : la PPDU de connexion de présentation est transmise par la SPDU de connexion de session).

3 DCS : Defined Context Set = ensemble de contextes définis

4 PPDU = Presentation Protocol Data Unit = unité de données du protocole de présentation

5 Le service de données utilisé pour les services de type 1 au niveau de la couche session est le service de données typées.

(12)

Service de type 3. Ce sont en réalité des services de session purs (exemple : la pose de point de synchronisation mineur ; on a une totale identité entre une primitive de service PSYNmreq⁶ et une primitive SSYNmreq⁷. La couche présentation ne rajoute rien aux éléments transportés par le point de synchronisation).

6 PSYNmreq = Presentation Synchronisation minor request 7 SSYNmreq = Session Synchronisation minor request

Figure 3. Accès aux services session

Application

Présentation

Session

1 2 3

(13)

(14)

Chapitre 2. Introduction à ASN.1

2.1. Nécessité d’une syntaxe commune

Une application qui échange des données avec une autre application a besoin de se faire comprendre de cette application distante. Or, il est courant que deux applications représentent de manière différente les données qu’elles manipulent. Par exemple, la représentation d’un entier dépend de la nature du processeur ; le codage d’un fichier dépend du système d’exploitation ; la structure des données dépend des applications elles-mêmes, ou plus précisemment du langage de programmation utilisé lors du développement de l’application. Chaque application sur un site donné dispose donc d’une syntaxe réelle pour représenter l’information.

Une solution à ce problème consiste, pour une application, à transformer sa syntaxe réelle propre en la syntaxe réelle de son correspondant. L’inconvénient d’une telle solution est qu’elle exige de chaque application la connaissance et l’interprétation de toutes les syntaxes réelle pouvant exister.

Une autre solution consiste à utiliser une syntaxe commune à toutes les applications. La syntaxe de transfert définie par ASN.1⁸ est une syntaxe commune et par conséquent va faciliter la communication entre deux applications.

Le principe de fonctionnement permettant à deux applications de communiquer est le suivant :

 Au niveau applicatif, les données devant être échangées entre deux entités d’application sont décrites par une syntaxe indépendante des langages de programmation utilisés, des systèmes d’exploitation et des processeurs ; cette syntaxe porte le nom de syntaxe abstraite.

 A partir de la notation de cette syntaxe abstraite, un outil (compilateur) génèrera d’une part la syntaxe réelle de ces données, et d’autre part génèrera un ensemble de fonctions de codage et de décodage (les règles de codage).

8 ASN.1: Abstract Syntax Notation number 1: Notation de Syntaxe Abstraite numéro 1 Figure 4. Principe de fonctionnement d'ASN.1

Syntaxe réelle Syntaxe abstraite

Compilateur

Syntaxe de transfert

Application

Présentation

Session

Règle de codage

(15)

 Lors d’une connexion, la couche présentation transformera la syntaxe réelle en un flot d’octets, appelé syntaxe de transfert, à l’aide des règles de codage. Ce flot d’octets est ensuite transféré via une connexion session.

Pourquoi un tel processus de transformation ? Dans les couches inférieures du modèle de référence OSI, chaque paramètre « données de l’utilisateur » d’une primitive de service est spécifié comme la valeur binaire d’une séquence d’octets. Par contre, dans la couche présentation, la nature des paramètres « données de l’utilisateur » est différente. Les spécifications de la couche application imposent en effet de véhiculer des valeurs de types très complexes, incluant éventuellement des chaînes de caractères de divers jeux.

2.2. Définition d’ASN.1

ASN.1 est un langage pour décrire de manière abstraite les données échangées par des applications de communication. Il est indépendant des applications, des systèmes d’exploitation et des processeurs.

ASN.1 est un ensemble de types de données de base pouvant être réutilisés pour en construire d’autres. C’est également un ensemble de règles de construction permettant de définir de nouveaux types de données. Enfin, c’est un ensemble d’opérateurs de construction utilisés pour définir de nouveaux types.

2.3. Types de base ASN.1

Nous ne donnons, dans le tableau ci-dessous, que quelques exemples de types de données de base et des valeurs possibles pour chacun des types présentés.

Voir le chapitre 4 pour plus d’informations sur les types de base.

Figure 5. Indépendance offerte par ASN.1 ASN.1

Description abstraite

Syntaxe réelle Syntaxe réelle

(16)

Tableau 3. Exemples de types de base

TYPE EXEMPLES DE VALEURS

BOOLEAN TRUE

FALSE

INTEGER 11321

-5

33265790054342334119874565

REAL 31415926 ×10⁻⁵

OCTETSTRING 0A2FEE0025

BITSTRING 011001100010110111100100001

OBJECTIDENTIFIER {iso norme 8571 pci(1)}

{1 0 8571 1}

2.4. Construction de nouveaux types

La description de données passe principalement par la définition de types de données. La notation de syntaxe abstraite ASN.1 offre de nombreux types de base. Toutefois, il est absolument fondamental de ne pas être limité à ces types prédéfinis. Il faut donc disposer de moyens de construction de nouveaux types de données. La notation de syntaxe ASN.1 définit deux méthodes pour construire des types nouveaux :

1. par étiquetage de types existants, qu’ils soient de base ou non ; 2. par utilisation d’outils de construction.

2.4.1. Etiquetage

La façon la plus simple est de présenter le concept d’étiquetage est encore d’en donner un exemple.

Exemple d’étiquetage :

VidéotexString ::= [21] IMPLICIT OCTETSTRING

Dans cet exemple, [21] est la nouvelle étiquette attribuée au type de base OCTETSTRING, donnant ainsi le nouveau type « VidéotexString ». On peut traduire ceci de la manière suivante :

« VidéotexString » est implicitement de la même nature que le type standard « OCTETSTRING », mais l’étiquette standard du type « OCTETSTRING » est remplacée par une nouvelle étiquette : 21.

Autre exemple :

VideotexString ::= [21] OCTETSTRING

Cette fois-ci, l’étiquette 21 est simplement ajoutée à celle du type de base pour donner le nouveau type. L’étiquette du type de base existe toujours. Cette écriture est identique à l’écriture suivante :

VideotexString ::=[21] EXPLICIT OCTETSTRING

(17)

2.4.2. Outils de construction

Nous ne développerons dans ce paragraphe que quelques exemples d’outils de construction. Nous avons choisi bien évidemment les outils les plus couramment utilisés dans ce domaine. Les outils étudiés sont :

 SEQUENCE {...}

 SEQUENCE OF

 SET {...}

 SET OF

 CHOICE {...}

Ces outils peuvent se combiner bien évidemment avec l’étiquetage pour construire de grandes variétés de structures.

2.4.2.1. Outil SEQUENCE

L’outil SEQUENCE permet de créer une structure de données dont chaque élément peut être soit une structure complexe, soit une donnée simple et pour laquelle l’ordre des éléments est fondamental. L’outil SEQUENCE OF est une variante de SEQUENCE.

Exemple :

Personne ::= SEQUENCE{

prénom PRINTABLESTRING, nom PRINTABLESTRING,

père [0] Personne OPTIONAL, mère [1] Personne OPTIONAL}

Dans cet exemple, Personne est un nouveau type décrivant une structure de données décomposée en quatre éléments. Les deux premiers éléments sont du même type (PRINTABLESTRING), mais leur ordre d’apparition dans la structure les identifie sans ambiguïté comme représentant d’abord le prénom de la personne, suivi de son nom. Les deux éléments suivants sont optionnels, et de fait nécessitent d’être étiquetés pour être distingués l’un de l’autre. Leur structure est du type Personne.

La syntaxe autorise en effet la récursivité.

Autre exemple :

Liste-entier ::= SEQUENCE OF INTEGER Prénoms ::= SEQUENCE OF PRINTABLESTRING -- dans l’ordre de l’état civil

Dans ces exemples, Liste-entier et Prénoms sont des types décrivant des structures de données dont tous les éléments sont identiques (en l’occurrence ici des nombres entiers ou des chaînes imprimables), et pour lesquels l’ordre est fondamental ; d’où l’utilisation de l’outil SEQUENCE OF.

2.4.2.2. Outil SET

L’outil SET permet de créer une structure de la même manière que l’outil SEQUENCE, mais cette fois-ci, l’ordre des éléments de la structure n’a pas d’importance. L’outil SET OF est une variante de SET.

(18)

Exemple :

Personne ::= SET{

prénom [0] PRINTABLESTRING, nom [1] PRINTABLESTRING, père [2] Personne OPTIONAL, mère [3] Personne OPTIONAL}

Dans cet exemple, l’ordre des éléments n’a pas, à priori, d’importance. Il est donc possible de donner d’abord le prénom puis le nom, ou bien l’inverse. Dans ces conditions, il est nécessaire d’étiqueter les différents éléments pour les distinguer les uns des autres.

Autre exemple :

Prénoms ::= SET OF PRINTABLESTRING

-- le prénom «usuel» peut être placé en premier

Ici, le type Prénoms représente une liste de chaînes imprimables pour laquelle l’ordre d’apparition des éléments n’a strictement aucune importance (ou bien pour lequel l’ordre serait préjudiciable).

2.4.2.3. Outil CHOICE

L’outil CHOICE permet de créer une structure de données dont le type final sera un des types de la liste proposée par CHOICE.

Exemple :

Personne ::= CHOICE{

prénom [0] PRINTABLESTRING, surnom [1] PRINTABLESTRING}

Dans cet exemple, une personne peut être identifiée par son surnom ou son prénom, mais pas par les deux simultanément. La distinction entre l’une ou l’autre des deux informations se fait par l’étiquette.

Autre exemple :

Valeur ::= CHOICE{

a INTEGER, b REAL}

Dans cet exemple, il est possible de coder une valeur suivant le type entier ou le type réel. La distinction entre les deux types de représentation se fait cette fois-ci de manière implicite car les deux représentations sont différentes par leur type. L’étiquetage des diverses possibilités n’est donc pas utile ici.

Les outils peuvent bien entendu être combinés :

Couple ::= SEQUENCE{

x INTEGER, y CHOICE{

INTEGER, REAL}}

Dans cet exemple, Couple est une structure dont le premier élément est un nombre entier et le second est soit un entier, soit un nombre réel.

(19)

2.5. Informations représentées en ASN.1

La notation ASN.1 va permettre de représenter deux sortes d’informations : 1. les types de données ;

2. les valeurs de données.

Exemple de notation de types de données :

Personne ::= [PRIVATE 1] IMPLICIT SEQUENCE{

nom PRINTABLESTRING,

prénoms SEQUENCE OF PRINTABLESTRING, âge INTEGER,

date-naissance GENERALIZEDTIME, photo BITSTRING,

numéro-S.S. NUMERICSTRING,

situation-maritale ENUMERATED {célibataire(0), marié(1),

divorcé(2), séparé(3), veuf(4)}, conjoint [0] IMPLICIT Personne OPTIONAL,

enfants [1] IMPLICIT SEQUENCE OF Personne OPTIONAL, décédé BOOLEAN}

Parents ::= SEQUENCE{

père [0] IMPLICIT Personne OPTIONAL, mère [1] IMPLICIT Personne OPTIONAL}

Les mots tels que « Personne » ou « Parents » sont de nouvelles définitions de types de données.

Les accolades ({ et }) sont des délimiteurs de constructions. Un identifiant tel que « mère » permet de nommer un champ dans une structure. Un mot tel que « INTEGER » définit un type de base d’ASN.1. L’utilisation du terme « OPTIONAL » permet d’indiquer qu’un champ peut éventuellement être absent. L’utilisation des crochets ([ et ]) permet de définir de nouvelles étiquettes.

Exemple de notation de valeurs de données :

valeur-Entière INTEGER :: 123559 -- un nombre entier valeur-Booléenne BOOLEAN ::= TRUE

valeur-Octet OCTETSTRING ::= ’0A5F342C’H

-- une chaîne hexadécimale chaîne-Bit BITSTRING ::= ’0001110010010001111’B -- une chaîne binaire

Les mots tels que « valeur-Entière » ou « chaîne-Bit » représentent des noms de variables. Le symbole « ::= » est un signe de production permettant de définir comme ici des variables ou comme plus haut des types. Le symbole « -- » permet l’introduction de commentaires.

2.6. Codage des valeurs

La notation abstraite est par définition indépendante des systèmes d’exploitation, des processeurs ; elle ne détermine pas la représentation des valeurs. Toutefois, les couches inférieures à la couche présentation véhiculent des flots d’octets. Il est donc nécessaire de disposer de règles de codage permettant de déterminer la valeurs des octets échangés dans ces couches. Le codage utilisé est du type « TLV » (Type-Longueur-Valeur).

Les règles de codage de base sont définies dans le chapitre 3, page 21.

(20)

2.7. Usages d’ASN.1

Le protocole de la couche présentation est lui-même décrit dans la notation de syntaxe ASN.1.

Donc, au niveau de cette couche, les normes appliquant la notation de syntaxe ASN.1 sont les suivantes :

Tableau 4. Normes au niveau de la couche présentation

Norme Nature

CCITT X.216 [ISO 8822] spécification du service de présentation CCITT X.226 [ISO 8823] spécification du protocole de présentation

Au niveau de la couche application, toutes les normes actuelles utilisent la notation de syntaxe ASN.1. On peut citer par exemple :

1. La messagerie X400⁹ ;

2. Le transfert de fichiers FTAM¹⁰ ; 3. Le système d’annuaire X500 ;

4. Les éléments de service ROSE¹¹, ACSE¹², RTSE¹³ ;

5. Le protocole non normalisé d’administration de réseau SNMP¹⁴. Parmi les autres usages d’ASN.1, on peut citer :

1. HTTP-Next generation ;

2. CMIP (protocole d’administration de réseaux) ; 3. Téléphonie mobile (connexion, commutation) ; 4. Systèmes de commutation (routeurs) ;

5. MHEG, T.120, H.245 (conférences multimedia) ; 6. LDAP¹⁵ (protocole d'accès aux services d'annuaires).

9 A cet égard, il convient de remarquer que la série X.400 (qui correspond à la série des protocoles de messagerie) comportait jusqu’en 1988 la recommandation X.409 qui décrivait la notation de syntaxe ASN.1 (notation de syntaxe abstraite et syntaxe de transfert). Cette recommandation a été retirée de la série X.400 pour être placée dans la série X.200 beaucoup plus générale.

Au passage, le texte de la recommandation a alors été décomposé en deux documents, un pour la description de la notation de syntaxe abstraite (X.208), et un pour la description des règles de codage de base (X.209).

10 File Transfer Access and Management : transfert, accès et gestion de fichiers.

11 Remote Operation Service Element : élément de service d’opérations distantes.

12 Association Control Service Element : élément de service de contrôle d’association.

13 Reliable Transfer Service Element : élément de service de transfert fiable.

14 Simple Network Management Protocol : protocole simple de gestion de réseaux.

15 Lightweight Directory Access Protocol.

(21)

Chapitre 3. Codage de base ASN.1

Le codage des types et valeurs ASN.1 est réalisé en utilisant le principe : Type Longueur Valeur

Deux formats pour le codage existent :

format 1 : longueur définie.

Dans ce format, la valeur est codée sur un nombre d’octets indiqué dans la champ longueur, et l’étiquette du type de cette valeur est donné dans le champ type.

format 2 : longueur indéfinie

Le champ longueur dans ce format ne précise pas la longueur de la valeur, mais indique que celle-ci sera suivi d’un champ de fin de données. La valeur doit dans ces conditions être structurée absolument en éléments codés suivant le premier format, ou suivant le second.

Exemples :

Tableau 5. Codage correct d'un nombre entier (exemple 1)

TYPE LONGUEUR VALEUR

02 04 0102234F

= type entier = longueur définie 16909135

Figure 6. Format avec longueur définie.

Figure 7. Format avec longueur indéfinie.

1 à p octets k octets n octets

TYPE LONGUEUR VALEUR

étiquette (tag) n

1 à p octets 1 octet n octets

TYPE LONGUEUR VALEUR

étiquette (tag) 80h

2 octets

00h 00h

FIN DE CONTENU

(22)

Tableau 6. Codage incorrect d'un nombre entier (exemple 2)

TYPE LONGUEUR VALEUR FIN DE CONTENU

02 80 0102234F 0000

= type entier = longueur indéfinie 16909135

Ici (tableau 6), le codage utilisant une longueur indéfinie est interdit et impossible puisque la valeur codée est un nombre entier, donc atomique. La séquence 0000 peut donc être interprétée comme faisant partie du nombre.

Tableau 7. Codage d'un typestructuré (séquence).

30 0D

= type séquence = longueur définie 02 04 013C2937

02 02 0342

02 01 19

Tableau 8. Codage d’un type structuré (séquence) ; longueur indéfinie.

30 80

= type séquence = longueur indéfinie 02 04 013C2937

02 02 0342

02 01 19

00 00

Dans cette structure (tableau 8), les octets « 00 00 » représentent la fin de la séquence. Il est intéressant de noter que le premier octet représente un type de données (fin de contenu ou EOC (End Of Content)), tandis que le second représente un champ de longueur (ici, pas de valeur associée, donc longueur nulle).

3.1. Codage des octets de type

Le ou les octets de type vont permettre de représenter trois sortes d’informations : 1. la classe du type (universelle, application, privée ou spécifique à un contexte) ; 2. la forme du type (type primitif ou type constructeur) ;

3. l’identifiant ou étiquette du type.

C’est cette dernière information qui va influer sur le nombre d’octets nécessaires au codage du type.

3.1.1. Etiquette d’un type

 première méthode.

Un seul octet code le type :

Tableau 9. Un seul octet codant le type

8 7 6 5 4 3 2 1

classe forme étiquette

(23)

L’étiquette du type est alors telle que : 0 n30

 deuxième méthode.

Plusieurs octets codent le type. La figure 8 présente ce principe de codage.

Le premier octet indique la classe et la forme du type (primitif ou constructeur), et signale que l’étiquette est transmise dans les octets suivants (11111 = extension de l’étiquette sur les octets suivants).

L’étiquette est transmise dans un nombre indéterminé d’octets. Le bit 8 de chaque octet indique s’il y a une suite ou non (1 = suite ; 0 = fin).

L’étiquette du type est alors telle que : 31 n∞

3.1.2. Classe d’un type

Tableau 10. Codage des bits 8 et 7 pour la classe.

classe bit 8 bit 7

UNIVERSAL 0 0

APPLICATION 0 1

CONTEXT-SPECIFIC 1 0

PRIVATE 1 1

Les définitions des classes sont les suivantes :

 UNIVERSAL :La classe UNIVERSAL est utilisée pour définir un type de données d’usage général, indépendant de l’application ; généralement les types de classe UNIVERSAL ne sont définis que dans la recommandation X.208.

Toutefois, les messages du protocole SNMP (administration de réseau) possèdent la classe UNIVERSAL, car les concepteurs du protocole ont estimé que la portée de leur application était universelle.

 APPLICATION : La classe APPLICATION est utilisée pour définir un type de données très répandu et largement utilisé, dans un contexte de présentation particulier ; généralement les types de classe APPLICATION ne sont définis que dans les recommandations ou normes internationales, ou dans des applications de portée très générale.

 CONTEXT-SPECIFIC :La classe CONTEXT-SPECIFIC est utilisée pour distinguer les membres d’un ensemble. Cette classe est donc très utilisée dans les structures « séquence » et

Figure 8. Codage du type sur plusieurs octets.

classe p/c 11111 1 1 0

étiquette

(24)

« ensemble ». La visibilité d’un tel type est en effet restreinte à l’intérieur d’un type structuré dans lequel il est défini.

 PRIVATE :La classe PRIVATE est utilisée pour définir un type de données qui trouve son utilisation dans tout organisme particulier ou dans un pays déterminé. Elle permet de définir des types relatifs à des applications de caractère privé.

3.1.3. Forme d’un type

La forme d’un type est «primitif» ou «constructeur». La forme dépend du type et de la valeur à coder.

 un type primitif est un type pour lequel les valeurs sont atomiques, c’est-à-dire qu’elles ne sont pas divisibles ou structurables ;

 un type constructeur est un type pour lequel les valeurs sont structurées en plusieurs éléments ; eux-mêmes peuvent être soit primitifs soit constructeurs (ceci permet de concevoir des structures complexes, arborescentes ou encore récursives).

Tableau 11. Codage du bit de forme.

forme bit 6

PRIMITIVE 0

CONSTRUCTEUR 1

3.2. Codage des octets de longueur

3.2.1. Longueur indéfinie

Lorsque la longueur d’une valeur est indéfinie¹⁶, l’octet de longueur est codé par la valeur 80 en hexadécimal.

Tableau 12. Champ de longueur indiquant une longueur indéfinie.

8 7....1

1 0000000

3.2.2. Longueur définie

Lorsque la longueur d’une valeur est définie¹⁷, deux cas de codage sont possibles. Soit la longueur est codée sur un octet, soit sur plusieurs.

cas 1 : la longueur n est dans la plage suivante : 0 n127

16 Le cas d’une longueur indéfinie ne peut se produire que pour des valeurs structurables, c’est-à-dire dont le type possède la forme dite « constructeur ».

17 Le cas de codage d’une longueur définie peut se produire indifféremment pour des types de forme primitive ou constructeur.

(25)

cas 2 : La longueur n est dans la plage suivante : 128 n2¹⁰⁰⁸

On peut noter que : 2¹⁰⁰⁸=256¹²⁶≈2,743 ×10³⁰³ En réalité, 2¹⁰⁰⁸ vaut exactement :

27430620343968443416279681255936046350371963179661660350560009942280986908798364 73582587849768181396806642362668936055872479091931372323951612051859122835149807 24935035500313226779509889596701232075627063117989759579697696445408449514637925 019572810613022629828775479492107003 6903071843030324651025760256

Pour transmettre cette quantité d’octets à raison de 1 Gbit/s il ne faut que 2,1944 ×10²⁹⁵ secondes !

L’âge de l’Univers (soit environ 15 milliards d’années) est évalué à 4,73364 ×10¹⁷ secondes ! Passer du débit de 1 Gbit/s à 100 Gbit/s ne changerait pas grand chose puisqu’il faudrait quand même 2,1944 ×10²⁹³ secondes !

3.3. Codage des octets de valeur

Le codage des octets de valeurs dépend uniquement du type de données à représenter. Ceci fait partie des règles pour chaque type.

Par exemple, les entiers sont codés en binaire ; les énumérés sont codés comme des entiers.

Pour des raisons d’économie, on conseille généralement de coder les valeurs sur le nombre minimum d’octets.

Le chapitre 4, « Principaux types ASN.1 », page 26 , présente autant que possible le codage des octets de valeurs pour chaque type défini dans ASN.1.

Figure 9. Champ de longueur indiquant une longueur inférieure à 128

Figure 10. Champ de longueur indiquant une longueur supérieure à 127

8 7 6 5 4 3 2 1

0 longueur n

N octets pour coder la longueur « n »

1 N

(26)

Chapitre 4. Principaux types ASN.1

4.1. BOOLEAN

Notation de type

Tableau 13. Notation du type booléen.

Identifiant Etiquette

BOOLEAN UNIVERSAL 1

exemple :

Marié ::= BOOLEAN

AutorisationAcces ::= SEQUENCE {lecture BOOLEAN, écriture BOOLEAN, exécution BOOLEAN}

Notation de valeur

Tableau 14. Notation de la valeur d'un booléen.

dénotationValeur type affectation valeur

marié BOOLEAN ::= TRUE

sexe-masculin BOOLEAN ::= FALSE

Règle de codage

Tableau 15. Codage d'une valeur booléenne.

valeur codage

TRUE 00

FALSE valeur différente de 00

4.2. INTEGER

But : représenter une donnée entière, sur un nombre d’octets à priori non déterminé, mais le plus petit possible. Valeurs positives ou négatives (en complément à deux).

Tableau 16. Notation du type entier.

INTEGER

INTEGER{Valeurs nommées}

UNIVERSAL 2

(27)

Exemples :

CodeErreur ::= INTEGER -- positif ou négatif

Jour ::= INTEGER {lundi(1), mardi(2), mercredi(3), jeudi(4), vendredi(5), samedi(6), dimanche(7)}

SituationMaritale ::= INTEGER {célibataire(0), marié(1), séparé(2), divorcé(3), veuf(4)}

Tableau 17. Notation de la valeur d'un entier.

âge INTEGER ::= 36

code-erreur INTEGER ::= -115

jour INTEGER ::= 7

jour INTEGER ::= lundi

Tableau 18. Codage d'un entier.

valeur codage

nombre entier | identificateur

nombre binaire codé sur le minimum d’octets

4.3. ENUMERATED

Le type énuméré permet de représenter des informations se présentant sous forme de liste.

Tableau 19. Notation de type énuméré.

ENUMERATED {Valeurs nommées} UNIVERSAL 10

Couleurs ::= ENUMERATED {noir(0), rouge(1), bleu(2), jaune(3)}

Tableau 20. Exemples de valeurs d'un énuméré.

drapeau Couleurs ::= rouge

autre-drapeau ENUMERATED ::= bleu

(28)

4.4. REAL

Tableau 21. Notation de type d'un réel.

Identifiant Etiquette

REAL UNIVERSAL 9

Circonférence ::= REAL Cercle ::= CHOICE {

diamètre [PRIVATE 0] IMPLICIT REAL, rayon [PRIVATE 1] IMPLICIT REAL}

Tableau 22. Exemples de valeurs d'un réel.

nom-de valeur REAL ::= {mantisse base exposant}

quart REAL ::= {1 2 -2} -- 0,25 =1 ×2⁻²

pi REAL ::= {314159 10 -5}

infini REAL ::= PLUS-INFINITY

moins-infini REAL ::= MINUS-INFINITY

Il existe malheureusement une « base de codage » différente de celle choisie pour la notation.

La mantisse M se met sous la forme : S⋅N⋅2^F dans laquelle :

 S = signe ;

 N = un nombre entier en base 2, 8 ou 16 ;

 F une valeur entre 0 et 3 permettant d’ajuster N sur un nombre entier d’octets.

Le codage est primitif. Le tableau suivant en donne les différentes possibilités.

Tableau 23. Codage d'un nombre réel.

valeur (notation) codage

0 rien

base = 10 premier octet : 00 00 00 yy

octets suivants : un champ suivant la norme choisie :

• yy = 00 : norme ISO 6093, forme NR1

• yy = 01 : norme ISO 6093, forme NR2

• yy =11 :norme ISO 6093, forme NR3

(29)

valeur (notation) codage

base = 2, 8 ou 16 premier octet : 1 s bb ff xx deuxième octet : E...E octets suivants : N...N

s = signe (0 si +, 1 si -) bb = base de codage :

00 = 2 01 = 8 10 = 16 ff = facteur d’ajustement (de 0 à 3)

xx : conditionne le codage de E :

• 00 : E codé sur 1 octet

• 01 : E codé sur 2 octets

• 10 : E codé sur 3 octets

• 11 : octet suivant = nombre d’octets de E E..E = codage E en base bb (complément à 2)

N..N = codage de N en base bb PLUS-INFINITY 1 octet de contenu 80 (hexa) MINUS-INFINITY 1 octet de contenu 81 (hexa)

exemple :

pi REAL ::= {314 10 -2} -- nombre pi

base de codage retenue = 16 ; on obtient alors : =323 ×16⁻³ ainsi qu’un facteur d’ajustement de 0 ; d’où le résultat :

Tableau 24. Exemple de codage de pi.

type longueur valeur

09 04 A0 FD 32 3D

4.5. BITSTRING

Ce type permet de représenter une suite d’éléments binaires non nécessairement multiple de 8 (pas de frontière sur un octet). Il est utilisé pour des images en général¹⁸, mais peut représenter aussi par exemple des données pouvant prendre des valeurs dans un ensemble de valeurs.

Tableau 25. Notation de type d'une chaîne binaire.

BITSTRING

BITSTRING {valeurs nommées}

UNIVERSAL 3

18 Photo, télévision, fax, etc.

(30)

Photo ::= BITSTRING

Indicateurs ::= BITSTRING{lecture(0),écriture(1),impression(2),occupé(3)}

Accès ::= BITSTRING{

propriétaire-lecture(0),propriétaire-écriture(1), groupe-lecture(2),groupe-écriture(3),

autres-lecture(4),autres-écriture(5)}Notation de valeur

Tableau 26. Exemples de valeurs de chaînes binaires.

dénotationValeur type affect. valeur

nom-de-valeur BITSTRING ::= chaîne de caractères an binaire ou en hexadécimal, ou liste d’identi ficateurs accèsDemande Indicateurs ::= ’0100’B -- binaire

accèsEnCours Indicateurs ::= ’9’H -- hexa

accès Accès ::= {groupe-lecture, groupe-écriture}

accèsInterdit Accès ::= {} -- aucun droit

Tableau 27. Codage d'une chaïne binaire.

valeurs codage : primitif ou constructeur

mode primitif • premier octet = nombre de bits non significatifs du dernier octet.

• octets suivants = la chaîne binaire, complétée avec des bits nuls (éventuellement) au dernier octet.

mode constructeur • premier octet = 23 hexa

• deuxième octet = 80 hexa

• suite = suite de chaînes binaires primitives ou construites

• derniers octets = fin de contenu (00 00)

4.6. OCTETSTRING

Ce type permet de représenter une variable qui peut prendre une valeur sous forme d’une liste d’octets (c’est le type ASN.1. le plus général ; il faut remarquer d’ailleurs que c’est à partir de ce type que sont construits beaucoup de types dits « utiles »).

Tableau 28. Notation de type d'une chaîne d'octets.

OCTETSTRING UNIVERSAL 4

Dump ::= OCTETSTRING

Fichier-Unix ::= OCTETSTRING

(31)

Tableau 29. Exemples de valeurs de chaînes d'octets.

nom-de-valeur OCTETSTRING ::= chaîne de caractères en binaire ou en hexadécimal (nombre entier d’octets)

dump Dump ::= ’08234C29CFFE42C1’H

indicateur OCTETSTRING ::= ’01101001110111011’B

Comme pour la chaîne de bit (BITSTRING), il est possible de coder de manière primitive ou constructeur.

4.7. NULL

Ce type permet de représenter un élément absent dans une structure de données, à moindre frais.

Tableau 30. Notation du type NULL.

NULL UNIVERSAL 5

Chambre-Patient ::= CHOICE{

numero INTEGER,

NULL -- si patient non résident}

Tableau 31. Exemples de valeurs du type NULL.

nom-de-valeur NULL ::= NULL

présence NULL ::= NULL

Tableau 32. Codage du type NULL.

valeur codage : primitif

NULL vide

4.8. SEQUENCE

L’intérêt de ce type est de pouvoir représenter une structure de données composée de plusieurs éléments, pour laquelle l’ordre des éléments est considéré comme important et significatif. Chaque élément n’est pas nécessairement du même type.

(32)

Tableau 33. Notation du type SEQUENCE.

SEQUENCE {...}

SEQUENCE {}

UNIVERSAL 16

Famille ::= SEQUENCE{ pere Personne, mere Personne,

enfants Personne OPTIONAL, Adresse}

Personne ::= SEQUENCE{ nom OCTETSTRING, prenom OCTETSTRING, age INTEGER OPTIONAL}

Couple ::= SEQUENCE{ COMPONENTS OF Personne, --père COMPONENTS OF Personne –mère}

L’utilisation de COMPONENTS OF permet d’alléger l’écriture mais n’apporte rien au niveau codage. Ce dernier exemple est donc totalement équivalent à l’écriture suivante :

Couple ::= SEQUENCE{ -- description du père nom OCTETSTRING, prenom OCTETSTRING, age INTEGER OPTIONAL -- description de la mère nom OCTETSTRING, prenom OCTETSTRING, age INTEGER OPTIONAL}

Tableau 34. Exemple de valeur d'une séquence.

dupont Famille ::= { père {nom "Dupont", prénom "Jean", âge 42},

mère {nom "Durandt", prénom "Marie"}

enfants {

nom "Dupont", prénom "Luc", âge 17},

"La Rochelle" -- adresse

Tableau 35. Codage du type séquence.

valeur codage : constructeur

éléments présents tous les éléments constitutifs et présents sont codés dans l’ordre de la description.

(33)

4.9. SEQUENCE OF

Ce type permet de représenter une liste de données de même type. L’ordre d’apparition des éléments est supposé avoir son importance.

Tableau 36. Notation du type SEQUENCE OF.

SEQUENCE OF UNIVERSAL 16

Tiercé ::= SEQUENCE OF INTEGER

Prénoms ::= SEQUENCE OF PRINTABLESTRING Personne ::= SEQUENCE{

nom PRINTABLESTRING,

prenoms SEQUENCE OF PRINTABLESTRING, age INTEGER OPTIONAL}

Tableau 37. Exemple de valeur d'une séquence répétitive.

prixAmérique Tiercé ::= {5, 2, 12}

voir les règles de codage du type SEQUENCE

4.10. SET

L’intérêt de ce type est de pouvoir représenter une structure de données de tous types. Chaque élément peut apparaître dans n’importe quel ordre.

Tableau 38. Notation du type SET (ensemble).

Identifiant Etiquette SET {...}

SET {}

UNIVERSAL 17

Tableau ::= SET{

libellé [0] PRINTABLESTRING, tableau [1] SEQUENCE OF Rangée}

-- le libellé peut apparaître indifféremment au-dessus ou au-dessous du tableau Rangée ::= SEQUENCE OF Cellule

Cellule ::= PRINTABLESTRING

(34)

Tableau 39. Exemples de valeurs du type ensemble.

table1 Tableau ::= {libellé "premier tableau", tableau {{"A","B"},{"C","D"}}}

table2 Tableau ::= {tableau {{"A","B"},{"C","D"}}, libellé "deuxième tableau"}

Tableau 40. Codage du type ensemble.

valeur codage : constructeur

éléments présents tous les éléments constitutifs et présents sont codés dans n’importe quel ordre.

4.11. SET OF

Même principe que le type SEQUENCE OF. La structure est composée d’éléments de même type.

Bien entendu, l’ordre des éléments n’a strictement aucune importance (sauf pour l’application).

4.12. CHOICE

Ce type permet de représenter un choix possible parmi plusieurs valeurs de types non obligatoirement identiques.

Tableau 41. Notation du type CHOICE (choix).

CHOICE {...} Aucune : c’est l’étiquette du type choisi qui est prise en compte.

Exemple de notations utilisant le type CHOICE :

FinRepas ::= CHOICE{

fromage [0] OCTETSTRING, dessert [1] OCTETSTRING}

Cercle ::= CHOICE{

rayon [PRIVATE 0] REAL, diamètre [PRIVATE 1] REAL}

Triangle ::= CHOICE{

côtés [PRIVATE 2] SEQUENCE OF REAL, angles [PRIVATE 3] SEQUENCE{

base REAL, angle1 REAL, angle2 REAL}}