Résumé

  • Dans la révision 04 du projet EPP sur HTTPS, un statut HTTP 200 accompagne toute réponse EPP produite après traitement, que la commande ait réussi ou échoué.
  • Sans réponse EPP valide, une requête qui a peut-être atteint la couche de traitement n’est pas « échouée » : son issue est indéterminée et doit rester bloquante pour la suite de la session.
  • La bonne pièce de gouvernance est une fiche de disposition reliant commande complète, identifiants de transaction, tentative HTTP, preuve d’application, décision de reprise et réconciliation finale.

Dans une salle d’exploitation, la couleur verte a une force politique. Elle ferme une alerte, fait baisser un compteur et autorise l’équipe suivante à avancer. Pour HTTP, la classe 2xx nourrit naturellement cette couleur. Mais le 200 renvoyé par un transport EPP sur HTTPS n’a pas le pouvoir qu’un tableau de bord risque de lui attribuer.

La révision 04 de draft-ietf-regext-epp-https, datée du 3 septembre 2026, décrit un tunnel. La requête HTTP transporte une commande du protocole EPP ; la réponse HTTP transporte la réponse EPP. Dès que la commande a atteint la couche EPP et qu’une réponse applicative a été produite, le serveur doit utiliser HTTP 200, même si le code EPP signifie un refus. Le succès du contenant ne préjuge pas du jugement contenu.

L’autre erreur serait symétrique. Une passerelle peut répondre sur surcharge, limite de débit, format non pris en charge ou panne en amont. Ce résultat appartient à HTTP. Il ne démontre pas nécessairement que la couche EPP n’a rien exécuté. Si le client ne reçoit aucune réponse EPP valide et que la commande a pu atteindre le traitement, le texte impose le mot le plus inconfortable et le plus exact : indéterminé.

Le registre n’est pas un service web ordinaire

EPP sert à gérer des objets dans un référentiel central partagé. RFC 5730 organise le protocole autour de sessions, de requêtes en lecture et de transformations telles que création, mise à jour, renouvellement, transfert ou suppression. Les commandes sont atomiques ; elles sont conçues pour pouvoir être rendues idempotentes. La nuance compte : « pouvoir être rendues » ne signifie pas que toute commande, enrichie de n’importe quelle extension, peut être rejouée sans examen.

Le nouveau transport réutilise POST et le port HTTPS 443. Une première requête POST vide établit la connexion EoH seulement si elle reçoit un 200 contenant l’accueil EPP et un identifiant de session HTTP. La session EPP authentifiée ne commence qu’après un login réussi. Ensuite, une requête porte une commande et une réponse porte le résultat correspondant.

Cette architecture permet de réemployer des équilibreurs de charge, pare-feux applicatifs et pratiques de déploiement familières au cloud. Elle introduit aussi une tentation : appliquer les automatismes du web sans comprendre la machine d’états d’EPP. Les auteurs ferment délibérément cette porte pour la mise en cache, le multiplexage et surtout la reprise automatique.

Le cas de l’identifiant de session rend la séparation presque pédagogique. Une commande munie d’un cookie vide ou invalide, si elle parvient néanmoins au traitement EPP, doit recevoir l’erreur EPP 2002 dans une réponse HTTP 200. Deux nombres proches appartiennent à deux alphabets différents. Le premier renseigne l’enveloppe ; le second tranche la commande.

L’indétermination ne doit pas être corrigée par le vocabulaire

Les systèmes d’incident préfèrent « succès » ou « échec ». Une troisième valeur complique les objectifs de service, les rapprochements et les responsabilités. Pourtant, supprimer cette valeur ne supprime pas la réalité qu’elle décrit. Cela déplace seulement l’incertitude vers quelqu’un qui la découvrira plus tard.

Une issue indéterminée établit une limite de connaissance. Le client n’a pas reçu de réponse EPP faisant autorité. Il ne peut pas exclure que le serveur ait commencé ou achevé le traitement. Il ne doit donc ni célébrer l’opération, ni la rejeter, ni envoyer mécaniquement la suivante. Ce statut ne dit rien d’une panne particulière et n’accuse aucun opérateur. Il protège le raisonnement contre une conclusion excédant les traces disponibles.

La distinction devient essentielle pour les transformations. Après une lecture perdue, une nouvelle lecture est souvent facile à raisonner. Après une opération susceptible de modifier un objet partagé, une seconde commande peut ajouter un effet, rencontrer un nouvel état ou produire une erreur qui ne révèle pas le sort de la première. Une interrogation ultérieure peut montrer l’état présent sans prouver quel essai l’a causé.

La reprise est une décision EPP

RFC 9110 ne classe pas POST parmi les méthodes idempotentes. Il autorise un client à le répéter s’il sait, par conception ou configuration, que la sémantique réelle le permet ; il interdit au mandataire de reprendre automatiquement une requête non idempotente. La révision 04 transpose cette prudence à l’intérieur du tunnel.

Un client EoH ne peut retenter que si trois conditions sont réunies : la défaillance paraît transitoire, la sémantique du statut HTTP reçu autorise une nouvelle tentative, et le client sait que la commande EPP complète, extensions incluses, a une sémantique applicative idempotente. Il faut renvoyer exactement la même commande, avec le même identifiant de transaction client s’il existait. Aucune commande ultérieure ne doit partir avant une réponse valide ou l’abandon de la session.

Cette attribution du pouvoir est saine. Une passerelle connaît le trajet ; le client EPP connaît l’intention, les extensions et l’ordre. Un maillage de services qui répète un POST après délai dépassé ne fournit pas une disponibilité neutre. Il prend une décision sur un objet de registre sans posséder les informations requises pour en mesurer l’effet. Le projet exige donc que les opérateurs désactivent cette reprise dans les intermédiaires qu’ils contrôlent.

clTRID corrèle, il ne promet pas à lui seul une déduplication

RFC 5730 permet au client de joindre un clTRID unique dans son propre espace d’identifiants. La réponse associe ce numéro au svTRID unique produit par le serveur. Ces valeurs protègent l’intégrité de la synchronisation commande-réponse ; les deux parties devraient les journaliser, les conserver et les protéger.

La révision 04 demande qu’une reprise autorisée conserve le même clTRID. C’est indispensable pour relier les tentatives. Ce n’est pas, dans les textes cités, une garantie universelle que tout serveur supprimera une exécution répétée. Un registre peut offrir une propriété plus forte dans son contrat de service ou son implémentation. Il faut alors conserver la version de cette garantie et la preuve qu’elle s’appliquait à la commande et aux extensions concernées. Transformer un identifiant de corrélation en clé d’idempotence implicite serait une politique locale non déclarée.

Un seul ordre explicable

HTTP/2 et HTTP/3 rendent le multiplexage banal. Le projet refuse pourtant plusieurs requêtes en attente pour une même session EPP. Le client doit attendre ; si un intermédiaire fabrique de la concurrence, le serveur doit annoncer s’il rejette ou sérialise. Cette règle ne gaspille pas simplement une optimisation. Elle garde une histoire causale.

Supposons qu’une mise à jour dépende d’une création, ou qu’un transfert change le client autorisé à agir. Si la première commande reste indéterminée et que la deuxième avance, l’état final peut correspondre à plusieurs séquences. L’équipe ne rapproche plus des faits ; elle reconstruit des scénarios. La barrière d’ordre empêche qu’une incertitude unique se transforme en graphe d’incertitudes.

Abandonner la session arrête ce graphe, mais ne clôt pas le dossier. La réconciliation peut demander une trace côté serveur, une réponse retrouvée, une lecture ciblée de l’objet, un échange opérateur à opérateur ou une procédure prévue au contrat. Une nouvelle connexion ne change pas le statut historique de la commande perdue.

La fiche de disposition de commande

Un journal HTTP répond à « quel composant a parlé ? ». Un journal EPP répond à « quelle commande et quel résultat ? ». La gouvernance doit relier les deux sans confondre leurs autorités. Pour chaque commande sortante, une fiche de disposition devrait conserver :

  1. la famille de commande, l’objet visé et l’empreinte canonique du XML complet avec extensions ;
  2. la session EPP, le clTRID et l’identité de chaque tentative HTTP ;
  3. l’instant d’émission et le dernier point où la non-livraison reste démontrable ;
  4. le statut HTTP, son émetteur réel et les événements d’intermédiation ;
  5. le code EPP et le svTRID lorsqu’une réponse valide existe ;
  6. une disposition ternaire — succès établi, échec établi, indéterminé ;
  7. la source exacte de l’analyse d’idempotence, extensions comprises ;
  8. la preuve qu’aucune commande suivante n’a franchi la barrière ;
  9. le responsable et la règle qui ont autorisé reprise, abandon ou rapprochement ;
  10. la preuve finale de clôture, sa date et les divergences qui subsistent.

Il ne s’agit pas d’imposer un logiciel mondial. L’idée de spécification initiale minimale défendue par Lu Heng conduit à exiger un noyau de distinctions et de preuves, puis à laisser chaque relation registre-bureau d’enregistrement choisir sa mécanique. La fiche peut prendre la forme d’un événement signé, d’un dossier d’incident ou d’une jonction protégée entre journaux. Sa fonction est d’empêcher les outils de présenter une hypothèse comme un fait.

Le Policy Mirror pose la question institutionnelle derrière le paramètre : qui gagne le droit de répéter une commande, et qui supporte l’erreur ? Si l’intermédiaire améliore son taux de succès apparent tandis que le titulaire, le bureau d’enregistrement ou le service d’assistance paie le rapprochement, la reprise automatique est déjà une politique de répartition des risques.

Le statut du projet reste une donnée de gouvernance

La révision 04 est un document de travail du groupe REGEXT, destiné au Standards Track. Ce n’est ni un RFC ni une décision achevée de l’IESG. Elle expire le 7 mars 2027 et peut encore changer. Le jalon de septembre 2026 pour soumission est un objectif, pas une preuve de soumission.

Le projet mentionne le SDK de Verisign et une implémentation IIT-CNR/Registro.it. Son propre avertissement issu de RFC 7942 précise que ces informations viennent des contributeurs, ne sont pas vérifiées par l’IETF, n’impliquent aucune approbation et ne constituent pas un catalogue. Elles témoignent d’un travail d’implémentation déclaré ; elles ne prouvent pas une pratique uniforme des reprises, des extensions ou de la réconciliation.

Enfin, le texte propose une entrée dans le registre IANA des extensions EPP. Une proposition n’est pas encore l’entrée active qu’elle décrit. La précision attendue du traitement des commandes commence par la précision avec laquelle on décrit l’autorité du document.

Sources

  1. IETF — EPP Transport over HTTPS, révision 04
  2. Datatracker — état du projet
  3. Datatracker — historique
  4. Groupe de travail REGEXT
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — correspondance des noms de domaine EPP
  7. RFC 5734 — transport EPP sur TCP
  8. RFC 9110 — sémantique HTTP
  9. RFC 7942 — visibilité du code en fonctionnement
  10. IANA — Extensions for EPP
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror