Summary

  • RPP core, Entwurfsversion 01, vom 2. November 2026 bildet die Verwaltung gemeinsam geführter Objekte wie Domains auf HTTP ab. Der Entwurf zu Datenobjekten definiert ihr Modell separat. Beide sind laufende IETF-Arbeiten.
  • Ein Transfer ändert den sponsernden Client, doch RPP modelliert dafür ein Prozessobjekt mit eigenem Lebenslauf. Der antragstellende Registrar sendet POST /domainNames/{name}/processes/transferProcesses; das Antwortbeispiel zeigt 201 Created mit Prozess-URL in Location.
  • Der Antragsteller kann einen offenen Transfer abbrechen. Der bisherige Sponsor kann ihn ablehnen oder genehmigen. Eine dauerhafte Nachrichtenwarteschlange kann das spätere Ergebnis melden; Lesen und Bestätigen einer Nachricht sind verschiedene Vorgänge.

Im Verkaufsgespräch wandert eine Domain von Registrar A zu Registrar B. Im RPP-core-Eintrag der IETF besteht diese Bewegung aus mehreren Schritten. Ein Antrag öffnet einen Prozess. Der aktuelle Sponsor kann entscheiden. Eine Nachricht kann das Ergebnis später zustellen. Das anfängliche Created bezieht sich im Beispiel auf den Prozess. Es ist kein Beweis dafür, dass im Domainobjekt schon ein anderer Registrar steht.

RPP ist als eigenständiges Protokoll angelegt, auch wenn Betreiber eine Brücke zu einem EPP-System bauen. Der Kernentwurf ordnet Pfade, HTTP-Methoden, Header und Statuscodes zu. Objektmodell und konkrete Nachrichtenformate stehen in anderen Spezifikationen. Diese Aufteilung hilft beim Lesen eines Protokolls: Eine erfolgreiche HTTP-Anfrage beantwortet zunächst, welcher Schritt angenommen wurde. Ihr Code allein benennt das Ergebnis für die Domain nicht.

Die URL gehört zur offenen Akte

Abschnitt 16.9.5 nennt den Transfer einen Wechsel des sponsernden Clients und gibt ihm ein Prozessobjekt. Der neue Registrar sendet POST an die transferProcesses-Sammlung der Domain. Im Antwortbeispiel erscheinen 201 Created, ein RPP-Ergebniscode und ein Location mit /transferProcesses/latest. Diese Adresse führt zum jüngsten Transferprozess. Sie ist noch keine Abfrage des endgültigen Sponsors.

Der Client kann den Prozesszustand per GET lesen. Solange der Transfer offen ist, kann der Antragsteller ihn mit DELETE abbrechen. Dem gegenwärtigen Sponsor stehen transferReject und transferApprove zur Verfügung. Die Verben markieren eine Zuständigkeitsgrenze. Der neue Registrar kann eine Akte anlegen, aber nicht durch einen anderen URL-Aufruf im Namen des alten Registrars genehmigen. Zu einem belastbaren Verlauf gehören Antrag, Prozesszustand, Entscheidung und spätere Domainabfrage.

Auch die Beständigkeit der URL ist begrenzt. Wenn der Server Prozessinstanzen zugänglich macht, muss die neueste unter latest erreichbar sein; er darf ihr zusätzlich eine dauerhafte Kennung geben. Legt er überhaupt keine dauerhafte Prozessressource offen, verlangt der Entwurf 200 OK statt 201 Created. Eine Integration darf daher nicht überall eine bleibende Prozess-URL voraussetzen. Sie kann aber Transaktionskennungen, verfügbare Zustände und den endgültigen Sponsor sichern.

Die gelesene Nachricht bleibt im Postfach

Der Entwurf beschreibt eine dauerhafte Warteschlange für asynchrone Nachrichten an den Client. Die Vollendung eines Transfers, der Zustimmung einer weiteren Partei braucht, ist ein genanntes Beispiel. GET holt Nachrichten; DELETE auf eine bestimmte Nachricht bestätigt sie. Bloßes Abrufen räumt sie nicht aus der Warteschlange. Die Trennung verhindert, dass „gesehen“ unbemerkt zu „bearbeitet“ wird. Die erste Antwort auf den Transferantrag und eine spätere Abschlussmeldung haben verschiedene Beweiswerte.

Wenn eine gewöhnliche Operation nebenbei einen Prozess anlegt, signalisiert Abschnitt 15 ihn mit Link und rel="rpp-process". process nennt den Typ, processId eine vom Server vergebene dauerhafte Kennung, falls vorhanden, und latest die jüngste Instanz dieses Typs. Der Link zeigt Arbeit an, die weiter verfolgt werden kann. Er ist keine Schlussentscheidung.

Die offiziellen Quellen enthalten keinen gemessenen Transfer eines produktiven Registers. Ein Versuch mit einer kontrollierten Domain müsste POST-Antwort, Prozessabfragen, Entscheidung des alten Sponsors, Abschlussnachricht, Bestätigung und abschließenden Sponsoreintrag zeitlich verbinden. Dann kann das Portal den Übergang von „beantragt“ zu „abgeschlossen“ auf einen konkreten Beleg stützen. Eine URL für den Transfer ist noch kein Beleg dafür, dass die Domain umgezogen ist.

RPP core Version 01 · Datatracker · RPP-Datenobjekte · RFC 5730