Résumé

  • Le 17 août 2026, l’IESG a approuvé draft-ietf-regext-ext-registry-epp-10 en vue d’une publication comme meilleure pratique actuelle. Le texte améliore l’enregistrement, l’examen et la maintenance des extensions EPP, sans transformer le catalogue de l’IANA en matrice universelle de compatibilité.
  • Le statut Active atteste une mise en œuvre et un usage dans au moins une paire registre–bureau d’enregistrement ou serveur–client. Il ne prouve ni l’annonce de l’URI par un serveur donné, ni les droits d’un client, ni l’acceptation d’une transaction.

Une donnée juste, une décision fausse

La scène d’ouverture est un cas hypothétique, non un incident attribué à un opérateur. Elle met en évidence une erreur de catégorie fréquente dans l’automatisation : prendre une preuve de coordination pour une autorisation d’exploitation.

Le registre public répond à des questions durables. Quel est le nom de l’extension ? Où trouver sa spécification stable ? Qui tient l’inscription ? Quel champ de TLD a été déclaré ? Quels renseignements de propriété intellectuelle sont signalés ? L’inscription est-elle active ou inactive ? Ces éléments rendent une extension identifiable et réduisent les collisions de noms.

Le serveur, lui, décrit son état présent. Son message d’accueil annonce les versions, les langues, les URI d’objets et, facultativement, les URI d’extensions qu’il accepte de négocier. Une connexion réussie fixe ensuite l’identité, les privilèges et la sélection de services pour la session. La réponse à une commande tranche enfin un cas précis sous la politique locale du moment.

Ces preuves sont complémentaires, jamais interchangeables. Une inscription peut être parfaitement tenue alors qu’un serveur n’offre pas l’extension. Un serveur peut l’annoncer mais la refuser à un compte. Une session peut la négocier sans que chaque opération devienne licite.

Ce que change réellement la décision de l’IESG

Le 17 août, l’IESG a approuvé la version 10 de « Extension Registry for the Extensible Provisioning Protocol » comme Best Current Practice. Le document reste un Internet-Draft jusqu’à sa publication par le RFC Editor et doit rendre obsolète la RFC 7451.

Le changement est institutionnel autant que rédactionnel. Le statut visé passe d’Informational à BCP. La discussion publique quitte l’ancienne liste eppext pour REGEXT. Une future demande ne pourra plus citer un Internet-Draft comme spécification permanente et le mécanisme d’allocation anticipée de la RFC 7120 ne s’applique pas. La référence doit être stable, aisément accessible et disponible en anglais dans le registre, même si d’autres versions linguistiques existent.

La politique demeure Specification Required au sens de la RFC 8126. L’IANA transmet la demande à des experts désignés. Ceux-ci examinent l’architecture ainsi que la documentation relative à la sécurité et à la vie privée. Un expert en conflit d’intérêts doit se récuser ; la liste publique conserve la discussion visible.

Le texte consolide aussi la discipline des URI. Schémas XML, URI de schéma et espaces de noms doivent être corrects et inscrits dans le registre XML de l’IETF. Les espaces réservés à l’IETF ne peuvent servir à une spécification propriétaire ou publiée dans un autre flux. L’inscription gagne donc en traçabilité et en possibilité d’implémentation. Elle ne devient pas pour autant un audit du parc de serveurs.

Active désigne une preuve bornée

Une fiche contient le nom, le statut documentaire, la référence, le déclarant, le champ TLD, les informations IPR, le statut et des notes. Lorsqu’une spécification n’est pas une RFC, son statut documentaire devient Other, afin de ne pas lui attribuer à tort la portée précise d’une RFC Informational.

Active signifie que l’extension est actuellement implémentée et utilisée. Inactive couvre l’absence de mise en œuvre ou d’usage et peut aussi s’appliquer lorsque la spécification citée n’est plus disponible. Ces valeurs ont donc un contenu réel.

Leur portée reste limitée. Les experts sont invités à être ouverts dès qu’une extension est déployée dans au moins une paire registre–bureau ou serveur–client. Ce minimum suffit à établir une réalité opérationnelle pour l’inscription. Il ne généralise pas cette réalité à tous les serveurs, tous les comptes ni tous les TLD.

Le champ TLD demande la même prudence. Une valeur nommée indique le périmètre déclaré. Any signifie que l’extension n’est pas liée à un TLD unique ; N/A, qu’elle ne concerne pas le traitement des noms de domaine. Any ne signifie ni obligatoire ni disponible partout.

Une interface fiable doit donc conserver la portée de la preuve, pas seulement afficher deux voyants « inscrit » et « actif ». Sans cette nuance, une donnée publique exacte devient le déclencheur d’un comportement mondial injustifié.

Le chevauchement est visible, pas supprimé

EPP associe un noyau réduit à des points d’extension parce que les registres suivent des politiques et des modèles économiques différents. Plusieurs extensions peuvent ainsi traiter des fonctions voisines. La RFC 7451 cherchait notamment à rendre ces doublons découvrables.

La nouvelle pratique ne feint pas de les éliminer. Pour une proposition non déployée, les experts peuvent demander un réexamen si une extension similaire existe déjà. Mais la ressemblance seule n’est pas un motif de refus lorsque les autres critères sont satisfaits. Une extension déjà utilisée par une paire serveur–client doit recevoir un examen pragmatique.

Cette permissivité ne crée aucune substituabilité. Deux mécanismes d’éligibilité, de tarification ou de noms internationalisés peuvent employer des URI, des données et des politiques différentes. Le client doit suivre l’URI exacte annoncée et la spécification attachée à cette URI, non une étiquette fonctionnelle approximative.

L’autorité opérationnelle commence à l’accueil

La RFC 5730 définit le message d’accueil EPP. Son menu de services liste les versions et langues prises en charge, les espaces de noms d’objets administrables et, s’il y en a, les espaces de noms d’extensions. Le serveur peut également limiter les privilèges de gestion selon le client.

Le client envoie ensuite une connexion dont la version et la langue doivent correspondre, en indiquant les URI d’objets et d’extensions retenues. Une connexion réussie ouvre une session qui préserve l’identité et le contexte d’autorisation.

Même alors, aucune commande future n’est garantie. Les codes de résultat distinguent une interdiction de politique locale, une dépendance d’objet, une valeur invalide selon la politique du serveur, un service non implémenté, une violation de gestion des données ou une panne transitoire ou définitive. Un unique booléen « pris en charge » efface précisément les différences nécessaires au contrôle.

La chaîne utile est donc : spécification inscrite ; statut actuel ; accueil du serveur cible ; négociation réussie pour le client exact ; forme de commande acceptée ; transaction réussie ; état final de l’objet vérifié. Chaque marche répond à une question plus étroite que la précédente.

Le registre courant n’est pas une mémoire historique

La procédure approuvée prévoit l’insertion, la modification, la désactivation et la suppression. La suppression d’une inscription issue du consensus IETF exige l’accord de l’IESG. Pour les autres, une demande du déclarant, examinée avec les experts, ou une approbation de l’IESG peut suffire. Un expert peut corriger les coordonnées lorsque le responsable disparaît.

Une entrée peut passer d’Active à Inactive, notamment si sa référence devient durablement inaccessible. Ces mécanismes protègent la qualité de la vue présente. Mais le texte souligne que le registre ne conserve pas d’historique et qu’une fiche supprimée n’y est plus traçable.

Les opérateurs doivent donc archiver leurs propres observations datées : copie ou empreinte de la spécification, état de la fiche, accueil reçu, choix de session et décision de migration. Sinon, la preuve qui justifiait une intégration peut disparaître alors que le code dépendant demeure.

La répartition des responsabilités est nette. L’IANA et les experts maintiennent un espace de coordination public. Le serveur décide ce qu’il annonce et applique. Le bureau d’enregistrement décide ce que ses clients négocient. Aucun acteur ne devrait certifier à la place d’un autre.

Sources