Zusammenfassung

  • Overview bündelte die wichtigsten Angaben vieler Artikel in geordneten, tabulatorgetrennten Zeilen und ersparte wiederholte Einzelabfragen mit HEAD.
  • LIST OVERVIEW.FMT durfte ein Feld nur ankündigen, wenn die Datenbank für alle einschlägigen Artikel dessen Inhalt oder dessen Fehlen erfasst hatte.
  • Bei einer Schemaänderung musste ein auslaufendes Feld vor dem Speicherstopp verschwinden; ein neues durfte erst nach Neuaufbau oder Ablauf alter Datensätze öffentlich werden.

Zwei Tabulatoren und eine offene Frage

In einem positionalen Format trägt auch eine Leerstelle Bedeutung. Stehen zwei Tabulatoren nebeneinander, bleibt die Spaltenposition erhalten. Der Client kann daraus aber nur dann auf einen fehlenden Header schließen, wenn er weiß, dass der Server diese Spalte bei jedem betreffenden Artikel nach derselben Regel geführt hat.

Eine halb aufgebaute Spalte erzeugt dagegen eine zweite mögliche Erklärung: Vielleicht besaß der Artikel den Wert, doch sein alter Overview-Datensatz wurde nie ergänzt. Dieselben Bytes würden dann entweder eine Eigenschaft des Artikels oder einen Mangel des Index beschreiben.

RFC 3977 löst diese Mehrdeutigkeit mit dem Begriff der Konsistenz. Für ein Feld ist die Datenbank konsistent, wenn sie bei allen einschlägigen Artikeln dessen Inhalt oder dessen Abwesenheit verzeichnet. Fehlen gespeicherte Werte trotz vorhandener Header, darf das Feld nicht im angekündigten Format stehen.

Vom einzelnen Kopf zur gemeinsamen Übersicht

Das ursprüngliche RFC 977 bot HEAD: Ein Client wählte einen Artikel nach Message-ID oder serverlokaler Nummer und erhielt dessen Headerblock. Das war eindeutig, aber teuer, wenn ein Newsreader zunächst nur Titel, Autoren, Daten und Threadbezüge einer großen Gruppe anzeigen wollte.

RFC 2980 dokumentierte mit XOVER eine andere Abrufeinheit. Für einen Nummernbereich lieferte der Server eine kompakte Zeile je vorhandenem Artikel. Zuerst kamen Artikelnummer, Subject, From, Date, Message-ID, References, Byte- und Zeilenzahl; optionale Felder konnten folgen. Ein Nullwert blieb als benachbartes Tabulatorpaar sichtbar.

Die Beschleunigung beruhte auf einem vorberechneten gemeinsamen Index. Gleichzeitig verschwanden die Feldnamen aus jeder einzelnen Zeile. Sobald Werte nur noch durch ihre Position bezeichnet werden, muss die Reihenfolge außerhalb der Zeile präzise und aktuell bekannt sein.

Ein stabiler Kern, ein erklärter Anhang

RFC 3977 standardisierte OVER mit acht Anfangsfeldern: Nummer oder Null, Subject, From, Date, Message-ID, References, :bytes und :lines. Interne leere Felder behalten ihren Platz; leere Felder am Ende dürfen entfallen. Gefaltete Header werden entfaltet, und Tabulatoren innerhalb eines Werts werden zu Leerzeichen, damit Inhalt nicht als Trennzeichen auftreten kann.

LIST OVERVIEW.FMT machte den Rest der Struktur sichtbar. Der Server nannte die Feldbeschreibungen in genau der Reihenfolge, in der OVER sie ausgab. Zusätzliche Header konnten folgen; ein Suffix :full zeigte an, dass der Headername im zurückgegebenen Wert erhalten blieb. Erweiterbarkeit wurde damit nicht zum Ratespiel, sondern zu einer abfragbaren Vereinbarung.

Diese Vereinbarung beschreibt den gegenwärtigen Zustand des Servers. Sie kann sich sogar während einer Sitzung ändern. Wer das einmal gelesene Format dauerhaft im Client festschreibt, riskiert, spätere Zeilen mit einer vergangenen Spaltenordnung zu deuten.

Eine Schemaänderung braucht eine Wartezone

Angenommen, ein Betreiber beginnt heute, einen weiteren Header zu indexieren. Neue Artikel füllen das Feld, alte Overview-Datensätze besitzen es nicht. Würde die Spalte sofort angekündigt, wären leere alte Zellen nicht interpretierbar: Der Header könnte fehlen, oder die Rückfüllung könnte fehlen.

RFC 3977 verlangt deshalb eine Reihenfolge. Soll ein Feld künftig nicht mehr gespeichert werden, wird es zuerst aus LIST OVERVIEW.FMT entfernt. Ein neues Feld wird erst angekündigt, wenn die Datenbank wieder konsistent ist – nach einem Neuaufbau oder nachdem die alten Datensätze abgelaufen sind und nur noch nach der neuen Regel erzeugte Zeilen verbleiben.

Das vorübergehende Verschweigen vorhandener Teilwerte ist kein Informationsverlust. Es verhindert, dass ungleich erfasste Daten als einheitliche Tabelle auftreten. Der Server verspricht weniger, damit jede verbleibende Aussage belastbar bleibt.

Nicht angekündigt ist nicht dasselbe wie nicht vorhanden

Wenn ein Feld im aktuellen Format angekündigt und seine Zelle bei einem Artikel leer ist, darf der Client laut RFC 3977 daraus schließen, dass der entsprechende Header oder Metadatenwert bei diesem Artikel fehlt. Ohne die Formatankündigung ist derselbe Schluss nicht zulässig.

Damit trennt das Protokoll zwei Arten von Abwesenheit. Die fehlende Spalte besagt, dass der Index keine konsistente Aussage anbietet. Die leere Zelle innerhalb einer zugesagten Spalte besagt etwas über den Artikel. Der Unterschied entsteht nicht in der Zelle, sondern in der nachgewiesenen Abdeckung um sie herum.

Berechnete Metadaten mit begrenzter Autorität

Overview enthält außerdem Werte, die nicht aus vom Autor gesetzten Headern stammen. Die mit einem Doppelpunkt bezeichneten Felder :bytes und :lines werden vom Server berechnet; ähnlich benannte Artikelheader dürfen dafür nicht als vertrauenswürdige Quelle dienen.

Auch eine serverseitige Berechnung ist keine unbegrenzte Garantie. RFC 3977 beschreibt historische Varianten der Bytezählung und warnt Clients davor, sich auf vollkommene Genauigkeit zu verlassen. Die Zeilenzahl besitzt eine genauer abgegrenzte Definition für den Body. Provenienz und Messunsicherheit können nebeneinander bestehen.

Die Bereichsausgabe bleibt ebenfalls begrenzt. Vorhandene Ergebnisse sind nach Artikelnummer sortiert, gelöschte Artikel sollen nicht erscheinen, und Nummernlücken bleiben möglich. OVER fasst den Bestand zusammen, den dieser Server noch berichten kann; es rekonstruiert keine abgelaufenen Inhalte.

Das IANA-Register der NNTP-Parameter führt OVER als registrierte Fähigkeit für Overview-Unterstützung. Das belegt die interoperable Kennzeichnung, nicht ihre heutige Verbreitung oder einen bestimmten Geschwindigkeitsgewinn.

Geschwindigkeit durch eine engere Zusage

Der gemeinsame Overview-Index machte das Durchsehen großer Gruppen praktikabel. Seine eigentliche Zuverlässigkeit entstand jedoch aus einer Einschränkung: Eine Spalte durfte erst sichtbar werden, wenn ihre Erfassungsregel die relevante Vergangenheit abdeckte.

Während eines unvollständigen Umbaus sagte der Server weniger. Nach Neuaufbau oder Ablauf durfte er mehr sagen. Das leere Feld wurde nicht von selbst glaubwürdig; die veröffentlichte, konsistente Spalte hatte seine Bedeutung erst verdient.

Quellen