Résumé

  • Le projet appelé à remplacer le RFC 7451 demande aux experts désignés une appréciation permissive dès lors qu’une extension EPP a été mise en œuvre et déployée par au moins un couple registre/bureau d’enregistrement, ou serveur/client. Il autorise aussi l’inscription de plusieurs extensions aux fonctions identiques ou proches.
  • Cette inscription garantit un identifiant repérable, une spécification durable et un examen attribuable. Elle ne choisit pas le meilleur mécanisme, ne confère pas le statut Standards Track, ne mesure pas l’adoption et ne prouve aucune compatibilité locale.
  • Le registre IANA expose déjà ce pluralisme : ses notes décrivent les extensions IDN et de confidentialité de CORE comme syntaxiquement et fonctionnellement identiques à celles de TANGO, mais placées dans des espaces de noms XML différents. Il faut donc cartographier la coexistence plutôt que fabriquer un classement.

Un responsable d’exploitation qui consulte le registre des extensions EPP cherche souvent une réponse binaire : cette extension est-elle la bonne ? La présentation en tableau encourage ce réflexe. Une ligne est active, elle renvoie vers un document et porte un nom stable ; elle paraît avoir franchi une sélection comparable à une certification.

Or le registre ne tranche pas une compétition. Il organise un espace de noms dans lequel des registres de domaine, des bureaux d’enregistrement et leurs fournisseurs ont déjà pris des décisions. Son utilité tient précisément à sa capacité de conserver ces décisions côte à côte, y compris lorsque leurs fonctions se recouvrent.

La révision 10 de draft-ietf-regext-ext-registry-epp, datée du 17 août 2026, formule cette limite sans détour. Une demande satisfaisant aux autres critères ne devrait pas être refusée au seul motif qu’une extension similaire existe. Les experts sont invités à se montrer permissifs si un couple registre/bureau d’enregistrement ou serveur/client l’a effectivement déployée. L’existence opérationnelle suffit à ouvrir la porte ; elle ne clôt pas le débat sur le choix collectif.

Le seuil d’entrée ne mesure pas la domination

EPP est un protocole de dialogue. Une fonction ne devient opérante que si un serveur la propose et qu’un client sait l’employer. Exiger au moins un couple déployé évite de réserver durablement une portion de l’espace de noms à une simple idée. C’est une preuve d’existence utile et proportionnée.

Mais cette unité minimale ne renseigne ni le nombre de domaines concernés, ni le volume de commandes, ni la diversité des logiciels. Elle n’indique pas si tous les bureaux accrédités auprès d’un registre disposent de la fonction, si plusieurs versions cohabitent, ou si les champs optionnels sont compris de la même façon. Une démonstration entre deux parties ne devient pas, par le seul effet de l’inscription, une pratique de secteur.

Le mot « Active » demande la même prudence. Dans le projet, une extension active est mise en œuvre et utilisée ; une extension inactive ne l’est pas, ou sa spécification n’est plus disponible. Ces états sont des repères de cycle de vie. Ils ne constituent ni une mesure d’audience ni un engagement de support. La colonne des TLD peut préciser le périmètre déclaré, mais elle ne remplace pas une matrice recensant versions de serveurs, clients, modes optionnels et dates de déploiement.

Le statut documentaire est encore un autre axe. Le registre rassemble des références Standards Track et des documents classés « Other ». Cette proximité visuelle n’élève pas une spécification privée au rang de norme IETF. À l’inverse, un document extérieur au Standards Track peut porter une dépendance critique pour des opérateurs. Statut institutionnel, déploiement et nécessité opérationnelle doivent rester trois constats distincts.

« Specification Required » protège la lisibilité

La politique « Specification Required » du RFC 8126 impose une référence permanente et publiquement accessible, examinée par des experts désignés. Le nouveau projet accepte les RFC et des spécifications propriétaires réellement disponibles, avec une version anglaise. Il écarte l’Internet-Draft comme référence permanente pour une inscription future et précise que l’allocation anticipée du RFC 7120 n’est pas une voie de contournement.

Cette discipline répond à un problème de mémoire. Un espace de noms public ne vaut que si l’on peut retrouver la signification promise par un identifiant. Le registre recueille ainsi le nom, le statut du document, la référence, le déclarant, les TLD, les informations de propriété intellectuelle, l’état actif ou inactif et des notes.

L’examen ne se limite pas à vérifier qu’une case est remplie. Il porte sur la solidité architecturale, le traitement de la vie privée, la syntaxe et la sémantique des URI, ainsi que l’usage approprié des espaces de noms XML IETF ou non-IETF. Un expert principal instruit normalement la demande. En cas d’indisponibilité, le groupe de suppléants statue par consensus à la majorité simple. Tout expert percevant un conflit doit se récuser. La liste REGEXT peut accueillir la discussion publique.

Ce mécanisme produit une responsabilité procédurale, non une médaille. Les experts peuvent exiger qu’une extension soit compréhensible et traçable. Ils ne sont pas chargés de départager l’élégance des architectures, les parts de marché ou les stratégies commerciales. L’inscription répond à « de quel mécanisme parle-t-on ? », pas à « lequel tout le monde devrait-il choisir ? ».

Le texte qui réorganise cette procédure demeure lui-même provisoire. Il s’agit d’un Internet-Draft actif, destiné à devenir un Best Current Practice, transmis à l’IESG et placé dans la file du RFC Editor dans l’attente de l’affectation d’un éditeur. S’il est approuvé et publié, il rendra le RFC 7451 obsolète. Présenter dès aujourd’hui ses règles comme celles d’un RFC publié effacerait une incertitude que le registre est précisément censé rendre visible.

CORE et TANGO montrent la réalité du chevauchement

Le registre IANA, mis à jour le 4 septembre 2026, contient un exemple plus parlant que toute hypothèse. Pour la gestion des noms de domaine internationalisés, une note indique que l’extension de CORE est syntaxiquement et fonctionnellement identique à son équivalent TANGO, tout en utilisant un autre espace de noms XML. Une note analogue accompagne leurs extensions de confidentialité.

Il serait tentant d’en conclure qu’un simple alias suffit. Pourtant l’espace de noms appartient à l’identité sur le fil. Un client qui construit des éléments XML dans un espace ne parle pas automatiquement l’autre. Un serveur peut accepter CORE, TANGO, les deux, ou aucun. Des outils de test, des politiques et des calendriers de maintenance peuvent différer même si les schémas partagent aujourd’hui leur fonction.

La note établit une relation documentée entre les conceptions. Elle ne promet pas que chaque opération, code d’erreur, champ optionnel et version future restera substituable. Elle ne révèle pas non plus pourquoi les deux lignées existent : séquence historique, communautés séparées, gouvernance du changement, contraintes contractuelles ou coût d’une coordination antérieure.

Conserver les deux lignes protège cette histoire technique. Supprimer l’une pour obtenir un tableau plus net rendrait les anciens journaux et logiciels plus difficiles à interpréter. La pluralité du registre ne prouve donc pas un échec de normalisation ; elle peut être la condition d’une migration responsable.

Une carte de coexistence pour décider

Le tableau IANA reste la source canonique de l’inscription. L’exploitant a toutefois besoin d’une vue complémentaire : une carte de coexistence. Ce nom désigne ici un outil d’analyse proposé par l’auteur, et non une exigence de l’IETF ou de l’IANA.

Cette carte commencerait par regrouper les extensions selon leur fonction durable — IDN, confidentialité, lancement, tarification ou autre — sans fusionner leurs identités. Elle conserverait ensuite l’espace de noms XML, la version de spécification et les surfaces de commande ou de réponse. Elle noterait la provenance de l’inscription : document permanent, statut, déclarant, date et chemin d’expertise.

Le déploiement aurait sa propre colonne, avec les parties qui l’attestent, les versions, les TLD et la date. « Un couple » resterait écrit « un couple ». Une autre colonne décrirait l’origine de la similarité : affirmation des déclarants, note IANA, comparaison de schémas, essai de conformité ou observation en production. Le degré de preuve ne devrait jamais être absorbé par le mot « identique ».

Enfin, la carte recenserait le support réel des clients et serveurs, les éventuelles passerelles entre espaces de noms, leurs pertes connues et l’historique des états. Elle permettrait de lire séparément quatre propositions trop souvent confondues : l’extension est inscrite ; elle a été déployée quelque part ; elle est prise en charge ici ; elle est interchangeable avec telle autre dans ce contexte.

Le retrait peut détruire une preuve

Le projet détaille l’ajout, la modification, la désactivation et le retrait. Un changement d’état doit être motivé. Le retrait d’une entrée issue du consensus IETF requiert l’accord de l’IESG. Pour une entrée non-IETF, l’IESG ou le déclarant d’origine, en relation avec les experts, peut demander retrait ou désactivation.

La distinction est lourde de conséquences, car le projet reconnaît que le registre ne possède pas de mécanisme d’historique. Une entrée supprimée n’y est plus traçable. L’état inactif avertit contre un nouveau déploiement tout en laissant une coordonnée aux systèmes anciens ; le retrait fait disparaître cette coordonnée de la vue courante.

Un journal EPP conservé pendant des années peut encore contenir l’espace de noms retiré. Un contrat ou un banc d’essai peut le citer. Sans copie datée du registre et sans spécification accessible, l’incident futur devient presque impossible à reconstituer. La gestion de cycle de vie n’est donc pas un simple nettoyage de catalogue. Elle décide quelles preuves resteront disponibles.

Sources