Résumé

  • La révision 15 du projet RDAP Extensions propose une date d’obsolescence dans le registre IANA. Le contact inscrit pourrait demander l’obsolescence de sa propre extension ; l’IESG pourrait la demander pour toute entrée.
  • Le projet de gestion des versions prévoit des annonces start, end, défaut, prédécesseur et successeur dans /help, une identification de la version dans la réponse et une préférence exprimée par le client. Ces éléments coordonnent une bascule sans connaître tous les clients.
  • Il faut donc un reçu de retrait qui distingue l’acte de registre, l’état de chaque serveur et la demande observée. Ce reçu est une proposition de Daniel Kade, pas une exigence de l’IETF.

L’obsolescence est souvent racontée au futur simple : on annonce, on attend, on supprime. RDAP résiste à cette grammaire. Un serveur public reçoit des clients qu’il n’a pas enrôlés. Certains passent tous les jours ; d’autres ne se réveillent que pour un audit annuel. La disparition d’une ancienne forme peut être invisible pendant des mois, puis casser l’outil dont dépend une décision urgente.

Le projet draft-ietf-regext-rdap-extensions-15, daté du 13 août 2026, part de ce réseau sans centre unique. Les serveurs RDAP appartiennent à des autorités différentes et se renvoient les requêtes par redirections et références. Les extensions doivent donc fonctionner sur des chemins où aucun opérateur ne voit l’ensemble des usages.

Le texte reste un projet de groupe de travail, destiné à la filière Standards Track. Le Datatracker demande une nouvelle révision à la suite d’une question du groupe ; aucun Area Director responsable n’est indiqué. Le projet de versionnage, révision 07 du 31 juillet, a le même statut de document de travail. Les mécanismes qu’ils décrivent ne sont ni des RFC ni des obligations de déploiement.

Une compétence limitée mais réelle

Le registre IANA donne un nom public aux extensions. Ce nom sert d’espace de noms et renvoie vers une spécification. Il n’encode pas forcément sa propre histoire : example1 peut succéder à example0, ou désigner tout autre chose. Sans relation déclarée, le numéro apparent n’est qu’une partie opaque de l’identifiant.

La révision 15 ajouterait un champ Deprecation Date. Le contact enregistré demanderait l’obsolescence de son extension ; l’IESG disposerait de la même faculté pour n’importe quelle entrée. IANA conserverait la date au format défini par RFC 3339. Le dispositif répond clairement à trois questions : qui peut demander, qui tient le registre et quand le nouvel état commence.

Il ne répond pas à une quatrième : qui a retiré le code ? Le registre ne commande ni les serveurs indépendants ni les clients. Il peut déclarer qu’un identifiant n’est plus la référence courante. Il ne peut pas faire disparaître une bibliothèque installée, modifier un script oublié ou prouver qu’un serveur ne renvoie plus l’ancienne structure.

Le projet demande aussi d’associer le 21 août 2025 à deux profils ICANN déjà indiqués OBSOLETED, icann_rdap_response_profile_0 et icann_rdap_technical_implementation_guide_0. Au 8 septembre 2026, le registre public, mis à jour le 1er septembre, affiche bien ces deux mentions et leurs successeurs de version 1, mais pas encore une colonne séparée pour la date. Rien ne permet d’y voir un manquement : l’instruction figure encore dans un Internet-Draft.

L’Expert Review protège une autre frontière. La politique exige une spécification stable, accessible et assez détaillée pour permettre des implémentations indépendantes. Le projet propose plusieurs experts et une double vérification. Cette procédure juge l’admissibilité d’un vocabulaire commun ; elle ne certifie pas le parc logiciel qui l’utilise.

Un serveur annonce sa propre trajectoire

Le projet de versionnage donne davantage de précision aux opérateurs. Dans /help, versioning_help peut lister les versions prises en charge, la version par défaut, les liens documentaires, les rapports de succession et des bornes start et end. versioning_data dit quelles versions ont façonné une réponse donnée. Le paramètre versioning_list permet au client d’indiquer celles qu’il souhaite.

Ces surfaces ne sont pas redondantes. L’aide décrit une capacité. La réponse décrit un fait d’exécution. La requête exprime une préférence. Un serveur peut conserver une ancienne version sans l’utiliser par défaut ; un client peut recevoir le nouveau format sans l’avoir explicitement choisi ; une réponse conforme ne prouve pas que les autres instances du service sont identiques.

La borne end est une promesse du serveur. Une fois l’instant passé, l’objet de version doit quitter la liste de prise en charge. L’absence de borne signifie qu’aucune expiration n’est planifiée. Dans les deux cas, on connaît la politique publiée par cet opérateur, pas l’état de tous ses clients.

Pour les changements incompatibles, la révision 07 recommande un intermédiaire : ancienne et nouvelle forme coexistent, le remplacement est annoncé, puis l’ancienne disparaît après une période jugée suffisante. Un autre scénario change d’abord la valeur par défaut tout en autorisant le client à demander l’ancienne version jusqu’à l’échéance. Ce sont de bons instruments. Ils ne produisent pas la durée universelle qui manque.

Le projet RDAP Extensions formule lui-même la limite : comme aucun lien n’unit nécessairement client et serveur, il est impossible d’établir absolument qu’un changement cassant n’affectera aucun client. La phrase interdit surtout la fausse certitude. Elle n’accorde pas à un client inconnu un veto perpétuel.

Mesurer sans construire un fichier des lecteurs

Un opérateur peut compter les requêtes explicites pour une ancienne version, comparer la période avant et après le changement de défaut, tester les redirections et contacter les clients qu’il administre. Ces observations réduisent l’incertitude. Elles ne couvrent pas les outils dormants, les intermédiaires ni les usages qui acceptent silencieusement le défaut.

La collecte peut elle-même devenir disproportionnée. Des journaux durables liant adresses, noms recherchés, signatures logicielles et versions demandées transformeraient une opération de compatibilité en instrument de traçage. Le bon indicateur est agrégé, limité dans le temps et décrit avec ses exclusions. « Aucune demande ancienne observée sur ces serveurs pendant cette période » reste utile. « Aucun client ne dépend plus de l’extension » dépasse la preuve.

Le reçu de retrait

Le premier volet du reçu identifierait l’extension exacte, le demandeur compétent, la décision enregistrée par IANA et sa date. Le deuxième décrirait le prédécesseur, le successeur, les incompatibilités, les éléments retirés et la spécification stable. Un suffixe numérique ne suffirait jamais comme preuve de filiation.

Le troisième volet serait propre à chaque service : instantané daté de /help, changement du défaut, début et fin annoncés, version effectivement renvoyée, comportement d’erreur, règle de retour arrière et observation du retrait. Le plan et le fait auraient deux champs différents.

Le quatrième volet publierait une mesure de la demande : fenêtre, serveurs couverts, granularité, protections de vie privée, fréquence des anciennes versions, clients gérés contactés et dépendances à fort impact encore ouvertes. L’inconnu resterait une valeur recevable.

Enfin, la décision de supprimer préciserait son auteur, la date de clôture des preuves et les exceptions. Le reçu relierait les incidents ultérieurs sans prétendre que leur absence prouve une réussite totale. Ainsi, IANA, l’opérateur et le client pourraient coordonner leurs actes sans que l’un se présente comme le mandataire des deux autres.

Sources