Zusammenfassung

  • draft-ietf-regext-balance-03 schlägt eine schreibgeschützte EPP-Abfrage für einen oder mehrere Finanzkonten vor; der Text ist ein aktiver Internet-Draft, kein RFC und kein Einführungsnachweis.
  • Balance Available, Cash Balance, Credit Line, Execution Limit und Notification Threshold haben unterschiedliche Funktionen und Beweiswerte.
  • Eine erfolgreiche Abfrage hält keinen Betrag fest. Erst die Antwort auf den späteren kostenpflichtigen Befehl dokumentiert dessen Entscheidung.

Ein Finanzsystem kann denselben Kunden gleichzeitig mit 800 Dollar verfügbarer Kapazität und einer Sperrgrenze von 500 Dollar zeigen. Das ist kein Rechenfehler. Der erste Wert beschreibt den berechneten Bestand, der zweite die operative Grenze. Problematisch wird es erst, wenn ein Client nur den größeren Wert speichert.

Der Entwurf definiert Balance Available als Credit Line plus Cash Balance. Die Credit Line wird aus aktiven Kreditinstrumenten berechnet, deren Auswahl Serverpolitik ist. Läuft ein Notkredit ab, sinkt die verfügbare Kapazität ohne Zahlungsvorgang. Cash Balance reagiert auf Einzahlungen, Auszahlungen sowie gebühren- und steuerinklusive Belastungen und Gutschriften. Ein positiver Summenwert muss deshalb weder Bargeld des Clients noch unveränderliche Kaufkraft bedeuten.

Das Execution Limit bestimmt, wann künftige kostenpflichtige Transaktionen auf einem Balance deaktiviert werden. basedOn verweist entweder auf Balance Available oder Cash Balance. Ein positives Limit stoppt vor vollständiger Ausschöpfung, etwa um Platz für serverseitige automatische Verlängerungen zu lassen. Ein negatives Limit erlaubt einen begrenzten Überzug. Der Nullpunkt ist also nicht zwangsläufig die Zulassungsgrenze.

Der Notification Threshold hat eine andere Aufgabe. Er löst beim Erreichen oder Unterschreiten eine einzelne Low-Balance-Nachricht in der EPP-Warteschlange aus. Er verwendet dieselbe Bezugsgröße wie das Execution Limit, kann aber einen anderen Betrag haben. Eine Warnung kann daher lange vor einer Sperre eintreffen. Ihr Empfang beweist weder Ablehnung noch korrekte Rechnung, Zahlungsunfähigkeit oder Abwicklung.

Revision 03 führt mehrere Balances pro Client-Server-Beziehung ein. Ein serverdefinierter Name macht jedes Konto eindeutig; Hauptwährung, Kredit und Grenzen können abweichen. Eine Poll-Nachricht kann mehrere betroffene Konten nennen. Wer Name, Währung oder basedOn entfernt und nur Zahlen zentralisiert, baut eine Bilanz ohne den dazugehörigen Entscheidungsraum.

Auch die Mehrwährungsdarstellung bleibt eine Auskunft. cashBalanceByCurrency kann Ursprungswährung, Betrag und direkt notierten Umrechnungskurs offenlegen. Die umgerechneten Komponenten müssen zusammen Cash Balance in der Hauptwährung ergeben. Damit lässt sich der ausgewiesene Wert nachvollziehen. Der Kurs wird dadurch nicht zum verbindlichen Preis für den nächsten Befehl, die Rechnung oder die spätere Zahlung.

RFC 5730 trennt schreibgeschützte Abfragen von Transformationsbefehlen. Die Balance-Abbildung definiert <info> und Low-Balance-<poll>, aber kein create, update, renew, delete oder transfer für das Balance-Objekt. Ebenso fehlen Reservierungs-Token, Bindefrist und atomare Bedingung zwischen Abfrage und Folgebefehl.

In dieser Lücke können parallele Belastungen, Erstattungen, Einzahlungen, Auszahlungen, Kreditänderungen oder automatische Verlängerungen den Zustand verändern. Der spätere Befehl erhält seine eigene EPP-Antwort. Sie ist der Beleg für die konkrete Annahme und Verarbeitung; die frühere Auskunft bleibt der Beleg für eine Darstellung zu einem bestimmten Zeitpunkt.

Zugriffsschutz löst nur einen Teil des Problems. Der Entwurf behandelt Finanzdaten als vertraulich und verlangt, sie auf den angemeldeten Client zu begrenzen. Eine erfolgreiche Authentisierung bestätigt aber weder die Buchführung noch Kreditpolitik, Wechselkurs, Steuerbehandlung, Rechnung oder interne Zeichnungsberechtigung.

Der Text erschien am 24. September 2026 als REGEXT-Arbeitsgruppendokument mit Standards-Track-Absicht. Namespace balance-0.4, Schema und beantragte IANA-Einträge sind Bestandteile des Entwurfs. Sie belegen keine endgültige IETF-Zustimmung, Implementierung, Nutzung oder finanzielle Wirkung.

Quellen