Aller au contenu principal

Type de contenu

Research

Dans la facette Type de contenu, les articles de type Research 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.

Le traducteur modifiait les paquets. Il devait aussi modifier les rapports : RFC 3158

Histoire d'Internet

Le traducteur modifiait les paquets. Il devait aussi modifier les rapports : RFC 3158

Un traducteur RTP pouvait alléger un flux, réunir plusieurs paquets ou changer sa cadence tout en conservant l’identifiant de la source. La vidéo pouvait donc parvenir au destinataire alors que les rapports RTCP continuaient de raconter l’ancien flux. RFC 3158 a rendu cette…

1 oct. 2026
Le jeton enfant était valide. La chaîne devait encore l’autoriser.

IETF

Le jeton enfant était valide. La chaîne devait encore l’autoriser.

Une signature correcte sur un jeton délégué ne suffit pas à produire un pouvoir exploitable. Le projet OAuth étudié exige de remonter jusqu’à une racine reconnue, de prouver chaque délégation et chaque réduction, puis de laisser au serveur de ressources sa décision locale.

1 oct. 2026
Le RFC disait « Standards Track » ; sa notice dit aujourd’hui « Historic » : RFC 3167

Histoire d'Internet

Le RFC disait « Standards Track » ; sa notice dit aujourd’hui « Historic » : RFC 3167

Un document d’archive conserve les mots de sa publication, tandis que sa notice de référence peut évoluer. En demandant le reclassement du RFC 1745, le RFC 3167 rend visible l’écart entre ces deux temporalités.

1 oct. 2026
Le serveur n’avait pas besoin du texte clair pour contrôler la disponibilité : RFC 3157

Histoire d'Internet

Le serveur n’avait pas besoin du texte clair pour contrôler la disponibilité : RFC 3157

Un coffre peut ignorer le contenu de l’enveloppe qu’il garde et conserver pourtant le pouvoir de la rendre introuvable. En août 2001, RFC 3157 appliquait cette dissociation aux identifiants cryptographiques devenus mobiles. Chiffrer une clé privée pendant son stockage et son…

1 oct. 2026
Le fabricant a signé les nouvelles racines. Le serveur de livraison restait non authentifié.

IETF

Le fabricant a signé les nouvelles racines. Le serveur de livraison restait non authentifié.

Un équipement peut recevoir des certificats d’autorité par un canal dont il ne reconnaît pas encore le serveur. La sécurité ne tient alors qu’à une discipline stricte: vérifier l’objet, décider localement de modifier la confiance, puis ouvrir une nouvelle session où l’identité du…

1 oct. 2026
L’opérateur junior pouvait lancer le script ; le senior l’avait préparé : RFC 3165

Histoire d'Internet

L’opérateur junior pouvait lancer le script ; le senior l’avait préparé : RFC 3165

En 2001, le Script MIB a transformé les scripts d’administration à distance en objets que l’on pouvait transférer, suivre et contrôler. Son exemple d’urgence traçait une limite nette: les opérateurs juniors pouvaient déclencher un lancement préparé, tandis que les seniors…

1 oct. 2026
L’émetteur voyait la perte, pas sa cause : RFC 3155

Histoire d'Internet

L’émetteur voyait la perte, pas sa cause : RFC 3155

Une fenêtre TCP qui se contracte raconte une décision, pas nécessairement un embouteillage. En août 2001, RFC 3155 partait de cette dissociation. Sur une liaison sujette aux erreurs, un segment corrompu pouvait produire, à l’extrémité, le même silence qu’un paquet éliminé dans…

1 oct. 2026
Le relais ajoutait un en-tête. La fin du message pouvait disparaître : RFC 3164

Histoire d'Internet

Le relais ajoutait un en-tête. La fin du message pouvait disparaître : RFC 3164

Dans l’ancien format BSD syslog, un relais pouvait rendre un message plus lisible en lui ajoutant une date et un nom d’hôte. Mais RFC 3164 plafonnait le paquet entier à 1 024 octets: cet en-tête pouvait prendre la place de la fin du message.

1 oct. 2026
Le domaine autorisait une question, pas une action

IETF

Le domaine autorisait une question, pas une action

Avec `dialogue.txt`, un domaine pourrait indiquer publiquement qu’un lecteur inconnu — humain ou logiciel — peut poser une question. La proposition n’a pourtant rien d’un mandat numérique: la remise d’un message n’ouvre pas le dialogue, la réponse ne confère aucun pouvoir d’agir…

1 oct. 2026
Le récepteur proposait le multiplexage. L’émetteur décidait encore de l’utiliser : RFC 3153

Histoire d'Internet

Le récepteur proposait le multiplexage. L’émetteur décidait encore de l’utiliser : RFC 3153

Un accord de protocole n’est pas toujours une promesse d’action. Dans RFC 3153, le récepteur PPP annonçait qu’il savait décomposer des trames multiplexées; l’émetteur obtenait alors le droit de les produire, sans en recevoir l’ordre. Cette séparation, publiée en août 2001 pour…

1 oct. 2026
Le serveur avait besoin d’un troisième défi : RFC 3163

Histoire d'Internet

Le serveur avait besoin d’un troisième défi : RFC 3163

Dans le mécanisme mutuel de RFC 3163, une troisième valeur aléatoire n’était pas un ornement. Elle répondait à un décalage d’ordre: le client avait déjà vu le premier défi du serveur lorsqu’il choisissait sa propre valeur aléatoire. La correction reste toutefois limitée, tout…

1 oct. 2026
Le nouvel arbre inverse existait avant la disparition de l’ancien : RFC 3152

Histoire d'Internet

Le nouvel arbre inverse existait avant la disparition de l’ancien : RFC 3152

Une migration Internet ne se produit pas au moment précis où un texte normatif change de nom. En août 2001, RFC 3152 plaça la résolution inverse IPv6 sous `IP6.ARPA`, demanda la délégation de ce domaine et déclara `IP6.INT` impropre aux nouvelles implémentations. L’ancien arbre…

1 oct. 2026
Le système de cartographie ignorait la destination. Il a tout de même indiqué une sortie.

IETF

Le système de cartographie ignorait la destination. Il a tout de même indiqué une sortie.

Une proposition LISP permet de choisir dynamiquement une passerelle pour une destination externe absente du système de cartographie. L’idée est utile, mais son vocabulaire peut tromper: trouver une sortie n’est ni identifier l’arrivée, ni démontrer que la route au-delà de la…

1 oct. 2026
L’IPv6 devait attendre l’authentification : RFC 3162

Histoire d'Internet

L’IPv6 devait attendre l’authentification : RFC 3162

Le serveur d’accès devait autoriser la session avant de savoir quel protocole Internet utiliserait l’hôte. RFC 3162 a permis à un échange RADIUS de transporter les deux possibilités, puis laissé la décision d’applicabilité au bord du réseau.

1 oct. 2026
L’ancien nom est devenu une URN, sans se résoudre tout seul : RFC 3151

Histoire d'Internet

L’ancien nom est devenu une URN, sans se résoudre tout seul : RFC 3151

XML avait hérité d’identifiants publics capables de survivre à une machine, mais incapables d’entrer tels quels dans toute interface exigeant une URI. RFC 3151 leur donna une transcription précise en `urn:publicid:`. Cette passerelle rendait le nom normalisé comparable et…

1 oct. 2026
Le DHCP annonce 1 Gbit/s. Il n’a pas déplacé le goulot d’étranglement.

IETF

Le DHCP annonce 1 Gbit/s. Il n’a pas déplacé le goulot d’étranglement.

Une nouvelle option DHCP peut transmettre le débit de service que l’opérateur souhaite voir appliqué. Elle rend une politique portable entre plusieurs équipements. Elle ne mesure ni le chemin d’accès, ni la file réelle, ni le service finalement obtenu.

1 oct. 2026
Un paquet pouvait faire attendre les autres : RFC 3150

Histoire d'Internet

Un paquet pouvait faire attendre les autres : RFC 3150

Sur une liaison très lente, la taille d’un paquet détermine aussi combien de temps les autres usagers de l’interface doivent attendre. RFC 3150 a fait de cette durée une contrainte de conception, au-delà de la seule efficacité en octets.

1 oct. 2026
L’agent d’appel contrôlait les fonctions. Le bouton muet restait local : RFC 3149

Histoire d'Internet

L’agent d’appel contrôlait les fonctions. Le bouton muet restait local : RFC 3149

MGCP plaçait l’intelligence d’appel hors du téléphone, mais RFC 3149 ne fit pas de chaque geste un aller-retour réseau. L’agent distant interprétait les touches numérotées et pilotait l’écran; le volume, le passage immédiat du combiné au haut-parleur et la coupure du microphone…

1 oct. 2026
Un même chemin pouvait produire deux mesures de capacité valides : RFC 3148

Histoire d'Internet

Un même chemin pouvait produire deux mesures de capacité valides : RFC 3148

Une mesure de transfert massif sur un seul flux semblait tenir dans un chiffre. RFC 3148 montre pourquoi les choix de transport pouvaient rendre ce chiffre dépendant de la méthode — et pourquoi la trace qui l’accompagne comptait.

1 oct. 2026
Le nouveau réseau de gestion devait traverser l’ancien : RFC 3147

Histoire d'Internet

Le nouveau réseau de gestion devait traverser l’ancien : RFC 3147

Le mot « migration » suggère qu’une infrastructure en remplace une autre d’un seul mouvement. RFC 3147 conserva une image moins nette: un équipement récent, géré par IP, pouvait se trouver derrière un réseau CLNS que l’exploitant ne pouvait pas encore retirer. Transporter GRE…

1 oct. 2026