Résumé

  • La RFC 920 ne se contentait pas de proposer des noms de premier niveau : elle associait chaque catégorie à un administrateur, à un agent d’enregistrement et à des conditions d’accès.
  • ARPA était explicitement temporaire. GOV, EDU, COM, MIL et ORG formaient les catégories institutionnelles ; les codes de pays et les multiorganisations restaient des possibilités sans entrée déjà créée.
  • Le seuil de 500 hôtes au premier niveau était une attente générale. Celui de 50 hôtes au second niveau était qualifié de très souple, et les grandes organisations pouvaient être admises en dessous.

Une liste qui faisait office de politique

L’arbre des domaines n’a pas commencé comme une rangée d’étiquettes que chacun aurait pu réclamer. En octobre 1984, la RFC 920, signée par Jon Postel et Joyce Reynolds, se présentait comme une déclaration officielle de politique de l’Internet Activities Board et de la DARPA pour créer des domaines dans l’ARPA-Internet et la communauté de recherche de la DARPA. Elle ne décrivait donc pas seulement la forme d’un nom. Elle précisait les catégories susceptibles d’exister, les administrations qui en répondraient et le chemin d’une demande jusqu’à son autorisation.

Le texte prolongeait un plan plus ancien. La RFC 881 exposait le projet de noms de domaine ; les RFC 882 et 883 décrivaient les concepts et leur mise en œuvre technique. La RFC 920 dit qu’elle affinait les exigences et ajoutait un ensemble limité de domaines de premier niveau. C’est un complément de politique au système technique, pas une spécification de protocole ni une règle universelle de gouvernance de l’Internet.

La première liste formait aussi un tableau de répartition des responsabilités :

Place dans la liste initiale Noms ou catégorie Indication donnée en 1984
Temporaire ARPA Hôtes actuels de l’ARPA-Internet ; nom explicitement temporaire
Catégories institutionnelles GOV, EDU, COM, ORG DARPA administrateur ; NIC agent
Catégorie militaire MIL DDN-PMO administrateur ; NIC agent
Pays Codes ISO alpha-2 anglais à deux lettres Aucun domaine national n’était encore établi
Multiorganisations Pas encore de nom attribué Aucune n’était établie ; un groupe international admissible pouvait être envisagé

La liste ne signifiait pas que chaque branche était déjà remplie. La RFC 920 précise que les domaines de pays et de multiorganisations n’avaient pas encore été établis. Les responsabilités n’étaient pas interchangeables : la DARPA administrait les catégories institutionnelles ; le bureau de programme du Defense Data Network administrait MIL. Le Network Information Center intervenait comme agent et bureau d’enregistrement. Pour un domaine de premier niveau, autorisation et enregistrement étaient des étapes distinctes, pas une conséquence automatique d’un nom plausible.

Les seuils d’effectifs étaient moins rigides qu’une simple barrière. Un domaine de premier niveau devait être spécialement autorisé et, en règle générale, on ne prévoyait cette autorisation que pour un domaine dépassant 500 hôtes. Pour le second niveau, la recommandation était de dépasser 50 hôtes ; la RFC 920 la qualifiait pourtant de « très souple » et admettait qu’une grande université ou entreprise ne compte que quelques hôtes. Elle précisait aussi qu’un groupe n’avait pas à créer un domaine simplement parce qu’il franchissait un seuil.

Le nombre ne suffisait pas : il fallait une administration responsable, un service de noms fiable et l’enregistrement auprès de l’autorité du niveau supérieur.

L’exception des multiorganisations montre que la première liste était un exercice de classement autant qu’un inventaire. Un grand consortium international composé de plusieurs organisations, difficile à faire entrer dans une seule catégorie, pouvait être envisagé au premier niveau. La RFC 920 prend comme exemple hypothétique un consortium appelé CSNET, communauté d’échange de courrier reposant sur plusieurs protocoles et réseaux, avec une administration responsable. Ici, l’exemple sert uniquement à montrer pourquoi le texte réservait une catégorie aux groupes transversaux.

La RFC précise qu’aucun domaine de multiorganisation n’était encore établi : cet exemple ne prouve donc pas que CSNET ait reçu ce statut.

La chaîne d’autorité se poursuivait sous le sommet. Un domaine de second niveau s’enregistrait auprès de son administrateur de premier niveau ; les niveaux suivants passaient par l’administrateur immédiatement supérieur ou son responsable désigné. Avant d’autoriser une branche, l’autorité supérieure devait juger que les exigences étaient satisfaites. Un administrateur pouvait transmettre une part de ses tâches à un sous-domaine, mais la personne responsable du domaine de premier niveau demeurait comptable de l’ensemble de l’arbre. La hiérarchie organisait donc les noms et la responsabilité de leur maintien.

Cette responsabilité avait un contenu concret. Une personne identifiée devait coordonner les questions relatives au domaine, disposer d’assez de compétence technique et d’autorité pour corriger les problèmes, puis agir si un hôte perturbait les échanges avec l’extérieur. Le texte demandait un service de noms fiable. Deux machines indépendantes alimentées séparément constituaient une solution pour éviter une panne commune, mais pas la seule : la coopération entre domaines ou un prestataire tiers étaient également possibles.

L’admissibilité dépendait donc de la capacité à administrer l’espace de noms et le service qui le rendait utile, pas de la seule catégorie figurant après le point.

ARPA portait la limite temporelle la plus nette. La RFC 920 explique que ce nom de premier niveau venait de l’histoire du système et devait finir par disparaître. Elle conseillait aux hôtes concernés de préparer leur rattachement à un autre domaine. Les hôtes du DDN qui ne participaient pas au nouveau service pouvaient continuer à utiliser le fichier HOSTS.TXT tenu par le NIC, même si le texte attendait aussi un changement de nom ultérieur. Ce sont des plans et des consignes d’une politique de 1984, pas la preuve que tous les hôtes aient migré ou qu’ARPA ait disparu à une date précise.

Un texte postérieur montre l’évolution du travail d’enregistrement sans réécrire ce que disait la RFC 920. Publiée en 1987, la RFC 1032 guide les administrateurs et décrit les rôles du NIC pour l’enregistrement et la zone racine. Elle indique aussi que les gestions de CSNET et UUCP jouaient un rôle de filtre : elles traitaient les demandes pour leurs propres organisations puis transmettaient les informations utiles au NIC. Son inventaire comprend NET et des domaines nationaux ; il s’agit d’un état ultérieur, qu’il ne faut pas projeter sur la liste initiale de 1984. Ce guide témoigne d’une voie administrative plus tardive, sans prouver que chaque attente de 1984 se soit réalisée exactement comme prévu.

La première liste de la RFC 920 allait donc au-delà de quelques étiquettes familières. Elle répartissait des catégories, désignait des administrateurs, réservait une exception aux groupes difficiles à classer et indiquait qui pouvait autoriser une nouvelle branche. La liste était courte, mais la procédure d’admission comptait déjà : un nom au sommet dépendait de son classement, d’un opérateur responsable et d’une autorité prête à l’enregistrer.

Sources

Ces documents voisins ont été consultés pour délimiter le sujet ; leur état ultérieur n’est pas rétroprojeté en 1984.