Zusammenfassung

  • Das RFC-9537-Mitglied redacted kann ein geschwärztes Feld benennen, die Methode angeben und auf die Struktur vor oder nach der Schwärzung verweisen. Es dokumentiert eine Serveraussage über die ausgelieferte Antwort, nicht den ursprünglichen Inhalt.
  • Grund und Richtlinie bleiben getrennte Belege. Selbst das Existenzsignal darf aus Datenschutzgründen fehlen. Eine belastbare Beobachtung bindet deshalb Anfrage, autoritativen Server, Zugriffsklasse, Zeitpunkt, Rohantwort, Pfadauswertung und Richtlinienversion zusammen.

Die leere Spalte im Prüfbericht

Ein Prüfsystem erfasst Kontaktfelder aus RDAP. Bei hundert Domains ist die Telefonnummer leer. Die Auswertung nennt das „hundert fehlende Datensätze“. Diese Zahl vermischt jedoch mindestens vier Fälle: nie erhobene Werte, für den öffentlichen Client entfernte Objekte, leere Positionen in einer strukturierten Kontaktkarte und durch einen anderen Kontaktweg ersetzte Werte.

RFC 9537 wurde im März 2024 als Standards-Track-Dokument der IETF veröffentlicht, um genau diese begrenzte Mehrdeutigkeit zu verringern. Der Standard beschreibt, wie ein RDAP-Server entfernte, geleerte, teilweise geschwärzte oder ersetzte Felder bezeichnet. Autoren sind James Gould, David Smith, Jody Kolker und Roger Carney. Goulds am 7. September 2026 erfasstes IETF-Profil führt dreizehn RFCs. Die Programmausschuss-Biografie des Registration Operations Workshop beschreibt ihn als Fellow bei Verisign mit Verantwortung für die technische Ausrichtung von Domain-Registry-Diensten.

Das belegt Arbeitskontext und gemeinsame Autorenschaft, keine Alleinerfindung und keine Kontrolle fremder Systeme.

Der Standard macht aus der leeren Spalte keine Offenlegung. Er lässt den Server präziser sagen, was er mit seiner Ausgabe getan hat. Die Wahrheit des internen Datensatzes und die Gültigkeit der Regel bleiben außerhalb dieses Signals.

Die Reichweite von redacted

Eine Antwort, die die Erweiterung benutzt, führt redacted in rdapConformance. Das betroffene Objekt enthält normalerweise ein Array von Beschreibungen. Jede Beschreibung braucht einen logischen name, entweder als registrierten Typ oder als freie Beschreibung.

Pfade verankern den Namen in einer Struktur. prePath bezeichnet die Stelle vor der Schwärzung und muss sich daher im ausgelieferten JSON nicht auflösen lassen. postPath zeigt auf einen erhaltenen leeren, teilweisen oder ersetzten Wert. Beide schließen einander aus. Ein replacementPath kann das Ersatzfeld benennen. Standardsprache für diese Ausdrücke ist JSONPath nach RFC 9535.

Damit lässt sich nachweisen, dass der Server ein Feld unter einem Namen und mit einer Methode als geschwärzt beschrieben hat. Der Pfad enthält nicht den früheren Wert. Er bestätigt weder die Richtigkeit des internen Registers noch die vermutete natürliche Person oder die korrekte Zuordnung einer Berechtigungsstufe. Eine Koordinate im JSON ist kein Beglaubigungsvermerk für das Verborgene.

IANA verwaltet den Erweiterungsbezeichner und wiederverwendbare Klassen für Namen, Gründe und Ausdruckssprachen. Registrierte Werte fördern gemeinsame Interpretation. Sie prüfen nicht jede konkrete Antwort und billigen keine lokale Richtlinie.

Vier Methoden erzeugen unterschiedliche Beweislagen

Bei removal verschwindet ein Feld oder Objekt. Diese Methode gilt als Standard, wenn method fehlt, außer wenn die Position eines Array-Elements seine Bedeutung trägt. Bei solchen jCard-Arrays erhält emptyValue den Platz und setzt den Wert auf eine leere Zeichenkette oder null. PartialValue lässt einen Teil einer formatierten Angabe sichtbar. ReplacementValue liefert einen anderen Wert oder ein anderes Feld, etwa eine anonymisierte E-Mail-Adresse oder ein Kontaktformular.

Eine Oberfläche darf alle vier mit demselben Hinweis darstellen; ein Belegspeicher sollte das nicht. Ein entferntes Objekt lässt sich anders prüfen als eine leere Position. Ein Adressfragment gibt weiterhin Informationen preis. Ein Formular ermöglicht Kontakt, ist aber nicht die ursprüngliche Mailbox. RFC 9537 untersagt außerdem aus wiederholten Buchstaben gebildete Platzhalter, weil willkürlicher Text das Feldformat verletzen und als echter Wert missverstanden werden kann.

Darum gehört die empfangene JSON-Form in die Akte. Ein Bildschirmfoto mit dem Wort „geschwärzt“ beseitigt gerade die Unterschiede, die die Erweiterung erhalten soll.

Ein Grund ist kein Richtlinienurteil

Eine Beschreibung kann optional einen reason tragen, als registrierten Typ oder als menschenlesbaren Text. Die Textbeschreibung darf keine Verarbeitungsabhängigkeit des Clients sein. Ein Automat, der die Worte „Server policy“ als dauerhafte Entscheidungsregel verwendet, erfindet eine Semantik, die der Standard ausdrücklich nicht verspricht.

Der Server darf eine Schwärzungsrichtlinie veröffentlichen; deren Inhalt liegt außerhalb von RFC 9537. Der Standard bewertet weder Einwilligung noch Rechtsraum, Offenlegungsanspruch oder Verhältnismäßigkeit. RFC 7481 ermöglicht Authentifizierung und gestuften Zugang nach lokaler Richtlinie. Zwei Clients können deshalb unterschiedliche gültige Sichten erhalten.

Das ICANN-RDAP-Response-Profile von 2024 zeigt, wie eine bestimmte Gemeinschaft eine konkrete Ebene ergänzt. Für die erfassten gTLD-Dienste ordnet es Registrierungsdaten den Namen und Methoden von RFC 9537 zu und macht etwa Vorgaben zur E-Mail-Ersetzung. Innerhalb dieses Geltungsbereichs ist es ein wichtiger Betriebsbeleg. Es ist weder universelle RDAP-Politik noch Entscheidung über den einzelnen Antrag.

Sogar die Aussage, ein Feld existiere verborgen, kann etwas verraten. Deshalb darf ein Server die Schwärzungsbeschreibung weglassen, wenn das Existenzsignal selbst ein Datenschutzproblem wäre. Fehlendes redacted beweist keine vollständige Antwort. Es kann auch fehlende Unterstützung oder bewusstes Schweigen über die Feldexistenz bedeuten.

Der minimale zusammenhängende Beleg

Am Anfang stehen die genaue URI und der Anfragetyp, lookup oder search. Festgehalten werden autoritativer Server, Weiterleitungen, Zeit, Transportidentität, Authentifizierung und Zugriffsklasse. Eine öffentliche und eine privilegierte Abfrage derselben Domain sind verschiedene Beobachtungen.

Danach folgen Rohbytes oder ein prüfbarer Hash, rdapConformance, Objektidentität und für jeden Eintrag Name, Pfadsprache, Pfad, Methode und Grund. Das Protokoll hält fest, ob postPath im empfangenen Objekt aufgelöst wurde, wie der nicht vorhandene prePath behandelt wurde und welche RDAP- und JSONPath-Versionen liefen. Sonst kann ein Client-Upgrade wie eine Serveränderung aussehen.

Wird eine Richtlinie verlinkt, müssen URL, beobachtete Version und Zeitpunkt erhalten bleiben. Eine später geänderte Seite belegt nicht automatisch die frühere Regel. Beim Vergleich zweier Sichten bleibt jede mit ihrer Zugriffsklasse verbunden.

RFC 9082 trennt lookup und search. In Suchantworten gehört die Schwärzungsbeschreibung zum einzelnen Ergebnisobjekt. Eine Begrenzung der gesamten Ergebnismenge ist etwas anderes als ein verborgenes Feld. Notices und remarks nach RFC 9083 liefern Antwort- oder Objektkontext, ersetzen aber nicht den strukturierten Feldeintrag.

Dieses Bündel trägt eine enge Aussage: Dieser Server beschrieb bei dieser Anfrage, zu dieser Zeit und für diesen Zugriff dieses Feld auf diese Weise als geschwärzt. Ursprungswert, Richtlinienbefugnis und Zugangsrecht brauchen eigene Belege.

Quellen