Domaine principal
Infrastructure Internet
Au sein de la facette Domaine principal, l'analyse Infrastructure Internet regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
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.…
IETF
Mike McBride et le registre multicast qui n’a supprimé qu’une catégorie de collision
Deux trains peuvent respecter leur horaire et se retrouver sur la même voie si le plan leur attribue le même tronçon. Le problème des identifiants de groupe multicast IPv6 était de cet ordre: le serveur et l’hôte obéissaient à une règle commune qui ne les séparait pas.
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…
Histoire d'Internet
Le chemin le plus rapide portait l’heure sans choisir l’horloge maîtresse : les deux boucles de la RFC 891
Dans les Fuzzballs, une même annonce HELLO nourrissait la table de routage et l’estimation du décalage horaire. Cette mise en commun économisait des échanges, mais elle ne confondait pas les pouvoirs: le délai choisissait un chemin, `CLOCK-HID` désignait la référence et l’horloge…
Histoire d'Internet
La trame était plus longue que le datagramme : comment le RFC 894 a tenu le bourrage Ethernet hors d’IP
Le RFC 894 affirme encore qu’un champ de données Ethernet a une longueur « minimale » de 1 500 octets, puis en déduit aussitôt une longueur maximale de datagramme de 1 500 octets. L’erreur n’a jamais été effacée du document publié. Elle est restée à côté de sa correction…
Tendances télécoms nationaux Europe et Moyen-Orient
Un pylône 4G rural ne prouve pas la couverture locale tant que l’opérateur et le lieu ne correspondent pas
Un pylône peut être actif, un objectif national atteint, et un téléphone précis rester sans service utilisable à l’endroit décisif. L’acceptation locale commence seulement lorsque l’opérateur, le lieu et le contexte sont nommés.
Histoire d'Internet
La première réponse n’était qu’un indice : comment la RFC 887 séparait découverte et confirmation
Une machine pouvait interroger tout le réseau local sans connaître l’adresse d’un serveur. Mais la RFC 887 réservait un autre message pour vérifier directement le candidat trouvé. Elle faisait ainsi de la provenance de la réponse une partie du protocole.
Histoire d'Internet
La liste disait « officiel », pas « mis en œuvre » : comment la RFC 880 séparait le statut du code en fonctionnement
La RFC 880 recommandait TCP et consignait, dans le même mouvement, ses ambiguïtés documentaires. Le mot « officiel » n'effaçait ni les corrections attendues, ni les options mal comprises, ni la distance entre une spécification et une machine. La liste servait précisément à…
Tendances télécoms nationaux Europe et Moyen-Orient
Un bouton NG eCall ne constitue pas un service local de sécurité éprouvé tant que le parcours 4G/5G n’est pas prêt
La présence d’une commande SOS et une date d’immatriculation admissible peuvent indiquer qu’un véhicule est susceptible d’embarquer le NG eCall. Elles ne démontrent pas que le parcours britannique entre le véhicule et les services d’urgence est déjà fiable.
Histoire d'Internet
La porte dérobée n’était pas une route : comment le RFC 831 contournait une partition de SATNET
Une seule ligne PSS arrivait à l’University College London. Il fallait pourtant y faire cohabiter le point d’accès ordinaire et un secours capable d’atteindre la moitié européenne de SATNET après une partition. Le RFC 831 ne proposait pas d’élargir le routage. Il confiait à un…
Histoire d'Internet
La passerelle transportait les octets, pas le sens manquant : comment la RFC 875 a contesté la traduction de protocoles
Deux réseaux incompatibles et une boîte entre eux: le dessin semblait avoir résolu le problème. En septembre 1982, la RFC 875 a rouvert cette boîte. Qui convertissait l’adresse, décidait qu’un accusé valait livraison, rapprochait deux contrôles de flux et interprétait un signal…
Histoire d'Internet
Le registre à jour, les machines en retard : comment la RFC 849 a partagé poussée et interrogation
En mai 1983, Mark Crispin ne contestait pas le contenu du fichier maître. Il observait qu'une copie locale pouvait vieillir sans bruit. La RFC 849 a donc séparé l'annonce, le numéro de version, le transfert, le contrôle d'intégrité et la reprise après une absence.
Histoire d'Internet
Le registre disait TCP, mais la prise devait répondre : comment la RFC 832 a mesuré le code en service
Un registre peut dire qu'une machine offre TCP. Il ne peut pas, à lui seul, ouvrir une connexion. En décembre 1982, les enquêtes de David Smallberg ont placé ces deux réalités dans des colonnes voisines: la déclaration du fichier des hôtes du NIC, puis ce qu'un essai Telnet, FTP…
Histoire d'Internet
La machine sans exécutif : comment RFC 818 plaça le Telnet utilisateur derrière le port 107
Le TC68K possédait seize prises série, une interface réseau et un minuteur, mais pas l'environnement général qu'un appel Telnet trouvait habituellement derrière le port 23. Cette absence ne fut pas comblée par un faux système de connexion. RFC 818 désigna l'application réellement…
Histoire d'Internet
Le service de noms a failli négocier : comment la RFC 830 séparait domaines et capacités
La source connaît le domaine de destination. Elle ne sait pourtant pas encore quel programme l'attend, quel transport il accepte ni même s'il propose le service demandé. La RFC 830 faisait de cet écart un élément d'architecture: localiser le domaine constituait une première…
Histoire d'Internet
Le numéro n’en faisait pas une norme : comment la RFC 825 inscrivait l’intention dans le document
Dans une bibliothèque, un manuel, le compte rendu d’une réunion et une proposition controversée peuvent porter des cotes voisines. Personne n’en déduit qu’ils ont la même autorité. La série des RFC avait besoin de cette même prudence: un numéro commun permettait de retrouver des…