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
L’identifiant qui survivait à la session, pas à la renaissance : pourquoi IMAP avait besoin d’UIDVALIDITY
La mémoire hors ligne d’une messagerie repose sur une promesse fragile: le numéro conservé hier doit encore désigner le même message demain. IMAP n’a pas transformé cette promesse en dogme. Il a prévu le moment où le serveur devait reconnaître qu’elle n’était plus tenable.
Histoire d'Internet
Un détour ne pouvait pas être aussi une destination : la frontière tracée par DNS CNAME
Le DNS pouvait conserver un ancien nom tout en conduisant vers une nouvelle destination, à une condition décisive: l’ancien nœud devait renoncer à ses propres réponses ordinaires. CNAME a fait de cette privation une instruction fiable — mémoriser le détour, reprendre la question…
Histoire d'Internet
Le bit qui refusait de faire d’une demi-réponse une vérité : quand le DNS changea de transport
Le DNS pouvait répondre vite dans un datagramme, à condition de tenir dans 512 octets. Quand la réponse débordait, son mécanisme le plus précieux n’était pas le morceau sauvé: c’était le bit TC, aveu explicite que le destinataire ne possédait pas encore la réponse.
Histoire d'Internet
Les six bits sans droit de passage : comment DiffServ a borné la qualité de service
À l'entrée d'un réseau, le marquage d'un paquet ressemble moins à un ordre qu'à une déclaration en douane. Le domaine suivant peut l'accepter, le contrôler, le traduire ou l'effacer: DiffServ a rendu la différenciation exploitable en refusant de confondre une valeur d'en-tête…
Histoire d'Internet
Le destinataire qui choisissait ce qui venait d’abord
Avant SMTP, une machine de courrier pouvait répondre à `MRSQ ?` par `215 T Text first, please`. Elle demandait alors le corps complet avant de connaître un seul destinataire. Une autre préférait recueillir tous les noms, puis recevoir une seule copie du texte. Ce choix n’était…
Histoire d'Internet
L’octet que l’émetteur n’envoyait pas : quand FTP MODE C tirait le remplissage du TYPE
Le décodeur lit une longueur, puis ne trouve aucun octet modèle. La trame n’est pourtant ni coupée ni corrompue. Dans le mode compressé de FTP, cette absence formait une instruction complète: la représentation négociée avait déjà désigné la valeur à restituer.
ICANN
Le numéro de priorité de l’ICANN ne classe pas l’évaluation des chaînes : quels sont les cinq contrôles hors file ?
Obtenir un petit numéro lors du tirage au sort de l’ICANN donne un avantage de calendrier. Ce n’est pourtant ni un feu vert pour la chaîne demandée, ni la promesse d’un résultat avant les autres candidats. Les documents officiels du cycle 2026 tracent une limite nette: le numéro…
Histoire d'Internet
La route qui reculait à chaque relais
Le relais ONE reçut `@ONE,@TWO:JOE@THREE` comme forward-path. Il ne devait pas conserver cette chaîne intacte. Il en retira son propre nom, puis ajouta dans le reverse-path le nom sous lequel l’environnement suivant le connaissait. La liste des étapes restant à franchir diminua…
Histoire d'Internet
L’octet qui devait paraître deux fois : comment FTP inscrivait les limites d’enregistrement dans un flux
Un octet composé uniquement de bits à un arrive en fin de lecture. Le récepteur ne peut encore décider s’il appartient au fichier. L’octet suivant dira s’il faut restituer une donnée littérale ou fermer un enregistrement, le fichier, voire les deux. FTP avait placé une grammaire…
IETF
Ray Bellis et le proxy qui devait transmettre l'inconnu
Un proxy DNS peut rendre un réseau domestique plus simple tout en créant une autorité que personne n'a formellement confiée: décider quels futurs usages du DNS auront le droit de passer. Dans la RFC 5625, Ray Bellis ne cherche pas à rendre cette petite machine omnisciente. Il lui…
Histoire d'Internet
La page absente qui n’était pas une page de zéros : comment FTP STRU P transportait les trous entre hôtes
Entre deux pages reçues, un indice manque. Rien ne permet pourtant de conclure à une perte sur le réseau. Dans la structure paginée de FTP, cette absence pouvait décrire le fichier lui-même: le trou n’était pas transmis, tandis qu’une page réellement présente et remplie de zéros…
Tendances FAI régionaux Europe et Moyen-Orient
Chez BSH, l’opérateur unique ne vaut que par la preuve des dépendances
BSH propose aux organisations multisites de regrouper leurs services de communication sous un seul contrat et une responsabilité unique. Cette simplicité peut accélérer la coordination d’un incident. Elle ne démontre toutefois ni l’indépendance des accès et des routes, ni la…
Histoire d'Internet
La consigne qui devait survivre à la coupure
Le routeur ne reçut qu’un datagramme IPv4, mais il dut fabriquer trois en-têtes différents. Le premier conserva une option Loose Source and Record Route de type 131 et une option Record Route de type 7. Les deux fragments suivants ne gardèrent que le type 131. Le bit de poids…
Histoire d'Internet
Le renommage qui n’avait pas encore eu lieu : comment FTP suspendit un fichier entre RNFR et RNTO
Une réponse positive ne signifiait pas toujours que FTP avait agi. Après `RNFR`, le code `350` indiquait que le serveur avait accepté l’ancien chemin et attendait encore le nouveau. Le fichier entrait dans une séquence, pas dans un nouveau nom. Cette nuance donne au vieux…
Récits
LACNIC : l’économie de la légitimité après un scandale
Une enquête conditionnelle sur les preuves, la récusation, le recours et la continuité nécessaires pour regagner la confiance régionale.
Histoire d'Internet
Le fichier intact dont l’unité avait disparu
Le contrôle d’intégrité est bon. Chaque bit du vieux fichier est encore là. Pourtant, l’équipe chargée de le relire ignore s’il faut couper la suite tous les huit, neuf ou trente-six bits. Le transport a été conservé, mais pas le paramètre qui donnait une frontière au contenu.…
Histoire d'Internet
La connexion qui survécut au changement de système de fichiers : FTP SMNT sépara identité et espace de noms
Dans le FTP de 1985, changer de terrain ne signifiait pas forcément changer de voyageur. Une session déjà authentifiée pouvait demander le montage d’une autre structure de fichiers tout en conservant l’identité, la comptabilité et les paramètres de transfert. Ce petit…
Histoire d'Internet
Le message qui voulait arriver avant la boîte aux lettres : pourquoi SMTP a abandonné la livraison au terminal
Dans le SMTP des débuts, expédier un message pouvait signifier interrompre un utilisateur devant son terminal. Trois commandes permettaient de viser l’écran, de se rabattre sur la boîte aux lettres ou de faire les deux. Cette branche oubliée du protocole liait le transport à une…
Histoire d'Internet
Le feu vert qui ne vous appartenait pas : comment NNTP séparait la règle du groupe du droit de publier
Dans la liste d'un serveur de news, un groupe se termine par `y`: la publication y est normalement admise. Pourtant, le même serveur peut répondre `440 Posting not permitted` à votre commande `POST`. NNTP ne se contredit pas. Il distingue une propriété générale du groupe d'une…
Histoire d'Internet
Le mot de passe accepté ne suffisait pas à ouvrir la session
Dans le dialogue FTP, un mot de passe pouvait être exact sans produire l’état « connecté ». Le serveur répondait `332` et attendait encore `ACCT`. Ce troisième renseignement ne répétait ni le nom d’utilisateur ni son secret: il désignait le contexte local dans lequel la session…