Résumé

  • Le 13 septembre 2026, un brouillon individuel sur les évaluations de fiabilité dans RDAP a atteint la révision 03. Ce n’est ni un texte adopté par REGEXT ni un RFC.
  • La demande portant sur reliabilityAssessment cite désormais une spécification indépendante dont l’auteur s’engage à figer les octets.
  • Le registre IANA consulté ne contient pas encore cet identifiant. La demande publiée ne prouve ni réception d’un dossier ni approbation des experts.
  • Une référence technique précise peut faciliter l’interopérabilité sans décider de la confiance à accorder aux évaluations.

Changer le fondement, pas le message

Pour deux développeurs, donner le même sens au nom d’une extension est indispensable. Pour une communauté de normalisation, décider de prendre en charge ce travail est une autre question. La nouvelle révision de RDAP Extension for Structured Reliability Assessment Metadata organise concrètement leur séparation.

L’extension proposée transporte, dans les réponses RDAP, des évaluations de bureaux d’enregistrement et de noms de domaine. Selon son annexe de changements, la révision 03 ne touche ni au modèle, ni à l’identifiant, ni au nom du membre JSON, ni au format transmis. La nouveauté essentielle se trouve dans la référence jointe à la demande d’enregistrement.

La révision 02 envisageait d’attendre la publication d’un RFC. La révision 03 explique que cette attente traduisait l’absence d’une référence stable. Les auteurs ont désormais publié bcsec-RDAP-RA Version 1 et demandent l’enregistrement sur cette base. Ils disent avoir rempli la condition manquante, non l’avoir écartée.

Il faut conserver le conditionnel institutionnel. La liste IANA vérifiée pour cet article ne comporte pas reliabilityAssessment. Une demande inscrite dans un document n’atteste pas que l’administration l’a reçue ou que les experts l’ont approuvée. Le suivi officiel reste celui d’un Internet-Draft individuel actif.

Une voie extérieure aux RFC existe

La politique du registre, Specification Required, exige un examen et une approbation par un expert désigné ainsi qu’une spécification publique durable suffisamment précise pour permettre des implémentations indépendantes compatibles. RFC 8126 juge le RFC idéal, mais prévoit expressément la publication en dehors de cette filière.

RFC 7480 définit le registre et son formulaire. Le brouillon de groupe sur les extensions RDAP propose de préciser les exigences de stabilité et la conduite de l’examen. Il ne faut pas présenter ces dispositions en cours d’élaboration comme un remplacement déjà définitif du RFC.

L’examen des experts n’est donc pas une simple formalité de réservation. Mais une éventuelle inscription ne constituerait pas davantage un vote de consensus IETF. Le texte indépendant dit explicitement que REGEXT peut ne pas adopter ce travail. Bertoldi Cybersecurity le publie seul, tout en attribuant la conception technique commune avec Simon Pietro Romano au brouillon individuel.

Deux textes, deux régimes de correction

La spécification indépendante promet que le contenu servi à son adresse canonique restera inchangé, même pour une correction rédactionnelle. Une erreur doit être signalée dans un document d’errata distinct, sans portée normative. Une correction affectant l’interopérabilité appelle une nouvelle spécification à une autre adresse. Un miroir est annoncé, mais la référence canonique prime en cas de désaccord.

C’est un engagement du publieur, pas une disponibilité éternelle démontrée par notre téléchargement. Son intérêt est de rendre impossible, dans le régime annoncé, la correction silencieuse du texte auquel une implémentation s’est attachée.

L’annexe C affirme que le modèle de données est identique à celui du brouillon et décrit néanmoins plusieurs différences éditoriales et procédurales. Les références à des travaux provisoires deviennent informatives ou leurs règles utiles sont reformulées. Les invitations à débattre disparaissent ou changent de forme. La publication indépendante ne demande pas l’enregistrement d’un type de valeurs dans RDAP JSON Values ; le brouillon poursuit cette démarche séparément.

Si un RFC voit le jour, le demandeur prévoit de faire remplacer la référence du registre par ce RFC. Cela nécessitera une nouvelle démarche observable. Cela ne prouvera pas que les logiciels installés ont changé. Et le nom de l’extension continuera de désigner un canal pour des résultats, pas une méthode de notation, un seuil d’action ou une autorité sur les parties évaluées.

Sources