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.

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…

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…

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…

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…

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…

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.…

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…

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…

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…

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…

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…

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…

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…

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…

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.

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…

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…

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…

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.

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…
