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 modèle décrivait la règle, pas le résultat exécuté : RFC 3060
La RFC 3060 a donné aux systèmes de gestion un vocabulaire commun pour les groupes, les règles, leurs conditions et leurs actions. Elle n’a pas fourni à chaque routeur le même moteur d’interprétation. On pouvait décrire quand une règle s’appliquait, voire indiquer si l’ordre des…

Histoire d'Internet
Le canal D est resté sur place quand le traitement des appels est passé à IP : RFC 3057
La RFC 3057 n’a pas transporté la ligne RNIS dans Internet. Elle s’arrêtait à une frontière précise: la passerelle de signalisation terminait toujours Q.921, tandis qu’IUA acheminait les primitives de la couche supérieure vers un processus de traitement des appels par SCTP. Le…

Histoire d'Internet
Le compteur déclarait l’appel réussi sans savoir si quelqu’un avait entendu : RFC 3055
En 2001, le groupe PINT a rendu mesurables des services téléphoniques déclenchés depuis Internet. RFC 3055 comptait les demandes reçues, réussies ou interrompues par service, période, client, utilisateur et passerelle. Sa limite est tout aussi précieuse: le serveur pouvait…

Histoire d'Internet
La voie 16 kHz est restée ouverte après l’extension à 14 kHz : RFC 5577
La RFC 5577 élargit le profil audio G.722.1 et ajoute une horloge d’échantillonnage plus rapide. Sa règle de migration la plus instructive est plus discrète: conserver l’offre à 16 kHz lorsque des terminaux plus anciens comptent encore.

Histoire d'Internet
Le téléphone nommait ses pièces, le contrôleur devait encore vérifier leur présence : RFC 3054
La RFC 3054 donna un vocabulaire commun à l’écran, aux touches, au combiné, au haut-parleur et au flux média d’un téléphone Internet. Le profil IPPhone permettait à un contrôleur distant de partir d’un modèle connu au lieu de deviner la fonction d’un inventaire arbitraire. Ce…

Histoire d'Internet
Le root DSE pouvait nommer son éditeur, mais pas déclarer ses capacités : RFC 3045
Un serveur LDAP pouvait indiquer au client qui avait écrit son logiciel et quelle version il déclarait exécuter. L’information aidait un opérateur ou un correctif très ciblé, mais ne constituait pas une liste de fonctions. La RFC 3045 pose nettement cette frontière: le nom du…

Histoire d'Internet
Le numéro ISSN demeurait, les URL bougeaient : le veilleur de la RFC 3044
En 2001, le Centre international de l’ISSN a montré comment un numéro familier pouvait circuler sous forme d’URN. La difficulté n’était pas d’imprimer le numéro, mais de maintenir le chemin entre ce numéro et l’adresse web mouvante d’une revue. La RFC 3044 était explicite…

Histoire d'Internet
Le courtier commandait le tunnel, une autre machine devait le transporter : RFC 3053
La RFC 3053 transforma une tâche pénible du premier Internet IPv6 en service: s’inscrire, fournir une extrémité IPv4, recevoir une configuration et se connecter. Mais son architecture révélait aussi la limite de cette facilité. Le Tunnel Broker décidait et ordonnait; un Tunnel…

Histoire d'Internet
Un nom mondial, un seul résolveur faisant autorité : la promesse et la limite de la RFC 3043
En janvier 2001, Network Solutions proposait un nom Internet durable pour les personnes et les organisations. La RFC 3043 rendait la référence transportable entre applications, mais son propre modèle d’enregistrement réservait l’interprétation faisant autorité au résolveur de…

Histoire d'Internet
Le standard recommandait LDP, sans prouver qu’il fonctionnait : RFC 3037
Dans RFC 3037, « recommandé » désignait un choix de protocole pour les équipements MPLS suivant les routes ordinaires. Le mot ne certifiait ni un logiciel présent, ni une option activée, ni une session TCP établie, ni une étiquette installée. L’intérêt historique du texte tient…

Histoire d'Internet
Deux ACK dupliqués pouvaient relancer l’envoi sans élargir la fenêtre : RFC 3042
Un émetteur TCP dispose d’une fenêtre de congestion de trois segments. Le segment du milieu disparaît, et les données suivantes ne produisent que deux ACK dupliqués: il en manque un pour atteindre le seuil de Fast Retransmit. En janvier 2001, RFC 3042 propose une réponse plus…

Histoire d'Internet
Le label ATM changeait à chaque commutateur ; les voisins LDP partageaient un VCID
Un champ VPI/VCI suffisait à acheminer les cellules sur un lien, mais sa valeur pouvait être remplacée au commutateur suivant. Pour établir une correspondance LDP, les deux ATM-LSR voisins avaient donc besoin d’un nom commun du circuit virtuel, distinct de leurs labels locaux.

Histoire d'Internet
Le cœur ne savait pas décrémenter le TTL : RFC 3034 a fait payer les sauts à l’entrée
Un commutateur Frame Relay savait remplacer un DLCI à grande vitesse, mais son matériel ne savait généralement pas retirer une unité au TTL de chaque paquet. RFC 3034 n’a pas fait disparaître ces sauts: il a déplacé leur comptabilité à la frontière du segment MPLS. La longueur…

Histoire d'Internet
LDP a gardé le préfixe complet, mais supprimé le FEC d’adresse hôte
Un protocole peut abandonner une distinction sans perdre la capacité qu’elle semblait réserver. En 2001, LDP séparait le préfixe d’adresse du FEC « Host Address ». En 2007, la révision a retiré ce dernier: le texte dit qu’aucune implémentation ne l’utilisait. Le préfixe, lui…

Histoire d'Internet
L’identifiant a nommé la session sans la déplacer : RFC 3033
Au début de 2001, un message de signalisation ATM pouvait désigner exactement une session IPv4 ou IPv6 et pourtant laisser ses paquets sur le circuit virtuel par défaut. RFC 3033 a normalisé le vocabulaire de cette coordination, sans confondre le nom transmis avec la connexion…

Histoire d'Internet
Le serveur annonçait une capacité. L’authentification a changé la réponse : RFC 2449
Avant de savoir qui se connecte, un client POP3 demande ce que le serveur sait faire. La réponse peut rester prudente. Une fois l’utilisateur authentifié — puis, éventuellement, la session protégée — le même serveur peut préciser ou modifier cette réponse. RFC 2449 a rendu la…

Histoire d'Internet
Le serveur a signé le verdict, pas la validité de l’objet : RFC 3029
Un certificat signé peut annoncer un échec. Sa signature ne rend pas valide ce qu’il examine; elle permet d’attribuer le verdict, de rattacher celui-ci à une requête, à une heure et à une politique. RFC 3029 a construit tout son protocole autour de cette séparation, plus…

Histoire d'Internet
Le réseau traitait les paquets à égalité ; le codec, non : RFC 2448
Dans une vidéo compressée, quelques octets perdus ne représentent pas toujours une petite perte. Un fragment d’image peut laisser une tache locale; une brève information qui explique comment lire la suite peut compromettre bien davantage. En 1998, la RFC 2448 proposait de faire…

Histoire d'Internet
Le filtre a décidé, le courrier n’était pas encore arrivé : RFC 3028
Le silence d’un script aurait pu devenir une trappe. Avec Sieve, il devient au contraire une précaution: si aucune action de remise n’est choisie, le message est conservé implicitement. RFC 3028 a ainsi fixé une frontière féconde entre la décision prise par une règle et le…

Histoire d'Internet
Le courriel transportait l’invitation ; il ne la définissait pas : RFC 2447
En 1998, RFC 2447 a décrit comment loger un objet iCalendar dans un message MIME pour faire passer les opérations iTIP par le courrier électronique. Le paquet pouvait aussi contenir une explication lisible par les clients sans fonction d’agenda, sans transformer cette explication…
