Zusammenfassung

  • Date bezeichnet den Zeitpunkt, zu dem der Ersteller eine Nachricht als fertig und transportbereit erklärte, nicht ihren tatsächlichen Transport.
  • Netnews-Relays müssen ihre Geschichte bereits gesehener Message-IDs begrenzen. Ein Cutoff nach Schreibzeit kann einen gerade eingespeisten, lange zurückgehaltenen Artikel als alt verwerfen.
  • Injection-Date fügte die Eintrittsbeobachtung hinzu, ohne Date zu ändern. Das Feld verbesserte die Entscheidung, bewies aber weder Urheberschaft noch Uhrgenauigkeit oder Ankunft bei allen Servern.

Ein neuer Artikel mit einem alten Montag

Jemand beendet einen Artikel ohne Netzverbindung. Die Anwendung setzt am Montag Date; erst am Freitag kann der posting agent ihn einem News-Server anbieten.

Für den Verfasser ist Montag richtig. Für ein Relay mit endlicher History kann derselbe Wert wie ein alter Artikel aussehen, der zurückkehrt, nachdem der Message-ID-Eintrag bereits gelöscht wurde.

Eine Änderung auf Freitag könnte die Weitergabe erleichtern, würde aber die Entstehungsgeschichte verschieben. Das unveränderte Datum kann dagegen eine Stale-Regel auslösen. Ein einziges Feld sollte plötzlich die Fertigstellung dokumentieren und zugleich die Aufnahme in den Verteilungsstrom rechtfertigen.

Injection-Date löste den Konflikt nicht durch Korrektur, sondern durch eine zweite, enger begrenzte Aussage.

Wofür Date tatsächlich stand

RFC 1036 bezeichnete Date, früher Posted, 1987 als Datum der ursprünglichen Veröffentlichung im Netz. Der Wert sollte während der Weitergabe unverändert bleiben. Kein Zwischenknoten durfte den Anfang still auf seine eigene Durchlaufzeit setzen.

RFC 5322 trennt Fertigstellung und Beförderung ausdrücklich. Das origination date ist der Zeitpunkt, an dem der Ersteller die Nachricht als vollständig und bereit für das Zustellsystem kennzeichnet. Beim Beispiel eines offline arbeitenden tragbaren Rechners gehört das Datum zum lokalen Einreihen, nicht zur späteren Verbindung.

Diese Bedeutung schützt die Chronologie des Erstellers. Als Nachweis des Netzeintritts reicht sie nicht. Eine lokale Uhr kann falsch sein, die Angabe kann täuschen oder das Warten kann völlig legitim Tage dauern. Auch ein genaues Date beantwortet die falsche Betriebsfrage.

Deduplizierung brauchte ein Ende der Erinnerung

Unabhängige relaying agents und serving agents tauschen Netnews-Artikel aus. RFC 5537 verlangt eine History bereits angenommener Artikel und die Ablehnung weiterer Angebote desselben Artikels. Message-ID liefert den Schlüssel.

Alle Kennungen dauerhaft zu behalten, ließe die Datenbank unbegrenzt wachsen. Das Protokoll erlaubt deshalb ein Cutoff-Intervall. Ältere Artikel können abgelehnt und ihre History-Einträge entfernt werden; eine spätere Rückkehr scheitert dann an der Zeitprüfung. Die RFC nennt mindestens sieben Tage als Usenet-Konvention und warnt, dass ein Intervall unterhalb der Ausbreitungszeit noch nie gesehene Artikel treffen kann.

Das Datum beweist kein Duplikat. Es begrenzt, wie lange der Server die Beweise zu dessen Erkennung aufbewahrt. Ein kurzer Zeitraum spart früher Ressourcen und riskiert verspätete Erstankünfte. Ein langer Zeitraum schützt langsame Pfade und kostet mehr Speicher.

Bei ausschließlicher Nutzung der Schreibzeit wurde schon das Warten außerhalb des Netzes vom internen Zeitbudget abgezogen.

Eine zweite Uhr mit kleinerem Anspruch

RFC 5536 definiert Injection-Date als Zeitpunkt, zu dem der Artikel in das Netz eingespeist wurde. Für Stale-Prüfungen sollte ein News-Server damit die bei der Einspeisung gesetzte Zeit verwenden können statt der vom user agent bei der Erstellung gesetzten.

Das Feld muss bei der Einspeisung eingefügt werden. Wegen älterer Software müssen Agenten Artikel ohne dieses Feld dennoch akzeptieren; dann greift RFC 5537 auf Date zurück. Die Migration blieb interoperabel, ohne eine gleichzeitige Umstellung vorzutäuschen.

Die zweite Uhr darf die erste nicht überschreiben. RFC 5536 verbietet die Änderung eines vorhandenen Date. Weil die Uhren verschiedener Agenten nicht synchron sein müssen, kann Injection-Date rechnerisch sogar früher liegen. Eine negative Differenz belegt zunächst Uhrenabweichung, nicht umgekehrte Kausalität.

Der definierte Name ersetzte das verwendete, aber undokumentierte NNTP-Posting-Date, das als deprecated markiert wurde. Standardisierung koordinierte die Bedeutung, nicht die Zeitquellen.

Drei Zeiten aus drei Blickwinkeln

Für die übliche History-Optimierung behandelt RFC 5537 Injection-Date als Artikeldatum und nur bei dessen Fehlen Date. Relays und Server prüfen zu weit in der Zukunft liegende Werte und vergleichen bei einem Cutoff die Zeit mit ihrem Intervall.

Eine Alternative entfernt History nach dem ersten lokalen Sehen. Im beschriebenen Verfahren muss die Aufbewahrung dann mindestens 24 Stunden länger sein als der Cutoff, um die zulässige Zukunftsabweichung abzudecken. Damit erscheint eine dritte Uhr.

RFC 3977 definiert den serverlokalen arrival timestamp und ordnet lokale Artikelnummern danach. Diese Beobachtung gehört genau einem Server.

  • Date gehört zur Vollständigkeitserklärung des Erstellers.
  • Injection-Date gehört zum Eintritt in Netnews.
  • arrival time gehört zur Annahme und Reihenfolge auf einem bestimmten Server.

Ihre Zusammenlegung schreibt Pfadverzögerung dem Autor zu oder deutet Offline-Warten als Rücklauf im Netz.

Mehrere Eingänge, kein neues Alter

Zur Redundanz oder zwischen getrennten Netzen konnte derselbe Artikel mehreren injecting agents angeboten werden. Es sollten keine unabhängigen Artikel entstehen. Wenn Pfade zusammentrafen, sollte Message-ID eine einzige Annahme ermöglichen.

RFC 5537 verlangt deshalb identische Message-ID-, Date- und Injection-Date-Felder in allen Proto-Artikel-Kopien. Wird ein bereits eingespeister Artikel für einen weiteren Netzeingang vorbereitet, bleiben alle drei unverändert. Eine Aktualisierung an jedem Gateway würde denselben Artikel wiederholt verjüngen.

Injection-Date ist daher nicht einfach das jeweilige Jetzt eines späteren Vermittlers. Bei mehrfacher Einspeisung wird es Teil der Kontinuität eines einzigen Veröffentlichungsakts.

Alte Auslegung blieb als Kompatibilität

Frühere Implementierungen ignorieren das neue Feld und wenden ihre Stale-Regeln weiter auf Date an. RFC 5537 erkennt an, dass ein weit zurückliegendes Erstellungsdatum trotz korrekter Einspeisezeit schlechtere Verbreitung verursachen kann.

Sind Message-ID und Date vorhanden, sollte der posting agent die zweite Zeit nach mehr als einem Tag hinzufügen und muss sie bei mehreren injecting agents setzen. Der Einspeiseagent prüft übermäßig zukünftige oder alte Werte und fügt seine aktuelle Zeit unter den vorgesehenen Bedingungen hinzu. In der Nähe des Posters kann er eine Ablehnung noch sinnvoll erklären.

Downstream bleibt alte Software jedoch alt. Kompatibilität erhielt die Kommunikation und akzeptierte zugleich eine Übergangsphase unterschiedlicher Entscheidungen.

Registrierung ist keine Beglaubigung

Injection-Date ist die Zeitaussage eines Agenten am Eintritt. Es ist keine kryptografische Signatur, kein Beweis des Verfassers und keine Garantie synchroner Uhren. Es bezeichnet weder Moderationsfreigabe noch Lesezeit, jede spätere Ankunft oder lokales Löschen.

Das aktuelle IANA-Register der Message Header führt Injection-Date als Standardfeld für Netnews mit Verweis auf RFC 5536. Das Register stabilisiert den Namen. Es bestätigt keinen einzelnen Wert und keine universelle Nutzung.

Der historische Gewinn lag in der Begrenzung. Der Ersteller behielt seine Zeit; das Netz ergänzte die für die Aufnahme nötige Beobachtung; jeder Server behielt seine lokale Ankunft. Das zweite Datum war nützlich, weil es das erste nicht löschen durfte.