Type de contenu
Analysis
Dans la facette Type de contenu, les articles de type Analysis de BTW.MEDIA sont regroupés selon un même format éditorial, afin de permettre aux lecteurs de comparer briefings, profils, notes de risque, analyses de marché et reportages d'événements sans mélanger différents types de preuves. Cette page explique comment ce type de contenu met en perspective les événements liés à l'infrastructure Internet, les mouvements d'entreprises, les décisions de gouvernance, les signaux opérationnels et les preuves publiques sur l'ensemble du site. Les lecteurs peuvent ainsi identifier les acteurs ou systèmes d'infrastructure les plus fréquents, comprendre comment la qualité des sources modifie l'interprétation et déterminer si le contenu relève d'un profil durable, d'un événement urgent, d'un signal de marché stratégique ou d'une évolution de gouvernance. Le résultat est une page de recherche utile aux opérateurs, investisseurs, clients, analystes et décideurs publics qui doivent comprendre les conséquences, le calendrier et les preuves qui sous-tendent des formats d'articles similaires.

Histoire d'Internet
Pour attendre moins, le paquet avait moins de place : le compromis de la RFC 1046
Une file courte tient mieux une promesse de délai qu'une file généreuse. Elle a aussi une conséquence immédiate: elle refuse plus tôt ce qui n'y entre pas. En 1988, la RFC 1046 a bâti sa proposition de service IP à faible délai sur cette tension, sans offrir à la classe rapide ni…

Histoire d'Internet
La boîte aux lettres était un contact, pas une salle de contrôle : la « tradition orale » de la RFC 1173
Au début de l’Internet, une panne visible de loin ne donnait pas à l’observateur le pouvoir de la réparer. Elle lui donnait, au mieux, une raison de trouver quelqu’un qui pouvait regarder du côté concerné. La RFC 1173, publiée en 1990, a fixé cette discipline de coopération: un…

Histoire d'Internet
Une phrase de politique n’était pas un contrôle réseau : RFC 1087 et les limites de « l’usage acceptable »
En 1989, l’Internet Activities Board pouvait désigner des comportements qui mettaient en danger une infrastructure de recherche partagée. Il pouvait condamner l’intrusion intentionnelle, la perturbation, le gaspillage, la destruction et l’atteinte à la vie privée. Mais aucune de…

Histoire d'Internet
Le bit préservait le chemin du retour, pas l'authenticité de la requête : le SRC HYPERchannel de la RFC 1044
La RFC 1044 ne disait pas simplement qu'une adresse source était « correcte ». Elle précisait le test: inverser les adresses du support devait ramener une réponse au processus d'origine. Cette précision faisait du bit SRC une preuve utile de réversibilité, tout en laissant hors…

Histoire d'Internet
La vitesse était une indication d’affichage, pas la liaison : la limite de Telnet dans le RFC 1079
En 1988, un programme de terminal distant pouvait apprendre quelque chose d’utile sur le terminal de son correspondant sans feindre de connaître le réseau qui les séparait. Le RFC 1079 trace cette limite avec une rare netteté. Il permet à un pair Telnet de demander deux vitesses…

Histoire d'Internet
Avant DHCP, quatre octets ont choisi la grammaire : RFC 1048 et la limite BOOTP de 64 octets
Une machine qui démarrait par le réseau devait comprendre une réponse avant même de posséder tous les moyens ordinaires de se configurer. En 1988, RFC 1048 a transformé les 64 octets réservés par BOOTP aux données de fournisseur en une petite langue commune. Son cookie magique…

Histoire d'Internet
Le nom était l’adresse. Il n’était pas une route : le mappage IP-sur-NetBIOS de RFC 1088
En 1989, RFC 1088 a fait tenir une convention d’acheminement locale dans une écriture lisible. Pour une machine IP sur NetBIOS, l’adresse IP devenait le nom NetBIOS `IP.XX.XX.XX.XX`, chaque octet étant rendu en hexadécimal ASCII. Cette formule évitait une requête d’adresse…

Histoire d'Internet
Quatre octets ont donné une frontière à TCP. Ils n’ont pas reconstruit le réseau OSI : la limite TPKT de RFC 1006
Une application peut écrire une unité cohérente et TCP peut néanmoins la livrer en morceaux, ou avec sa voisine. Ce n’est pas une défaillance de TCP: c’est sa promesse de flot d’octets. RFC 1006 a répondu à ce décalage pour le transport ISO par une convention volontairement…

Histoire d'Internet
Le jeton a trouvé la connexion. Il n'a pas admis le sous-flux : la frontière MP_JOIN de MPTCP
Le premier paquet d'une nouvelle liaison peut porter une histoire qui lui est antérieure. Dans MPTCP, un SYN sur une autre paire d'adresses ne crée pas nécessairement une nouvelle conversation applicative: il propose d'ajouter un sous-flux TCP à une connexion déjà établie. La…

Récits
LACNIC et l’économie d’une transition au-delà des RIR
Une architecture de relais crédible doit transmettre un service, des preuves et une autorité légitime — pas seulement une base de données.

Histoire d'Internet
La bannière occupait l’écran, pas la décision : la RFC 933 et la frontière d’affichage de Telnet
Une mention de sécurité répétée par l’application à chaque nouvel écran était à la fois fragile et coûteuse. La RFC 933 proposait de la confier au Telnet du poste de travail; elle rendait ainsi le marquage persistant, sans transformer ce texte en règle d’accès.

Histoire d'Internet
Le NAK refusait le port, non le paquet : RFC 938 et la frontière entre réception et aiguillage
Un protocole expérimental de 1985 pouvait confirmer l'avancée d'une séquence tout en déclarant inconnu le port local visé. Cette réponse, `PORT NAK`, ne dit pas qu'une application a reçu les données; elle soigneusement distingue le constat du transport de la décision…

Histoire d'Internet
L’UUID a traversé la connexion. L’autorité est restée sur place : le pari de la RFC 927 contre la double identification
Supprimer un second mot de passe ne supprimait pas une seconde décision. En 1984, la RFC 927 proposait qu’un hôte transmette un identifiant de quatre octets après avoir authentifié l’utilisateur; l’hôte cible gardait néanmoins le droit d’accepter ou de refuser cette parole venue…

Histoire d'Internet
La branche disait « personne en aval » : RFC 1075 et le rapport de non-appartenance à durée limitée de DVMRP
En 1988, le routage multicast expérimental devait savoir quand cesser d'envoyer le trafic d'un groupe vers une branche. RFC 1075 proposait une réponse volontairement étroite: un routeur en aval pouvait signaler qu'il n'avait aucun membre descendant pour un groupe donné, et son…

Histoire d'Internet
La frappe tenait en quatre octets : comment la RFC 916 fit porter la répétition par l’état
Le troisième octet de l’en-tête n’avait pas un sens stable. À l’ouverture, il annonçait la capacité du récepteur; dans un paquet ordinaire, il comptait les données; avec le drapeau `SO`, il devenait la donnée elle-même. La RFC 916 économisait des octets en exigeant que les deux…

Histoire d'Internet
Le nom qui ne donnait aucune mesure : RFC 1065 et la forme des choses administrables
En 1988, l'administration d'Internet devait pouvoir décrire ce qui pouvait être observé sans faire passer une description pour une observation. RFC 1065 a imposé cette retenue: un type d'objet géré pouvait avoir un nom stable, une syntaxe, un codage et une catégorie d'accès…

Histoire d'Internet
L’octet qui disait « on recommence » : SLIP, RFC 1055 et le prix d’une trame retrouvée
Sur une ligne série, le récepteur ne reçoit pas des paquets déjà découpés: il reçoit une suite de caractères dans le temps. Après un parasite, cette différence devient décisive. RFC 1055 conseillait d’envoyer `END` non seulement à la fin, mais aussi au début d’un datagramme SLIP.…

Histoire d'Internet
Le basculement n’en était pas un seul : comment la RFC 897 dissocia le renommage de la résolution DNS
Le calendrier public avançait sur trois horloges. Les noms pouvaient changer en mars, les serveurs arriver plus tard et les logiciels continuer à lire une table locale. La RFC 897 ne décrivait donc pas un instant magique où « le DNS » aurait remplacé l'ancien monde, mais une…

Histoire d'Internet
Les réseaux locaux que l’hôte ne devait pas voir : RFC 925 et le prix d’une topologie cachée
Un site Internet des débuts pouvait afficher chaque câble au reste du réseau, ou faire croire à ses hôtes que plusieurs LAN n’en formaient qu’un. RFC 925 choisissait cette seconde illusion: l’ARP de l’hôte restait ordinaire, tandis qu’un intermédiaire devait découvrir, mémoriser…

Histoire d'Internet
Le porteur n’était pas la connexion : comment la RFC 892 séparait l’état de transport du chemin réseau
La RFC 892 autorisait deux relations inverses: plusieurs connexions de transport pouvaient partager une connexion réseau, et une connexion de transport pouvait, dans la classe prévue, utiliser plusieurs connexions réseau. Cette symétrie obligeait à distinguer l’état de la…
