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 révision qui ne pouvait pas rappeler son prédécesseur : comment Supersedes a séparé remplacement et effacement
Sur Usenet, corriger un article et faire disparaître l’ancienne version relevaient de deux pouvoirs différents. `Supersedes` permettait à une nouvelle publication de circuler normalement tout en demandant à chaque site de retirer un prédécesseur identifié. La correction pouvait…
Histoire d'Internet
La réponse qui ne devait pas revenir dans la même salle : comment Followup-To a séparé public et destination
Un article Usenet pouvait être lu dans plusieurs groupes tout en demandant que la réponse suivante paraisse ailleurs. `Followup-To` ne déplaçait pas l’original et ne fermait pas son public. Il proposait au logiciel une destination pour un nouvel acte de publication, que le…
Histoire d'Internet
Quitter sans effacer : le droit précis créé par IMAP UNSELECT
Un client voulait libérer une boîte aux lettres tout en restant authentifié. La commande `CLOSE`, pourtant évidente par son nom, rendait aussi définitive la suppression de tous les messages marqués `\Deleted`. `UNSELECT` a donné à la simple sortie son propre sens.
Histoire d'Internet
La date qui ne pouvait pas réserver de disque : comment Expires a séparé pertinence et conservation sur Usenet
Une date précise peut accompagner un article sans garantir sa présence jusqu’à cette échéance. Sur Usenet, `Expires` permettait à l’auteur d’indiquer quand une annonce perdrait son utilité. Les disques, les exceptions d’archivage et la décision de retrait restaient sous…
Histoire d'Internet
Le ticket reprenait la session, pas le protocole
Dans une grappe de serveurs, un ticket TLS peut revenir vers une autre machine que celle qui l’a émis. La cryptographie autorise parfois une reprise rapide; elle ne décide pourtant pas quelle grammaire applicative cette nouvelle connexion va parler. ALPN oblige chaque…
Histoire d'Internet
La frontière qu’un en-tête ne pouvait contenir : comment Distribution limita Usenet sans le rendre privé
Usenet savait transporter une consigne de portée: locale, nationale, institutionnelle. Il ne transportait pas la frontière correspondante. Celle-ci demeurait dans les accords entre relais, les noms reconnus par chaque site et les passerelles tenues par les opérateurs.…
Histoire d'Internet
La seconde date qui refusa d’effacer la première : comment Injection-Date sépara l’écriture de l’entrée en réseau
Un article Netnews achevé un lundi pouvait rester sur un ordinateur hors ligne avant d’entrer dans le réseau le vendredi. La première date racontait le geste de l’auteur; la seconde devait aider les serveurs à distinguer une arrivée récente d’un ancien article revenu dans le…
Histoire d'Internet
La mémoire louée par des fragments qui ne formaient jamais un paquet
Un fragment isolé n’était pas seulement un morceau de trafic. À l’arrivée, il pouvait ouvrir un contexte, réserver un tampon et faire démarrer une attente. La question historique n’était donc pas simplement « combien de temps patienter ? », mais « quel témoin faut-il conserver…
Histoire d'Internet
Le numéro disait où, pas quoi : comment Xref a rendu l’emplacement Usenet local
Un même article Usenet pouvait porter un numéro différent dans chaque groupe, puis en recevoir d’autres sur le serveur voisin. Xref n’a pas supprimé cette pluralité: il lui a donné une portée exacte, en séparant l’identité mondiale de l’article de ses coordonnées locales.
Histoire d'Internet
Le nom de fichier que l’expéditeur ne pouvait pas choisir
En 1989, une exigence destinée aux hôtes Internet remplaça une indication FTP ambiguë par deux formes exactes: `125 FILE: pppp` et `150 FILE: pppp`. Quatre caractères et deux-points transformaient enfin une phrase de serveur en reçu exploitable par un programme — sans transformer…
Histoire d'Internet
La liste qui n’était pas son adresse : comment List-Id lui donna un nom stable
Une liste de discussion pouvait changer de serveur sans changer de communauté. List-Id a donné un nom durable à cette continuité, tout en laissant l’adresse de dépôt, les commandes et l’authentification évoluer sous des contrôles distincts.
Histoire d'Internet
La route que le relais devait oublier : SMTP conserva la syntaxe après lui avoir retiré son autorité
Une ancienne adresse SMTP peut encore énumérer des relais avant la boîte finale. Le serveur contemporain doit reconnaître cette forme, sans être obligé de suivre l'itinéraire. Ce paradoxe est volontaire: l'interopérabilité a conservé la grammaire, tandis que le pouvoir de choisir…
Histoire d'Internet
La nouvelle adresse qui n’était pas un renommage : SMTP sépara transfert et indication
Une boîte aux lettres a déménagé. Deux serveurs connaissent sa nouvelle adresse, mais le premier répond `251` et prend le message, tandis que le second répond `551` et le refuse. Le renseignement est identique; la responsabilité change de camp. SMTP a ainsi empêché qu’une…
Histoire d'Internet
Une note peut manquer ; une autre refuse de finir
Pour un réseau, deux paquets perdus peuvent se ressembler. Pour un instrument, perdre l'ordre de commencer une note ou celui de l'arrêter produit deux histoires différentes. Le journal de récupération de RTP MIDI a été conçu autour de cette dissymétrie: réparer ce qui persiste…
Histoire d'Internet
Le décalage qui ne savait pas nommer le fichier : la reprise FTP supposait un objet inchangé
Une coupure laisse deux souvenirs très différents: des octets déjà payés et l'identité du fichier qu'ils étaient censés former. FTP a su conserver le premier sous forme de point de reprise. Le second resta une promesse entre les systèmes, car aucune position ne peut dire à elle…
IETF
Job Snijders et la liste qui signait des octets, pas la vérité
Un prestataire peut vérifier qu’un fichier n’a pas changé et ignorer encore s’il doit agir. C’est précisément l’espace que Job Snijders et ses coauteurs ont donné à la RPKI Signed Checklist: une preuve étroite, liée à des ressources Internet et à des empreintes exactes, qui…
Histoire d'Internet
Le nom que le message devait forger lui-même : Message-ID sans registre central
Un relais ajoute un champ de trace: les octets changent, mais le message demeure le même. Un auteur révise une phrase: il peut créer une nouvelle version, même si presque tout le texte subsiste. `Message-ID` a nommé cette frontière sémantique, puis permis aux réponses et aux…
Histoire d'Internet
Transporter un état sans en connaître le sens
Dans une chaîne RADIUS, un intermédiaire pouvait rendre un service essentiel en s'abstenant d'interpréter les données de son voisin. Proxy-State séparait une obligation commune — conserver et restituer des octets — du sens privé que chaque implémentation leur donnait. Cette…
Histoire d'Internet
Prolonger une réservation sans la vérifier
Pour alléger RSVP, une extension a remplacé la répétition des descriptions complètes par des listes d’identifiants. Une réservation pouvait ainsi rester active sans que son contenu soit présenté à nouveau. Le gain était réel dans son principe; la capacité de réparation, elle…
Histoire d'Internet
La réponse que SMTP ne pouvait diviser : LMTP et la remise par destinataire
À la frontière de la remise locale, un même message peut rencontrer plusieurs réalités. Une boîte l'accepte, une autre manque temporairement de quota. SMTP ne dispose que d'un verdict final pour la transaction entière. LMTP a rendu ce verdict pluriel et ordonné, afin que la file…