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.
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…
IETF
Le dernier fragment d’en-tête est arrivé. Le premier manquait toujours.
Le paquet portait `MHF=2`: il contenait la fin d’un en-tête principal JPEG 2000 fragmenté. Le signal était exact, mais il ne reconstituait pas le début perdu. RFC 5371 distingue ainsi l’emplacement d’une pièce, la présence de l’en-tête, son contrat d’identification et le résultat…
Histoire d'Internet
Une seule liaison a déplacé tout un réseau. Elle ne prouvait pas que chaque nœud était joignable : RFC 3963
Dans le réseau mobile imaginé en 2005, le mouvement pouvait être réel tout en restant invisible aux machines transportées. Cette élégance avait un prix documentaire: lorsque l’agent mère acceptait la nouvelle liaison, il confirmait une décision de transfert. Il ne certifiait ni…
IETF
Le contrôleur était authentifié. Sa politique dépassait pourtant son mandat.
Le certificat du serveur de clés était valide, mais le flux qu’il voulait installer ne l’était pas pour ce groupe. La RFC 5374 n’a pas demandé au membre de confondre ces deux constats. Elle a ajouté la GPAD précisément pour qu’une identité reconnue reste enfermée dans un…
IETF
Le nom de l’appelant a traversé le pont. Son ancrage transactionnel, non.
Le transcodeur a repris la valeur visible du champ `From`, puis il a créé un nouvel INVITE, un nouveau tag et une nouvelle transaction. Pour le destinataire, le même appelant semblait toujours présent. Pour l’enquêteur, la continuité devait encore être démontrée. La RFC 5370…
Histoire d'Internet
Zéro ne voulait pas dire « par défaut », mais 4 294 967 296 itérations : RFC 3962
Un champ absent et un champ rempli de zéros se ressemblent facilement après leur passage dans une base de données. Dans RFC 3962, ils déclenchaient pourtant deux charges séparées par un facteur supérieur à un million. L’histoire d’AES dans Kerberos est aussi celle d’une…
IETF
Le mot « Priv » demandait un privilège. Il ne l’accordait pas.
La RFC 5373 compare `Priv-Answer-Mode` à `sudo`. Le préfixe attire l’attention sur une demande exceptionnelle; il ne transporte pas le droit de l’exécuter. Entre l’appelant et le haut-parleur, le terminal conserve une table d’autorisation, une politique par direction média et la…
Histoire d'Internet
La même clé Kerberos avait besoin d’un numéro pour chaque usage : RFC 3961
Une clé pouvait être légitime et l’opération mal nommée. RFC 3961 a donc demandé aux protocoles Kerberos de fournir, avec la clé, un numéro d’usage: non pas un secret supplémentaire, mais l’étiquette qui empêchait plusieurs pouvoirs cryptographiques de se confondre.
IETF
La présence annonçait un terminal audio. Un autre appareil a répondu.
Le document de présence était récent et précis: le téléphone déclaré ne proposait que l’audio. L’appel a pourtant abouti sur un client logiciel capable de vidéo. RFC 5369 n’avait pas produit une contradiction; il avait révélé une erreur de sujet. Une capacité annoncée et une…
IETF
Le 202 est arrivé avant les trois BYE. Il ne pouvait donc pas raconter leur résultat.
Le serveur de conférence a accepté une demande unique, puis seulement ensuite a produit trois transactions distinctes. Cette chronologie, dessinée dans la RFC 5368 elle-même, interdit une conclusion pourtant tentante: la réponse au REFER n’est pas le reçu collectif des opérations…
Histoire d'Internet
Le tunnel acceptait le paquet. La décapsulation effaçait sa trace la plus proche : RFC 3964
Le danger historique de 6to4 ne tient pas seulement à l'usurpation d'adresse. Il tient au moment précis où une machine accomplit correctement son travail: elle retire l'enveloppe IPv4, livre le paquet IPv6 à l'étape suivante et peut, ce faisant, faire disparaître l'indice qui…
IETF
Le serveur avait accepté l’abonnement. Il n’avait encore prouvé l’état d’aucune ressource.
La réponse positive concernait un dialogue entre le client et le serveur de listes. Derrière ce dialogue, trois URI exigeaient encore trois observations. La RFC 5367 refuse de faire parler le premier statut au nom de ces ressources: ce sont les notifications qui indiquent si le…
IETF
Le 200 OK a ouvert la conférence. Aucun invité n’avait encore rejoint.
La réponse paraissait clore l’opération: la conférence existait, l’organisateur y était entré et le serveur avait compris la liste jointe à l’INVITE. La RFC 5366 refuse pourtant d’en déduire davantage. Le 200 ne dit pas qu’un seul des invités a été appelé, admis, connecté aux…
Histoire d'Internet
Le téléphone annonçait une sonnerie. L’appelant devait encore écouter les paquets : RFC 3960
Dans un appel SIP, le correspondant pouvait être alerté sans qu’aucune tonalité ne traverse le réseau. Le poste de l’appelant comblait alors le silence, puis cédait la place aux médias reçus: une continuité sonore construite avec deux autorités différentes.
IETF
Le nom de l’expéditeur est resté. Son autorité, elle, a changé de mains.
Bob a vu Alice dans le champ From. Pourtant, le message qu’il recevait n’était pas la continuation transparente de la transaction d’Alice. Le service de liste avait terminé un premier échange, appliqué une règle de confidentialité, puis créé une nouvelle requête. Préserver un nom…
Histoire d'Internet
L’adresse de groupe nommait son point de rendez-vous. Elle ne prouvait pas son existence : RFC 3956
Avec la RFC 3956, une adresse multicast IPv6 devenait aussi une instruction de calcul: elle indiquait quel RP essayer. La même formule donnait le même candidat partout, sans transformer ce candidat en route, service ou preuve de livraison.
IETF
La liste reçue n’était pas la liste d’origine : le relais avait construit une vue pour ce destinataire
La RFC 5364 ne demande pas au relais de recopier une liste maîtresse dans chaque requête SIP. Elle lui demande d’en produire une projection adaptée au destinataire: certains URI restent visibles, les copies cachées disparaissent, et des entrées anonymisées peuvent ne laisser…
Histoire d'Internet
Le paquet ne portait aucun compte de trames. Le récepteur devait diviser : RFC 3952
La RFC 3952 n’a pas mis le nombre de trames iLBC dans la charge RTP. Elle a préféré une économie conditionnelle: la longueur devenait un compte seulement si le récepteur possédait encore le mode négocié.
IETF
Un destinataire n’avait pas consenti. Aucun envoi ne devait partir.
Neuf autorisations étaient valides. La dixième manquait. Le service n’avait donc pas neuf messages à envoyer et un cas à écarter: il avait une opération indivisible qui ne pouvait pas commencer. La règle de la RFC 5363 est plus exigeante que le filtrage opportuniste.…
IETF
La permission réside au relais, pas dans le carnet d’adresses de l’administrateur
Dans RFC 5360, le gestionnaire d’une liste peut proposer une nouvelle adresse, mais cette modification ne donne pas au relais le droit d’y envoyer du trafic. Le destinataire doit consentir à une traduction précise, puis le relais doit conserver et appliquer cette permission.…