Résumé

  • La RFC 1394 plaça dans un même répertoire les noms de territoires, indicatifs téléphoniques, codes télex, answerbacks et domaines Internet. Une ligne signalait une correspondance connue, pas un service actif.
  • Le document conserva ses incertitudes : deux marqueurs distinguaient les informations absentes, l’exactitude n’était pas garantie et les corrections restaient ouvertes par courrier, courriel ou télex.
  • Une valeur correcte ne prouvait ni délégation DNS, ni circuit autorisé, ni identité du correspondant, ni livraison, ni reconnaissance politique.

Une table commune, des autorités distinctes

La RFC 1394, publiée en janvier 1993, répondait à une difficulté très concrète. Les mêmes lieux étaient décrits par plusieurs systèmes de communication, chacun avec ses propres codes. Le lecteur pouvait connaître un suffixe Internet sans connaître l’indicatif télex, ou disposer d’un numéro téléphonique sans savoir quel domaine chercher.

Le tableau rapprocha cinq éléments : nom du lieu, indicatif téléphonique, code pays du télex, answerback et domaine Internet. Il ajouta aussi des réseaux de messagerie publics et des entrées infranationales. Cette largeur le rendait pratique, mais interdisait de lire toutes les colonnes comme un seul registre.

Un indicatif guide un réseau de téléphonie. Un answerback appartient au fonctionnement du télex. Un domaine se place dans un arbre de noms. Une adresse commerciale peut désigner le service d’un opérateur. Leur voisinage sur le papier fournit une piste de passage d’un système à l’autre ; il ne transfère pas l’autorité d’un système au suivant.

L’absence avait plus d’un sens

Le mode d’emploi distinguait deux marqueurs. Quatre tirets signifiaient qu’aucun indicatif téléphonique n’était connu ; trois tirets signalaient les autres données manquantes ou inconnues. Un vide ne fut donc pas transformé en réponse unique.

Les lignes montraient aussi que la relation n’était pas bijective. Un lieu pouvait avoir plusieurs codes télex, plusieurs noms historiques ou aucun domaine indiqué. Plusieurs libellés pouvaient converger vers le même suffixe. Des territoires, anciens États, régions et fournisseurs apparaissaient dans une seule liste sans devenir pour autant des objets de même nature.

L’auteur indiqua que les informations provenaient de plusieurs sources et de plusieurs pays. Malgré le soin apporté, leur exactitude ne pouvait être garantie et certains codes pouvaient être erronés. Les rectifications étaient sollicitées par trois canaux. Cette procédure donnait au document un responsable éditorial et une possibilité de correction, non une synchronisation instantanée avec chaque réseau.

Une donnée publiée restait donc datée. Pour une décision coûteuse, il fallait encore savoir qui avait observé la valeur, quand elle avait été vérifiée et quelle autorité pouvait la confirmer.

Deux lettres ne créaient pas un domaine

La RFC 920 avait retenu les codes alpha-2 de l’ISO 3166 pour les domaines nationaux. Elle séparait néanmoins la forme du label, l’établissement effectif du domaine et la publication de son administrateur et de son agent. La disponibilité d’un code dans une norme ne réalisait pas ces actes.

La RFC 1034 fournit la distinction technique décisive. Le DNS est découpé en zones. Un serveur ne fait autorité que pour une portion délimitée de l’arbre ; il peut aussi conserver des données non autoritatives en cache. Une délégation exige des enregistrements à la coupure entre parent et enfant ainsi que les informations permettant de joindre les serveurs de l’enfant.

Inscrire deux lettres dans la RFC 1394 ne créait ni cette coupure, ni ces enregistrements, ni le gestionnaire. Le tableau pouvait rapporter qu’un suffixe correspondait à un territoire. Seule l’observation de la délégation permettait d’établir qu’il se trouvait effectivement dans le DNS, et seule une interrogation située dans le temps renseignait sur son fonctionnement.

Le raisonnement inverse était tout aussi limité. Un domaine actif ne confirmait pas automatiquement l’indicatif téléphonique ou l’answerback placé à côté. Chaque colonne conservait sa propre horloge et son propre exploitant.

Un suffixe pouvait cacher une passerelle

Les notes sur BITNET et UUCP rendaient la frontière visible. Les noms terminés par .BITNET ou .UUCP étaient employés dans leurs communautés, mais n’étaient pas enregistrés dans le DNS. Depuis Internet, le courrier devait passer par une passerelle et subir une transformation d’adresse utilisant alors le signe pour cent.

La forme ressemblait à un domaine ; le mécanisme ne reposait pourtant pas sur la résolution de ce suffixe. La passerelle détenait la règle de passage. Son acceptation d’un message ne prouvait ni la réception par le système distant, ni l’existence de la boîte finale, ni la lecture par une personne.

Le même document décrivait .ARPA comme une partie historique du DNS utilisée pour la résolution inverse des hôtes et réseaux. Une ponctuation semblable pouvait ainsi recouvrir une délégation DNS, une convention communautaire ou une notation de passerelle. La syntaxe seule ne révélait pas le dépositaire de la vérité.

La politique se trouvait après le code

Avant son long tableau, la RFC 1394 avertissait que la possibilité de joindre un pays dépendait de l’existence d’une connexion et de l’autorisation de l’emprunter. Elle citait des restrictions politiques parmi les causes possibles d’échec.

Une ligne bien remplie ne répondait donc qu’à une première question : quels identifiants étaient alors associés ? La deuxième concernait l’exécution : un chemin fonctionnait-il depuis cette origine, à cet instant ? La troisième concernait la permission : les opérateurs, contrats et autorités applicables autorisaient-ils l’échange ?

Le silence ne permettait pas de choisir entre ces causes. Le code pouvait être périmé, la route absente, la passerelle indisponible, la communication interdite ou le destinataire inexistant. Imputer l’échec au pays ou à la validité de son suffixe aurait dépassé l’observation.

Même le succès restait borné. Une connexion achevée établissait qu’un chemin avait fonctionné une fois. Elle n’authentifiait pas nécessairement le correspondant et ne créait aucun droit durable à utiliser le même chemin.

Le catalogue ne reconnaissait aucun État

La RFC refusa explicitement de se prononcer sur la validité du nom ou de l’existence d’un pays. Les noms anciens et alternatifs étaient recherchés parce qu’ils aidaient un lecteur à retrouver une entrée, non parce que l’éditeur entendait arbitrer la géographie politique.

Cette retenue évitait qu’une opération de repérage devienne un acte diplomatique. Dans une liste qui mêlait anciens États, territoires, subdivisions et réseaux privés, l’inclusion pouvait documenter l’usage d’une époque sans approuver un statut. Une correction de libellé ne devait pas acquérir le poids d’une reconnaissance.

La RFC 1591 décrivit ensuite les responsabilités des gestionnaires de domaines de premier niveau. Le gestionnaire d’un ccTLD devait assurer un service, des contacts et une exploitation effective. Elle précisa aussi que l’IANA n’avait pas pour activité de décider ce qui constituait ou non un pays ; le recours à l’ISO 3166 maintenait cette détermination dans une procédure séparée.

La chaîne restait donc distribuée : une source maintenait les codes, la racine coordonnait une délégation, un gestionnaire exploitait le domaine, les réseaux transportaient les messages et les autorités publiques décidaient dans leur ordre juridique. Aucun maillon n’héritait de toutes les compétences des autres.

La modestie faisait fonctionner l’outil

La RFC 1394 ne traita pas de sécurité. Elle n’authentifiait pas les lignes, ne prouvait aucun consentement et ne garantissait aucune livraison. Ce silence fixe la limite d’emploi du document plutôt qu’il ne l’annule.

Le tableau transformait une ignorance diffuse en questions vérifiables. Quel code faut-il confirmer ? Le suffixe est-il réellement délégué ? Quel serveur fait autorité ? Quelle passerelle opère ? Une liaison existe-t-elle depuis ce point ? Son usage est-il permis ? Le destinataire a-t-il accepté le message ?

Tant que ces questions restaient séparées, la liste demeurait une bonne infrastructure de coordination. Elle aidait à trouver le prochain témoin sans se faire passer pour le témoin final.