Groupe de travail Réseau

Convention de désignation de domaine pour les applications d’utilisateur de l’Internet

Table des Matières

1. Introduction 1

2. Modèle structurel 1

3. Avantage de la dénomination absolue 3

4. Interopérabilité 3

5. Service de noms 4

6. Autorité de désignation 5

7. Applications orienté réseau 5

8. Relais de messagerie 5

9. Mise en œuvre 6

10. Résumé 6

Appendice A Spécification en BNF 6

Appendice B Aparté sur l’allocation des noms simples 7

Appendice C Exposé complémentaire sur service de nom et serveurs de noms 8

Appendice D Exposé complémentaire sur l’interopérabilité et les traductions de protocole 8

Glossaire 9

Références 9

Pendant de nombreuses années, la convention de désignation "<usager>@<hôte>" a servi à la communauté des utilisateurs de l’ARPANET pour son système de messagerie, et la sous chaîne "<hôte>" a été utilisée pour d’autres applications telles que les transferts de fichiers (FTP) et l’accès au terminal (Telnet). Avec l’arrivée de l’interconnexion de réseaux, cette convention de désignation a besoin d’être généralisée pour s’accommoder de l’inter réseautage. Une décision a récemment été prise de remplacer le champ de simple nom, "<hôte>", par un champ de nom composite, "<domaine>" [2]. La présente note est une tentative pour clarifier cette convention de dénomination généralisée, la convention de dénomination de l’Internet, et explorer les implications de son adoption pour le service des noms de l’Internet et les applications d’utilisateur.

L’exemple suivant illustre les changements de la convention de dénomination :

L’intention est que les noms Internet soient utilisés pour former une hiérarchie administrative structurée en arborescence, plutôt qu’une hiérarchie strictement dépendante de la topologie. La chaîne de gauche à droite des composants de nom va du plus spécifique au plus général, c’est-à-dire que la racine de l’arborescence, l’univers administratif, est sur la droite.

Le service des noms pour réaliser la convention de dénomination de l’Internet est supposée être indépendante de l’application. Elle ne fait pas partie d’une application particulière, mais plutôt un service de noms indépendant sert différentes applications d’utilisateur.

La convention de dénomination de l’Internet se fonde sur le concept de domaine. Le nom d’un domaine consiste en l’enchaînement d’un ou plusieurs <noms simples>. Un domaine peut être considéré comme une région de juridiction pour l’allocation des noms et la responsabilité de la traduction de nom en adresse. L’ensemble des domaines forme une hiérarchie.

En utilisant une représentation de la théorie des graphes, cette hiérarchie peut être modélisée comme un graphe dirigé. Un graphe dirigé consiste en un ensemble de nœuds et en une collection d’arcs, où les arcs sont identifiés par des paires ordonnées de nœuds distincts [1]. Chaque nœud du graphe représente un domaine. Une paire ordonnée (B, A), un arc de B à A, indiquent que B est un sous domaine du domaine A, et que B est un simple nom unique au sein de A. On appellera B un enfant de A, et A un parent de B. Le graphe dirigé que décrit le mieux la hiérarchie de désignation est appelé une "arborescence", qui est un arbre avec une racine dont tous les arcs sont dirigés vers la racine (Figure 1). La racine de l’arborescence représente l’univers de désignation, ancêtre de tous les domaines. Les points d’extrémité (ou feuilles) de l’arborescence sont les domaines de niveaux inférieurs.

Le nom simple d’un enfant dans ce modèle est nécessairement unique au sein de son domaine parent. Comme le nom simple du parent d’un enfant est unique au sein du domaine du grand parent de l’enfant, l’enfant peut être désigné de façon univoque dans le domaine de son grand parent par l’enchaînement de son nom simple suivi par le nom simple de son parent.

Par exemple, si le nom simple d’un enfant est "C1" alors aucun autre enfant du même parent ne peut être nommé "C1". De plus, si le parent de cet enfant est nommé "P1", alors "P1" est un nom simple univoque dans le domaine du grand parent de l’enfant. Donc, l’enchaînement C1.P1 est unique dans le domaine du grand parent de C1.

De façon similaire, chaque élément de la hiérarchie est désigné de façon univoque dans son univers par son nom complet, l’enchaînement de son nom simple et de ceux des domaines le long du chemin qui conduit à l’univers de désignation.

La structure hiérarchique de la convention de désignation de l’Internet prend en charge la décentralisation de l’autorité de désignation et la distribution de la capacité du service de noms. On suppose une autorité de désignation et un serveur de noms associés à chaque domaine. Dans les Sections respectivement 5 et 6, on discute du service des noms et des autorités de désignation.

Au sein d’un domaine de point d’extrémité, des noms univoques sont alloués à <usager> représentant les boîtes aux lettres des usagers. Les boîtes aux lettres d’usager peuvent être vues comme les enfants de leurs domaines respectifs. En réalité, il peut exister des anomalies qui violent le modèle arborescent de la hiérarchie de désignation. Des chevauchements de domaines impliquent une parenté multiple, c’est-à-dire qu’une entité de la hiérarchie de désignation est un enfant de plus d’un domaine. On peut concevoir que ISI puisse être un membre du domaine ARPA aussi bien que du domaine USC (Figure 2). Une telle relation constitue une anomalie à la règle de la connexité unique entre deux points quelconques de l’arborescence. L’enfant commun et le sous arbre ci-dessous deviennent les descendants des deux domaines parents.

Quelques problèmes de la parenté multiple sont examinés dans l’Appendice B. Les implications générales de la parenté multiple feront l’objet d’investigations complémentaires.

La dénomination absolue implique que les noms (complets) sont alloués par rapport à un point de référence universel. L’avantage de la dénomination absolue est qu’un nom ainsi alloué peut être universellement interprété par rapport au point de référence universel. La convention de désignation de l’Internet fournit la dénomination absolue avec l’univers de désignation comme son point de référence universel.

Pour la dénomination relative, une entité est désignée selon la position de l’entité de désignation par rapport à celle de l’entité désignée. Un ensemble d’hôtes fonctionnant avec le système d’exploitation "unix" échangent de la messagerie en utilisant une méthode appelée "uucp". La convention de désignation employée par uucp est un exemple de dénomination relative. Le receveur de message est normalement désigné par un chemin de source qui identifie une chaîne d’hôtes connus localement reliant l’hôte de l’envoyeur à celui du receveur. Un nom de destination peut être, par exemple, "alpha!beta!gamma!john", où "alpha" est supposé connu de l’hôte d’origine, "beta" est connu de "alpha", et ainsi de suite.

Le système de messagerie uucp a mis en évidence beaucoup des problèmes inhérents à la désignation relative. Lorsque les noms d’hôtes ne sont interprétables que localement, l’optimisation de l’acheminement devient impossible. Un message de réponse peut devoir traverser le chemin inverse vers l’envoyeur d’origine afin d’être transmis aux autres parties.

De plus, si un message est transmis par un des receveurs d’origine ou passé comme texte d’un autre message, la trame de référence du chemin de source relatif peut être complémenté perdu. De tels schémas de désignation relatifs posent de sévères problèmes pour de nombreux usages dont dépend la communauté ARPA Internet.

Pour permettre l’interopération avec une convention de désignation différente, les noms alloués par une convention de désignation étrangère ont besoin d’accommodements. Du fait de la nature autonome des domaines, un environnement de désignation étranger peut être incorporé comme domaine n’importe où dans la hiérarchie. Au sein de l’univers de désignation, le service des noms pour un domaine est fourni au sein de ce domaine. Donc, une convention de désignation étrangère peut être indépendante de la convention de désignation de l’Internet. Cela implique qu’aucune convention standard pour les désignations n’a besoin d’être imposée pour permettre les interopérations parmi des environnements de désignation hétérogènes.

Il pourrait y avoir une convention de désignation, disons, dans le monde FOO, quelque chose comme "<usager>%<hôte>%<zone>". Les communications avec une entité dans cet environnement peuvent être réalisée à partir de la communauté de l’Internet en ajoutant simplement ".FOO" à la fin du nom dans cette convention étrangère.

Une façon de s’accommoder du "uucp world" décrit dans la dernière section est de le déclarer comme un système étranger. Donc, un nom uucp "alpha!beta!gamma!john" pourrait être connu dans la communauté Internet comme "alpha!beta!gamma!john.UUCP".

Communiquer avec un sous domaine complexe est un cas différent qui peut être traité comme une interopération. Un sous domaine complexe est un domaine avec une structure de désignation interne complexe présumée inconnue du monde extérieur (ou dont le monde externe ne se soucie pas de s’embarrasser de sa complexité).

Pour l’application de système de messagerie, les noms incorporés dans le texte du message sont souvent utilisés par la destination pour des objets tels que la réponse au message original. Donc, les noms incorporés peuvent avoir besoin d’être convertis au profit du serveur de noms dans l’environnement de destination.

La conversion des noms sur la frontière entre des environnements de désignation hétérogènes est un sujet complexe. L’exemple suivant illustre certaines des questions impliquées.

Un message est envoyé de la communauté de l’Internet à l’environnement FOO. Il peut porter les champs "From" et "To" suivants :

où "FOO" est un domaine indépendant de l’environnement de désignation Internet. L’interface sur la frontière des deux environnements peut être représenté par un module logiciel. On peut supposer que cette interface est une entité de la communauté Internet aussi bien que de la communauté FOO. Pour le bénéfice de l’environnement FOO, les champs "From" et "To" doivent être modifiés à la frontière à l’arrivée du message. On peut voir la désignation comme une couche de protocole séparée, et traiter la conversion comme une traduction de protocole. La question est compliquée lorsque le message est envoyé à plus d’une destination au sein de différents environnements de désignation ; ou que le message est destiné à un environnement qui ne partage pas de frontière avec l’environnement de désignation d’origine.

Bien que le sujet de la conversion sorte du domaine d’application de la présente note, quelques questions sont examinées à l’Appendice D.

Le service des noms est un service réseau qui fournit une traduction de nom en adresse. Un tel service peut être réalisé de différentes façons. Pour un simple environnement de réseautage, il peut être accompli avec une seule base de données centrale contenant la correspondance de nom en adresse pour toutes les entités réseau pertinentes, comme les hôtes.

Dans le cas des vieux noms d’hôte de l’ARPANET, une base de données centrale est dupliquée dans chaque hôte individuel. Le module d’origine d’un processus d’application va interroger le service de noms local (par exemple, en faisant un appel système) pour obtenir l’adresse réseau pour l’hôte de destination. Avec la prolifération des réseaux et l’accroissement accéléré du nombre d’hôtes qui participent au réseautage, de taille toujours croissante, la fréquence des mises à jour, et la dissémination de la base de données centrale rendent cette approche ingérable.

La structure hiérarchique de la convention de désignation de l’Internet prend en charge la décentralisation de l’autorité de désignation et la répartition de la capacité du service de noms. Elle s’accommode déjà de la croissance de l’univers de désignation. Elle permet un nombre arbitraire de couches hiérarchiques. L’ajout d’un nouveau domaine apporte peu de complexité au système Internet existant.

Le service de noms de chaque domaine est supposé être fourni par un ou plusieurs serveurs de noms. Il y a deux modèles de la façon dont un serveur de noms accomplit sa tâche, qui peuvent être appelés "itératif" et "récurrent".

Pour un serveur de noms itératif, il peut y avoir deux sortes de réponses. La première sorte de réponse est une adresse de destination. La seconde sorte de réponse est l’adresse d’un autre serveur de noms. Si la réponse est une adresse de destination, l’interrogation est alors satisfaite. Si la réponse est l’adresse d’un autre serveur de noms, l’interrogation doit alors être répétée en utilisant ce serveur de noms, et ainsi de suite jusqu’à obtention d’une adresse de destination.

Pour un serveur de noms récurrent, il y a seulement une sorte de réponse – une adresse de destination. Cela fait peser sur le serveur de noms l’obligation de faire en fait appel à un autre serveur de noms si il ne peut pas répondre lui-même à l’interrogation.

On note que les boucles peuvent être évitées car les noms présentés pour traduction peuvent seulement être un enchaînement fini. Cependant, il faut faire attention lorsque on emploie un mécanisme de pointeur sur le prochain nom simple pour résolution.

On pense que certains serveurs de noms seront récurrents, mais on ne pense pas que ce soit le cas de tous. Cela signifie que l’appelant doit être prêt aux deux types de serveurs. D’autres éléments et des exemples du service de noms figurent à l’Appendice C.

Le service de noms de base de chaque domaine est la traduction des noms simples en adresses pour tous ses enfants. Cependant, si seul ce service de noms de base est fourni, l’utilisation de noms complets (ou pleinement qualifiés) sera nécessaire. Une telle exigence peut en pratique être déraisonnable. Donc, on propose l’utilisation de noms partiels dans le contexte où leur caractère univoque est préservé. Par construction, l’univocité de la désignation est préservée au sein du domaine d’un ancêtre commun. Donc, un nom partiellement qualifié est construit en omettant dans le nom complet les ancêtres communs aux parties communicantes. Lorsque un nom partiellement qualifié quitte son contexte d’unicité, il doit avoir sa qualification complétée.

L’utilisation de noms partiellement qualifiés fait peser une exigence sur le service des noms de l’Internet. Pour satisfaire à cette exigence, le service de noms de chaque domaine doit être capable, en plus du service de base, résoudre les noms simples pour tous ses ancêtres (y compris lui-même) et leurs enfants. Dans l’Appendice B est traitée la distinction nécessaire entre noms simples pour une telle résolution.

Il doit y avoir une autorité de désignation associée à chaque domaine pour allouer des noms simples et s’assurer d’une distinction appropriée parmi les noms simples.

Noter que si l’utilisation des noms partiellement qualifiés est permise dans un sous-domaine, l’unicité des noms simples au sein de ce sous-domaine est insuffisante pour éviter les ambiguïtés avec les noms extérieurs au sous-domaine. L’Appendice B discute de l’allocation des noms simples dans un sous-domaine qui permettrait l’utilisation de noms partiellement qualifiés sans ambiguïté.

Administrativement, il y a, associé à chaque domaine, une seule personne (ou bureau) appelé le registraire. Le registraire de l’univers de désignation spécifie l’ensemble de niveau supérieur des domaines et désigne un registraire pour chacun de ces domaines. Le registraire pour un certain domaine détient l’autorité de désignation pour ce domaine.

Pour les applications d’utilisateur telles que le transfert de fichiers et l’accès au terminal, l’hôte distant doit être désigné. Pour être compatible avec la convention de désignation de l’ARPANET, un hôte peut être traité comme un domaine de point d’extrémité.

De nombreux environnements de systèmes d’exploitation ou de langage de programmation au moment du lancement fournissent des fonctions ou des invocations (JSYS, SVC, UUO, SYS, etc.) de services standard (par exemple, l’heure, le compte de l’usager connecté, la conversion de nombres en chaînes). Il est vraisemblablement très utile que de telles fonctions ou invocations soient développées pour traduire un nom d’hôte en une adresse. Bien sûr, plusieurs systèmes ont déjà sur l’ARPANET de telles facilités pour traduire un nom d’hôte ARPANET en une adresse ARPANET sur la base de tableaux internes.

On recommande que cette disposition d’une fonction ou invocation standard pour la traduction des noms en adresses soit étendue pour accepter les noms de la convention Internet. Cela va promouvoir une interface cohérente pour les utilisateurs de programmes qui impliquent des activités d’inter réseautage. La facilité standard pour la traduction des noms Internet en adresses Internet devrait inclure tous les mécanismes disponibles sur l’hôte, comme de vérifier dans un tableau local ou une antémémoire des noms récemment vérifiés, ou de consulter un serveur de noms via l’Internet.

Le relais est un dispositif adopté par de plus en plus de système de messagerie. Le relais facilite, entre autres choses, les interopérations entre des systèmes de messagerie hétérogènes. Le terme de "relais" est utilisé pour décrire la situation où un message est acheminé via un ou plusieurs points intermédiaires entre l’envoyeur et le receveur. Les relais de messagerie sont normalement spécifiés explicitement comme points de relais dans les instructions de livraison de messages. Habituellement, chacun des relais intermédiaires suppose la responsabilité du message relayé [3].

On peut faire le point sur la différence de base entre le relais de messagerie et le système de désignation uucp. La différence est que alors que le relais de messagerie avec les désignations absolues peut aussi être considéré comme une forme d’acheminement de source, les noms de chaque point intermédiaire et celui de la destination sont universellement interprétables, tandis que les noms d’hôte le long d’un chemin de source de la convention uucp sont relatifs et donc seulement interprétables localement.

La convention de désignation Internet permet explicitement les interopérations entre systèmes hétérogènes. Cela implique que l’origine d’une communication peut désigner une destination qui réside dans un système étranger. La probabilité est que l’adresse du réseau de destination puisse n’être pas compréhensible pour le système de transport de l’origine. Donc, un mécanisme de relais implicite est invoqué à la frontière entre les domaines. La fonction de ce relais implicite est la même que celle du relais explicite.

Cela représente l’ensemble des organisations impliquées dans le système Internet à travers l’autorité de l’Agence des recherches avancées de la Défense des États-Unis. Cela inclut tous les hôtes de recherche et développement sur l’ARPANET et des hôtes sur de nombreux autres réseaux. Mais il faut noter que le domaine de niveau supérieur "ARPA" ne se transpose pas de façon univoque en ARPANET – les domaines sont administratifs, pas topologiques.

Dans la transition de la convention de désignation de l’ARPANET à la convention de désignation de l’Internet, un nom d’hôte peut être utilisé comme un nom simple pour un domaine d’extrémité. Donc, si "USC-ISIF" est un hôte ARPANET, alors "USC-ISIF.ARPA" est le nom d’un domaine Internet.

Une convention de désignation hiérarchique fondée sur le concept de domaine a été adoptée par la communauté de l’Internet. C’est une convention de désignation absolue définie le long de frontières administratives plutôt que topologiques. Cette convention de désignation est adaptative pour les interopérations avec d’autres conventions de désignation. Donc, aucune convention standard n’a besoin d’être imposée pour les interopérations entre des environnements de désignation hétérogènes.

Cette convention de désignation Internet permet un service de désignation réparti et des fonctions d’autorité de désignation pour chaque domaine. Nous avons spécifié ces fonctions requises à chaque domaine. Sont aussi exposées les implications sur les applications en mode réseau, les systèmes de messagerie, et les aspects administratifs de cette convention.

On présente ici une définition assez détaillée du "BNF" de la forme admise pour une "boîte-aux-lettres" de messagerie informatique composée d’une "partie-locale" et d’un "domaine" (séparés par un signe @). Il est clair que le domaine peut être utilisé séparément dans d’autres applications en mode réseau.

<snum> ::= un, deux, ou trois chiffres représentant une valeur d’entier décimal dans la gamme de 0 à 255

<a> ::= un des 52 caractères alphabétiques de A à Z en majuscules et de a à z en minuscules

<q> ::= un des 128 caractères ASCII sauf CR, LF, guillemet ("), ou barre oblique inverse (\)

<s> ::= "<", ">", "(", ")", "[", "]", "\", ".", ",", ";", ":", "@", """, et les caractères de contrôle (codes ASCII de 0 à 31 inclus et 127)

Noter que la barre oblique inverse, "\", est un caractère de signalisation, qui est utilisé pour indiquer que le prochain caractère est utilisé littéralement (au lieu de son interprétation normale). Par exemple, "Joe\,Smith" pourrait être utilisé pour indiquer un seul champ d’utilisateur de neuf caractères avec une virgule comme quatrième caractère du champ.

Les noms simples qui constituent un domaine peuvent contenir des caractères aussi bien majuscules que minuscules (ainsi que des chiffres et des traits d’union) mais ces noms ne sont pas sensibles à la casse.

Les hôtes sont généralement connus par des noms. Parfois, un hôte n’est pas connu de la fonction de traduction et la communication est bloquée. Pour outrepasser cette barrière, deux formes d’adresses sont aussi permises pour les "noms" d’hôtes. Une forme est un entier décimal préfixé d’un signe dièse, "#". Une autre forme, appelée "décimal séparé par des points", est avec quatre petits entiers en décimal séparés par des points et inclus entre crochets, par exemple, "[123.255.37.2]", qui indique une adresse ARPA Internet de 32 bits en quatre champs de 8 bits. (Bien sûr, ces formes d’adresses numériques sont spécifiques de l’Internet, d’autres formes peuvent devoir être fournies si ce problème survient dans d’autres systèmes de transport.)

Dans l’exemple suivant, il y a deux hiérarchies de désignation qui se joignent à l’univers de désignation 'U'. L’une consiste en les domaines (S, R, N, J, P, Q, B, A) et l’autre en les domaines (L, E, F, G, H, D, C, K, B, A). Le domaine B est supposé avoir plusieurs parentés comme indiqué.

Supposons que quelqu’un à A essaye d’initier une communication avec la destination H. Le nom pleinement qualifié de destination serait : H.G.F.E.L.U

Omettant les ancêtres communs, le nom partiellement qualifié pour la destination serait : H.G.F

Pour permettre le cas des noms partiellement qualifiés, le serveur de noms A a besoin de résoudre le nom simple F, c’est-à-dire, F a besoin d’être distinct de tous les autres noms simples dans sa base de données.

Pour permettre au serveur de noms d’un domaine de résoudre les noms simples, un nom simple pour un enfant doit être alloué distinct de ceux de tous ses ancêtres et de leur successeurs immédiats. Cependant, une telle distinction ne serait pas suffisante pour permettre la résolution des noms simples dans les domaines de niveau inférieur parce que ceux-ci pourraient avoir des parentés multiples en dessous du niveau de ce domaine.

Dans l’exemple ci-dessus, supposons qu’un nom va être alloué à un nouveau domaine X par D. Pour permettre au serveur de noms en D de résoudre les noms simples, le nom pour X doit être distinct de L, E, D, C, F, et J. Cependant, pour permettre à A de résoudre les noms simples, X a besoin d’être aussi distinct de A, B, K, ainsi que de Q, P, N, et R.

- Les noms simples le long des pistes parallèles (les pistes distinctes allant d’un domaine à l’univers de désignation) doivent être distincts, par exemple, N doit être distinct de E pour B ou A pour résoudre correctement les noms simples.

- Aucune unicité universelle des noms simples n’est invoquée, par exemple, le nom simple S n’a pas à être distinct de ceux de E, F, G, H, D, C, K, Q, B, ou A.

- Plus le niveau auquel survient un domaine est bas, plus il est à l’abri de l’exigence d’unicité de désignation.

- Pour satisfaire à l’exigence de distinction des noms simples pour une résolution correcte à tous les niveaux, une autorité de désignation a besoin d’assurer que le nom simple à allouer est distinct de ceux des bases de données de serveur de noms dans les domaines de désignation d’extrémité au sein de son domaine. Par exemple, pour que D alloué un nom simple pour X, il va avoir besoin de consulter les bases de données de A et K. Il est cependant acceptable d’avoir des noms simples sous le domaine A qui soient identiques à ceux qui sont sous K. Manquer à de telles allocations distinctes de noms simples de la part de l’autorité de désignation d’un domaine mettrait en péril la capacité de résolution de noms simples pour les entités au sein de l’arborescence sous ce domaine.

Le service de noms sur un système devrait apparaître au programmeur d’un programme d’application simplement comme un appel système ou un sous-programme de bibliothèque. Au sein de cette invocation ou sous-programme, il peut y avoir plusieurs types de méthodes pour résoudre la chaîne de nom en une adresse.

D”abord, un tableau local peut être consulté. Ce tableau peut être un tableau complet et peut être mis à jour fréquemment, ou il peut être simplement une antémémoire des quelques dernières transpositions de noms en adresses récemment déterminées.

Ensuite, une invocation à un serveur de noms peut être faite pour résoudre la chaîne en une adresse de destination.

Enfin, un appel peut être fait à un serveur de noms pour résoudre la chaîne en une adresse relais.

Chaque fois qu’un serveur de noms est appelé, il peut être un serveur récurrent ou un serveur interactif.

Si le serveur est récurrent, l’appelant ne sera pas capable de dire si le serveur avait lui-même les informations pour résoudre l’interrogation ou si il a appelé un autre serveur de façon récurrente (sauf peut-être le temps que cela prend).

Si le serveur est itératif, l’appelant doit être prêt à la réponse à son interrogation, où à une réponse indiquant qu’il devrait appeler un serveur différent.

On devrait noter que le service des noms principaux exposé dans le présent mémoire est simplement un service de chaîne de nom à adresse. Pour certaines applications, d’autres services peuvent être nécessaires.

Par exemple, même au sein de l’Internet, il y a plusieurs procédures ou protocoles pour transférer effectivement la messagerie. Il est besoin de déterminer quelles procédures de messagerie peut utiliser l’hôte de destination. Un autre besoin est de déterminer le nom d’un hôte relais si les hôtes de source et de destination n’ont pas de procédures de messagerie communes. Ces services plus spécialisés doivent être spécifiques de chaque application car les réponses peuvent dépendre de l’application, mais la traduction de base de nom en adresse est indépendante de l’application.

Appendice D Exposé complémentaire sur l’interopérabilité et les traductions de protocole

La traduction des protocoles d’un système à un autre est souvent assez difficile. Voici quelques questions qui découlent de l’examen des problèmes de traductions des adresses entre systèmes de messagerie :

Quel est l’impact des différents environnements d’adressage (c’est-à-dire, des environnements de formats d’adresse différents) ?

On note que la frontière d’un environnement de désignation peut coïncider ou non avec la frontière des différents systèmes de messagerie. La conversion des désignations devrait elle être indépendante du système d’application ?

La frontière entre des environnements d’adressage différents peut coïncider ou non avec celle de différents environnements ou systèmes d’application de désignation. Une approche générique paraît être nécessaire.

Si la conversion des désignations doit être indépendante du système d’application, une forme d’interaction paraît nécessaire entre le module d’interface de la conversion de désignation et des fonctions de niveau application, comme l’analyse et la modification du texte des messages.

Pour s’accommoder du chiffrement, une conversion peut n’être pas souhaitable du tout. Que peut-il alors y avoir comme alternative à la conversion ?

Une adresse est un identifiant numérique pour la localisation topologique de l’entité désignée.

Un nom est un identifiant alphanumérique associé à l’entité désignée. Pour une identification univoque, un nom doit être unique dans le contexte dans lequel le nom est utilisé. Un nom peut être transposé en une adresse.

Un nom complet est un enchaînement de noms simples représentant la relation hiérarchique du désigné par rapport à l’univers de désignation, c’est-à-dire qu’il est l’enchaînement des noms simples des nœuds de la structure arborescente du domaine commençant par son nom propre et se terminant par le nom du nœud de niveau supérieur. C’est un nom unique dans l’univers de désignation.

C’est une abréviation du nom complet qui omet les noms simples des ancêtres communs des parties communicantes.

C’est un identifiant alphanumérique unique seulement au sein de son domaine parent.

Un domaine définit une région de juridiction pour l’allocation de noms et de responsabilité pour la traduction de nom en adresse.

C’est un environnement de réseautage qui emploie une convention de désignation spécifique.

C’est un mécanisme du réseau (par exemple, un processus) qui réalise la fonction du service de noms.

C’est une entité administrative qui a l’autorité pour allouer les noms simples et la responsabilité de la résolution des conflits de désignation.

Une entité du réseau peut avoir une ou plusieurs relations hiérarchiques par rapport à l’univers de désignation. De telles relations multiples sont des relations parallèles l’une par rapport à l’autre.

Une entité réseau a une parenté multiple lorsque il lui est alloué un nom simple par plus d’un domaine de désignation.

[2] [RFC0805] J. Postel, "Notes de réunion de la messagerie informatique", février 1982.

[4] [RFC0822] D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, remplacée par la RFC5322)

Groupe de travail Réseau	Zaw-Sing Su (SRI)
Request for Comments : 819	Jon Postel (ISI)
Traduction Claude Brière de L’Isle	août 1982