Résumé

  • La RFC 1277 encodait les données nécessaires pour tenter une connexion OSI sur TCP/IP ou certains réseaux X.25, en l’absence de service réseau OSI.
  • Son format globalement unique pouvait identifier un réseau et porter des paramètres de transport ; l’attribution ne prouvait pas que l’adresse était routable ni qu’un service répondait.

L’annuaire OSI pouvait renvoyer une adresse de présentation, mais le modèle supposait que les adresses réseau provenaient d’un service OSI. Cette hypothèse ne convenait pas à tous les pilotes. Des applications OSI tournaient déjà sur Internet, sur des réseaux X.25 publics ou privés et sur des réseaux isolés. Attendre un service réseau OSI mondial aurait rendu l’annuaire inutilisable dans les environnements mêmes où l’on cherchait à l’expérimenter.

La RFC 1277 ne traitait qu’une étape de la chaîne de connexion. Une application consultait une adresse de présentation ; le client devait ensuite extraire chaque adresse réseau, déterminer si elle était utilisable et de quelle manière, classer ses préférences, puis tenter la connexion. Le mémo s’attachait à l’extraction. Il définissait des encodages qui permettaient au client de déduire les informations de couche inférieure que l’annuaire ne fournissait pas séparément. Il ne définissait ni toute la procédure de connexion, ni la découverte de route, ni la réussite d’un échange applicatif.

Cette distinction comptait parce qu’une adresse remplissait plusieurs fonctions. Pour le X.25 international, une adresse de forme X.121 pouvait identifier un DTE et, dans le cas approprié, permettre une route sur le réseau public X.25. Mais un identifiant d’allocation n’était pas nécessairement topologique : un système ne pouvait pas supposer que toute partie attribuée mondialement décrivait un chemin. La RFC 1277 précise que l’IDP servait surtout à l’allocation et que l’utilisateur ne pouvait, en principe, en déduire le routage.

Sa recommandation d’interpréter certaines formes X.121 comme des routes dépendait du service et du format utilisés ; des moyens privés pouvaient révéler de meilleures voies.

Pour les réseaux TCP/IP qui transportaient le service de transport OSI défini par la RFC 1006, la RFC 1277 employait un autre encodage. La partie spécifique au réseau plaçait d’abord une adresse IPv4 sur douze chiffres, puis éventuellement un port sur cinq chiffres et un ensemble de transport sur cinq chiffres. Ce dernier était un mot de drapeaux de 16 bits : les valeurs correspondaient à TCP et UDP ; en l’absence de valeur ou avec zéro, le protocole par défaut était TCP. L’exemple du RFC encode 10.0.0.6, le port 9 et UDP. C’est une règle d’interprétation pour tenter une connexion, pas la preuve que l’adresse est actuelle, joignable, à l’écoute ou autorisée.

Le nouveau format devait aussi se distinguer d’une adresse utilisée par un véritable service réseau OSI. La RFC 1277 choisissait l’AFI Telex parce qu’il laissait une plus grande partie spécifique au domaine et risquait moins d’être confondu avec ces autres usages. Un préfixe court séparait les sous-réseaux ; le reste transportait des données propres au réseau. Le compromis échangeait une structure compacte et auto-descriptive contre une longue représentation décimale. Le mémo relève qu’un format binaire ASN.1 aurait été séduisant, mais qu’il ne tenait pas dans l’espace d’adressage disponible.

Ce compromis appartenait à un contexte d’ingénierie transitoire, pas à une loi intemporelle des adresses. La note historique du mémo indique que la méthode avait été mise en œuvre et sa viabilité démontrée dans les projets THORN et ISODE/QUIPU. C’est la preuve d’une proposition fonctionnelle dans ces projets, non d’une adoption générale. La RFC 1278 a ensuite décrit une représentation lisible des adresses de présentation, destinée explicitement à l’affichage plutôt qu’au stockage interne : elle se situe à un autre niveau que l’allocation et l’encodage de couche inférieure de la RFC 1277.

Quant aux recommandations NSAP de la RFC 1237, elles concernent le service réseau sans connexion OSI, et non le cas non-OSI visé par la RFC 1277.

La leçon durable de la RFC 1277 est plus étroite que « une adresse indique comment se connecter ». Une entrée d’annuaire peut contenir assez de structure pour qu’un client choisisse une interprétation de couche inférieure. Il lui faut encore une route active, un écouteur compatible, un échange de transport réussi et une réponse applicative. Prendre la valeur encodée pour la preuve de ces quatre éléments confondrait allocation, interprétation, joignabilité et service — une affirmation que le mémo ne faisait jamais.

Sources : RFC 1277 ; RFC 1006 ; RFC 1278 ; RFC 1237.