Aller au contenu principal

Profil

Research

Research rassemble les profils des personnes, entreprises, institutions et autres entités couvertes par BTW.MEDIA, afin que les lecteurs puissent comparer les sujets derrière ses reportages. La page permet de comparer les profils publics, les événements associés, les dossiers de preuves, les changements de responsabilités, l’ampleur des activités, l’exposition aux instances de gouvernance, les liens organisationnels et la pertinence sur le marché, tout en distinguant les fiches des organisations et des personnes de la simple chronologie de l’actualité. Les lecteurs peuvent comprendre qui ou ce que représente le profil, sur quelles sources publiques il s’appuie, comment il se relie aux entreprises, aux infrastructures, aux marchés, aux instances de gouvernance ou aux événements, et quels changements méritent une attention continue à mesure que le sujet évolue.

Les adresses aux deux bouts ne nommaient pas le réseau traversé : RFC 1272

Histoire d'Internet

Les adresses aux deux bouts ne nommaient pas le réseau traversé : RFC 1272

En 1991, un fournisseur Internet pouvait voir les adresses source et destination d’un paquet sans savoir quelle administration voisine l’avait acheminé au-delà d’une frontière. La RFC 1272 a fait de cet écart le problème central de la comptabilité réseau: pour rapprocher l’usage…

8 oct. 2026
Le cookie est devenu un second registre de session : RFC 5381

IETF

Le cookie est devenu un second registre de session : RFC 5381

Un identifiant peut être exact et pourtant désigner la mauvaise autorité. Dans l’expérience NETCONF sur SOAP consignée par la RFC 5381, la session existait dans le message NETCONF, dans un cookie HTTP et, selon la norme citée, dans la connexion persistante. Le client et le…

8 oct. 2026
Le client universel était un leurre : RFC 3981 a laissé le cœur incomplet à dessein

Histoire d'Internet

Le client universel était un leurre : RFC 3981 a laissé le cœur incomplet à dessein

Un socle commun peut relier des registres sans comprendre leurs données. RFC 3981 a assumé cette limite: IRIS partageait des enveloppes, des références et un lookup élémentaire, tandis que chaque type de registre conservait ses propres recherches et relations. L’incomplétude du…

8 oct. 2026
Pour gérer les équipements, SNMP devait traverser les routeurs : le choix UDP/IP de la RFC 1270

Histoire d'Internet

Pour gérer les équipements, SNMP devait traverser les routeurs : le choix UDP/IP de la RFC 1270

En octobre 1991, placer la gestion du réseau au niveau réseau d’Internet ne répondait pas seulement à un souci d’économie de code. Les messages des opérateurs devaient souvent franchir des routeurs, des changements de support et des pannes localisées pour atteindre les…

8 oct. 2026
L’accusé de liaison était valide. Le premier paquet utile n’est jamais arrivé

IETF

L’accusé de liaison était valide. Le premier paquet utile n’est jamais arrivé

Dans la RFC 5380, un Mobility Anchor Point peut accepter une nouvelle association entre une adresse régionale stable et l’adresse locale courante. Cet accusé clôt une opération de contrôle précise. Il ne certifie ni le tunnel, ni le MTU utilisable, ni la livraison à…

8 oct. 2026
Le nom traversait trois transports de stockage sans désigner une adresse : RFC 3980

Histoire d'Internet

Le nom traversait trois transports de stockage sans désigner une adresse : RFC 3980

Un équipement pouvait parler Fibre Channel, SAS et iSCSI sans devoir changer d’identité à chaque port. RFC 3980 a ouvert à iSCSI la forme NAA déjà utilisée ailleurs. Ce pont conservait le nom du nœud logique; il ne disait ni où le joindre ni si une session fonctionnait.

7 oct. 2026
Quatre branches à la fois, des millions au total

IETF

Quatre branches à la fois, des millions au total

Un tableau de bord peut afficher quatre branches SIP actives et rester vert toute la journée. Un autre compteur, placé juste à côté, peut pourtant approcher dix millions de requêtes terminées. RFC 5393 oblige à lire les deux. `Max-Breadth` borne le travail simultané; il rend le…

7 oct. 2026
La case vide n’autorisait rien : la discipline de confidentialité de la RFC 5379

IETF

La case vide n’autorisait rien : la discipline de confidentialité de la RFC 5379

Dans une matrice de traitement, une case vide peut sembler inoffensive. Pour un service de confidentialité SIP, elle pouvait pourtant séparer une protection exacte d’une réécriture arbitraire. La RFC 5379 a organisé les champs visés par chaque valeur de confidentialité et rappelé…

7 oct. 2026
La compatibilité cachait le coût. La RFC 1263 voulait rendre visible la frontière des versions

Histoire d'Internet

La compatibilité cachait le coût. La RFC 1263 voulait rendre visible la frontière des versions

En 1991, la question n’était pas de savoir si TCP évoluerait, mais où cette évolution prendrait place. La RFC 1263 soutenait qu’une extension rétrocompatible pouvait éviter un déploiement simultané tout en transférant la complexité dans un protocole déjà difficile à faire…

7 oct. 2026
Le serveur a refusé l’appel ; le réseau a multiplié l’effort

IETF

Le serveur a refusé l’appel ; le réseau a multiplié l’effort

Dans le livre de comptes d’un réseau SIP, un refus n’est pas une opération gratuite. Il faut recevoir la requête, la lire, choisir une réponse, l’émettre et parfois répéter tout le dialogue. RFC 5390 a montré qu’un serveur déjà saturé pouvait produire un 503 parfaitement conforme…

7 oct. 2026
Une phrase juridique devait être corrigée. Le consensus n’avait pas changé.

IETF

Une phrase juridique devait être corrigée. Le consensus n’avait pas changé.

Une ambiguïté apparaît dans le texte d’une licence. L’objectif collectif reste intact, mais la correction est urgente. Si chaque mot juridique était figé dans un RFC, il faudrait rouvrir le document de processus pour réparer la formulation. La RFC 5377 a précisément évité cette…

7 oct. 2026
Un nom fut réservé pour SIP et SIPS sans s’appliquer aux deux : RFC 3969

Histoire d'Internet

Un nom fut réservé pour SIP et SIPS sans s’appliquer aux deux : RFC 3969

Dans RFC 3969, chaque nom de paramètre occupait une place sous SIP et sous SIPS, même lorsque son mécanisme ne concernait qu’un seul schéma. Ce doublon apparent protégeait l’unicité du sens. Il ne promettait ni applicabilité symétrique, ni implantation, ni réussite d’un appel.

7 oct. 2026
Deux recherches dans la PAD empêchaient une seule chute de confiance

IETF

Deux recherches dans la PAD empêchaient une seule chute de confiance

RFC 5386 n’a pas traité l’anonymat comme une qualité résiduelle accordée après l’échec d’une identité connue. Il a imposé deux recherches logiquement distinctes dans la base d’autorisation des pairs. La première donnait priorité aux relations authentifiées. La seconde n’ouvrait…

7 oct. 2026
Le nom était enregistré. Le terminal pouvait encore ne pas le comprendre : RFC 3968

Histoire d'Internet

Le nom était enregistré. Le terminal pouvait encore ne pas le comprendre : RFC 3968

Une ligne de registre ressemblait à une fiche d’identité: champ d’en-tête, paramètre, indicateur de valeurs fermées, références. Mais la fiche ne contenait ni le programme du terminal ni le résultat de l’appel. RFC 3968 a donné une provenance publique aux mots d’extension de SIP…

7 oct. 2026
Le SDP a accepté la compensation. Il n’a pas identifié l’en-tête conservé.

IETF

Le SDP a accepté la compensation. Il n’a pas identifié l’en-tête conservé.

L’offre proposait `mhc=1` et la réponse l’a accepté. Les deux extrémités partageaient donc une méthode de récupération des en-têtes JPEG 2000 perdus. Elles ne partageaient pas, pour autant, la preuve qu’un en-tête complet avait été reçu, conservé sous le bon identifiant et…

7 oct. 2026
L’auteur gardait son droit; le Trust recevait une licence irrévocable

IETF

L’auteur gardait son droit; le Trust recevait une licence irrévocable

Dans RFC 5378, deux réalités que l’on oppose trop souvent coexistent. Le contributeur, ou son employeur, peut conserver le droit d’auteur sur l’apport initial. En même temps, l’acte de soumettre accorde à l’IETF Trust une licence durable et très large. Cette architecture protège…

7 oct. 2026
Le tunnel était actif. Sa route principale ne l’était peut-être pas : RFC 3970

Histoire d'Internet

Le tunnel était actif. Sa route principale ne l’était peut-être pas : RFC 3970

Un voyant « actif » résumait plusieurs chemins. Un seul chemin secondaire suffisait à maintenir le tunnel, même si le principal ne transportait rien. RFC 3970 n’a pas supprimé cette ambiguïté: il l’a rendue mesurable en séparant état global, chemins, trois versions de la route…

7 oct. 2026
AS210860 : la requête aut-num sans résultat, alors qu'AS197909 annonce 193.20.0.0/15

Récits

AS210860 : la requête aut-num sans résultat, alors qu'AS197909 annonce 193.20.0.0/15

Le résumé de veille AS210860: la requête aut-num sans résultat, alors qu'AS197909 annonce 193.20.0.0/15 explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour…

7 oct. 2026
Les chaînes étaient différentes. La ressource téléphonique pouvait rester la même : RFC 3966

Histoire d'Internet

Les chaînes étaient différentes. La ressource téléphonique pouvait rester la même : RFC 3966

Les parenthèses et les tirets aidaient l’œil; ils ne devaient pas créer une nouvelle ressource. À l’inverse, un contexte local ou un paramètre supplémentaire ne pouvait pas disparaître sous prétexte de normalisation. RFC 3966 a donc dessiné une égalité sélective: oublier la…

7 oct. 2026
Le fournisseur cachait ses sauts, pas son obligation de vérifier le segment

IETF

Le fournisseur cachait ses sauts, pas son obligation de vérifier le segment

Un opérateur n'avait aucune raison de livrer toute sa topologie interne à un client ou à un pair pour calculer un chemin inter-AS. RFC 5376 lui permettait de rendre une référence opaque à la place des sauts. Cette discrétion protégeait une information sensible; elle ne supprimait…

7 oct. 2026