Zusammenfassung

  • Das Netnews-Feld Supersedes benennt genau einen Vorgänger per Message-ID. Die Revision bleibt ein gewöhnlicher neuer Artikel mit eigener Identität.
  • Die Rücknahme wird wie ein Cancel authentifiziert und autorisiert. Jeder Serving-Site entscheidet über seine Kopie, sodass zwei Sites dieselbe Revision und dennoch verschiedene sichtbare Vergangenheiten haben können.
  • Cancel-Lock und Cancel-Key stärkten später den Berechtigungsnachweis, versprachen aber keine netzweite Löschung.

Dieselbe Korrektur, zwei Zustände des Vorgängers

Zwei Newsserver nehmen einen korrigierten Artikel an. Auf dem ersten besteht die Rücknahmeanforderung die Prüfung; der alte Artikel wird dort nicht mehr regulär ausgeliefert. Der zweite kann den Nachweis nicht bestätigen oder folgt einer anderen Richtlinie und behält beide Fassungen.

Die Revision ist an beiden Orten erfolgreich erschienen. Nur die lokale Behandlung des Vorgängers weicht ab. Wer diesen Zustand pauschal „ersetzt“ nennt, verschweigt, ob damit eine Versionsbeziehung, eine Anzeigepräferenz oder die tatsächliche Entfernung aus einem bestimmten Speicher gemeint ist.

Supersedes ließ die Korrektur gerade deshalb vorankommen, weil es keine vollständige Bereinigung der verteilten Vergangenheit voraussetzte.

Cancel hatte die Rücknahme schon lokal verankert

RFC 1036 beschreibt einen Cancel-Steuerartikel, der sein Ziel durch die Message-ID identifiziert. Das empfangende System führt die Rücknahme an der Kopie aus, über die es verfügt. Eine zentrale Urschrift, deren Löschung alle Replikate verändert, gab es nicht.

Schwierig war die Berechtigung. Die frühe Regel verglich Sender oder From von Anforderung und Ziel und räumte lokalen Administratoren Handlungsmacht ein. Ähnlich aussehende Header waren jedoch ein schwacher Beleg dafür, dass der Antragsteller den ursprünglichen Artikel kontrollierte.

Damit standen zwei Schäden gegeneinander: legitime Korrekturen konnten wirkungslos bleiben, oder Angreifer konnten fremde Beiträge entfernen. Die Entscheidung musste jeder Verwahrer seiner Kopie verantworten.

Supersedes schrieb keinen alten Datensatz um

RFC 5536 beschränkt Supersedes im Netnews auf eine einzige Ziel-Message-ID. Die Wirkung entspricht einem Cancel für dieses Ziel, unmittelbar gefolgt von der normalen Verarbeitung des neuen Artikels, als wäre das Feld entfernt worden.

Die Revision übernimmt also weder die Identität noch den Speicherplatz ihres Vorgängers. Sie erhält eine eigene Message-ID, eigene Header und einen eigenen Verteilungsweg. Das Feld stellt eine Beziehung zwischen zwei Veröffentlichungen her und bittet um eine getrennte Handlung an der älteren.

Vor allem hängt die Aufnahme der Revision nicht davon ab, ob die Rücknahme gelingt. Der neue Artikel bleibt normal, auch wenn der alte sichtbar bleibt.

Die Serving-Site entschied über ihre Kopie

RFC 5537 stellt klar, dass Supersedes selbst kein Control Message ist. Sein Rücknahmeteil unterliegt dennoch derselben Authentifizierung und Autorisierung wie Cancel. Wird er anerkannt, führt die Site dieselbe lokale Maßnahme aus.

Unabhängig davon soll sie den neuen Artikel normal behandeln. Annahme der Revision beweist somit keine Löschung; Fortbestand des Vorgängers beweist keine Ablehnung der Korrektur.

Die RFC hält auch die missbräuchliche Realität fest: Viele Sites ignorierten Cancel und Supersede, weil Authentifizierung schwierig und unbefugte Entfernung attraktiv war. Ein Posting-Agent sollte verhindern, dass jemand einen fremden Artikel überschreibt, doch nach der Einspeisung bleibt die Prüfung bei den nachfolgenden Betreibern.

Schlüssel stärkten den Nachweis, nicht den Herrschaftsbereich

RFC 8315 führte Cancel-Lock und Cancel-Key ein. Der ursprüngliche Artikel trägt einen Lock-Wert; ein späterer Cancel oder superseding article liefert einen Schlüssel, dessen Ableitung mit dem Lock verglichen werden kann. Damit prüft die Site Wissen, das an die ursprüngliche Veröffentlichung gebunden ist, statt nur einer ähnlichen Absenderangabe zu vertrauen.

Ein passender Schlüssel beantwortet jedoch nur die Frage nach dem Antragsteller. Er zwingt kein unabhängiges Archiv, holt keine Gateway-Kopie zurück, beseitigt kein Zitat und vereinheitlicht keine Aufbewahrungsrichtlinien. Selbst eine authentifizierte Anforderung hat einen benennbaren Wirkungsort.

„Hier authentifiziert und ausgeführt“ ist deshalb eine belastbare Aussage. „Aus dem Internet gelöscht“ ist es nicht.

Das gleichnamige Mail-Feld gehörte in einen anderen Vertrag

RFC 2156 definiert beim Übergang zwischen Internet Mail und X.400 ebenfalls ein Supersedes-Feld, dort mit einem oder mehreren Nachrichtenkennungen. RFC 5536 grenzt die Netnews-Variante mit genau einem Ziel ausdrücklich davon ab.

Auch die IANA Message Headers Registry führt getrennte Standard-Einträge für Mail und Netnews. Ein gemeinsamer Name macht aus Mailbox, Newsserver und Archiv keinen gemeinsamen Rückrufdienst.

Die Registrierung stabilisiert Syntax und Normverweis. Sie belegt weder heutige Implementierung noch den Verbleib konkreter Kopien.

Eine neue Tatsache konnte eine alte nicht überall beseitigen

Das Verfahren erzeugte keine makellose, einheitliche Historie. Ein Leser sieht nur die Revision, ein anderer beide Versionen, und ein Archiv bewahrt, was eine Serving-Site nicht mehr anzeigt. Diese Uneinheitlichkeit ist die ehrliche Folge verteilter Verwahrung.

Systeme müssen deshalb Beziehung, Ausblendung, Rücknahme aus einem konkreten Speicher und nachgewiesene Abwesenheit in einem bestimmten Korpus unterscheiden. Kein Zustand beweist automatisch den nächsten.

Supersedes machte die Korrektur zu einer eigenständigen neuen Tatsache und die Rücknahme zu einer begrenzten Anforderung. Die Revision musste die Vergangenheit nicht überall beherrschen, um sie künftig richtigzustellen.