Résumé

  • La RFC 8334 distingue l’enregistrement de lancement de la demande de lancement. Dans le second modèle, le serveur peut accepter plusieurs demandes pour un même nom et répondre 1001 avec applicationID et pendingCreate sans avoir attribué le domaine.
  • La réussite porte sur la commande et sur la création d’un objet de demande. Elle ne prouve ni priorité de marque, ni attribution, ni publication au registre, ni délégation DNS, ni fonctionnement d’un service.
  • Une preuve exploitable conserve les identifiants de transaction, la phase et sa politique, l’historique ordonné des états et des messages poll, puis le domain:panData final. Elle vérifie ensuite l’objet domaine et le DNS sur des plans séparés.

Dans les systèmes administratifs, un numéro inspire confiance. Il rend une demande retrouvable, permet de rappeler un dossier et montre qu’un guichet l’a prise en charge. Mais sa force est exactement celle-là. Le numéro ne dit pas encore qui obtiendra le bien demandé.

La RFC 8334 transforme cette nuance en protocole. Publiée sur la voie des normes de l’IETF en mars 2018, elle est l’œuvre commune de J. Gould, W. Tan et G. Brown. Le registre IANA des extensions EPP la référence comme spécification de la phase de lancement. Le rôle de Gavin Brown est ici celui d’un coauteur, non celui d’un arbitre des marques, d’un exploitant de registre ou du propriétaire d’une décision d’attribution.

La fiche IETF conservée le 31 août 2026 apporte le contexte humain : vingt-cinq ans dans le DNS et les noms de domaine, vingt-deux ans chez Team Internet PLC, auparavant CentralNic, dont quatorze comme directeur technique, puis un poste chez ICANN. Elle recense quatre RFC, dont la RFC 8334, et des fonctions publiques telles que la présidence des travaux RESTful Provisioning Protocol et la revue ARTART. Ces faits datés éclairent une compétence ; ils ne lui transfèrent le mandat d’aucun registre.

Le dossier et le domaine ne sont pas le même objet

La RFC nomme deux modèles. Un Launch Registration est un enregistrement unique réalisé pendant une phase de lancement selon un modèle de type premier arrivé, premier servi. Un Launch Application exprime l’intention d’enregistrer. Dans ce second cas, le serveur peut recevoir plusieurs demandes portant sur le même domaine, puis en choisir une à attribuer.

Cette possibilité n’est pas une règle universelle. Tous les lancements n’acceptent pas plusieurs candidats ; tous les serveurs ne prennent pas en charge les demandes de lancement ; toutes les phases ne suivent pas le même ordre. Le protocole décrit comment exprimer le modèle choisi. La politique du serveur décide de l’utiliser.

Quand une commande valide crée une demande, la RFC impose trois résultats : créer l’objet de demande, lui attribuer un identifiant et placer l’objet domaine EPP dans l’état pendingCreate. Le serveur retourne l’applicationID, qui permet de distinguer plusieurs dossiers concernant le même nom.

Il s’est donc bien passé quelque chose. La commande n’est pas « presque réussie » : elle a été acceptée et un état durable existe. Mais cet état est celui d’une demande. L’identifiant désigne la demande. pendingCreate annonce que l’action n’est pas terminée. Substituer le mot domaine au mot demande change le sujet de la preuve.

Cette substitution peut contaminer toute une organisation. Un message client annonce « votre domaine a été créé ». La comptabilité déclenche un revenu sur l’événement de soumission. Une équipe DNS cherche une délégation qui ne peut pas encore exister. Un audit mesure le délai depuis le mauvais départ. Le remède consiste à nommer l’objet dans chaque événement : demande acceptée, demande validée, demande attribuée, objet domaine créé, délégation publiée.

Le code 1001 contient deux temps

Le cœur EPP de la RFC 5730 définit le résultat 1001 : la commande s’est terminée avec succès, l’action reste en attente. La réponse conserve l’identifiant de transaction du client lorsqu’il est fourni et ajoute celui du serveur. La RFC 8334 illustre ce résultat avec la phase et l’identifiant de demande.

Le reçu prouve donc une phrase limitée : tel serveur a accepté et enregistré telle opération de demande, pour tel client commanditaire, dans telle phase, à tel moment. Il faut y joindre le nom demandé, la sous-phase éventuelle, la forme de commande, l’état EPP et l’état de lancement.

Il ne prouve pas que le candidat a acquis un droit. Il ne prouve pas que la validation est achevée. Il ne départage pas des demandes concurrentes. Il ne crée pas silencieusement l’objet de domaine stable de la RFC 5731. Il ne publie rien dans RDAP, n’ajoute aucune délégation à la zone parente et ne met aucun service en ligne.

La séparation relève de l’agence. Le bureau d’enregistrement soumet ; un validateur peut évaluer une marque ou un avis ; le registre applique ses règles ; un système de publication expose des données ; l’opérateur de zone publie la délégation ; les serveurs faisant autorité répondent ; l’exploitant du service configure son application. La réussite du premier verbe n’hérite pas des pouvoirs attachés aux suivants.

Une phase n’est pas sa politique

La RFC définit notamment les phases sunrise, landrush, claims, open et custom. Le client doit indiquer la phase. Le serveur devrait la vérifier et peut vérifier une sous-phase. Des phases peuvent se chevaucher, et un attribut de nom permet de préciser une sous-phase ou une phase personnalisée.

Ces valeurs sont essentielles pour retrouver le contexte, mais elles ne contiennent pas toutes les règles. Deux registres peuvent employer sunrise avec des calendriers, validateurs, frais, critères d’éligibilité et méthodes d’arbitrage différents. La RFC laisse volontairement une partie de la politique hors bande.

Il faut donc geler, avec la transaction, la version de la politique et sa période d’effet. Sans elle, une phase ne permet pas de savoir quel document de marque était exigé, si plusieurs demandes étaient admises, quelle transition devait se produire ou quand la décision finale devait être rendue.

La RFC 7848 décrit les objets de marque et de marque signée utilisés par les mécanismes associés. Selon la phase et la forme, la RFC 8334 peut transporter une marque, une marque signée, un code de validation ou un avis. Ces éléments fournissent une provenance. Ils ne sont pas un titre automatique sur le domaine.

Une marque signée valide peut soutenir une étape de validation. L’accusé d’un avis peut prouver qu’une information a été présentée. L’identifiant du validateur peut préciser qui a fourni le résultat. C’est encore au registre d’appliquer sa politique d’attribution. Inversement, l’auditeur ne peut pas déclarer un champ manquant tant qu’il n’a pas établi que la phase et la forme actives l’imposaient.

pendingCreate doit rester une chronologie

Les états de lancement comprennent pendingValidation, validated, invalid, pendingAllocation, allocated, rejected et custom. Quand un état de lancement non final est employé, l’objet conserve pendingCreate. La RFC autorise l’omission de certaines étapes : l’ordre exact dépend de la politique.

Une colonne contenant le dernier état ne suffit donc pas. Elle ne dit pas si la validation a eu lieu, si une étape a été normalement sautée, quel événement a informé le client ou combien de temps la demande est restée dans chaque décision.

La file poll de la RFC 5730 fournit le canal asynchrone. Chaque message a un identifiant ; le client le récupère puis l’acquitte. La RFC 8334 recommande ces messages pour les changements intermédiaires. Pour les résultats finaux allocated et rejected, le serveur doit insérer le message domain:panData défini par la RFC 5731.

Le dossier de preuve conserve l’ordre, l’identifiant du message, sa mise en file, sa réception, son acquittement, l’état, l’applicationID et les identifiants de transaction. allocated établit que cette demande a été choisie et qu’un objet domaine peut résulter de l’action. rejected établit qu’elle ne devient pas cet enregistrement. Le silence n’établit aucun des deux.

Cette prudence est d’autant plus importante que les demandes peuvent être confidentielles. La RFC exige le résultat 2201 pour les opérations non autorisées et permet une information filtrée selon la politique. L’absence dans une vue publique ne prouve pas l’absence d’une demande. Elle peut seulement décrire la limite d’observation de cette vue.

Après l’attribution, d’autres horloges démarrent

Même un panData final annonçant allocated ne prouve pas que le monde entier peut déjà utiliser le domaine. Il faut lire l’objet domaine de la RFC 5731. Puis vérifier séparément la projection publique ou RDAP, la présence de la délégation dans la zone parente, les réponses des serveurs faisant autorité et la disponibilité du service.

Chaque plan a son propriétaire et son délai. Une attribution sans objet domaine signale un problème de provisioning du registre. Un objet domaine sans délégation oriente vers la publication de zone ou la configuration du titulaire. Une délégation sans réponse faisant autorité vise l’hébergement DNS. Un DNS correct sans service relève de l’application ou du réseau.

La primauté du code en fonctionnement ne demande pas de mépriser le registre. Elle demande de ne faire témoigner chaque système que sur ce qu’il observe. EPP prouve l’état EPP. Le registre prouve son objet. RDAP prouve ce qu’il publie. Le DNS prouve une réponse à une heure et depuis un point d’observation. Une connexion prouve une tentative de service. Aucun de ces reçus n’est le remplaçant des autres.

Le faisceau minimal de preuves

Pour raconter correctement une demande de lancement, il faut pouvoir joindre :

  1. les identifiants de transaction client et serveur, l’heure, le client commanditaire, le domaine et le résultat ;
  2. la phase, la sous-phase, la forme de commande, la version de politique et sa période d’effet ;
  3. l’applicationID, pendingCreate, l’état de lancement initial et les droits de consultation ;
  4. le validateur, la marque, la marque signée, le code ou l’avis uniquement quand la politique applicable l’exige ;
  5. les états et messages poll dans l’ordre, avec réception, acquittement, étapes sautées et exceptions ;
  6. le domain:panData final allocated ou rejected ;
  7. l’objet domaine résultant, s’il y a attribution ;
  8. la publication registre/RDAP, la zone, le DNS faisant autorité et le service comme observations datées distinctes ;
  9. la base de confidentialité, le filtrage, les lecteurs autorisés, la conservation et le responsable d’audit.

Cette chaîne protège le demandeur autant que le registre. Elle prouve l’acceptation sans la gonfler en attribution. Elle permet au validateur de montrer son travail sans revendiquer la décision finale. Elle localise une panne sans forcer la divulgation de demandes confidentielles.

La contribution la plus utile de la RFC 8334 est peut-être de donner un nom durable à ce qui n’est pas encore achevé. L’applicationID empêche la demande de disparaître dans un simple « en attente ». Le modèle d’état conserve les décisions suivantes. La gouvernance commence quand l’organisation accepte de garder cet intervalle visible.

Sources