Zusammenfassung

  • draft-ietf-regext-balance-02 lässt den angemeldeten EPP-Client verfügbares Guthaben, Barbestand, Kreditlinie sowie optionale Ausführungs- und Warnschwellen abfragen.
  • Die Antwort eignet sich als Steuerungswert, enthält aber weder einzelne Buchungen noch Berechnungszeitpunkt, Herkunft des Wechselkurses, Richtlinienversion oder reservierte Verpflichtungen.
  • Beeinflusst der Saldo die Entscheidung über einen kostenpflichtigen Befehl, sollten Registry und Registrar einen gesonderten Finanzstatusbeleg aufbewahren, der Berechnung, Sitzung und Ergebnis verbindet.

Vor einem langen Wochenende startet ein Registrar einen Erneuerungslauf. Die Saldoabfrage zeigt einen positiven Betrag. Einige Befehle gelingen, der nächste wird aus finanziellen Gründen abgelehnt. Der Betrieb hat EPP-Transaktionsnummern, die Buchhaltung ein internes Konto und der Support vielleicht einen Screenshot. Keine dieser Spuren muss belegen, welche Lastschrift, Reserve, Umrechnung oder Schwelle im Augenblick der Ablehnung galt.

Hier liegt keine zwingende Rechenpanne vor. Es ist die Grenze zwischen einem Betriebsprotokoll und dem Abrechnungssystem dahinter.

Revision 02 des Balance Mapping wurde am 14. August 2026 als aktives Dokument der REGEXT-Arbeitsgruppe veröffentlicht und ist für den Standards Track vorgesehen. Sie bleibt ein Internet-Draft, ist kein RFC und belegt keine Einführung bei einer bestimmten Registry.

Die Standardisierung löst ein praktisches Problem. Ein Registrar sollte seine finanzielle Handlungsfähigkeit nicht nur über proprietäre Portale und E-Mails erfahren. Ein gemeinsames EPP-Objekt bringt den Status dorthin, wo die Provisionierung geschieht. Eine einheitliche Zahl ist jedoch noch keine einheitliche Begründung.

Verfügbar heißt nicht: als Kontoauszug belegt

Der Entwurf definiert balanceAvailable als creditLine + cashBalance. Der Barbestand bezeichnet Mittel, die der Betreiber für den Client hält; die Kreditlinie den eingeräumten Kredit. Gebühren erscheinen negativ, Erstattungen und Einzahlungen positiv, Auszahlungen negativ.

Das ist genauer als ein unbeschrifteter „Kontostand“. Es trennt die operative Verfügbarkeit außerdem vom ausstehenden Saldo, der eine andere buchhalterische Frage beantwortet und im Mapping nicht verwendet wird.

Das Schema nennt aber keine Einzelposten. Welche Registrierung, Verlängerung, Erstattung, Einzahlung oder Korrektur zum Barbestand führte, bleibt außerhalb der Antwort. Ebenso fehlen ein ausdrücklicher Stichtag, der Abschlusszeitraum, der Umgang mit strittigen Beträgen und noch nicht verbuchte Reservierungen.

Der Client kann damit prüfen, was der Server aktuell ausweist, nicht aber die Berechnung unabhängig wiederholen. Für ein schlankes EPP ist das vernünftig. Problematisch wird es, wenn genau diese Projektion einen betrieblichen Vorgang sperrt und später als vollständige Erklärung gelten soll.

Die Ausführungsschwelle verschiebt die wirkliche Grenze

Das optionale executionLimit legt den Punkt fest, unter dem kostenpflichtige Client-Transaktionen abgelehnt werden dürfen. Ohne Angabe gilt 0,00. Der Entwurf erlaubt bewusst positive und negative Werte.

Eine positive Schwelle bewahrt einen Puffer oberhalb von null. Als Grund nennt der Text serverseitig ausgelöste Vorgänge wie automatische Verlängerungen. Sichtbar verfügbares Geld ist dann nicht vollständig für neue Befehle einsetzbar, weil der Betreiber Raum für künftige Verpflichtungen schützt.

Eine negative Schwelle erweitert den Spielraum unter null. Der Registrar darf innerhalb dieser Toleranz weitere Vorgänge anstoßen. Die Entscheidungsgrenze ergibt sich daher erst aus verfügbarem Saldo, Schwelle und Preis des beabsichtigten Vorgangs.

Die Antwort zeigt die aktuelle Schwelle, nicht aber ihre Entstehung. Wer hat den Puffer genehmigt? Wann wurde er geändert? Welche Auto-Renew-Prognose liegt zugrunde? Gibt es Produktunterschiede oder eine zeitweilige Ausnahme? Das Protokoll sagt es nicht.

Auch reserviert eine Saldoabfrage kein Geld. Eine zweite Sitzung kann zuerst handeln, ein Buchungslauf kann den Wert ändern, und eine nichtfinanzielle Regel kann den Befehl abweisen. Die Abfrage ist ein Eingangssignal, keine Annahmegarantie.

Eine Warnung ist ein Warteschlangenereignis

Mit notificationThreshold kann der Server beim Unterschreiten eines Grenzwerts eine Niedrigsaldo-Nachricht erzeugen. Das Attribut basedOn muss dieselbe Grundlage verwenden wie das Ausführungslimit. Warnung und Sperre sollen nicht unbemerkt über verschiedene Größen sprechen.

Die Nachricht läuft über die EPP-Poll-Warteschlange. Das Basisprotokoll liefert Einstellungszeit und Nachrichtenkennung; Befehle und Antworten tragen Client- und Server-Transaktionskennungen. Der Client bestätigt den Eintrag im normalen poll-Ablauf. Vorgesehen ist eine Meldung beim Übertritt, nicht eine Wiederholung bei jeder Abfrage.

Das belegt technische Zustellung und Bestätigung. Es beweist nicht, dass die Finanzabteilung informiert war, Geld nachgeschossen wurde, der Registrar der Rechnung zustimmte oder bei einer späteren Ablehnung noch derselbe Grenzwert galt. Empfang, Kenntnis, Zustimmung und Behebung sind getrennte Ereignisse.

Die Währungsrechnung hat keine Quellenangabe

Im Mehrwährungsfall kann der Barbestand nach Währung, Betrag, Umrechnungskurs und Wert in der Referenzwährung aufgeschlüsselt werden. Die Summe der umgerechneten Werte muss cashBalance ergeben. Verwendet wird die direkte Notierung: Ein Betrag in der Ausgangswährung wird mit dem Kurs multipliziert.

Der Client kann so die dargestellte Addition prüfen. ISO-4217-Codes schaffen eindeutige Einheiten. Nicht genannt werden Kursanbieter, Beobachtungszeit, Version der Rundungsregel oder Ersatzquelle bei Datenausfall. Selbst der Saldo trägt keinen ausdrücklichen „Stand von“-Zeitpunkt.

Mit großem Puffer mag das folgenlos bleiben. Nahe am Ausführungslimit kann eine kleine Kursdifferenz über einen ganzen Vorgang entscheiden. Die Währungsinfrastruktur wird damit zur unsichtbaren Abhängigkeit der Namensverwaltung.

EPP muss deshalb kein Devisenmarkt werden. Wohl aber sollte ein autorisiertes Nachweissystem Quelle und Zeitpunkt des Kurses festhalten, sobald die Umrechnung eine operative Wirkung entfaltet.

Vertraulichkeit verteilt die Beweise

Der Entwurf behandelt Finanzdaten als vertraulich und beschränkt den Zugriff auf den angemeldeten Client. Das ist richtig: Barbestand, Kredit und Schwellen eines Registrars gehen Wettbewerber nichts an.

Für die spätere Untersuchung liegen die Teile dadurch an verschiedenen Orten. Ein Dienstleister führt die EPP-Sitzung, besitzt aber nicht das Geld. Die Buchhaltung kennt Posten, aber nicht die genaue Befehlsfolge. Die Registry kennt ihre Richtlinie, darf jedoch das gesamte Konto nicht offenlegen.

Die Lösung ist weder Öffentlichkeit noch ein vollständiges Hauptbuch in EPP. Benötigt wird ein schmaler, integritätsgeschützter Beleg für die berechtigten Parteien: weniger Offenlegung als im Konto, mehr Erklärungskraft als in der Saldoanzeige.

Ein Beleg für den tatsächlich entscheidenden Zustand

Ich schlage einen Finanzstatusbeleg vor, sobald eine Saldoregel vor einem kostenpflichtigen EPP-Befehl warnt, ihn zulässt oder ablehnt. Das ist eine redaktionelle Governance-Empfehlung und keine Vorgabe des Internet-Drafts.

Der Beleg verbindet authentifizierten Client, Sitzungskontext, clTRID und svTRID der Abfrage, Abrufzeit, Referenzwährung, verfügbaren Saldo, Barbestand, Kreditlinie, Ausführungslimit und Warnschwelle. Bei mehreren Währungen hält er Betrag, angewandten Kurs, Quelle, Beobachtungszeit und Rundungsregel je Komponente fest.

Er verweist außerdem auf die Grundlage außerhalb von EPP: unveränderlichen Buchungsschnappschuss oder Auszugsreferenz, wesentliche ausstehende Soll- und Habenposten, Auto-Renew-Reserve, Richtlinienversion und zeitweilige Ausnahme. Ein Hash oder kontrollierter Verweis kann Integrität sichern, ohne Geschäftsdetails zu vervielfältigen.

Schließlich bindet er den betroffenen Befehl: Objektklasse, Preisreferenz, Anforderungs- und Entscheidungszeit, Ergebnis, EPP-Code und beide Transaktionskennungen. Bei einer nichtfinanziellen Ursache wird diese benannt. Ändert sich der Saldo zwischen Abfrage und Befehl, bleiben beide Zustände erhalten.

Aus „nicht genug Geld“ wird eine überprüfbare Abfolge. Registry und Registrar können erkennen, ob Nebenläufigkeit, Umrechnung, Reserve, verspätete Buchung, Richtlinienänderung oder ein anderer Ablehnungsgrund die Differenz erzeugte.

Das Protokoll klein halten, die institutionelle Erinnerung nicht

Das Mapping ist absichtlich nur für Abfragen gedacht. Es definiert keine Saldologik für check, create, delete, renew, transfer oder update. Unterschiedliche Geschäftsmodelle müssen so nicht in ein universelles Gebührenprotokoll gepresst werden.

Das Risiko entsteht, wenn der standardisierte Wert für Support und Automatisierung zur endgültigen Wahrheit wird, während seine Voraussetzungen flüchtig bleiben. Eine einheitliche Oberfläche kann dann die Unterschiede interner Regeln besser verdecken als erklären.

Revision 02 hat die Sprache bereits geschärft: „balance“ wurde zu „balance available“, basedOn kam hinzu, der Namespace wechselte auf 0.3. „Verfügbar“ bezeichnet eine bedingte Handlungsfähigkeit. Der nächste Governance-Schritt besteht darin, die Bedingungen der tatsächlich ausgeübten Entscheidung zu bewahren.

Quellen