Zusammenfassung

  • RFC 3940 kennzeichnete ein gerade übertragenes NormObject innerhalb des Absenders, damit Daten und Reparaturen zusammenfanden; eine globale Inhaltsidentität entstand daraus nicht.
  • Der 16-Bit-Zähler konnte umlaufen und erneut erscheinen. Ein langlebiger Name musste von der Anwendung in NORM_INFO oder im Inhalt definiert und aufbewahrt werden.

Weniger Rückmeldungen verlangten eine genaue Zuordnung

Bei einer Multicast-Übertragung an Tausende Empfänger würde die Bestätigung jedes Pakets selbst zur Last. NORM ließ erfolgreiche Empfänger schweigen. Wer eine Lücke fand, meldete den Verlust; Vorwärtsfehlerkorrektur konnte unterschiedliche Lücken mit zusätzlichen Symbolen schließen.

Für diese Reparatur musste dennoch feststehen, welchem Objekt ein Segment oder eine Anfrage galt. RFC 3940, im November 2004 als Experimental veröffentlicht, führte object_transport_id ein. Der Sender vergab steigende Werte und verwendete denselben Wert für Übertragung und Reparatur eines Objekts. Gemeinsam mit der im Protokoll getragenen Senderkennung war das NormObject während seines Weges durch die Sitzung unterscheidbar.

Die Nummer ordnete eine laufende Arbeit. Sie taufte den Inhalt nicht für sein späteres Leben.

FILE war ein Lagerhinweis, keine Bedeutung

NORM kannte statische Speicherdaten, Dateien und unbegrenzte Datenströme. Zwischen NORM_OBJECT_DATA und NORM_OBJECT_FILE lag vor allem ein Hinweis an den Empfänger: Arbeitsspeicher oder nichtflüchtiger Speicher. Ansonsten waren beide endliche Inhaltseinheiten mit derselben Transportbehandlung. Selbst ein Stream durfte nach Wahl der Anwendung statische Daten tragen.

FILE lieferte deshalb weder Dateinamen noch Pfad, Version oder Herkunft. Ein Empfänger konnte jedes Byte einer Liste wiederherstellen und trotzdem nicht wissen, ob sie aktuell, zurückgezogen oder nur formatgleich war. Korrekte Fehlerbehebung erzeugte keine geschäftliche Zuordnung.

Der endliche Zähler kam wieder vorbei

Das Objektfeld war 16 Bit breit, und jeder Sender führte seine Folge unabhängig. Eine einzelne Zahl erhielt Bedeutung erst zusammen mit Sender, Senderinstanz, Sitzung und aktuellem Zustand. RFC 3940 räumte ein, dass Werte in sehr langen Sitzungen wiederholt werden können, und verlangte bei stark abweichenden Folgen eine neue Synchronisierung.

Die Spezifikation zog eine klare Grenze: NORM-Nachrichtenköpfe boten keine globale oder anwendungsbezogene Inhaltsidentifikation. Transportkennungen galten nur, solange der Sender das Objekt übertrug oder reparierte. Monotones Zählen bedeutete lokale Ordnung, nicht ewige Einmaligkeit.

RFC 5740 ersetzte RFC 3940 im November 2009 und brachte NORM auf den Standards Track. Die Grenze blieb bestehen. Der Nachfolger formulierte ausdrücklich, das Feld werde in einer langlebigen Sitzung umlaufen und wiederholt. Die Standardisierung des Verfahrens machte aus seiner flüchtigen Marke keinen Archivschlüssel.

Eine kleine Begleitkarte konnte Bedeutung tragen

Mit NORM_INFO durfte die Anwendung einem Objekt optionalen Kontext beilegen. Als Beispiel nannte der Text den MIME-Typ. Ein Empfänger konnte vor der zuverlässigen Aufnahme entscheiden, ob ihn das Objekt interessierte, und eine fehlende INFO-Einheit nachfordern.

INFO war aber keine Namensbehörde. Inhalt und Semantik gehörten der Anwendung, die Nutzung war freiwillig, und die gesamte Einheit musste in eine Sender-Nutzlast passen. Diese Atomizität erleichterte schnelle Reparatur, begrenzte aber den Raum. Weder dauerhafte ID noch Hash, Version, Signatur oder Dateiname waren vorgeschrieben.

Dass INFO dieselbe Transportnummer trug, verband Karte und Objekt während der Übertragung. Wer anschließend nur die Nummer speicherte, aber Instanz, Sitzungsgeneration und Anwendungs-ID verwarf, behielt eine Garderobenmarke ohne Gebäude und Datum. Bei der späteren Wiederverwendung hatte nicht das Protokoll zwei Inhalte gleichgesetzt; das Archiv hatte den Geltungsbereich vergessen.

Vollständige Bytes konnten im falschen Datensatz landen

Ein Cache verwende dauerhaft nur die Senderkennung des Protokolls und die 16-Bit-Nummer. Nach Zustandsverlust kehrt er zurück, nachdem der Zähler einmal herumgelaufen ist. Das neue Objekt wird vollständig und korrekt repariert. Trotzdem hängt der Cache womöglich alten Titel, alte Löschfrist oder alte Berechtigung an die neuen Bytes.

Das ist eine aus dem Modell abgeleitete Möglichkeit, kein behaupteter Vorfall. Sie trennt Beweise: Transportzustand ordnet ein Segment dem aktiven Objekt zu. Ein von der Anwendung gelieferter Hash kann Bytes vergleichen. Eine dauerhafte ID verbindet die Lieferung mit einer Version. Freigabe und Veröffentlichung benötigen wiederum eigene Nachweise. Keine Ebene erbt durch Erfolg die Autorität der nächsten.

Historisch bedeutsam ist die Zurückhaltung von RFC 3940. Das Protokoll schuf genau so viel Identität, wie verteilte Reparatur brauchte, und hielt dann an. Es bewegte Daten; das Gedächtnis blieb bei der Anwendung.