Summary

  • Le projet RPP core, version 01, daté du 2 novembre 2026, fait correspondre la gestion d'objets partagés, dont les domaines, à HTTP. Le projet sur les objets de données décrit le modèle séparément.
  • Un transfert change le client qui parraine un objet, mais RPP représente ce changement comme un processus doté de son propre cycle de vie. Le nouveau bureau lance POST /domainNames/{name}/processes/transferProcesses. L'exemple de réponse est 201 Created avec une URL de processus dans Location.
  • Le demandeur peut annuler un transfert en attente ; le bureau actuellement responsable peut le rejeter ou l'approuver. Une file de messages durable peut signaler le résultat asynchrone. Lire un message ne suffit pas à l'acquitter.

Le transfert d'un domaine ressemble à une flèche d'un bureau d'enregistrement vers un autre. Dans la fiche RPP core de l'IETF, cette flèche cache plusieurs opérations. La demande crée un objet de processus. Une autre partie peut encore décider. Le registre peut ensuite émettre une notification, et le client doit l'acquitter. Le nom 201 Created décrit l'objet créé dans l'exemple : le processus. Il ne certifie pas encore le nouveau parrain du domaine.

RPP est conçu comme un protocole autonome. Il peut être relié à un système EPP, mais cette passerelle est distincte. Le projet principal définit l'usage des chemins, méthodes, en-têtes et codes HTTP ; les objets et leurs opérations sont décrits dans un autre texte, et le format concret des messages encore ailleurs. Pour un exploitant, la question devant un journal HTTP est donc précise : quel objet cette réponse vient-elle de faire avancer ?

Une URL peut nommer le travail restant

La section 16.9.5 appelle transfert le changement de client parrain. Pour le démarrer, le bureau entrant envoie un POST à la collection transferProcesses du domaine. L'exemple renvoie 201 Created, un code RPP et Location finissant par /transferProcesses/latest. Cette adresse désigne le processus de transfert le plus récent. Le serveur vient de reconnaître la naissance d'une démarche ; il n'a pas, par cette seule réponse, prouvé que la fiche du domaine porte déjà un autre bureau.

Le client peut interroger le processus par GET. Tant que le transfert attend, son initiateur peut l'annuler par DELETE. Le bureau qui parraine actuellement le domaine dispose d'opérations transferReject et transferApprove. Ces verbes attribuent des pouvoirs différents à des acteurs différents. Le bureau entrant ouvre le dossier ; il ne peut transformer sa propre demande en approbation du bureau sortant par un simple changement de chemin. Pour reconstruire l'événement, il faut suivre la demande, l'état du processus, la décision et la fiche finale du domaine.

Le projet encadre également la promesse faite par l'URL. Quand le serveur expose une instance de processus, il doit rendre accessible la dernière sous latest ; il peut ajouter un identifiant persistant. S'il choisit de ne conserver aucune ressource de processus persistante, il doit répondre 200 OK plutôt que 201 Created. Il serait donc imprudent de promettre une URL permanente chez tout registre. Même sans elle, un intégrateur peut exiger la suite des identifiants de transaction, des états et de la lecture finale de l'objet.

La boîte de réception ne se vide pas à l'ouverture

Le projet prévoit aussi une file durable de messages asynchrones. Il cite la fin d'un transfert qui exige l'approbation d'une autre partie. Le client récupère les messages par GET et acquitte un message déterminé par DELETE. Un avis simplement consulté doit rester dans la file tant que cet acquittement n'arrive pas. Cette règle sépare « nous avons vu le résultat » de « nous avons traité le résultat ». Le premier 201 et l'avis de fin ne sont donc pas deux formes du même reçu.

Quand une opération ordinaire crée un processus en effet secondaire, la section 15 prévoit un en-tête Link avec rel="rpp-process". L'attribut process indique le type ; processId apparaît si le serveur a attribué un identifiant persistant ; latest signale le plus récent processus de ce type. Ces liens aident à retrouver le dossier à suivre. Ils n'annoncent pas son verdict.

Les sources officielles ne fournissent ni transfert réel mesuré ni trace d'un registre en production. Un essai sur un domaine maîtrisé devrait enregistrer la réponse POST, les états GET du processus, l'éventuelle décision du bureau sortant, le message final, son acquittement et la nouvelle fiche du domaine. L'interface pourrait alors annoncer honnêtement à quel moment le domaine a changé de parrain. Le projet dessine déjà la frontière : recevoir l'adresse d'un transfert n'est pas recevoir le domaine.

RPP core version 01 · Statut Datatracker · Objets RPP · RFC 5730