Zusammenfassung

  • Der als aktuell bezeichnete AFRINIC-Eintrag zu WHOIS 2.10.7 vom 29. November 2022 nennt JSContact als neue RDAP-Funktion.
  • Der aktuelle RDAP-Leitfaden erklärt Abfragen, Client und die Weiterleitung außerhalb der Region, nennt aber keine JSContact-Version, Antwortrepräsentation, Konformitätskennung oder Anforderungsmethode.
  • Das beschreibt eine Grenze der öffentlichen Dokumentation, nicht das Verhalten eines Endpunkts, einen Standardverstoß oder einen Schaden.

Eine Funktionsmeldung beantwortet nicht jede Client-Frage

Der Changelog von AFRINIC enthält eine klare, aber kurze Aussage. WHOIS 2.10.7 ist dort als aktuelle Ausgabe ausgewiesen. Der Eintrag vom 29. November 2022 nennt Korrekturen und Verbesserungen zur Konformität mit dem NRO-RDAP-Profil sowie eine neue RDAP-Funktion, JSContact. Damit ist öffentlich belegt, dass AFRINIC eine funktionale Änderung beschrieben hat.

Der RDAP-Leitfaden hat einen anderen Zweck. Er führt zum Endpunkt und zu den Abfragen nach IP-Netz, Autonummer, Reverse DNS und Entität. Er verweist auf den Kommandozeilen-Client NicInfo und zeigt, wie eine Ressource außerhalb der AFRINIC-Region mit HTTP 301 und einem Location-Header weitergereicht wird. Für einen gewöhnlichen Lookup ist das eine ausreichende und nützliche Orientierung.

Die beiden Seiten machen jedoch nicht sichtbar, wie der Name aus der Änderungsnotiz an eine Client-Antwort gebunden wird. In der aktuellen RDAP-Anleitung finden sich JSContact, jCard, rdapConformance und version nicht. Aus den veröffentlichten Seiten lässt sich daher nicht ableiten, welche Kontaktrepräsentation gemeint ist, ob eine Version eine Rolle spielt, ob ein Client eine Variante anfordern kann oder welches Antwortsignal die Auswahl ausweist.

Diese Feststellung darf nicht größer gemacht werden als ihre Quelle. Sie besagt nicht, dass der AFRINIC-Endpunkt JSContact nicht zurückgibt. Sie besagt nicht, dass ein NRO-Profil oder ein anderer Standard nicht erfüllt wird, dass ein Client versagt oder dass personenbezogene Daten gefährdet sind. Für diesen Beitrag wurde keine Live-Antwort als Tatsachenbasis herangezogen. Gegenstand ist allein die öffentliche Verbindung zwischen einer Funktionsankündigung und einer nutzbaren Beschreibung.

Der historische Wortwechsel ist keine Implementierungsdiagnose

Schon im April 2022 gab es einen IETF-Internet-Draft zur Nutzung von JSContact in RDAP-Antworten. Die elfte Fassung war ausdrücklich ein Arbeitsdokument; sie beschrieb eine Erweiterung für Entitätskontakte und verwendete unter anderem jscard. Dass dieser Text vor dem AFRINIC-Eintrag lag, beweist weder eine Übernahme noch eine Pflicht zur Übernahme.

Die gegenwärtige Fassung vom August 2026 verwendet spätere Begriffe und Abläufe: jscontact_card, vom Client verlangte Repräsentationsauswahl, rdapConformance als Signalisierung und Übergangsstufen zwischen jCard und JSContact. Das ist ein technischer Vergleichsmaßstab, kein rückwirkendes AFRINIC-Kriterium. Er erklärt, weshalb ein Formatname allein nicht genügt: Standardantwort, ausdrückliche Anforderung, Antwortkennzeichnung und Kompatibilitätsphase sind voneinander verschiedene Informationen.

Auch das aktuelle IANA-Register führt die Hauptversionen 1.0 und 2.0 getrennt. Es sagt nichts über eine bei AFRINIC eingesetzte Version aus. Es zeigt nur, dass ein allgemeiner Formatname ohne Kontext für eine öffentliche Schnittstelle zu wenig präzise sein kann.

AFRINIC hat starke Gründe, die öffentliche Dokumentation nicht zu einem internen Architekturprotokoll auszubauen. Weder reale Kontaktdaten noch Sicherheitskonfigurationen, Verkehrsdaten oder private Umstellungspläne müssen veröffentlicht werden. Ein knapper Changelog und eine Anleitung für häufige Abfragen sind je für sich vernünftige Dokumente.

Eine verhältnismäßige Ergänzung wäre ein kurzer Verfügbarkeitsnachweis für Erweiterungen. Er könnte Dienst- und Dokumentationsrevision verbinden, gegebenenfalls die angekündigte Repräsentation und Version nennen, eine öffentliche Anforderungsmethode nur dann ausweisen, wenn sie existiert, das Antwortsignal und den Kompatibilitätszustand vermerken sowie Profilreferenz, dokumentiertes Fallback, Verantwortlichkeit, Korrektur und Ablösung festhalten. Ein nicht sensibler Testnachweis kann die Prüfung belegen, ohne Produktivdaten offenzulegen.

Präzision ohne Kompetenzverschiebung

Der Nachweis würde AFRINIC weder eine Repräsentation noch einen Migrationszeitpunkt vorschreiben. Die operative Entscheidung bleibt beim Register. Er verhindert nur, dass Außenstehende aus dem Wort „hinzugefügt“ eine nie veröffentlichte Zusage über Version, Standardverhalten oder Kompatibilität ableiten.

Das ist für beide Seiten ein Gewinn. Client-Autoren erhalten eine überprüfbare öffentliche Grenze. AFRINIC erhält einen datierten Ort für Klarstellung und Korrektur. Keine politische Entscheidungsbefugnis wird verschoben, und keine Sicherheitsinformation muss veröffentlicht werden.

Quellen

  1. AFRINIC Online Services Changelog
  2. AFRINIC RDAP-Leitfaden
  3. IETF draft-ietf-regext-rdap-jscontact-11
  4. IETF draft-ietf-regext-rdap-jscontact
  5. IANA-JSContact-Register