Résumé
- Le corps de la RFC 1097 affirme spécifier un standard, mais sa fiche actuelle auprès du RFC Editor porte le statut
Unknowndans l’Independent Stream ; le Datatracker précise qu’elle n’a pas de statut formel dans le processus de normalisation de l’IETF. - Le dispositif satirique restait désactivé par défaut. DO/WILL devait établir l’accord des deux extrémités avant l’envoi de la durée, de la fréquence et du message. Cet état du client ne constituait pas le consentement informé de la personne.
- La RFC exigeait seulement que le client tente un affichage dont le placement et le rendu dépendaient de l’implémentation. Elle ne prouvait ni lumière à l’écran, ni perception, ni persuasion, ni mise à jour du logiciel.
Une déclaration de statut n’est pas un statut
La RFC 1097 possède tous les signes extérieurs d’une option Telnet. Elle porte un numéro, une date — le 1er avril 1989 —, un auteur, B. Miller de CMU-NetDev, des commandes, une valeur par défaut et des exemples. Son paragraphe liminaire va jusqu’à déclarer qu’elle spécifie un standard pour la communauté Internet.
Le texte atteste cette déclaration, pas sa validité institutionnelle. La fiche du RFC Editor classe aujourd’hui le document Unknown et l’associe à l’Independent Stream. La fiche IETF Datatracker indique qu’il s’agit d’une Independent Submission, non avalisée par l’IETF et sans statut formel dans son processus de normalisation.
Les deux couches ne s’annulent pas. L’archive conserve exactement ce que le mémo prétendait être ; le catalogue dit quelle autorité lui est reconnue. Substituer la phrase du document à la fiche officielle reviendrait à laisser une pièce délivrer elle-même son titre.
L’archive peut conserver l’humour sans le rendre normatif
Dans RFC 8700, l’histoire des cinquante ans de la série, les RFC du 1er avril sont décrites comme une composante humoristique particulière de l’Independent Stream, sans la procédure formelle ordinaire d’examen et d’approbation. Elles sont néanmoins choisies et relues pour cette fonction singulière.
RFC 1097 exploite précisément la familiarité du lecteur avec une spécification. L’humour naît de rubriques impeccablement rangées autour d’une idée absurde : « persuader » les utilisateurs en faisant clignoter « Use VMS » ou « Go home ». Sa présence dans la série prouve qu’un texte historique a été publié et préservé. Elle ne transforme pas toutes ses phrases en exigences d’un Internet Standard.
Le message prétendument clandestin commençait par une demande
La mécanique empruntée au vrai Telnet est moins arbitraire que le sujet. RFC 854 définit une communication orientée octets, fondée sur un terminal virtuel commun et sur des options négociées. Une extrémité propose ; l’autre accepte ou refuse. En cas d’option inconnue, le retour au comportement NVT reste compréhensible par les deux côtés.
RFC 855 sépare ensuite l’accord de principe et la discussion des paramètres. DO/WILL ouvre la possibilité ; la sous-négociation vient après. DON'T/WON'T peut y mettre fin.
RFC 1097 respecte ce dessin. WILL sollicite la permission d’afficher ou confirme que l’émetteur le fera ; WON'T refuse. DO demande à l’autre extrémité d’afficher ou lui en accorde la permission ; DON'T l’interdit. La valeur par défaut est WON'T/DON'T : aucun message.
Ce refus initial ne rend pas la proposition éthique. Il révèle seulement la portée du protocole. Le serveur ne possède pas d’emblée l’écran distant. Le client doit entrer dans un état où la suite devient recevable.
Le numéro 257 se trouvait au-delà de la liste ordinaire
RFC 1097 attribue à SUBLIMINAL-MESSAGE le numéro 257. Le registre IANA actuel expose la table Telnet jusqu’à 255, réservé à Extended-Options-List, sans ligne nommée 257.
Le contexte existe dans RFC 861. EXOPL, code 255, devait ouvrir un groupe supplémentaire de 256 options grâce à une négociation encapsulée. RFC 1097 place donc son numéro juste après l’espace ordinaire, mais ses exemples se contentent de la notation symbolique IAC DO/WILL/SB SUBLIMINAL-MESSAGE et n’explicitent pas l’encapsulation EXOPL.
Il est possible d’établir le voisinage conceptuel, pas un paquet observé. Les sources ne montrent ni attribution IANA actuelle de 257, ni encodage déployé, ni interopérabilité. Un numéro écrit dans un canular et une entrée de registre sont deux faits distincts.
Le client pouvait dire oui sans consulter l’utilisateur
Une fois l’option acceptée, l’émetteur fournissait deux valeurs de 16 bits et une chaîne. La première fixait la durée en millisecondes, la seconde l’intervalle en secondes. Le client devait accepter la sous-négociation et tenter l’affichage régulier. En revanche, la position et le rendu restaient locaux. La valeur 255 devait être doublée conformément à l’échappement Telnet.
L’accord appartient ainsi aux processus Telnet. Le mémo dit que « le client » a accepté ; il ne décrit ni dialogue avec la personne, ni choix éclairé du contenu, ni accord sur l’objectif de persuasion. Une configuration automatique peut produire WILL sans que l’utilisateur sache qu’une décision vient d’être prise en son nom.
Le partage du contrôle est plus précis que la formule « le serveur affiche ». Le serveur choisit la chaîne et le calendrier. Le client choisit le procédé de rendu. La personne demeure en dehors de cette négociation. Présence devant le terminal, consentement et perception ne sont pas des champs Telnet.
Tenter un affichage ne prouve pas son effet
Le verbe essentiel de RFC 1097 est « tenter ». La réception des paramètres peut être établie par les octets. L’appel d’une routine peut être établi par un journal local. Il faut encore une observation différente pour confirmer que l’état du terminal a produit un signal visible, puis une autre pour savoir si quelqu’un regardait, a remarqué le signal, l’a compris et a agi.
Le mémo évoque une implémentation CMU attentive à la vitesse de ligne, aux capacités vidéo et à la persistance du phosphore, ainsi qu’une version en morse sur la LED Caps Lock. Ce sont des affirmations internes au texte satirique, non une preuve indépendante de livraison ou d’usage.
La chaîne correcte va donc du document archivé à son statut officiel, puis à la capacité négociée, aux paramètres reçus, à la tentative locale, à la présentation physique, à la perception et enfin au comportement. Sauter un maillon transforme une trace limitée en verdict.
Sources
- RFC 1097 — Telnet Subliminal-Message Option
- Fiche RFC Editor de RFC 1097
- Fiche IETF Datatracker de RFC 1097
- RFC 8700 — Fifty Years of RFCs
- RFC 854 — Telnet Protocol Specification
- RFC 855 — Telnet Option Specifications
- RFC 861 — Telnet Extended Options: List Option
- RFC 1080 — Telnet Remote Flow Control Option
- IANA — Telnet Options
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
