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.
Histoire d'Internet
Quatre octets nuls séparaient IKE d’ESP. Ils n’authentifiaient ni l’un ni l’autre : RFC 3948
Une seule règle de pare-feu et une seule association NAT pouvaient laisser passer la négociation IKE, les données ESP protégées et l’entretien du chemin. Pour rendre ce partage possible, la RFC 3948 réservait quatre octets nuls à l’aiguillage vers IKE. Ce choix disait quel…
IETF
Le cookie était authentique. Il ne disait pas si la transaction était terminée.
Après la panne, le nouvel élément du pool a reçu le dernier cookie conservé par l’utilisateur. La signature était valide. Pourtant, ce reçu ne disait ni si l’ancienne requête avait été validée, ni si l’état représenté était encore le plus récent, ni si la nouvelle version du…
IETF
Une séquence relue par le groupe de travail ne devient pas l’unique architecture
RFC 5359 présente des scénarios SIP soigneusement vérifiés et relus collectivement. Cette qualité éditoriale en fait une référence de conception solide. Le même texte précise pourtant que les RFC de protocole restent normatives et que les services peuvent être réalisés autrement…
Histoire d'Internet
L’identifiant d’objet était temporaire. L’application devait se souvenir de ce qu’était le contenu : RFC 3940
RFC 3940 savait livrer un objet à un groupe et réparer les pertes, mais refusait d’en faire un objet durable par le seul pouvoir d’un numéro. Son compteur de transport sur 16 bits appartenait à un émetteur et à un instant de transmission; le souvenir du contenu restait à la…
IETF
La valeur était enregistrée. Le routeur n’avait toujours pas consenti à l’examiner.
Le registre paraissait complet: un numéro, une description, une référence normative et une procédure d’attribution. Pourtant, sur le chemin réel, le routeur pouvait ignorer l’option, transmettre le paquet comme un datagramme ordinaire ou le filtrer avant tout traitement de…
Histoire d'Internet
Le numéro de rappel entra dans l’e-mail. Son sens ne voyagea pas avec lui : RFC 3939
En 2004, conserver un numéro dans un message vocal semblait résoudre un problème de mémoire. RFC 3939 montra pourtant que la copie fidèle d’une chaîne ne transportait ni le plan de numérotation qui la rendait utile, ni la preuve de l’identité humaine qu’on pouvait être tenté de…
IETF
Soustraire le temps du réflecteur améliore la mesure, pas son autorité
RFC 5357 fait inscrire au réflecteur l’heure d’arrivée puis l’heure de départ de chaque paquet TWAMP. Leur différence permet d’isoler le séjour dans le réflecteur. Cette correction rend le calcul plus précis; elle ne transforme pas la valeur obtenue en verdict sur le service, le…
Histoire d'Internet
Le nom promettait de durer. Son résolveur n’existait pas encore : RFC 3937
RFC 3937 a donné à l’IPTC un espace mondial de noms persistants, mais il a aussi laissé apparaître une distinction décisive: le mot `current` pouvait rester stable tandis que le document désigné changeait. La permanence du nom ne garantissait ni l’immuabilité du contenu, ni même…
IETF
Une nouvelle tentative a réussi. Elle n’a pas authentifié la liste du KDC.
Un client PKINIT peut refuser ses premiers paramètres ECDH, recevoir du KDC une liste ordonnée de solutions de rechange, puis réussir avec l’une d’elles. Cette réussite établit une compatibilité cryptographique à la seconde tentative. Elle ne prouve pas que la liste reçue dans…
IETF
La liste était classée par préférence. Personne n’avait authentifié son ordre.
Le message semblait offrir une sortie propre à un désaccord cryptographique: le KDC refusait la courbe du client, puis renvoyait une liste ordonnée de paramètres acceptables. Il suffisait de reprendre le premier choix commun. Le RFC 5349 révèle la faiblesse de ce raisonnement: le…
Histoire d'Internet
Le code était privé. Ses bits de tête commandaient encore chaque routeur ignorant : RFC 3936
Un numéro réservé à un fournisseur ne restait pas enfermé chez lui. Dans RSVP, les premiers bits du numéro de classe indiquaient déjà à un ancien nœud s’il devait refuser tout le message, supprimer seulement l’objet inconnu ou le transmettre intact.
IETF
Le fax commence. L’absence de méthode n’est révélée qu’à cet instant.
Le Call Agent avait délégué la conduite du fax à la passerelle. La commande avait réussi, aucun défaut n’avait été signalé et la continuité semblait acquise. Pourtant, ce n’est qu’au début effectif du fax qu’un événement `nopfax(start)` révèle qu’aucune méthode spéciale commune…
IETF
Le réseau pair était bien authentifié. Le mauvais observateur a tout de même reçu la présence.
Le certificat désignait correctement le domaine distant. Le canal était chiffré, le partenaire figurait dans la fédération et l’abonnement SIP provenait bien de son infrastructure. Pourtant, aucune de ces preuves ne répondait à la question décisive: quelle personne se trouvait…
Histoire d'Internet
L’essai devait expirer. Son bilan pouvait ne jamais être écrit : RFC 3933
Entre une décision informelle de l’IESG et une règle permanente, RFC 3933 a installé un pont provisoire. Sa durée devait être bornée. En revanche, la question testée, les critères et le récit final pouvaient rester moins précis que l’échéance elle-même.
IETF
Le DNS répondit sans erreur. L’appel dut pourtant s’arrêter.
Le code semblait rassurant: `NOERROR`. Mais la réponse ne contenait aucune URI SIP ou H.323 utilisable. Dans la politique de l’essai décrit par le RFC 5346, ce résultat imposait l’échec immédiat pour un numéro joignable uniquement par ENUM. Un `NXDOMAIN`, pourtant plus alarmant…
Histoire d'Internet
Le message ressemblait à un document. Le protocole l’avait déjà décomposé : RFC 3930
Une signature posée au bas d’un objet complet paraît naturelle. Sur un réseau, cet objet peut pourtant être reconstruit, traversé par morceaux et interprété avec un état que la page ne contient pas. RFC 3930 a fait de cette différence un problème de conception.
IETF
Le moteur a donné son identifiant. Il n’a pas donné les droits d’accès.
Le gestionnaire venait de résoudre un problème de nommage: derrière l’adresse de transport, quel moteur SNMP servait le contexte local ? La réponse était exploitable, stable et peut-être construite à partir d’une adresse MAC ou IP. Elle ne disait pourtant ni qui formulait la…
IETF
La sonde ne voyait pas un VLAN. Le rapport y a vu une absence.
Pendant sept jours, aucune opération SNMP d’écriture n’apparut dans la trace. Le graphique semblait donc montrer un réseau administré uniquement en lecture. Mais la sonde n’avait jamais reçu le VLAN où circulaient les changements. Le zéro était exact dans le fichier et faux pour…
Histoire d'Internet
Le sous-type a traversé MIME et SDP. Ses paramètres ont dû être remappés : RFC 3555
Entre `audio/l16` et `L16/48000/2`, la casse pouvait changer sans changer l’identité. Mais RFC 3555 n’en déduisait pas que toutes les valeurs étaient interchangeables: il imposait une carte précise pour éviter qu’un nom commun ne masque des contrats différents.
IETF
La colonne disait « sans valeur ». Le drapeau changeait pourtant le traitement.
Dans le registre créé par RFC 5341, `No Value` décrit une forme de paramètre, pas une absence de sens. Confondre les deux revient à effacer une instruction précisément parce qu’elle ne porte pas de signe égal.