Rôle
Assure l’adaptation des données entre les systèmes hétérogénes – Gére la représentation des données.
Le modèle OSI est conçu pour faciliter l’interconnexion de systèmes ouverts ! Mais ces systèmes sont bien souvent hétérogènes, ils utilisent d’ailleurs bien souvent des modèles de représentation des données qui sont différents. Par exemple les uns utiliseront un codage EBCDIC (notamment chez IBM) et d’autre un codage ASCII (notamment en UNIX) pour réaliser le codage d’une grille de caractère !
Pour certains systèmes il faudra de plus implémenter un système de cryptage des données (notamment dans le cas des applications de traitements bancaires ou même pour le Télécommerce sur Internet !).
La couche présentation assure ces fonctions.
L’unité de données du protocole est appelée la PPDU (Presentation Protocol Data Unit). Cette PPDU est bien sûr, en principe, encapsulée dans la SPDU du niveau 5.
Fonctions
1 – Négociation de syntaxe de transfert
Imaginons trois Internautes : un anglais, un français et un grec (pourquoi pas ?). Un soir ils se rencontrent sur un « chat-room » (pour faire dans l’air du temps !). Aucun d’entre-eux ne sait parler la langue de l’autre, et pourtant ils aimeraient communiquer !
Première solution : L’anglais, peu avare, téléphone à une boite d’intérim et commande deux traducteurs. Lorsqu’il veut parler au français il active son traducteur français, lorsqu’il veut parler au grec, il active son traducteur grec ! Vous imaginez sans peine la joie de l’agence d’intérim lorsque l’anglais décide de converser avec des autochtones de dix nations différentes !
Deuxième solution : Le français, plus avisé (bien sûr) dans ses dépenses (plus avare quoi !), décide de n’engager qu’un seul traducteur ! Il dit : « Moi je veux un traducteur en Espéranto ! Il traduira mon bon français des chaumières en un pur Espéranto que les autres devront comprendre et eux-mêmes traduire dans leur dialecte incompréhensible ! ». Avisé, le français, a ainsi réparti les coûts de traduction sur les différents communicants ! De plus quiconque voudra participer à la discussion devra se procurer un seul traducteur Espéranto (le cours du traducteur Espéranto est à la hausse … Métier d’avenir !).
Troisième solution : Le grec, cherche toujours ! (Ce que je peux être méchant quelques fois !).
Le modèle OSI propose d’appliquer la solution 2, mais laisse aussi toute latitude pour se rabattre sur la première solution … Je m’explique :
Dans le cas 1, deux entités ne parlant pas le même langage, pourront tenter de négocier l’utilisation d’un langage commun. Par exemple, si A parle nativement en A, et B parle nativement en B. A dit à B : » Moi je sais parler en A et C. Et toi ? « , B répond : » Moi je parle en A et B. Parlons donc en A, OK ? ». A répond : « OK ». Négociation terminée !
La couche présentation propose, par son protocole, la négociation de langages de transfert.
Dans le cas 2, deux entités ne parlant pas le même langage pourront négocier une syntaxe de transfert commune. Par exemple, si A parle nativement en A, mais dispose d’une couche présentation proposant un langage C, et B parle nativement en B mais dispose également d’une couche présentation proposant un langage C. A dit à B : » Moi je sais parler en A etC. Et toi ? « , B répond : » Moi je parle en C et B, on parle donc en C, OK ? », A répond : « OK ». Négociation terminée !
On remarque ici que le langage choisi n’est aucun des deux langages natifs. C’est un choix de langage de transfert ! A va traduire sa syntaxe A en C, l’émettre, B en réception traduit C en B, et le tour est joué ! Enfin presque …
2 – Une syntaxe de transfert à toute épreuve
Le paragraphe précédent présente les négociations de manière idyllique ! En effet, on peut facilement imaginer que pour certains mots il n’y ait pas d’équivalent d’un langage à un autre ! Ainsi certains caractères de la grille EBCDIC qui est codée sur 8 bits, sont intraduisibles en ASCII qui est codé sur 7 bits ! (256 possibilités en EBCDI, contre 128 en ASCII !).
Mon anglais me l’interdit, mais je suis sûr que les anglophobes (non, ce n’est pas une faute !), que vous êtes sauront trouver des exemples de non correspondance entre Français et Anglais (à part le mot : Mouton !).
Résultat, si l’on veut être sûr de pouvoir acheminer toutes les informations de manière transparente, il faudra dénicher une syntaxe de transfert capable d’acheminer à peu près n’importe quel type de données !! Et là … OSI est arrivé !
ASN 1 (Abstract Syntax Notation Number One), vous connaissez ? C’est un langage de type LTV (Longueur, Type, Valeur : à vos souhaits !) qui permet de décrire à peu près n’importe quels types de données, et donc se présente comme leader pour le transport d’informations hétéroclites !
Défini par la norme ISO 8824, il permet de décrire une variable (ou une donnée) par son type (booléen, entier, réel, binaire, octet long, séquence, chaîne de caractère, etc…), sa valeur (a, 1, 125, bobo, tartuffe, NON, OUI, AND, etc ..) et sa longeur (1 bit, un octet, un mot, etc ..).
Plus fort ! L’ASN 1 est également utilisé comme langage de description de programmation. Les requêtes SNMP pour l’adressage des objets dans les MIBs (attention, ici je m’adresse aux experts, désolés pour les autres !), sont aussi décrits en ASN 1.
Remarques
En résumé, la couche Présentation autorise entre-autres :
- La négociation de syntaxes de transfert
- La conversion de syntaxes locales en syntaxes de transfert
- L’utilisation d’une syntaxe de transfert normalisée (ASN 1)
- La cryptage des informations à des fins sécuritaires.
Je n’ai dans ce chapitre, pas franchement parlé des méthodes de cryptages, pour au moins deux raisons :
- Je dispose d’assez peu d’informations sur le sujet.
- La presse se fait suffisamment l’écho du problème actuellement (je te le code sur combien ton message ? Deux ou 64 bits ? Qu’est-ce qu’il va dire le gouvernement ? Tu crois qu’il arrivera à décoder mes messages, pour que je sois autorisé à coder sur 32 bits ?)
Le chapitre suivant vous présente donc très sommairement la couche Application.