Zusammenfassung

  • In RFC 3632 bedeutete -Approve:No beim aktuellen Sponsor Ablehnung, beim ursprünglichen Antragsteller Stornierung des eigenen Transfers. Authentifizierter Akteur, Rolle, Vorzustand und Zeitpunkt vervollständigten die Semantik.
  • 200 Command completed successfully belegt erfolgreiche RRP-Verarbeitung. Es belegt weder den Willen des Registranten noch Zustimmung, DNS-Veröffentlichung oder beobachteten Diensterfolg.
  • Nachweisfähige Protokolle verbinden Session, Rolle, Objekt, Vorzustand, Regel, Frist, Antwort, Folgezustand und Benachrichtigung. Ein Payload ohne diese Beziehung ist syntaktisch exakt und institutionell unbestimmt.

Die Beweislast lag außerhalb der Payload

RFC 3632 erschien im Dezember 2003 als Informational-Dokument zu RRP 2.0.0. Es ist kein Internet Standard und keine heutige Betriebsempfehlung. Seine bleibende Pointe ist enger: Ein Befehl konnte nur mit Wissen interpretiert werden, das nicht im Befehl stand.

Sendete der aktuelle Sponsoring-Registrar -Approve:No, lehnte er den Transferantrag eines anderen ab. Sendete der Registrar, der den Antrag gestellt hatte, denselben Wert, zog er den eigenen Antrag zurück. Ablehnung und Stornierung liegen auf entgegengesetzten Seiten der institutionellen Beziehung.

Der RFC-Editor-Eintrag, der IETF Datatracker, die Dokumenthistorie und die Errata-Suche belegen Status und Pflege des Textes. Sie belegen keine konkrete Implementierung oder Transaktion.

Die Session war Teil der Grammatik

RFC 2832 leitete die Identität des antragstellenden Registrars aus der aktiven authentifizierten Session ab. Die Registry kannte zugleich den aktuellen Sponsor des Domains. Erst die Verbindung aus Principal, Objektbeziehung und Transferzustand ergab eine zulässige Aktion.

Ein selbst ausgefülltes Identitätsfeld hätte diese Autorität nicht geschaffen. Ein Feld behauptet, eine Session authentifiziert, und der Registry-Zustand ordnet die Rolle zu. Versuchte ein unbeteiligter Registrar zu genehmigen oder abzulehnen, musste die Operation scheitern.

Der mögliche verlierende Registrar sollte außerdem außerhalb des Protokollkanals per E-Mail oder Bericht informiert werden. Die Beweiskette war verteilt: Anmeldung, Nachricht, persistenter Zustand und Zustellung der Mitteilung hatten jeweils einen anderen Gegenstand.

RRP gab keine Zeitstempel oder Transaktionskennungen zurück. Die beschriebenen Tages- und Wochenberichte lieferten Zeiten in lokaler Registry-Zeit. Ohne gespeicherte Korrelation und Zeitzonenbasis konnte eine spätere Untersuchung zwei korrekte Datensätze nicht sicher ordnen.

Autorität hatte ein Ablaufdatum

RFC 3375 teilte die Rollen vorab zu. Der Antragsteller initiiert den Transfer und darf ihn vor einer Entscheidung stornieren. Der aktuelle Sponsor darf genehmigen oder ablehnen. Nicht berechtigte Akteure müssen abgewiesen werden. Beide Seiten brauchen Sicht auf pending und abgeschlossen.

RFC 3632 setzte die Stornierung in RRP um, verwendete dafür aber den vorhandenen negativen Approval-Wert. Sie musste vor der expliziten Entscheidung des Sponsors und vor einer impliziten Registry-Entscheidung nach Ablauf des Timers eintreffen.

Zeit war damit kein Komfortfeld, sondern Eingabe der Autorisierung. Erforderlich sind serverseitiger Empfangszeitpunkt, Zeitbasis, gültige Timer-Policy, das schließende Ereignis und Zustände vor und nach der Verarbeitung. Eine Client-Uhr allein belegt die Reihenfolge auf dem entscheidenden Server nicht.

Nach dem Übergang aus pending existiert die frühere Stornierungsmöglichkeit nicht mehr. Ein späterer Prozess kann den Betrieb korrigieren, aber nicht beweisen, ob der ursprüngliche Versuch rechtzeitig war. Wer nur den Endzustand speichert, verliert genau diese Unterscheidung.

Ein 200er hat einen begrenzten Aussagesatz

Das Beispiel in RFC 3632 endet mit 200 Command completed successfully. Diese Antwort ist belastbare Evidenz für die RRP-Verarbeitung. Sie wird erst irreführend, wenn ihr Betreff erweitert wird.

Sie belegt nicht, dass der Registrant die Stornierung wollte, dass der Registrar intern ordnungsgemäß autorisiert wurde, dass Sponsorship endgültig wechselte oder DNS publiziert wurde. Sie beobachtet keinen Nutzerzugriff. Für jede dieser Aussagen gibt es einen anderen Aussteller.

Lu Hengs On Authority and Belief liefert die Kontrollfrage: Wer spricht über welches Objekt mit welchem Mandat? Die Registry spricht über ihre Verarbeitung und Daten. Ihr Statuscode darf nicht zum Stellvertreter für Kundenwillen oder Netzwirklichkeit werden.

Eine Leitungsansicht trennt deshalb Kundenautorisierung, Registrar-Handlung, Registry-Sponsorship, DNS-Veröffentlichung und Servicebeobachtung. Sie korreliert diese Spalten, ohne Unsicherheit durch einen grünen Wert zu überschreiben.

EPP machte Rollen sichtbarer

RFC 5731 bezeichnet Transferoperationen getrennt als request, cancel, approve, reject und query. Pending-Information kann antragstellenden Client und Datum sowie handelnden Client und Aktionsdatum enthalten. RFC 5730 stellt Client- und Server-Transaktionskennungen bereit.

Das erleichtert den Beleg. Ein Export muss nicht aus demselben „No“ zwei Aktionen ableiten. Dennoch bewahren sich Felder nicht selbst. Telemetrie kann IDs verwerfen, Uhren können driften, ein Requesting Client ist nicht der Registrant, und EPP-Erfolg ist kein DNS-Beobachtungspunkt.

RFC 3730 dokumentiert eine frühere EPP-Generation. Die RFCs dienen hier als Designvergleich, nicht als Behauptung über Migration oder Konformität eines benannten Betreibers.

510 entschied über Darstellung, nicht Identität

RFC 3632 ergänzte Code 510 für unzulässige Domain-Codierung bei ADD oder MOD. RFC 5890 entwickelte später die IDNA-Begriffe weiter.

Eine angenommene Darstellung hat eine Syntax und Policy dieser Schnittstelle bestanden. Sie belegt weder Markenrecht noch Organisationsidentität, Absicht, sichere Anzeige oder tatsächliche Delegation. Auch eine Ablehnung ist kein universelles Urteil über den Namen.

„Gültig“ braucht daher immer ein Objekt: gültig für welche Grammatik, welche Version und welchen Zeitpunkt? Ohne diese Ergänzung übernimmt der Parser institutionelle Entscheidungen, für die er keine Autorität besitzt.

Ein gespeicherter IPv6-Wert ist kein Erreichbarkeitsnachweis

RFC 3632 erlaubte vollständige und komprimierte IPv6-Adressen in Nameserver-Objekten. RFC 4291 beschreibt die Architektur; RFC 5952 empfiehlt später eine kanonische Textform.

Parser-Akzeptanz, Registry-Speicherung, Delegationsveröffentlichung, Routing und autoritative DNS-Antwort sind getrennte Tatsachen. Eine kann wahr sein, während die nächste fehlt. Ein Label „IPv6 aktiv“ ist nur dann ehrlich, wenn es die beobachtete Ebene nennt.

Die Kette sollte Host-Objekt, Parent- oder Root-Zone, Routing-Sicht, DNS-Antwort und verteilte Probes enthalten. Abweichung zeigt nicht bloß Fehler, sondern die Schicht, in der formaler Zustand und Betrieb auseinandergehen.

557 markierte eine fremde Kontrollfläche

Code 557 kennzeichnete ein gesperrtes Nameserver-Objekt, das mit einer Top-Level-Domain verbunden war. Änderungen erforderten Koordination außerhalb des normalen Registrar-Pfads. Das war kein absolutes Verbot, sondern eine Aussage über fehlende einseitige Befugnis.

Die heutige Root-Zone-Verwaltung der IANA ist ein separates System. Root Zone Management, TLD-Verwaltung, Zustimmung, technische Nameserver-Anforderungen und RZMS API trennen Credentials, begrenzte Rechte, Zustimmung, technische Prüfung, Umsetzung und Kontrolle. Bei gemeinsam genutzten Nameservern können weitere TLD-Parteien betroffen sein.

Diese heutigen Quellen erklären keine historische RRP-Transaktion. Sie zeigen dieselbe architektonische Grenze: Registry-Objekt, autorisierter Root-Antrag, Root-Veröffentlichung und funktionierender Dienst sind nicht derselbe Zustand.

Ein Mindestbeleg ist eine Beziehung

Für einen Transfer sind Protokoll- und Build-Version, Session, Client-ID, Antragsteller, Sponsor, Domain, Antragszeit, Vorzustand, Befehlsbytes, Policy und Timer, Autorisierungsentscheidung, Antwort, Folgezustand, Mitteilungen und endgültige Entscheidung zu verbinden. Eine DNS-Aussage braucht eigene Veröffentlichungs- und Beobachtungsbelege.

Hengs Minimum Initial Specification liefert das Maß: eine gemeinsame kleinste Schnittstelle schaffen, ohne spätere Entscheidungshoheit zu zentralisieren. Die Registry muss Kundenwillen und Verfügbarkeit nicht beherrschen; sie muss ihre eigene Entscheidung sicher korrelierbar machen.

On Reality Layers trennt Symbol, institutionelle Entscheidung, Registerzustand, DNS und Nutzung. Running Code Primary verlangt den Nachweis der ausgeführten Transition.

Die Compliance-Tabelle am Anfang war technisch ordentlich und sachlich unvollständig. Sie bewahrte jedes Zeichen, aber nicht denjenigen, dessen Befugnis den Zeichen Bedeutung gab. RFC 3632 erinnert daran, dass Normalisierung keine Neutralität ist, wenn sie Rollen löscht.

Quellen

  1. RFC 3632 — VeriSign Registry Registrar Protocol 2.0.0
  2. RFC 3632 als Text
  3. RFC-Editor-Information zu RFC 3632
  4. RFC 3632 im IETF Datatracker
  5. Dokumenthistorie von RFC 3632
  6. Errata-Suche zu RFC 3632
  7. RFC 2832 — Registry Registrar Protocol 1.1
  8. RFC 3375 — Generische Registry–Registrar-Anforderungen
  9. RFC 3730 — Extensible Provisioning Protocol
  10. RFC 5730 — Extensible Provisioning Protocol
  11. RFC 5731 — EPP Domain Mapping
  12. RFC 5732 — EPP Host Mapping
  13. RFC 4291 — IPv6 Addressing Architecture
  14. RFC 5952 — IPv6-Textdarstellung
  15. RFC 5890 — IDNA-Definitionen
  16. IANA — Root Zone Management
  17. IANA — Verwaltung einer Top-Level-Domain
  18. IANA — Zustimmung zu einer Root-Zone-Änderung
  19. IANA — Technische Nameserver-Anforderungen
  20. IANA — Root Zone Management System API
  21. Lu Heng — On Authority and Belief
  22. Lu Heng — On Reality Layers
  23. Lu Heng — Running Code Primary
  24. Lu Heng — Minimum Initial Specification