Zusammenfassung

  • Revision 15 von RDAP Extensions schlägt ein IANA-Datum für die Ausmusterung vor. Der eingetragene Kontakt könnte die eigene Erweiterung, die IESG jeden Eintrag zur Ausmusterung anmelden. Das ändert den Registerstatus, nicht fremde Software.
  • Der Versionierungsentwurf veröffentlicht in /help Versionen, Standard, Vorgänger, Nachfolger sowie start und end, kennzeichnet die Version einer Antwort und nimmt Clientwünsche entgegen. Er koordiniert, ohne alle Clients zu kennen.
  • Ein Stilllegungsbeleg muss Registerentscheidung, Serverzustand, gemessene Nachfrage und verbleibende Ungewissheit trennen. Das ist Daniel Kades Vorschlag, keine IETF-Vorgabe.

Auf einer Bestandsliste ist Ausmusterung binär. In einem offenen Abfrageprotokoll ist sie eine Folge voneinander unabhängiger Entscheidungen. Ein selten gestartetes Programm kann lange nach dem Stichtag noch eine alte Antwortstruktur erwarten. Der Eintrag im Register und der spätere Fehler können gleichzeitig korrekt sein, weil sie verschiedene Gegenstände beschreiben.

draft-ietf-regext-rdap-extensions-15 vom 13. August 2026 betrachtet RDAP als Geflecht getrennter Auskunftsstellen. Clients folgen Bootstrap-Antworten, Umleitungen und Verweisen zu TLD-, Registrar- oder RIR-Servern. Kein Betreiber besitzt automatisch eine vollständige Liste der Programme am anderen Ende.

Der Text ist ein aktiver REGEXT-Arbeitsgruppenentwurf mit angestrebtem Standards-Track-Status. Laut Datatracker ist wegen eines in der Arbeitsgruppe erhobenen Punktes eine neue Revision nötig; ein verantwortlicher Area Director ist nicht benannt. Auch Revision 07 des Versionierungsentwurfs vom 31. Juli ist kein RFC und kein Einsatznachweis.

Das Register entscheidet über den Namen

Erweiterungskennzeichen erscheinen in rdapConformance und bilden Namensräume für Protokollelemente. Sie sind opak. Eine Ziffer am Ende belegt weder Version noch Nachfolge. Die Beziehung muss in einer Spezifikation stehen.

Revision 15 würde Deprecation Date ergänzen. Der im Register genannte Kontakt dürfte die eigene Erweiterung melden, die IESG jede Erweiterung. IANA trüge das Datum im RFC-3339-Format ein. Damit ist die Kompetenz für den öffentlichen Status des Kennzeichens nachvollziehbar.

Diese Kompetenz reicht nicht bis zur Laufzeit. IANA entfernt kein JSON-Feld von unabhängigen Servern und aktualisiert keine Clientbibliothek. „Obsolet“ sagt, wie das Kennzeichen heute eingeordnet wird; es sagt nicht, wo alter Code weiterläuft.

Der Entwurf bittet um den 21. August 2025 für icann_rdap_response_profile_0 und icann_rdap_technical_implementation_guide_0. Das am 1. September 2026 aktualisierte Register zeigt beide als OBSOLETED und daneben ihre Nachfolger der Version 1, aber noch keine eigene Datumsspalte. Daraus folgt kein IANA-Versäumnis: Die neue Anweisung ist bislang Entwurfstext.

Specification Required und Expert Review schützen wiederum die Aufnahme in den Namensraum. Die Referenz muss stabil, zugänglich und für unabhängige Implementierung ausreichend sein. Revision 15 schlägt mindestens drei Fachprüfer und eine Zweitprüfung vor. Das ist Qualitätskontrolle einer Registrierung, keine Vermessung aller Installationen.

Der Server entscheidet über sein Angebot

Revision 07 schlägt versioning_help für /help vor. Dort stehen unterstützte Versionen, Standard, Dokumentation, Vorgänger, Nachfolger sowie Beginn und Ende. versioning_data benennt die in einer konkreten Antwort verwendete Version. versioning_list transportiert den Wunsch des Clients.

Diese Aussagen dürfen nicht verschmelzen. Unterstützung ist nicht Standardauswahl. Eine neue Antwort beweist nicht die Entfernung der alten Version. Ein Client ohne ausdrücklichen Wunsch kann lediglich dem Standard folgen, ohne auf die neue Semantik vorbereitet zu sein.

end bezeichnet das vom Server angekündigte Supportende. Danach muss das Versionsobjekt aus der Anzeige verschwinden; fehlt end, ist kein Ablauf geplant. Das verpflichtet den Server zu einer klaren Aussage über sich selbst. Es attestiert nicht die Umstellung fremder Clients.

Für inkompatible Änderungen empfiehlt der Entwurf eine Zwischenstufe: alte und neue Elemente parallel anbieten, Ersatz und Frist bekanntmachen, danach das alte Element entfernen. Alternativ wechselt zuerst der Standard, während Clients bis zum Ende ausdrücklich die alte Version wählen können. Ein sinnvolles Verfahren—aber ohne universell richtige Dauer.

Der Erweiterungsentwurf nennt die Grenze offen: Zwischen RDAP-Client und -Server besteht keine notwendige Beziehung; daher lässt sich nicht absolut beweisen, dass eine brechende Änderung alle Clients verschont. Daraus folgt weder sorgloses Abschalten noch ewige Kompatibilität. Unsicherheit muss als Entscheidungsgröße sichtbar werden.

Messen, ohne Leser zu katalogisieren

Betreiber können alte Versionswünsche zählen, Fehler nach dem Standardwechsel beobachten, Verweispfade prüfen und verwaltete Clients ansprechen. Seltene Abläufe und Clients, die nie eine Version anfordern, bleiben dennoch teilweise unsichtbar.

Eine dauerhafte Verknüpfung von Abfrageobjekt, Adresse und Softwarefingerabdruck wäre unverhältnismäßig. Öffentliche Nachweise sollten Zeitfenster, Serverumfang, Aggregation und Löschung nennen. Null beobachtete Altanfragen in dieser Stichprobe ist möglich; null abhängige Clients weltweit ist nicht belegt.

Der Stilllegungsbeleg

Zuerst werden Kennzeichen, Version, befugter Antragsteller, IANA-Eintrag und Datum festgehalten. Danach folgen Vorgänger, Nachfolger, Inkompatibilitäten, entfernte Elemente und stabile Referenz. Die dritte Ebene dokumentiert je Server /help-Beobachtungen, Standardwechsel, start/end, Antwortversion, Fehlerverhalten, Rückfallregel und tatsächliche Entfernung.

Die vierte Ebene fasst Nachfrage zusammen: Zeitraum, Knoten, Datenschutzverfahren, alte Versionsrate, bekannte offene Clients und nicht messbare Bereiche. Schließlich nennt der Betreiber seine Entscheidung, den Belegstichtag und Ausnahmen. Plan und Vollzug bleiben getrennt.

So behält IANA die Autorität über den Registerstatus, der Betreiber über den Dienst und der Clienthalter über seine Aktualisierung. Der Beleg verbindet sie, ohne eine nicht vorhandene Gesamtvollmacht zu erfinden.

Quellen