Aller au contenu principal

Domaine principal

Infrastructure

Au sein de la facette Domaine principal, l'analyse Infrastructure 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.

Le livre était sur une étagère. Le résolveur ne pouvait offrir qu’une notice : RFC 3187

Histoire d'Internet

Le livre était sur une étagère. Le résolveur ne pouvait offrir qu’une notice : RFC 3187

Une résolution réussie ne livrait pas toujours un fichier. Si l’ouvrage n’existait qu’en version physique, RFC 3187 estimait que la meilleure réponse pouvait être une notice bibliographique et l’emplacement d’un exemplaire en bibliothèque. Le nom persistait; l’accès restait une…

2 oct. 2026
Le client voyait une liaison directe. L’opérateur détenait la paire d’adresses cachée : RFC 3186

Histoire d'Internet

Le client voyait une liaison directe. L’opérateur détenait la paire d’adresses cachée : RFC 3186

Un voyant physique pouvait rester allumé alors que le protocole de ligne était déjà mort. Cette formule — « link up, line protocol down » — révèle mieux RFC 3186 que le mot tunnel: le client observait une liaison PPP apparemment simple, tandis que la cause, le chemin et le…

2 oct. 2026
Retirer un nom de l’enveloppe ne révoquait pas l’ancienne clé : RFC 3185

Histoire d'Internet

Retirer un nom de l’enveloppe ne révoquait pas l’ancienne clé : RFC 3185

Une nouvelle enveloppe chiffrée pouvait omettre trois destinataires et pourtant rester lisible par eux. Leur nom avait disparu de la représentation; le pouvoir reçu avec la clé précédente, lui, n’avait pas été repris. RFC 3185 exposait cette différence sans détour: réduire la…

2 oct. 2026
Le domaine a signé le message. La personne restait sans nom : RFC 3183

Histoire d'Internet

Le domaine a signé le message. La personne restait sans nom : RFC 3183

Entre « ce domaine a laissé partir ce message » et « cette personne en est l’auteur », il existe un espace probatoire que l’interface moderne efface volontiers. RFC 3183 plaça précisément son mécanisme dans cet espace: une organisation pouvait authentifier quelqu’un en interne et…

2 oct. 2026
Le nom est entré dans RSVP. L’autorité devait encore décider ce qu’il signifiait : RFC 3182

Histoire d'Internet

Le nom est entré dans RSVP. L’autorité devait encore décider ce qu’il signifiait : RFC 3182

Un localisateur de politique ressemble à une permission quand on le lit trop vite. Il n’en est pas une. Dans la RFC 3182, ce localisateur indiquait où chercher une règle; un identifiant, un ticket Kerberos ou un certificat apportait une preuve d’identité d’une qualité variable…

2 oct. 2026
Le nouveau flux a obtenu l’admission. Sa priorité de défense devait encore survivre à l’arrivée suivante : RFC 3181

Histoire d'Internet

Le nouveau flux a obtenu l’admission. Sa priorité de défense devait encore survivre à l’arrivée suivante : RFC 3181

Dans un réseau saturé, arriver le premier n’était plus une garantie, et arriver le dernier n’était plus une condamnation. La RFC 3181 permit à une nouvelle demande de supplanter une réservation antérieure, mais elle refusa de confondre l’autorité d’entrer avec celle de rester.…

2 oct. 2026
Le moteur répondit 231. Le script devait encore un reçu de fin : RFC 3179

Histoire d'Internet

Le moteur répondit 231. Le script devait encore un reçu de fin : RFC 3179

Dans un système d’administration, la première réponse rassurante arrive souvent trop tôt. La RFC 3179 avait prévu ce piège. Le code 231 attestait qu’une commande avait conduit le moteur à un état précis; d’autres messages portaient les résultats provisoires, les erreurs et la fin…

2 oct. 2026
Le cœur oubliait le flux. Les bords devaient encore prouver sa réservation : RFC 3175

Histoire d'Internet

Le cœur oubliait le flux. Les bords devaient encore prouver sa réservation : RFC 3175

La RFC 3175 proposait de rendre RSVP supportable à grande échelle en retirant du cœur une partie de la mémoire par flux. Elle ne promettait pas qu’un gros bloc de bande passante rendrait chaque engagement individuel vrai. Plus le centre devenait sobre, plus les deux bords…

2 oct. 2026
La zone était critique, mais elle ne devait pas rester la tâche des serveurs racine : RFC 3172

Histoire d'Internet

La zone était critique, mais elle ne devait pas rester la tâche des serveurs racine : RFC 3172

La RFC 3172 imposait aux serveurs de `.arpa` une discipline digne de la racine du DNS. Elle disait pourtant que leur présence sur des machines de la racine devait changer. Cette tension révèle un principe solide: préserver le nom et le service n’oblige pas à consacrer l’opérateur…

2 oct. 2026
Le registre avait attribué l’adresse multicast. Il devait encore vérifier son usage : RFC 3171

Histoire d'Internet

Le registre avait attribué l’adresse multicast. Il devait encore vérifier son usage : RFC 3171

Une adresse peut rester des années dans une table et pourtant perdre la raison qui l’y avait conduite. En 2001, la RFC 3171 ne confondait pas la permanence visuelle du registre avec une nécessité perpétuelle: l’attribution devait rester exceptionnelle, être réexaminée et, lorsque…

2 oct. 2026
L’index nommait la ligne de politique. Il n’en expliquait pas le sens : RFC 3159

Histoire d'Internet

L’index nommait la ligne de politique. Il n’en expliquait pas le sens : RFC 3159

Deux lignes arrivent dans un équipement. Elles contiennent les mêmes conditions, la même action et les mêmes références; seul leur numéro change. S’agit-il de deux politiques ou de deux adresses pour un contenu identique ? Avec la RFC 3159, SPPI refusait de charger l’identifiant…

2 oct. 2026
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 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
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 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
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