Résumé

  • Le projet individuel draft-gould-regext-epp-server-validation-00 fournit un conteneur commun aux validations synchrones, asynchrones et planifiées, mais le type de contrôle relève de la politique du serveur.
  • success décrit seulement le dernier résultat. La date, l’opération déclenchante, l’historique des transitions et les raisons d’échec restent facultatifs.
  • Un reçu d’état doit fixer définition, version, point d’observation, données, temps, destinataire, identifiant poll, accusé de réception et preuve de correction.

Le projet répond à un vrai besoin : faire remonter dans EPP des contrôles effectués par le serveur, par exemple sur la résolution DNS ou DNSSEC. Le résultat peut accompagner une commande de transformation, être demandé avec info, ou arriver plus tard dans la file poll. Une vérification planifiée dont l’état change rejoint également cette file.

Ce vocabulaire commun ne rend pas les contrôles identiques. Le champ type dépend de la politique du serveur ; dns et dnssec ne sont que des exemples. Deux registres peuvent donc écrire le même type tout en choisissant d’autres résolveurs, algorithmes, temporisations ou nouvelles tentatives. Le schéma compare la forme, pas la substance.

Le temps facultatif borne la preuve

La date d’exécution, l’opération, le dernier succès, le premier échec et le dernier échec avant retour au vert sont facultatifs. Les raisons sont elles aussi facultatives, répétables, propres au serveur et éventuellement marquées par langue.

L’absence n’est pas un historique. Sans lastFailed, on ne peut pas conclure que l’objet n’a jamais échoué. Sans lastSuccess, un échec n’est pas nécessairement permanent. Sans date, un succès n’est pas actuel. DNS, signatures, caches et chemins évoluent ; une observation exacte hier peut être inutilisable pour une décision aujourd’hui.

La lecture prudente est « le dernier contrôle du type X effectué par ce serveur a réussi ». « Le domaine est sain » ajoute une continuité, une couverture et une certification absentes du message.

La file poll conserve la livraison, pas le remède

RFC 5730 impose une file par client. Le serveur rend le premier message, son identifiant unique et un compteur. Le client accuse réception ; le serveur retire alors le message et expose le suivant. Ce mécanisme est ordonné et sobre.

Mais l’accusé signifie reçu, non corrigé. Une alerte peut être lue par un automate, acquittée puis perdue avant l’équipe d’exploitation. Une transition planifiée peut attendre derrière d’autres messages. Temps de validation, mise en file, lecture, acquittement et traitement interne sont cinq faits différents.

La sécurité introduit une asymétrie légitime. Le serveur choisit ce qu’il montre au client sponsor ou non sponsor et peut réserver les raisons au sponsor. Deux vues différentes ne sont pas forcément contradictoires ; elles doivent simplement porter l’identité du destinataire et la règle de divulgation.

Le projet couvre création, renouvellement, transfert, mise à jour, certaines suppressions, restauration, opérations automatiques et actions personnalisées. Les commandes ne reçoivent aucun nouvel élément ; la validation apparaît dans la réponse. Le serveur conserve donc la main sur le moment et la définition du contrôle.

Un reçu avant l’acquittement

Le reçu proposé consigne type et version de politique, point d’observation, paramètres, données testées et temps. Il précise le déclencheur ou l’origine planifiée, conserve les transitions disponibles et marque les champs absents comme inconnus.

Il enregistre ensuite objet, classe du destinataire, identifiant et date de file, lecture, acquittement et transfert interne. Enfin, il sépare acquittement, ticket, correction et nouvelle validation. Le texte d’une raison reste utile aux humains sans devenir un code stable inventé.

Le document est un Internet-Draft individuel du 19 juillet 2026. Datatracker dit qu’il n’a ni statut formel, ni flux RFC, ni statut RFC visé, tandis que son en-tête annonce Standards Track. Les demandes d’enregistrement IANA sont futures. Il faut étudier le mécanisme sans l’appeler consensus ou déploiement.

Sources