La couche présentation ; la syntaxe ASNmichel/Supports/presentation.pdf · Informations Ce...

La couche présentation

La syntaxe ASN.1

Michel Gardie

GET/INT/LOR/RIP 5 février 2004

Informations

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

Pour l’historique du document :

© 1990 FRANCE TELECOM INT/DSR

© 1992, 1993, 1994, 1996, 1998 : INT/LOR/AIGRI

© 2001 GET/INT/LOR/RIP

© 2002 GET/INT/LOR/RIP© 2003 GET/INT/LOR/RIP

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

Table des matièresChapitre 1. La couche présentation...................................................................................................... 6

1.1. Rôle...........................................................................................................................................61.1.1. Préservation de la sémantique........................................................................................... 61.1.2. Négociation des syntaxes de transfert............................................................................... 81.1.3. Accès aux services fournis par la couche session.............................................................. 9

1.2. Mise en œuvre...........................................................................................................................91.3. Syntaxes.................................................................................................................................... 9

1.3.1. Syntaxe abstraite............................................................................................................... 91.3.2. Syntaxe de transfert...........................................................................................................9

1.4. Contexte de présentation.........................................................................................................101.5. Négociation des contextes de présentation............................................................................. 101.6. Accès aux services session...................................................................................................... 11

Chapitre 2. Introduction à ASN.1.......................................................................................................132.1. Nécessité d’une syntaxe commune..........................................................................................132.2. Définition d’ASN.1................................................................................................................. 142.3. Types de base ASN.1..............................................................................................................142.4. Construction de nouveaux types............................................................................................. 15

2.4.1. Etiquetage....................................................................................................................... 152.4.2. Outils de construction..................................................................................................... 16

2.4.2.1. Outil SEQUENCE...................................................................................................162.4.2.2. Outil SET.................................................................................................................162.4.2.3. Outil CHOICE.........................................................................................................17

2.5. Informations représentées en ASN.1.......................................................................................182.6. Codage des valeurs................................................................................................................. 182.7. Usages d’ASN.1......................................................................................................................19

Chapitre 3. Codage de base ASN.1.................................................................................................... 203.1. Codage des octets de type.......................................................................................................21

3.1.1. Etiquette d’un type..........................................................................................................213.1.2. Classe d’un type.............................................................................................................. 223.1.3. Forme d’un type.............................................................................................................. 23

3.2. Codage des octets de longueur............................................................................................... 233.2.1. Longueur indéfinie...........................................................................................................233.2.2. Longueur définie............................................................................................................. 23

3.3. Codage des octets de valeur....................................................................................................24

Chapitre 4. Principaux types ASN.1................................................................................................... 254.1. BOOLEAN............................................................................................................................. 254.2. INTEGER............................................................................................................................... 254.3. ENUMERATED.....................................................................................................................264.4. REAL...................................................................................................................................... 274.5. BITSTRING........................................................................................................................... 284.6. OCTETSTRING.....................................................................................................................294.7. NULL......................................................................................................................................304.8. SEQUENCE........................................................................................................................... 304.9. SEQUENCE OF..................................................................................................................... 324.10. SET....................................................................................................................................... 32

GET/INT/LOR de 57 La couche présentation ; la syntaxe ASN.1

4.11. SET OF................................................................................................................................. 334.12. CHOICE............................................................................................................................... 334.13. TYPE SELECTION (<)....................................................................................................... 344.14. ANY / ANY DEFINED BY................................................................................................. 354.15. OBJECTIDENTIFIER..........................................................................................................354.16. TYPES CHAINES DE CARACTERES.............................................................................. 374.17. TYPES TEMPORELS..........................................................................................................38

4.17.1. GENERALIZEDTIME................................................................................................. 384.17.2. UTCTIME.....................................................................................................................39

4.18. TYPES UTILES................................................................................................................... 394.18.1. OBJECTDESCRIPTOR............................................................................................... 394.18.2. EXTERNAL..................................................................................................................39

4.19. SOUS-TYPES...................................................................................................................... 404.19.1. Valeurs simples..............................................................................................................404.19.2. Sous-types inclus...........................................................................................................404.19.3. Intervalles...................................................................................................................... 404.19.4. Contraintes sur les tailles...............................................................................................404.19.5. Alphabets autorisés........................................................................................................40

Chapitre 5. Le protocole X.226.......................................................................................................... 415.1. Présentation du protocole X.226............................................................................................ 41

5.1.1. Relations avec la couche application............................................................................... 415.1.2. Relations avec la couche session..................................................................................... 415.1.3. Fonctions de la couche présentation................................................................................425.1.4. Négociation de la syntaxe................................................................................................425.1.5. Définition de contextes de présentation.......................................................................... 425.1.6. Gestion de l’ensemble des contextes définis (DCS)........................................................ 42

5.2. Le protocole et le service de présentation...............................................................................425.2.1. Les primitives.................................................................................................................. 435.2.2. Les PPDU........................................................................................................................445.2.3. Structure des PPDU........................................................................................................ 455.2.4. Particularités du protocole.............................................................................................. 45

5.2.4.1. Transfert d’informations.......................................................................................... 455.2.4.2. Gestion des contextes.............................................................................................. 455.2.4.3. Restauration des contextes...................................................................................... 465.2.4.4. Unités fonctionnelles de session.............................................................................. 465.2.4.5. Unités fonctionnelles de session nécessaires............................................................465.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


Index des figuresFigure 1. Enchaînement des syntaxes............................................................................................ 8Figure 2. Négociation des contextes de présentation.................................................................... 8Figure 3. Accès aux services session............................................................................................. 12Figure 4. Principe de fonctionnement d'ASN.1............................................................................. 13Figure 5. Indépendance offerte par ASN.1.................................................................................... 14Figure 6. Format avec longueur définie......................................................................................... 20Figure 7. Format avec longueur indéfinie...................................................................................... 20Figure 8. Codage du type sur plusieurs octets............................................................................... 22Figure 9. Champ de longueur indiquant une longueur inférieure à 128 ........................................ 24Figure 10. Champ de longueur indiquant une longueur supérieure à 127..................................... 24


Chapitre 1. La couche présentation

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

Tableau 1. Normes utilisées

Nature Norme ISO Recommandation ITU-TService 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ôleLa couche présentation se charge de la représentation des informations échangées entre systèmesouverts.Il peut y avoir un problème d’interfonctionnement lorsque, par exemple, deux calculateurs ayant unegestion 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 à cetype de problème.

La couche présentation va par conséquent offrir plusieurs fonctionnalités, parmi lesquelles les pluscaracté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émantiqueCe point est important. Cela signifie qu’il n’est pas obligatoire que la représentation (syntaxe) desdonnées soit préservée, tant que la sémantique reste inchangée.

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

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 programmationdifférents.


Ceci conduit naturellement à ce que la représentation des données particulières à chaque applicationsoit 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’unereprésentation commune des données qu’elles échangeront. Une telle représentation commune desdonnées est appelée syntaxe de transfert.Il est tout à fait possible que plusieurs syntaxes de transfert puissent coexister au sein d'une mêmeapplication.Une syntaxe de transfert doit permettre de coder l’information indépendamment de la manière dontcelle-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 depasser 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 depasser d’une syntaxe réelle à une syntaxe de transfert (et vice-versa), les données applicatives quiseront échangées sont alors représentées à l’aide d’une notation particulière. Par exemple, on peutconvenir d’utiliser le langage C pour représenter des données (c’est le cas lorsque les applicationsutiliseront la syntaxe de transfert XDR1). 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 autrenotation ; ASN.1 est un exemple de notation qui répond à ces trois critères : indépendance vis-à-visdu 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 notationindé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épendantede 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’uneconnexion, la syntaxe de transfert qui sera utilisée pour la représentation commune des donnéesapplicatives. Cette négociation fait donc appel à la notion de syntaxe de transfert (c’est-à-dire lesdonnées telles qu’elles circuleront sur les réseaux de communication) et à la notion de syntaxeabstraite (c’est-à-dire les données que l’on cherche à échanger). Le lien entre une syntaxe abstraite etune 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 entresyntaxes.

Prenons un exemple dans cette figure : l’application A3 possède deux groupes de donnéesréprésentées respectivement par les syntaxes abstraites SA4 et SA5. Chacun de ces groupes possèdebien évidemment une représentation réelle SR4 et SR5. Le concepteur de l’application a seulementdécrit les données sous leur forme abstraite, puis a utilisé un compilateur pour générerautomatiquement les syntaxes réelles correspondantes ainsi que les fonctions de codage et dedécodage qui permettent de passer d’une syntaxe réelle vers une syntaxe de transfert. Toutefois, lecompilateur a généré pour le groupe SA4 deux ensembles de fonctions de codage et de décodagevers les syntaxes de transfert ST2 et ST3. Autrement dit, il existe deux contextes de présentationpossibles 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 contextespeuvent en outre être utilisés simultanément.

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


1.1.2. Négociation des syntaxes de transfertIl est possible qu’une syntaxe abstraite puisse être représentée à l’aide de plusieurs syntaxes detransfert. Il faut donc que les deux entités de présentation se mettent d’accord sur la syntaxe detransfert 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 decoder des données (représentées abstraitement à l’aide de la syntaxe abstraite SA1) selon deuxsyntaxes de transfert ST1 et ST2. Le système A propose donc au système B de choisir le mode decodage.

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


Figure 1. Enchaînement des syntaxes

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

7

6

SR1 SR3 SR4 SR6SR2 SR5

ST1

A1 A2 A3 A4

SA1SA2 SA3 SA4 SA5 SA6

ST2 ST3 ST4 ST5

Contexte de présentation SR = syntaxe réelleSA = syntaxe abstraiteST = syntaxe de transfert

7

6

[sa1, (st1, st2)]

[sa1, st1]

SR2

SA1 SA1

ST1ouST2

ST1

SR1

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

1.1.3. Accès aux services fournis par la couche sessionCeci est fondamental. En effet, la couche session offre aux applications des services facilitant lasynchronisation de données. La couche présentation ne doit pas interdire l’accès à ces services. Il enrésulte que la couche présentation offre l’intégralité des services de session.

1.2. Mise en œuvreLa 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 desdonnées manipulées par ces applications. Ceci permet de générer automatiquement les structuresréelles (le plus souvent dépendantes du système d’exploitation, du processeur et du langage deprogrammation utilisés) ainsi que les procédures de codage et de décodage permettant de passer dela syntaxe réelle à la syntaxe de transfert (et réciproquement). Un contexte de présentation sematérialise alors sous la forme d’interfaces programmatiques et de bibliothèques.

1.3. Syntaxes

1.3.1. Syntaxe abstraiteDé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 dedonnées de la couche application (ou d’informations de contrôle d’un protocoled’application) en appliquant des règles de notation indépendantes de la technique decodage 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’uneapplication 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)}


1.3.2. Syntaxe de transfertDé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 ouabstraite.

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

Une syntaxe de transfert est également identifiée par un nom qui est, bien sûr, unOBJECTIDENTIFIER. Ceci est également nécessaire car une application peut éventuellementutiliser 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ésentationUn 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’uneapplication), un contexte de présentation représente un environnement selon lequel les valeurs dedonnées de la syntaxe abstraite peuvent être transférées (sous forme d’une chaîne binaire) sansambiguïté.

Du même point de vue, un contexte de présentation représente une utilisation spécifique distincted’une syntaxe abstraite. Plusieurs contextes de présentation peuvent être définis pour la mêmesyntaxe abstraite ; des valeurs de données de présentation transmises exprimées selon des contextesde 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ésentationLa couche présentation se charge de négocier la syntaxe de transfert. Cette négociation a lieu entredeux entités de présentation lorsqu’un utilisateur (application) fournit le nom d’une syntaxe abstraitequi nécessite une syntaxe de transfert. L’entité de présentation appelante propose pour chaquesyntaxe abstraite une liste de syntaxes de transfert compatibles. La négociation réussit si l’entité deprésentation appelée fournit comme résultat l’association de la syntaxe abstraite nommée avec unedes syntaxes de transfert compatibles. C’est à partir de cet instant qu’est constitué le contexte deprésentation.

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

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

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

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


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 contextesdéfinis3 Le service de connexion permet de définir une liste initiale de contextes ; le service demodification permet quant à lui d’ajouter ou de supprimer des contextes, et cela au cours d’unecommunication.

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 lesdiffé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ésentationidentifiant de contexte nom de syntaxe abstraite nom de syntaxe de transfertdéfini par l’usager (couche application) en tant que paramètrede service de connexion ou de modifica tion de contexte

défini par la couche présentation lorsd’une négociation

1.6. Accès aux services sessionLes services de session sont fournis aux entités d’application sous la forme de services deprésentation. Ceci signifie que les entités d’application doivent gérer et synchroniser les dialogues, etque 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 partiellementtransparente à certains services.

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

Service de type 1. Ces services sont exclusivement de nature syntaxique (gestion de lasyntaxe par exemple). Généralement, la couche présentation transforme cesservices en des éléments de protocole de la couche présentation (autrementdit, des PPDU4) qui transitent en tant que données au niveau de la couchesession5.

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

3 DCS : Defined Context Set = ensemble de contextes définis4 PPDU = Presentation Protocol Data Unit = unité de données du protocole de présentation5 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.


Service de type 3. Ce sont en réalité des services de session purs (exemple : la pose de pointde synchronisation mineur ; on a une totale identité entre une primitive deservice PSYNmreq6 et une primitive SSYNmreq7. La couche présentationne rajoute rien aux éléments transportés par le point de synchronisation).

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


Figure 3. Accès aux services session

Application

Présentation

Session

1 2 3

Chapitre 2. Introduction à ASN.1

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

Une solution à ce problème consiste, pour une application, à transformer sa syntaxe réelle propre enla syntaxe réelle de son correspondant. L’inconvénient d’une telle solution est qu’elle exige dechaque 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 detransfert définie par ASN.18 est une syntaxe commune et par conséquent va faciliter lacommunication 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 sontdécrites par une syntaxe indépendante des langages de programmation utilisés, des systèmesd’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 lasyntaxe réelle de ces données, et d’autre part génèrera un ensemble de fonctions de codage etde 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

coda

ge

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érenceOSI, chaque paramètre « données de l’utilisateur » d’une primitive de service est spécifié comme lavaleur binaire d’une séquence d’octets. Par contre, dans la couche présentation, la nature desparamètres « données de l’utilisateur » est différente. Les spécifications de la couche applicationimposent en effet de véhiculer des valeurs de types très complexes, incluant éventuellement deschaînes de caractères de divers jeux.

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

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

2.3. Types de base ASN.1Nous ne donnons, dans le tableau ci-dessous, que quelques exemples de types de données de base etdes 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éelleSyntaxe réelle

Tableau 3. Exemples de types de base

TYPE EXEMPLES DE VALEURSBOOLEAN TRUE

FALSE

INTEGER 11321-533265790054342334119874565

REAL 31415926 ×10−5

OCTETSTRING 0A2FEE0025

BITSTRING 011001100010110111100100001

OBJECTIDENTIFIER {iso norme 8571 pci(1)}{1 0 8571 1}

2.4. Construction de nouveaux typesLa description de données passe principalement par la définition de types de données. La notation desyntaxe abstraite ASN.1 offre de nombreux types de base. Toutefois, il est absolument fondamentalde ne pas être limité à ces types prédéfinis. Il faut donc disposer de moyens de construction denouveaux types de données. La notation de syntaxe ASN.1 définit deux méthodes pour construiredes 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. EtiquetageLa 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, donnantainsi 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 nouveautype. L’étiquette du type de base existe toujours. Cette écriture est identique à l’écriture suivante :VideotexString ::=[21] EXPLICIT OCTETSTRING


2.4.2. Outils de constructionNous ne développerons dans ce paragraphe que quelques exemples d’outils de construction. Nousavons 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 grandesvariétés de structures.

2.4.2.1. Outil SEQUENCEL’outil SEQUENCE permet de créer une structure de données dont chaque élément peut être soitune structure complexe, soit une donnée simple et pour laquelle l’ordre des éléments estfondamental. 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 enquatre éléments. Les deux premiers éléments sont du même type (PRINTABLESTRING), mais leurordre d’apparition dans la structure les identifie sans ambiguïté comme représentant d’abord leprénom de la personne, suivi de son nom. Les deux éléments suivants sont optionnels, et de faitné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 donttous les éléments sont identiques (en l’occurrence ici des nombres entiers ou des chaînesimprimables), et pour lesquels l’ordre est fondamental ; d’où l’utilisation de l’outil SEQUENCEOF.

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


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 donnerd’abord le prénom puis le nom, ou bien l’inverse. Dans ces conditions, il est nécessaire d’étiqueterles 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’apparitiondes éléments n’a strictement aucune importance (ou bien pour lequel l’ordre serait préjudiciable).

2.4.2.3. Outil CHOICEL’outil CHOICE permet de créer une structure de données dont le type final sera un des types de laliste 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 lesdeux simultanément. La distinction entre l’une ou l’autre des deux informations se fait parl’é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. Ladistinction entre les deux types de représentation se fait cette fois-ci de manière implicite car les deuxreprésentations sont différentes par leur type. L’étiquetage des diverses possibilités n’est donc pasutile 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 lesecond est soit un entier, soit un nombre réel.


2.5. Informations représentées en ASN.1La 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 » permetde nommer un champ dans une structure. Un mot tel que « INTEGER » définit un type de based’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 entiervaleur-Booléenne BOOLEAN ::= TRUEvaleur-Octet OCTETSTRING ::= ’0A5F342C’H -- une chaîne hexadécimalechaî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. Lesymbole « ::= » est un signe de production permettant de définir comme ici des variables ou commeplus haut des types. Le symbole « -- » permet l’introduction de commentaires.

2.6. Codage des valeursLa 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 coucheprésentation véhiculent des flots d’octets. Il est donc nécessaire de disposer de règles de codagepermettant de déterminer la valeurs des octets échangés dans ces couches. Le codage utilisé est dutype « TLV » (Type-Longueur-Valeur).

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


2.7. Usages d’ASN.1Le 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 lessuivantes :

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

Norme NatureCCITT 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 syntaxeASN.1. On peut citer par exemple :

1. La messagerie X4009 ;

2. Le transfert de fichiers FTAM10 ;

3. Le système d’annuaire X500 ;

4. Les éléments de service ROSE11, ACSE12, RTSE13 ;

5. Le protocole non normalisé d’administration de réseau SNMP14.

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. LDAP15 (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) comportaitjusqu’en 1988 la recommandation X.409 qui décrivait la notation de syntaxe ASN.1 (notation de syntaxe abstraite et syntaxede 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 desyntaxe 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.


Chapitre 3. Codage de base ASN.1

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

Type Longueur ValeurDeux 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, etl’é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 quecelle-ci sera suivi d’un champ de fin de données. La valeur doit dans ces conditions êtrestructuré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 VALEUR02 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 DECONTENU

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

TYPE LONGUEUR VALEUR FIN DE CONTENU02 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 valeurcodée est un nombre entier, donc atomique. La séquence 0000 peut donc être interprétée commefaisant partie du nombre.

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

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

02 02 034202 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 034202 01 1900 00

Dans cette structure (tableau 8), les octets « 00 00 » représentent la fin de la séquence. Il estinté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 valeurassociée, donc longueur nulle).

3.1. Codage des octets de typeLe 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 1classe forme étiquette


L’étiquette du type est alors telle que : 0 n30

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 quel’étiquette est transmise dans les octets suivants (11111 = extension de l’étiquette sur les octetssuivants).

L’étiquette est transmise dans un nombre indéterminé d’octets. Le bit 8 de chaque octet indiques’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 7UNIVERSAL 0 0APPLICATION 0 1CONTEXT-SPECIFIC 1 0PRIVATE 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’usagegénéral, indépendant de l’application ; généralement les types de classe UNIVERSAL ne sontdéfinis que dans la recommandation X.208.Toutefois, les messages du protocole SNMP (administration de réseau) possèdent la classeUNIVERSAL, 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èsrépandu et largement utilisé, dans un contexte de présentation particulier ; généralement lestypes de classe APPLICATION ne sont définis que dans les recommandations ou normesinternationales, ou dans des applications de portée très générale.

CONTEXT-SPECIFIC :La classe CONTEXT-SPECIFIC est utilisée pour distinguer lesmembres 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

« 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 sonutilisation dans tout organisme particulier ou dans un pays déterminé. Elle permet de définir destypes relatifs à des applications de caractère privé.

3.1.3. Forme d’un typeLa 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 sontpas 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 desstructures complexes, arborescentes ou encore récursives).

Tableau 11. Codage du bit de forme.

forme bit 6PRIMITIVE 0CONSTRUCTEUR 1

3.2. Codage des octets de longueur

3.2.1. Longueur indéfinieLorsque la longueur d’une valeur est indéfinie16, l’octet de longueur est codé par la valeur 80 enhexadécimal.

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

8 7....11 0000000

3.2.2. Longueur définieLorsque la longueur d’une valeur est définie17, deux cas de codage sont possibles. Soit la longueurest codée sur un octet, soit sur plusieurs.

cas 1 : la longueur n est dans la plage suivante : 0 n127

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.


cas 2 : La longueur n est dans la plage suivante : 128 n21008

On peut noter que : 21008=256126≈2,743 ×10303

En réalité, 21008 vaut exactement :

274306203439684434162796812559360463503719631796616603505600099422809869087983647358258784976818139680664236266893605587247909193137232395161205185912283514980724935035500313226779509889596701232075627063117989759579697696445408449514637925019572810613022629828775479492107003 6903071843030324651025760256

Pour transmettre cette quantité d’octets à raison de 1 Gbit/s il ne faut que 2,1944 ×10295

secondes !

L’âge de l’Univers (soit environ 15 milliards d’années) est évalué à 4,73364 ×1017 secondes !

Passer du débit de 1 Gbit/s à 100 Gbit/s ne changerait pas grand chose puisqu’il faudrait quandmême 2,1944 ×10293 secondes !

3.3. Codage des octets de valeurLe codage des octets de valeurs dépend uniquement du type de données à représenter. Ceci faitpartie 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 minimumd’octets.

Le chapitre 4, « Principaux types ASN.1 », page 26 , présente autant que possible le codage desoctets 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

Chapitre 4. Principaux types ASN.1

4.1. BOOLEAN

Notation de type

Tableau 13. Notation du type booléen.

Identifiant EtiquetteBOOLEAN UNIVERSAL 1

exemple :

Marié ::= BOOLEANAutorisationAcces ::= 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 valeurmarié BOOLEAN ::= TRUEsexe-masculin BOOLEAN ::= FALSE

Règle de codage

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

valeur codageTRUE 00FALSE valeur différente de 00

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

Notation de type

Tableau 16. Notation du type entier.

Identifiant EtiquetteINTEGERINTEGER{Valeurs nommées}

UNIVERSAL 2


Exemples :

CodeErreur ::= INTEGER -- positif ou négatifJour ::= 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)}

Notation de valeur

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

dénotationValeur type affectation valeurâge INTEGER ::= 36code-erreur INTEGER ::= -115jour INTEGER ::= 7jour INTEGER ::= lundi

Règle de codage

Tableau 18. Codage d'un entier.

valeur codagenombre entier |identificateur

nombre binaire codé sur le minimum d’octets

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

Notation de type

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

Identifiant EtiquetteENUMERATED {Valeurs nommées} UNIVERSAL 10

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

Notation de valeur

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

dénotationValeur type affectation valeurdrapeau Couleurs ::= rougeautre-drapeau ENUMERATED ::= bleu


4.4. REAL

Notation de type

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

Identifiant EtiquetteREAL UNIVERSAL 9

Circonférence ::= REAL

Cercle ::= CHOICE { diamètre [PRIVATE 0] IMPLICIT REAL, rayon [PRIVATE 1] IMPLICIT REAL}

Notation de valeur

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

dénotationValeur type affectation valeurnom-de valeur REAL ::= {mantisse base exposant}quart REAL ::= {1 2 -2} -- 0,25 =1 ×2−2

pi REAL ::= {314159 10 -5}infini REAL ::= PLUS-INFINITYmoins-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⋅2F

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.

Règle de codage

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

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

valeur (notation) codage0 rienbase = 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


valeur (notation) codagebase = 2, 8 ou 16 premier octet : 1 s bb ff xx

deuxième octet : E...Eoctets 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 bbPLUS-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−3 ainsi qu’un facteur d’ajustementde 0 ; d’où le résultat :

Tableau 24. Exemple de codage de pi.

type longueur valeur09 04 A0 FD 32 3D

4.5. BITSTRINGCe type permet de représenter une suite d’éléments binaires non nécessairement multiple de 8 (pas defrontière sur un octet). Il est utilisé pour des images en général18, mais peut représenter aussi parexemple des données pouvant prendre des valeurs dans un ensemble de valeurs.

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

Identifiant EtiquetteBITSTRINGBITSTRING {valeurs nommées}

UNIVERSAL 3

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


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

Notation de type

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

dénotationValeur type affect. valeurnom-de-valeur BITSTRING ::= chaîne de caractères an binaire ou en

hexadécimal, ou liste d’identi ficateursaccèsDemande Indicateurs ::= ’0100’B -- binaireaccèsEnCours Indicateurs ::= ’9’H -- hexaaccès Accès ::= {groupe-lecture, groupe-écriture}accèsInterdit Accès ::= {} -- aucun droit

Règle de codage

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

valeurs codage : primitif ou constructeurmode 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. OCTETSTRINGCe type permet de représenter une variable qui peut prendre une valeur sous forme d’une listed’octets (c’est le type ASN.1. le plus général ; il faut remarquer d’ailleurs que c’est à partir de cetype que sont construits beaucoup de types dits « utiles »).

Notation de type

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

Identifiant EtiquetteOCTETSTRING UNIVERSAL 4

Dump ::= OCTETSTRING

Fichier-Unix ::= OCTETSTRING


Notation de valeur

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

dénotationValeur type affect. valeurnom-de-valeur OCTETSTRING ::= chaîne de caractères en binaire ou en

hexadécimal (nombre entier d’octets)dump Dump ::= ’08234C29CFFE42C1’Hindicateur OCTETSTRING ::= ’01101001110111011’B

Règle de codage

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

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

Notation de type

Tableau 30. Notation du type NULL.

Identifiant EtiquetteNULL UNIVERSAL 5

Chambre-Patient ::= CHOICE{ numero INTEGER, NULL -- si patient non résident}

Notation de valeur

Tableau 31. Exemples de valeurs du type NULL.

dénotationValeur type affect. valeurnom-de-valeur NULL ::= NULLprésence NULL ::= NULL

Règle de codage

Tableau 32. Codage du type NULL.

valeur codage : primitifNULL vide

4.8. SEQUENCEL’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.


Notation de type

Tableau 33. Notation du type SEQUENCE.

Identifiant EtiquetteSEQUENCE {.....}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 niveaucodage. 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}

Notation de valeur

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

dénotationValeur type affect. valeurdupont 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

Règle de codage

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.


4.9. SEQUENCE OFCe type permet de représenter une liste de données de même type. L’ordre d’apparition des élémentsest supposé avoir son importance.

Notation de type

Tableau 36. Notation du type SEQUENCE OF.

Identifiant EtiquetteSEQUENCE OF UNIVERSAL 16

Tiercé ::= SEQUENCE OF INTEGER

Prénoms ::= SEQUENCE OF PRINTABLESTRING

Personne ::= SEQUENCE{ nom PRINTABLESTRING, prenoms SEQUENCE OF PRINTABLESTRING, age INTEGER OPTIONAL}

Notation de valeur

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

dénotationValeur type affect. valeurprixAmérique Tiercé ::= {5, 2, 12}

Règle de codage

voir les règles de codage du type SEQUENCE

4.10. SETL’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.

Notation de type

Tableau 38. Notation du type SET (ensemble).

Identifiant EtiquetteSET {.....}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


Notation de valeur

Tableau 39. Exemples de valeurs du type ensemble.

dénotationValeur type affect. valeurtable1 Tableau ::= {libellé "premier tableau",

tableau {{"A","B"},{"C","D"}}}table2 Tableau ::= {tableau {{"A","B"},{"C","D"}},

libellé "deuxième tableau"}

Règle de codage

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 OFMê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. CHOICECe type permet de représenter un choix possible parmi plusieurs valeurs de types nonobligatoirement identiques.

Notation de type

Tableau 41. Notation du type CHOICE (choix).

Identifiant EtiquetteCHOICE {.....} 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}}


Figure ::= CHOICE{ triangle Triangle, cercle Cercle}

Notation de valeur

monChoix FinRepas ::= dessert ‘‘Profiteroles’’ -- slurp!

rond Figure ::= cercle diamètre {2532 10 -2} -- 25,32 (cm)

autreRond Figure ::= cercle rayon {145 10 -3} -- 1,45 (cm)

symbole Figure ::= triangle côtés {{12 10 -1} {9 10 -2}} -- deux côtés seulement indiqués

Règle de codage

C’est celle du type choisi.

4.13. TYPE SELECTION (<)Ce type permet d’extraire un type apparaissant dans la liste des types d’un type choix.

Notation de type

Tableau 42. Notation du type sélection.

Identifiant Etiquette< Aucune : c’est l’étiquette du type choisi qui est prise en compte.

Exemple :

soit la définition :AttributFichier ::= CHOICE{ dateDernièreUtilisation GENERALIZEDTIME, nomFichier VISIBLESTRING}

On peut alors créer :AttributsCourants ::= SEQUENCE{ dateDernièreUtilisation < AttributFichier, nomFichier < AttributFichier}

ou encore :ListeAttributs ::= SEQUENCE{ premierAttribut dateDernièreUtilisation < AttributFichier, secondAttribut nomFichier < AttributFichier}

Notation de valeur

Le tableau 43 utilise les exemples ci-dessus pour donner des exemples de valeurs du type sélection.


Tableau 43. Exemples de valeurs du type sélection.

dénotationValeur type aff. valeurattributs AttributsCourants ::= {dateDernièreUtilisation

"19910419104820",nomFichier "Source.c"}

liste ListeAttributs ::= {premierAttribut"19910419104820",secondAttribut "Source.c"}

4.14. ANY / ANY DEFINED BYCe type permet de représenter un type quelconque. Au cours d’une communication, le type àprendre en compte est obtenu par recherche d’une référence (index dans une liste de types possibles,ou recherche par un identificateur universel).

Notation de type

Tableau 44. Notation du type ANY (quelconque).

Identifiant EtiquetteANY DEFINED BY Aucune : c’est l’étiquette du type résultant qui est prise en

compte

exemple :

TypeSuper ::= SEQUENCE{index INTEGER, typeVoulu ANY DEFINED BY index}

4.15. OBJECTIDENTIFIERCe type permet d’identifier un objet informationnel19.

La sémantique d’une valeur d’identificateur d’objet est définie par référence à un arbred’identificateurs d’objets. Un arbre d’identificateurs est un arbre dont la racine est la norme ASN.1elle-même, et les nœuds correspondent aux autorités administratives responsables de l’affectation desarcs issus de chaque nœud. Un arc s’appelle un composant.

Notation de type

Tableau 45. Notation du type OBJECT IDENTIFIER.

Identifiant EtiquetteOBJECTIDENTIFIER UNIVERSAL 6

Exemple :

NormeInternationale ::= OBJECTIDENTIFIER

19 Exemple d’objet informationnel : l’objet «pci» défini dans la norme ISO 8571 (FTAM)


Notation de valeur

Tableau 46. Exemple de valeur d'un identificateur d'objet.

dénotationValeur type aff. valeurfTAM NormeInternationale ::= {iso standard 8571}

-- iso a la valeur 1-- standard vaut 0

Affectation des composants

Tableau 47. Composant racine.

Valeur Identifiant du composant0 ITU (ex CCITT)1 ISO2 JOINT ISO-ITU

Tableau 48. Composant ISO.

Valeur Identifiant du composant0 standard1 autorité d’enregistrement2 membre3 organisation reconnue

Tableau 49. Composant ITU.

Valeur Identifiant Décomposition0 recommandation 26 lettres (A à Z) puis numéro de la norme1 question 32 x période d’étude + numéro de groupe d’étude2 administration cf. X.121 DCC3 opérateur de réseau cf. X.121 DNIC

Règle de codage

Le codage est primitif. Les octets de contenu sont une liste ordonnée de sous-identificateurs.Un sous-identificateur se code par une série de un ou plusieurs octets. Le bit de chaque octetindiques s’il est le dernier de la série : le bit 8 du dernier octet est zéro ; le bit 8 des octets précédentsest un. Les bits 7 à 1 des octets dans la série encodent le sous-identificateur sous forme d’un entiernon signé.

Le nombre de sous-identificateur doit être un de moins que le nombre de composants de l’objectidentifier.

La valeur numérique du premier sous-identificateur est dérivé de la valeur des deux premierscomposants de l’object identifier : avec X = premier composant et Y = deuxième composant.

La relation qui permet d’obtenir le premier octet est la suivante : 40 X Y


exemple 1

fTAM NormeInternationale ::= {iso standard 8571}

Tableau 50. Codage d’une valeur : fTAM.

type longueur valeur06 03 28 C2 7B

Avec X = iso = 1 et Y = standard = 0, cette relation permettant d’obtenir le premier octet donne 40comme résultat, soit 28 en hexadécimal.Quant à 8571, son codage hexadécimal est C27B. En effet, le codage binaire de 8571 est10000111111011.En séparant par tranches de 7 bits, on obtient : 1000011-1111011. On va obtenir 2 octets. Lepremier aura le bit 8 à 1, et le dernier à zéro ; ce qui donne 11000011-01111011 ; soit enhexadécimal : C27B.

exemple 2

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

Le premier octet de valeur est donné par la relation :⟨X =2 ∣Y=1 ⟩ 81 soit 51 en hexadécimal.

Le troisième composant (codage-base) est codé par 01. On obtient :

Tableau 51. Codage d’une valeur : asn1.

type longueur valeur06 02 5101

4.16. TYPES CHAINES DE CARACTERESDe nombreux types « chaînes de caractères » ont été définis pour la syntaxe ASN.1, ceci afin d’offrirle maximum de flexibilité aux usagers de la syntaxe. Tous les types chaînes de caractères sont déduitsdu type de base OCTETSTRING.

Les types chaînes de caractères actuellement existants sont les suivants :

Tableau 52. Chaînes de caractères.

Type Identifiant EtiquetteChaîne numérique NUMERICSTRING UNIVERSAL 18Chaîne imprimable PRINTABLESTRING UNIVERSAL 19Chaîne télétex TELETEXSTRING UNIVERSAL 20Chaîne télétex T61STRING UNIVERSAL 20Chaîne vidéotex VIDEOTEXSTRING UNIVERSAL 21Chaîne ASCII IA5STRING UNIVERSAL 22Chaîne graphique GRAPHICSTRING UNIVERSAL 25Chaîne visible VISIBLESTRING UNIVERSAL 26


Type Identifiant EtiquetteChaîne généralisée GENERALSTRING UNIVERSAL 27Chaîne universelle UNIVERSALSTRING UNIVERSAL 28Chaîne caractère CHARACTER UNIVERSAL 29Chaîne BMP BMPSTRING UNIVERSAL 30

4.17. TYPES TEMPORELS

4.17.1. GENERALIZEDTIMECe type est composé de valeursreprésentant :

une date calendaire (ISO 2014 : représentation numérique des dates),

une heure (ISO 3307 : représentation de l’heure),

le facteur de décalage horaire local (ISO 4031 : représentation des différences d’heure).

Notation de type

Tableau 53. Notation du type GENERALIZEDTIME (Heure généralisée).

Identifiant EtiquetteGENERALIZEDTIME [UNIVERSAL 24] IMPLICIT VISIBLESTRING

L’heure généralisée est représentée sous la forme d’une chaîne visible pour laquelle diversespossibilités sont offertes :

1. une chaîne représentant la date, l’année étant représentée par quatre chiffres (AAAA), le moispar deux chiffres (MM), ainsi que le jour (JJ), suivie par une chaîne représentant l’heure(HHMMSS ou HHMMSS.d), sans séparateur autres que la virgule ou le point décimal, et sanslettre Z à la fin. Ce cas représente l’heure locale.

2. une chaîne représentant la date, comme au point 1, suivie de la lettre Z majuscule à la fin. Cecas représente l’heure universelle coordonnée.

3. la même chaîne qu’au point 1 suivie d’une chaîne représentant le décalage horaire (caractère+ ou - suivi de HHMM).

Dans ce cas, la chaîne formée comme au cas 1 représentant l’heure locale t1, le décalagehoraire t2 permet de déterminer l’heure UTC comme suit :

Heure UTC = t1 – t2

exemples :

1. 20010717164835.2

Heure locale : 16h 48mn 35,2 sec le 17 juillet 2001

2. 20030815122500.8Z


Heure UTC : 12h 25mn 00,8 sec le 15 août 2003

3. 20051225224835.2+0200

Heure locale : 22h 48mn 35,2 sec le 25 décembre 2005

Décalage horaire : 2 heures

Heure UTC : 20h 48mn 35,2 sec le 25 décembre 2005

4.17.2. UTCTIMELe type est composé de valeurs représentant :

1. une date calendaire (AAMMJJ où AA sont les deux chiffres de plus faible poids de l’annéechrétienne, MM est le mois (janvier étant 01) et JJ le jour du mois (01 à 31)),

2. une heure, à la précision de la minute ou de la seconde (HHMM ou HHMMSS), soit enfinune des deux possibilités suivantes :

a. le caractère Z indiquant l’heure UTC ;b. le facteur de décalage horaire local par rapport à l’heure universelle coordonnée (caractère

+ ou - suivi de HHMM).

Notation de type

Tableau 54. Notation du type UTCTIME (heure universelle).

Identifiant EtiquetteUTCTIME [UNIVERSAL 23] IMPLICIT VISIBLESTRING

heure1 UTCTIME ::= 891110073021Z -- heure UTC = 7h 30mn 21s du 10 novembre 1989

heure2 UTCTIME ::= 891110073021-0200 -- heure locale = 9h 30mn 21s du 10 novembre 1989 -- décalage horaire de 2 heures.

4.18. TYPES UTILES

4.18.1. OBJECTDESCRIPTORBut : décrire un objet quelconque sous forme de texte lisible par l’homme. Joue un rôle decommentaire.

4.18.2. EXTERNALBut : représenter une donnée identifiée dans un ensemble de données enregistré, qui n’utilisenécessairement pas la même syntaxe de transfert (codages différents).

L’identification de la donnée enregistrée s’effectue par :

une référence directe à un objet (OBJECTIDENTIFIER),


une référence indirecte à un «identificateur de contexte de présentation» sous forme d’unINTEGER.

Notation de type

Tableau 55. Notation du type EXTERNAL (externe).

Identifiant EtiquetteEXTERNAL [UNIVERSAL 8] IMPLICIT SEQUENCE{

direct-reference OBJECTIDENTIFIER OPTIONAL,indirect-reference INTEGER OPTIONAL,data-value OBJECTDESCRIPTOR OPTIONAL,encoding CHOICE{ ASN.1-type [0] ANY, octet-aligned [1] IMPLICIT OCTETSTRING, arbitrary [2] IMPLICIT BITSTRING}}

4.19. SOUS-TYPESSousType ::= TypeOriginal (Contrainte | Contrainte... | Contrainte)

Pour améliorer la lisibilité, deux cas particuliers :SousType ::= SET SIZE contrainte OF TypeOriginalSousType ::= SEQUENCE SIZE contrainte OF TypeOriginal

Quelques exemples sont présentés dans les sections suivantes.

4.19.1. Valeurs simplesINTEGER (2)

INTEGER (3|4|6|10)

4.19.2. Sous-types inclusSousTypeRestreint (INCLUDES SousType)

4.19.3. IntervallesINTEGER (4 .. 100)INTEGER (4 < .. < 100)

REAL (0 .. PLUS-INFINITY)

4.19.4. Contraintes sur les taillesOCTETSTRING (SIZE(4 .. 10)) -- entre 4 et 10 octets


4.19.5. Alphabets autorisésChiffres ::= IA5STRING (FROM (‘‘0’’|‘‘1’’|‘‘2’’|‘‘3’’|‘‘4’’|‘‘5’’|‘‘6’’|‘‘7’’|‘‘8’’|‘‘9’’))


Chapitre 5. Le protocole X.226

5.1. Présentation du protocole X.226L’objectif du protocole X.226 est de négocier (ou renégocier) un ensemble de contextes deprésentation.

Pour cela, on est amenés à définir les concepts suivants :

ensemble des contextes définis20

Ceci représente l’ensemble des contextes de présentation qui ont été définis par un accordintervenu entre les trois partenaires d’une communication : les deux utilisateurs et l’entité deprésentation elle-même.

contexte par défaut.

Le contexte par défaut est un contexte de présentation qui est toujours connu de l’entité deprésentation d’une part, et des deux utilisateurs d’autre part.

5.1.1. Relations avec la couche applicationUn protocole d’application est spécifié en termes de transfert de valeurs de données entre entitésd’application, utilisant le paramètre « données de l’utilisateur » des primitives du service deprésentation.

Un ensemble de définitions de valeurs de données associé à un protocole d’application constitue unesyntaxe abstraite (Section 1.3.1, page 9). Pour que deux entités d’application puissent réussir àcommuniquer, elles doivent se mettre d’accord sur l’ensemble des syntaxes abstraites qu’elles ontl’intention d’utiliser. Au cours de la communication, elles peuvent décider de modifier cet accord. Ilpeut en résulter une modification de l’ensemble des syntaxes abstraites en vigueur.

La spécification de syntaxe abstraite identifie le contenu informationnel de l’ensemble des valeurs dedonnées. Il n’identifie pas les syntaxes de transfert à utiliser lorsque des valeurs de données sonttransférées entre applications, et ne concerne pas la représentation locale des valeurs de données.

La raison d’être de la couche présentation est de garantir la conservation du contenu informationneldes valeurs de données durant le transfert. C’est aux entités d’application coopérantes qu’incombe laresponsabilité de déterminer l’ensemble des syntaxes abstraites qu’elles emploient dans leurcommunication ; cette détermination se traduit par un accord dont elles informent les entités deprésentation. Connaissant l’ensemble des syntaxes abstraites à utiliser, les entités de présentationsont responsables du choix des syntaxes de transfert mutuellement acceptables qui préservent lecontenu informationnel des valeurs de données.

5.1.2. Relations avec la couche sessionL’utilisateur du service de présentation (en l’occurrence, une application) bénéficie d’un accès auservice de session qui lui permet une utilisation intégrale de ce service.

20 DCS : defined context set.


5.1.3. Fonctions de la couche présentationLa couche présentation a deux fonctions qu’elle remplit pour le compte des utilisateurs(applications) :

1. la négociation des syntaxes de transfert ;

2. la transformation vers une syntaxe de transfert (codage) et à partir d’une syntaxe de transfert(décodage).

5.1.4. Négociation de la syntaxeLa négociation de la syntaxe de transfert a lieu entre les deux entités de présentation lorsqu’unutilisateur fournit le nom d’une syntaxe abstraite qui nécessite une syntaxe de transfert.

La négociation réussit si son résultat est l’association de la syntaxe abstraite nommée et d’unesyntaxe de transfert compatible. Une telle association constitue un contexte de présentation(Section 1.4, page 10).

En général, la combinaison d’une syntaxe abstraite et d’une syntaxe de transfert n’est pasnécessairement unique. Il peut être possible de représenter une syntaxe abstraite particulière par uneou plusieurs syntaxes de transfert ; il peut être également possible d’utiliser une même syntaxe detransfert pour représenter plusieurs syntaxes abstraites différentes.

5.1.5. Définition de contextes de présentationDeux services permettent de définir des contextes de présentation :

1. le service de connexion de présentation ;

2. le service de gestion de contextes de présentation. (Section 5.1.6)

Ce dernier service est optionnel. Il permet en outre de supprimer des contextes qui ne sont plusnécessaires. Lorsque des contextes sont définis, ils sont ajoutés à un ensemble dénommé DCS(ensemble des contextes définis ; defined context set). Si le DCS est vide, il est possible de transférerdes valeurs de données qui seront alors exprimées selon le contexte par défaut.

5.1.6. Gestion de l’ensemble des contextes définis (DCS)La gestion du DCS est mis en œuvre grâce à deux unités fonctionnelles de présentation optionnelles :

1. gestion des contextes ;

2. restauration de contextes (la gestion des contextes doit avoir été choisie).

5.2. Le protocole et le service de présentationLe protocole de présentation est relativement complexe. Aussi est-il représenté ci-dessous selondeux aspects : le service d’une part (les primitives et surtout leurs paramètres) et les éléments deprotocole (PPDU) d’autre part.


5.2.1. Les primitivesLe service de présentation (X.216) est en apparence relativement complexe. Il convient toutefois denoter qu’il reprend l’intégralité du service session auquel sont ajoutés des primitives spécifiques à lacouche présentation. Le tableau ci-dessous présente la liste complète des primitives de présentation.Chaque primitive de présentation est associée à une primitive de session.

Tableau 56. Liste des primitives présentation.

Primitive Présentation Primitive Session associéePCONreq / ind / resp / conf SCONreq / ind / resp / conf

PRELreq / ind / resp / conf SRELreq / ind / resp / conf

PUABreq / ind SUABreq / ind

PPABind SPABind

PALTERreq / resp STDreq

PALTERind / conf STDind

PDTreq / ind SDTreq / ind

PTDreq / ind STDreq / ind

PEXreq / ind SEXreq / ind

PCDreq / ind / resp / conf SCDreq / ind / resp / conf

PGTreq / ind SGTreq / ind

PPTreq / ind SPTreq / ind

PCGreq / ind SCGreq / ind

PSYNmreq / ind / resp / conf SSYNmreq / ind / resp / conf

PSYNMreq / ind / resp / conf SSYNMreq / ind / resp / conf

PRSYNreq / ind / resp / conf SRSYNreq / ind / resp / conf

PUERreq / ind SUERreq / ind

PACTSreq / ind SACTSreq / ind

PACTRreq / ind SACTRreq / ind

PACTIreq / ind / resp / conf SACTIreq / ind / resp / conf

PACTDreq / ind / resp / conf SACTDreq / ind / resp / conf

PACTEreq / ind / resp / conf SACTEreq / ind / resp / conf

Le tableau suivant présente les paramètres des primitives de connexion présentation.

Tableau 57. Liste des paramètres des primitives de connexion.

nom du paramètre req ind resp confadresse de l’entité présentation appelante m m

adresse de l’entité présentation appelée m m

adresse de l’entité présentation en réponse m m

liste de définitions de contextes de présentation u c

liste de résultats de définitions de contextes c c c

nom du contexte de présentation par défaut u c

résultat pour le contexte présentation par défaut c c


nom du paramètre req ind resp confqualité de service s s s s

proposition de l’utilisateur du service présentation u c u c

mode m m

proposition pour l’utilisateur de session s s s s

nº de série de synchronisation session initial s s s s

attribution initiale des jetons s s s s

identificateur de connexion session s s s s

données utilisateur u c u c

résultat m m

m la présence de ce paramètre est obligatoire.u la présence de ce paramètre dépend de l’utilisateur.c la présence de ce paramètre est conditionnelle.s le paramètre est un paramètre de session.vide le paramètre ne figure pas.

Il est intéressant de noter que, comme la plupart des primitives de présentation, les primitives deconnexion présentation donnent accès à certains paramètres de connexion session. Ainsi, la primitivePCONreq va correspondre à la primitive SCONreq. Toutefois, certains paramètres de la primitivePCONreq sont traduits directement en termes de paramètres de la primitive SCONreq (Citons parexemple « l’attribution initiale des jetons » ou encore « l’identificateur de connexion session »).D’autres sont partiellement transmis à la fois en tant que paramètres de la PPDU CP (ConnectPresentation) et en tant que paramètres de la primitive SCONreq (Citons « l’adresse de l’entitéappelante ». Ce paramètre est ainsi transmis sous la forme d’un « sélecteur de présentation de l’entitéappelante » dans la PPDU CP, et sous la forme d’une « adresse de SSAP appelant » dans la primitiveSCONreq). Enfin, les autres paramètres de la primitive PCONreq sont exclusivement transmis sousforme de paramètres de la PPDU CP (Citons la « liste de définitions de contextes »). Quant à elle, laPPDU CP est transmise en tant que données utilisateur de la primitive SCONreq.

5.2.2. Les PPDULe tableau ci-dessous présente la liste complète des éléments de protocole (PPDU) X.226.

Tableau 58. Liste des PPDU.

type signification (français) signification (anglais)AC Modification de contextes Alter Context

ACA Accusé de réception de modification de contextes Alter Context Acknowledge

ARP Terminaison anormale par le fournisseur Abnormal Release Provider

ARU Terminaison anormale par l’utilisateur Abnormal Release User

CP Connexion de présentation Connect Presentation

CPA Acceptation de connexion de présentation Connect Presentation Accept

CPR Refus de connexion de présentation Connect Presentation Reject

RS Resynchronisation Resynchronize

RSA Accusé de réception de resynchronisation Resynchronize Acknowledge

TC Informations de capacités Capability Data


type signification (français) signification (anglais)TCC Accusé de réception d’informations de capacités Capability Data Acknowledge

TD Données de présentation Presentation Data

TE Données exprès Expedited Data

TTD Données typées de présentation Presentation Typed Data

Le tableau suivant donne la correspondance entre les PPDU et les SPDU.

Tableau 59. Correspondance entre les PPDU et les SPDU.

PPDU SPDU utilisée pourtransférer la PPDU

AC TD

ACA TD

ARP AB

ARU AB

CP CN

CPA AC

CPR RF

RS RS

RSA RA

TC CD

TCC CDA

TD DT

TE EX

TTD TD

5.2.3. Structure des PPDULa structure des éléments de protocole est donnée en syntaxe abstraite ASN.1 plus loin dans ledocument.

5.2.4. Particularités du protocoleIl est toutefois intéressant de noter quelques détails spécifiques concernant leur structure.

5.2.4.1. Transfert d’informationsLes PPDU TD, TTD, TE, TC et TCC n’ont pas d’existence propre. Simplement, les paramètres« données » des primitives présentation correspondantes deviennent les paramètres « données » desprimitives session associées.Toutefois, ces données sont représentées comme des données utilisateur et sont donc codées en tantque telles (Section 5.2.4.6).


5.2.4.2. Gestion des contextesCette unité fonctionnelle permet d’ajouter des contextes au DCS ; elle permet également d’ensupprimer.

5.2.4.3. Restauration des contextesSi cette unité est utilisée, l’entité de présentation mémorise le DCS à des points spécifiés au cours dela connexion. Si l’utilisateur demande un retour à l’un de ces points, le DCS est rétabli tel qu’il étaità ce point.

5.2.4.4. Unités fonctionnelles de sessionLes PPDU CP et CPA contiennent toutes les deux un paramètre appelé « propositions-utilisateur-session » contenant une liste d’unités fonctionnelles de session. Or, cette liste doit également êtretransmise à session par les primitives SCONreq et SCONresp.

La raison d’être de cette duplication est la suivante. Il est possible que deux applications désirantétablir une association ne souhaitent pas utiliser les unités fonctionnelles session de transfert dedonnées typées et/ou de resynchronisation. Toutefois, si ces deux applications souhaitent utiliser lesunités fonctionnelles présentation de modification et/ou de restauration de contextes, il est nécessairede disposer des deux unités fonctionnelles non choisies.

Pour résoudre ce dilemme, la liste des unités fonctionnelles session absolument nécessaires auxapplications est transmise en tant que paramètre des PPDU, et la liste révisée de ces unités(autrement dit la liste demandée par les applications, plus les unités nécessaires à présentation) estcommuniquée à la couche session.

5.2.4.5. Unités fonctionnelles de session nécessairesChacune des deux unités fonctionnelles de présentation permettant la gestion du DCS suppose lamise en œuvre d’unités fonctionnelles de session, sans que celles-ci aient été nécessairement choisiepar l’utilisateur (voir section 5.2.4.4).

La gestion des contextes impose les données typées de session.

La restauration de contextes impose soit la gestion d’activité de session, soit la synchronisation(mineure ou majeure) et la resynchronisation de session.

5.2.4.6. Données utilisateurLa majorité des PPDU sont capables de transporter des « données utilisateur » ; autrement dit, desdonnées en provenance de la couche application. Toutefois, il est spécifié (Section 1.4) que lesdonnées utilisateur peuvent être représentées suivant un ou plusieurs contextes de présentation.

Pour atteindre cet objectif, la structure suivante a donc été définie :

Données-utilisateur ::= CHOICE { [APPLICATION 0] IMPLICIT Données-codage-simple, [APPLICATION 1] IMPLICIT Données-codage-intégral }

Données-codage-simple ::= OCTETSTRING

Données-codage-intégral ::= SEQUENCE OF Liste-PDV

Liste-PDV ::= SEQUENCE { Nom-syntaxe-transfert OPTIONAL, Identificateur-contexte,


valeur CHOICE { type-ASN1-unique [0] ANY, aligné-octet [1] IMPLICIT OCTETSTRING, arbitraire [2] IMPLICIT BITSTRING } }

Les données utilisateur sont représentés au choix soit selon la variante « Données-codage-simple »,soit selon la variante « Données-codage-intégral ».La variante «Données-codage-simple » est utilisée, généralement, lorsque les données doivent êtretransmises selon le contexte par défaut. Le codage de cette variante est très facile puisque c’est toutsimplement une chaîne d’octets.

La variante « Données-codage-intégral » est utilisée dans les autres cas. Cette variante permet detransférer des données selon d’autres contextes, éventuellement imbriqués, et, également, selond’autres syntaxes abstraites si cela est nécessaire (variante « arbitraire » ou « aligné-octet »).En effet, le codage de cette variante précise que les données seront structurées comme étant unesuite ordonnée de blocs. Chaque bloc représente des données transmises dans un contexte deprésentation. La structure d’un bloc est la suivante :

1. éventuellement le nom de la syntaxe de transfert utilisée pour le codage ;

2. l’identificateur (un nombre entier) du contexte de présentation (ce qui revient à identifier lasyntaxe de transfert ; c’est la raison pour laquelle il n’est pas nécessaire de transmettre denom de cette syntaxe de transfert) ;

3. les données elles-mêmes (représentées au choix comme une chaîne binaire, une chaîned’octets, ou comme n’importe quel autre type ASN.1 si cela est nécessaire).


Chapitre 6. Tableau récapitulatif des typesASN.1

Le tableau ci-dessous présente tous les types universels définis dans la norme ASN.1. La colonneP/C précise si le type est primitif ou constructeur, voire les deux. La colonne Hexa donne le codagehexadécimal du type ; éventuellement, si le type est à la fois primitif et constructeur, les deuxcodages sont donnés dans cet ordre.

Tableau 60. Récapitulatif des types UNIVERSAL.

Type Identifiant Etiquette Hexa P/CBooléen BOOLEAN UNIVERSAL 1 01 PEntier INTEGER UNIVERSAL 2 02 PChaîne binaire BIT STRING UNIVERSAL 3 03/23 P/CChaîne d’octets OCTET STRING UNIVERSAL 4 04/24 P/CNul NULL UNIVERSAL 5 05 PIdentifiant d’objet OBJECT IDENTIFIER UNIVERSAL 6 06 PDescripteur d’objet OBJECT DESCRIPTOR UNIVERSAL 7 07/27 P/CExterne EXTERNAL UNIVERSAL 8 28 CRéel REAL UNIVERSAL 9 09 PEnumération ENUMERATED UNIVERSAL 10 0A PType imbriqué EMBEDDED-PDV UNIVERSAL 11 0B P/Cusage ultérieur UNIVERSAL 12-15Suite SEQUENCE UNIVERSAL 16 30 CSuite répétitive SEQUENCE OF UNIVERSAL 16 30 CEnsemble SET UNIVERSAL 17 31 CEnsemble répétitif SET OF UNIVERSAL 17 31 CChaîne numérique NumericString UNIVERSAL 18 12/32 P/CChaîne imprimable PrintableString UNIVERSAL 19 13/33 P/CChaîne télétex TeletexString

T61StringUNIVERSAL 20 14/34 P/C

Chaîne vidéotex VideotextString UNIVERSAL 21 15/35 P/CChaîne ASCII IA5String UNIVERSAL 22 16/36 P/CHeure universelle UTCTime UNIVERSAL 23 17/37 P/CHeure généralisée GeneralizedTime UNIVERSAL 24 18/38 P/CChaîne graphique GraphicString UNIVERSAL 25 19/39 P/CChaîne visible VisibleString UNIVERSAL 26 1A/3A P/CChaîne généralisée GeneralString UNIVERSAL 27 1B/3B P/CChaîne universelle UniversalString UNIVERSAL 28 1C/3C P/CChaîne caractère Character UNIVERSAL 29 1D/3E P/CChaîne BMP BMPString UNIVERSAL 30 1E/3E P/C


Chapitre 7. Structure des PPDU duprotocole X226

Nous donnons ci-dessous in extenso la définition ASN.1 de la structure des PPDU.

X226-PRESENTATION DEFINITIONS ::=

-- Le type suivant est transmis lors de l’établissement de la connexion.

Type-CP ::= SET { [0] IMPLICIT Sélecteur-mode,

-- le paramètre ci-dessous est utilisé seulement en mode X410 [1] IMPLICIT SET { COMPONENTS OF APDU-Transfert-Fiable.apdu-RTORQ} OPTIONAL,

-- le paramètre ci-dessous est utilisé seulement en mode normal. [2] IMPLICIT SEQUENCE { [0] IMPLICIT Version-protocole DEFAULT{v1}, [1] IMPLICIT Sélecteur-entité-appelante OPTIONAL, [2] IMPLICIT Sélecteur-entité-appelée OPTIONAL, [4] IMPLICIT Liste-définitions-contextes OPTIONAL, [6] IMPLICIT Nom-contexte-défaut OPTIONAL, [8] IMPLICIT Propositions-utilisateur-PS OPTIONAL, [9] IMPLICIT Propositions-utilisateur-session OPTIONAL, -- ce paramètre ne peut pas être présent si identique au -- paramètre «propositions révisées de l’utilisateur pour la -- session»

Données-utilisateur OPTIONAL}}

Type-CPC ::= Données-utilisateur

-- Le type suivant est transmis lors de l’acceptation de la connexion.

PPDU-CPA ::= SET { [0] IMPLICIT Sélecteur-mode -- parametre ci-dessous uniquemenent en mode X410 [1] IMPLICIT SET { COMPONENTS OF APDU-Transfert-Fiable.apdu-RTOAC} OPTIONAL -- parametre ci-dessous uniquement en mode mormal. [2] IMPLICIT SEQUENCE { [0] IMPLICIT Version-protocole DEFAULT{v1}, [3] IMPLICIT Sélecteur-en-réponse OPTIONAL, [5] IMPLICIT Liste-résultats-contextes OPTIONAL, [8] IMPLICIT Propositions-utilisateur-PS OPTIONAL, [9] IMPLICIT Propositions-utilisateur-session OPTIONAL Données-utilisateur OPTIONAL}}

-- Le type suivant est utilisé lors du rejet d’une connexion


PPDU-CPR ::= CHOICE { SET {COMPONENTS OF APDU-Transfert-Fiable.apdu-RTORJ}, -- mode X410 SEQUENCE { [0] IMPLICIT Version-protocole DEFAULT{v1}, [3] IMPLICIT Sélecteur-en-réponse OPTIONAL, [5] IMPLICIT Liste-résultats-contextes OPTIONAL, [7] IMPLICIT Résultat-contexte-défaut OPTIONAL, [10] IMPLICIT Raison-fournisseur OPTIONAL, Données-utilisateur OPTIONAL} -- mode normal}

-- Le type suivant est utilisé lors de l’abandon d’une connexion

Type-coupure ::= CHOICE { PPDU-ARU PPDU-ARP}

-- La PPDU ARU correspond à l’abandon de la connexion par l’utilisateur.

PPDU-ARU ::= CHOICE { SET {COMPONENTS OF APDU-Transfert-Fiable.apdu-RTAB}, -- mode X410 [0] IMPLICIT SEQUENCE { [0] IMPLICIT Liste-identificateurs-contextes OPTIONAL, Données-utilisateur OPTIONAL} -- mode normal}

-- La PPDU ARP correspond à l’abandon par le fournisseur de service (provider)-- c’est-à-dire lorsque la couche présentation décide de manière-- unilatérale d’abandonner la connexion.

PPDU-ARP ::= SEQUENCE { raison-fournisseur [0] IMPLICIT Raison-coupure OPTIONAL, [1] IMPLICIT Identificateur-événement OPTIONAL}

-- Les données typées session peuvent transporter 3 types de PPDU.

Type-données-typées ::= CHOICE { ppdu-AC [0] IMPLICIT PPDU-AC, ppdu-ACA [1] IMPLICIT PPDU-ACA, ppdu-TTD Données-utilisateur}

-- La PPDU AC permet de modifier la liste des définitions de contextes-- de présentation.

PPDU-AC ::= SEQUENCE { [0] IMPLICIT Liste-additions-contextes OPTIONAL, [1] IMPLICIT Liste-suppressions-contextes OPTIONAL, Données-utilisateur OPTIONAL}-- La PPDU ACA est la réponse à la PPDU AC


PPDU-ACA ::= SEQUENCE { [0] IMPLICIT Liste-résultats-additions-contextes OPTIONAL, [1] IMPLICIT Liste-résultats-suppressions-contextes OPTIONAL, Données-utilisateur OPTIONAL}

-- La PPDU RS est émise lors d’une resynchronisation

PPDU-RS ::= SEQUENCE { [0] IMPLICIT Liste-identificateurs-contextes OPTIONAL, Données-utilisateur OPTIONAL}

-- La PPDU RA est la réponse à la PPDU RS

PPDU-RSA ::= SEQUENCE { [0] IMPLICIT Liste-identificateurs-contextes OPTIONAL, Données-utilisateur OPTIONAL}

-- transfert des données utilisateur. Utilisé seul, ce type correspond-- à la PPDU DT

Données-utilisateur ::= CHOICE { [APPLICATION 0] IMPLICIT Données-codage-simple, [APPLICATION 1] IMPLICIT Données-codage-intégral}

-- Un des deux choix possibles du type Donnees-utilisateur.-- C’est ce type qui doit être utilisé pour le transfert de données selon le-- contexte de présentation par défaut.

Données-codage-simple ::= OCTETSTRING

-- Un des deux choix possibles du type Donnees-utilisateur.-- C’est le choix le plus courant. Est obligatoire lorsqu’il y a plusieurs-- contextes de présentation existants.

Données-codage-intégral ::= SEQUENCE OF Liste-PDV

-- La structure Liste-PDV permet de transporter un ou plusieurs données en-- précisant pour chacune d’entre elles le contexte de présentation utilisé.

Liste-PDV ::= SEQUENCE { Nom-syntaxe-transfert OPTIONAL, Identificateur-contexte, valeur CHOICE { type-ASN1-unique [0] ANY, aligné-octet [1] IMPLICIT OCTETSTRING, arbitraire [2] IMPLICIT BITSTRING}}


-- Types secondaires.-- Ces types ne sont jamais transmis seuls et font toujours partie d’une-- PPDU plus importante.

Raison-coupure ::= INTEGER { raison-non-spécifiée (0), ppdu-non-reconnue (1), ppdu-non-attendue (2), primitive-service-session-non-attendue (3), paramètre-ppdu-non-reconnu (4), paramètre-ppdu-non-attendu (5), valeur-paramètre-ppdu-non-valide (6)}

-- identification des syntaxes

Nom-syntaxe-abstraite ::= OBJECTIDENTIFIER

Nom-contexe-défaut ::= SEQUENCE { [0] IMPLICIT Nom-syntaxe-abstraite, [1] IMPLICIT Nom-syntaxe-transfert}

Nom-syntaxe-transfert ::= OBJECTIDENTIFIER

-- adressage presentation

Sélecteur-entité-appelée ::= Sélecteur-présentation

Sélecteur-entité-appelante ::= Sélecteur-présentation

Sélecteur-en-réponse ::= Sélecteur-présentation

Sélecteur-présentation ::= OCTETSTRING

-- gestion des contextes

Liste-contextes ::= SEQUENCE OF SEQUENCE { Identificateur-contexte, Nom-syntaxe-abstraite, SEQUENCE OF Nom-syntaxe-transfert}

Liste-additions-contextes ::= Liste-contextes

Liste-résultats-additions-contextes ::= Liste-résultats

Liste-définitions-contextes ::= Liste-contextes


Liste-résultats-contextes ::= Liste-résultats

Liste-suppressions-contextes ::= SEQUENCE OF Identificateur-contexte

Liste-résultats-suppresions-contextes ::= SEQUENCE OF INTEGER {acceptation (0), refus-utilisateur (1)}

Identificateur-contexte ::= INTEGER

Liste-identificateurs-contextes ::= SEQUENCE OF SEQUENCE { Identificateur-contexte, Nom-syntaxe-transfert}

Résultat-contexte-défaut ::= Résultat

Liste-résultats ::= SEQUENCE OF SEQUENCE { [0] IMPLICIT Résultat, [1] IMPLICIT Nom-syntaxe-transfert OPTIONAL, raison-fournisseur [2] IMPLICIT INTEGER { raison-non-spécifiée (0), syntaxe-abstraite-non-acceptable (1), syntaxes-transfert-non-acceptables (2), dépassement-limite-locale-sur-DCS (3)} OPTIONAL}

Résultat ::= INTEGER { acceptation (0), refus-utilisateur (1), refus-fournisseur (2)}

-- gestion des incidents

Identificateur-événement ::= INTEGER { ppdu-CP (0), ppdu-CPA (1), ppdu-CPR (2), ppdu-ARU (3), ppdu-ARP (4), ppdu-AC (5), ppdu-ACA (6), ppdu-TD (7), ppdu-TTD (8), ppdu-TE (9), ppdu-TC (10), ppdu-TCC (11), ppdu-RS (12), ppdu-RSA (13), sRELind (14), sRELconf (15), sGTind (16), sPTind (17),


sGCind (18), sSYMmind (19), sSYNmconf (20), sSYNMind (21), sSYNMconf (22), sPERind (23), sUERind (24), sACTSind (25), sACTRind (26), sACTIind (27), sACTIconf (28), sACTDind (29), sACTDconf (30), sACTEind (31), sACTEconf (32)}

Raison-fournisseur ::= INTEGER { raison-non-spécifiée (0), engorgement-temporaire (1), dépassement-limite-locale (2), adresse-entité-appelée-inconnue (3), version-protocole-non-acceptable (4), contexte-défaut-non-acceptable (5), données-utilisateur-non-lisibles (6), pSAP-non-disponible (7)}

-- controle des fonctionnalites globales du protocole

Sélecteur-mode ::= SET { [0] IMPLICIT INTEGER { mode-X410 (0), mode-normal (1)}}

Version-protocole ::= BITSTRING {v1 (0)}

Propositions-utilisateur-PS ::= BITSTRING { gestion-contextes (0), restauration (1)}

Propositions-utilisateur-session ::= BITSTRING { semi-duplex (0), duplex (1), données-exprès (2), synchronisation-mineure (3), synchronisation-majeure (4), resynchronisation (5), gestion-activité (6), terminaison-négociée (7), informations-capacités (8), signalisation-anomalies (9), données-typées (10)}

END


La couche présentation ; la syntaxe ASNmichel/Supports/presentation.pdf · Informations Ce...

Documents

Transcript of La couche présentation ; la syntaxe ASNmichel/Supports/presentation.pdf · Informations Ce...