Résumé

  • Whois 1.124 a ajouté le texte brut et les réponses sans formatage à la Versions API. La documentation de RIPE NCC situe le déploiement en production au 27 août 2026 ; l’examen présenté ici date de septembre.
  • L’objet historique est filtré avant sa restitution. Le corps en texte brut ne passe pas par l’ajout du numéro de révision effectué dans la réponse structurée : un fichier détaché de sa requête n’est pas une archive du message de mise à jour d’origine.

Un fichier d’historique peut être parfaitement lisible et pourtant perdre une partie de ce qui l’identifie. La clé de l’objet reste visible, ses attributs se comparent facilement, mais le numéro demandé a pu rester dans l’adresse de la requête plutôt que dans le texte sauvegardé.

Il s’agit d’un cas de classement hypothétique, pas d’une erreur observée chez un utilisateur de RIPE Database. Il montre simplement pourquoi la commodité d’un format et la portée d’une preuve doivent être examinées séparément.

Whois 1.124 a introduit des réponses text/plain et unformatted dans la Versions API. La documentation officielle indique un déploiement dans l’environnement de préproduction le 13 août, puis en production le 27 août. L’URI d’une version précise contient la source, le type d’objet, sa clé et son numéro. Cette enquête de septembre suit le code publié sous la référence 9095208c158c9d6630e6b1eac33e845d2c537d3d, non toutes les installations actuelles.

Le filtre précède le format

Le service examiné sélectionne le type d’objet et transmet SHOW_VERSION avec le numéro demandé. La requête emprunte le chemin REST et produit un VersionWithRpslResponseObject.

Ce résultat n’est pas la conservation d’une soumission HTTP ou d’un courriel original. L’exécuteur de requêtes historiques applique d’abord ses fonctions de filtrage des adresses électroniques, de l’authentification, des attributs changed et des données personnelles. Il associe ensuite l’objet ainsi traité à la révision demandée.

Changer la représentation ne permet donc pas de remonter à une transaction originale non filtrée. Cela ne signifie pas non plus que chaque attribut de chaque objet soit modifié. Un texte RPSL visible peut coïncider avec un texte autrefois soumis ; l’interface ne garantit pas pour autant l’identité avec cette soumission.

La distinction protège une fonction raisonnable. Rendre l’historique consultable ne suppose pas de republier des informations d’authentification ou des données personnelles filtrées. La recherche d’une preuve lisible n’annule pas ces protections.

Le numéro est ajouté dans une autre branche

Lorsque l’en-tête Accept contient text/plain, le service renvoie directement la représentation textuelle du RpslObject historique et termine cette branche.

Dans la réponse structurée, il poursuit le traitement : le paramètre unformatted détermine le choix du mappage d’attributs, puis le WhoisObject reçoit explicitement la révision historique. L’ensemble est placé dans WhoisResources, avec notamment des informations d’erreur, de conditions d’utilisation et de version logicielle.

L’ajout de la révision appartient donc à cette seconde branche. La sortie en texte brut ne l’exécute pas. Elle ne passe pas non plus par l’appel au mappeur qui interprète unformatted. Ce paramètre ne doit pas être décrit comme un moyen d’obtenir la requête originale, quel que soit le média choisi.

Cette observation concerne le chemin de production du corps de réponse dans le code étudié. Tous les en-têtes HTTP, intercepteurs et proxys n’ont pas été audités. L’URI de la requête continue d’identifier la révision sélectionnée. Des champs ordinaires ou des remarques rédigées par l’utilisateur peuvent aussi contenir des dates ; ce n’est pas une raison pour présumer que le numéro propre à la réponse structurée figure dans tout fichier texte isolé.

Il faut également distinguer la version du logiciel de la révision de l’objet. La première décrit le code du service ; la seconde désigne une position dans l’historique demandé. L’une ne remplace pas l’autre.

Sauvegarder la lecture et son contexte

Le texte brut a de vrais avantages. Il s’ouvre dans des outils simples, se conserve facilement et se compare sans enveloppe JSON ou XML. La réponse structurée apporte un contexte explicite, mais n’est pas nécessairement le format le plus pratique pour chaque tâche.

La bonne question est ce qui accompagne la sauvegarde. Conserver l’URI exacte, la source, le type, la clé et la révision demandée ; préciser la représentation et la date de capture ; garder les en-têtes et les métadonnées structurées disponibles. L’empreinte doit porter sur le corps effectivement reçu, dans le format indiqué.

Une empreinte protège l’intégrité des octets conservés. Elle ne reconstitue ni une URI perdue ni les attributs filtrés, et ne prouve pas qui a autorisé la transaction d’origine. Deux représentations peuvent différer en octets sans établir un changement de la ressource.

L’historique, l’identité de sa révision et la preuve de transaction sont liés. Ce ne sont pas trois noms pour une même pièce.

Sources