Résumé

  • En 1977, NAME/FINGER permettait à un hôte distant de demander qui utilisait un système ou de rechercher une personne nommée.
  • La requête était minime, mais la réponse pouvait révéler nom, lieu, inactivité, dernière déconnexion ou message personnel.

Une ligne vide suffisait pour interroger

La requête la plus parlante de la note NAME/FINGER de 1977 ne contient presque rien : un retour chariot suivi d’un saut de ligne. Le client se connecte à un service distant, envoie cette ligne vide et peut recevoir la liste des personnes qui utilisent alors le système. Selon le site, la réponse indique des noms, les travaux en cours, le temps d’inactivité d’un terminal et parfois sa position dans un bâtiment. Une recherche nominative peut aussi dépasser la session ouverte : elle peut donner l’heure de la dernière déconnexion et le court message laissé par la personne.

Le réseau transportait la question, pas une identité uniforme

Ce mécanisme précède les pages de profil, mais il n’en est pas une version miniature. Il relie une question réseau aux informations que chaque hôte sait déjà produire sur ses propres comptes et terminaux. Dans le RFC 742, Ken Harrenstien précise que le protocole se limite surtout à une ligne de commande et n’impose aucun format de réponse. Chaque site transforme donc ses données locales en texte selon ses propres choix. La requête voyage; le récit de la personne reste défini par l’ordinateur qui l’héberge.

De SAIL au réseau : une pratique devient protocole

Le RFC 742 décrit une chaîne d’appropriation plutôt qu’une création isolée. Le programme FINGER de Les Earnest à SAIL a inspiré NAME sur le système ITS du MIT. Earl Killian au MIT et Brian Harvey à SAIL ont mis en œuvre le protocole, puis un serveur similaire a été lancé à SRI. Le RFC cite ces trois sites; il ne fournit pas de mesure permettant d’estimer l’adoption ailleurs.

Les sorties reproduites dans l’annexe du RFC 742 rendent très concrète la frontière entre état machine et présence humaine. Une sortie indique des consoles et des tâches en cours. Une autre précise qu’une personne n’est pas connectée, puis affiche son plan : où elle prévoit d’être, quand elle sera joignable et comment la contacter. Tous les serveurs n’étaient pas tenus de révéler ces éléments. Mais les démonstrations montrent qu’une requête d’état pouvait associer des données de fonctionnement à un texte volontairement laissé par l’utilisateur.

La première spécification reflète aussi l’infrastructure de son époque. RFC 742 décrit l’accès au socket 117 en octal, soit le port 79 en décimal, via ICP et deux connexions 8 bits. En 1984, RFC 924 classe Finger parmi les protocoles facultatifs et note que des adaptations sont nécessaires pour TCP. Sa description reste centrée sur l’activité actuelle ou la plus récente d’une personne.

En juin 1990, le procès-verbal d’une réunion IAB/IETF maintient temporairement RFC 742 comme Proposed Standard hérité, tout en demandant un meilleur document et un nouvel examen. RFC 1194 paraît en novembre. Il veut clarifier les échanges sans casser les implémentations existantes, souvent issues de BSD Unix. Il qualifie aussi les informations sur les utilisateurs de sensibles et détaille des choix de refus, de fichiers exposés, de programmes exécutés et de journalisation.

La limite durable du protocole est là : rendre une personne interrogeable sur le réseau ne rendait ni sa réponse uniforme ni sa publication obligatoire. L’administrateur choisissait les champs; l’utilisateur pouvait rédiger un plan, mais ne contrôlait pas nécessairement les informations produites par le système. La révision de 1990 ne supprime pas cette tension. Elle la rend administrable.

Sources primaires