Résumé

  • La RFC 779 proposait qu’un client Telnet transmette au serveur une indication de lieu en caractères imprimables, afin de préciser où joindre une personne venue d’un autre site.
  • L’échange avançait par décisions distinctes : option inactive au départ, offre du client, accord du serveur, envoi du texte, puis éventuelle utilisation de ce texte dans une liste locale.

« Il est connecté depuis le laboratoire d’à côté. » Pour trouver son téléphone, bonne chance. En 1981, des systèmes savaient dresser la liste des utilisateurs présents avec un nom et parfois l’emplacement physique d’un terminal. Mais lorsqu’une personne ouvrait une session depuis un autre établissement, le serveur n’affichait souvent que le nom du site d’origine. Dans la RFC 779, Earl Killian donna à Telnet un moyen d’obtenir une réponse plus proche d’un bureau que d’une carte institutionnelle.

Le besoin venait des usages ordinaires des ordinateurs partagés. La RFC 742 sur NAME/FINGER prévoyait qu’une demande de liste des personnes connectées renvoie leur nom complet et, dans la mesure où on le connaissait, le lieu physique de leur terminal. Le rapport pouvait inclure le temps d’inactivité ou la tâche en cours. Cette information aidait à trouver un collègue présent dans le bâtiment ou à appeler un téléphone voisin. Une connexion distante réduisait la précision : le serveur voyait le site du lien, pas le poste où quelqu’un était assis.

Killian proposa d’ajouter SEND-LOCATION, l’option Telnet numéro 23. Le réglage initial gardait l’échange éteint des deux côtés. Lorsque le programme de l’utilisateur connaissait son lieu, il pouvait envoyer WILL SEND-LOCATION. Un serveur capable de s’en servir répondait DO SEND-LOCATION. Le client avait alors la possibilité de transmettre une suite de caractères ASCII imprimables dans une sous-négociation délimitée par IAC SB et IAC SE. On parle d’un texte fourni par le côté utilisateur, pas d’une machine qui aurait découvert une position à son insu.

Les verbes du protocole dessinaient aussi les refus. WON'T signifiait que l’émetteur refusait l’option ; DON'T, que l’autre côté demandait de ne pas l’employer. Le serveur pouvait demander le lieu avec DO, et le client pouvait refuser. Après l’accord, le texte pouvait arriver plus tard pendant la session. Proposition, acceptation et contenu étaient trois faits différents. La localisation utile aux collègues dépendait de cette petite chorégraphie.

L’idée avait un précédent. La RFC 734 sur SUPDUP décrivait déjà l’envoi d’un texte donnant le lieu de la console. Le serveur l’enregistrait normalement pour l’afficher lorsque quelqu’un lançait une commande who. La RFC 779 plaçait cette possibilité dans la négociation de Telnet. Dans les deux cas, l’information venait de la machine proche de la personne ; le système distant décidait comment l’utiliser.

La liste d’utilisateurs et l’option Telnet remplissaient donc des tâches complémentaires. NAME/FINGER décrivait un résultat qui pouvait contenir le lieu d’un terminal. SEND-LOCATION fournissait au serveur une nouvelle manière de recevoir ce lieu. La RFC citait les systèmes ITS comme capables d’exploiter le message. Le passage important allait de la connaissance du client au contexte du serveur. L’affichage restait une affaire de logiciel local.

Cette petite option déplaçait une frontière sociale. Un nom accompagné du seul établissement obligeait à chercher dans un bâtiment entier. Une description donnée par l’utilisateur pouvait conduire à une pièce ou à un téléphone. Elle pouvait aussi rejoindre une liste consultée par d’autres personnes présentes sur le système. RFC 779 séparait l’accord de transmission de la décision d’affichage. L’ordinateur gagnait une adresse humaine parce qu’une personne, puis un serveur, avaient pris chacun une décision.

Telnet servait à ouvrir une session de terminal. Deux pages de protocole rappellent que la session transportait aussi des détails de la vie autour du terminal : où trouver le collègue qui tape, et comment lui parler sans parcourir tout le couloir en demandant son nom.