Zusammenfassung

  • Der ECRIT-Entwurf ergänzt LoST um eine geordnete Abfrage geplanter Änderungen, die Datumsprüfung asOf und den Hinweis revalidateAfter. Ein Client kann mögliche Treffer auswählen und Ersatzdatensätze vor dem Wirksamkeitszeitpunkt vorbereiten.
  • Zwei Abfragen mit demselben zukünftigen asOf dürfen zu unterschiedlichen Zeiten verschieden ausfallen. Die Antwort gibt den gegenwärtigen Kenntnisstand des Servers wieder; sie garantiert weder den späteren Mapping-Zustand noch die lokale Umsetzung.
  • Ein zweistufiger Validierungsbeleg sollte Vorbereitung und tatsächliche Umstellung getrennt erhalten. Das ist Daniel Kades redaktioneller Vorschlag, keine IETF-Vorgabe und kein Nachweis einer Implementierung.

Ein unveränderter Ort bekommt eine Zeitgrenze

Als typischen Fall nennt der Entwurf die Eingemeindung eines Teils eines Landkreises oder Bezirks. Vor dem Stichtag kann das Feld für die Gemeinde leer sein oder einen anderen Wert enthalten; danach gehört der Gemeindename in dieselbe zivile Ortsangabe. Auch umbenannte oder neu nummerierte Straßen erzeugen einen Wechsel.

Revision 18 von Validation of Locations Around a Planned Change ist ein aktiver Internet-Draft der ECRIT-Arbeitsgruppe. Er ist Arbeitsstand, kein RFC, und belegt weder Einführung noch Betriebserfahrung oder einen realen Notrufvorfall.

RFC 5222 definiert LoST. Ein Client übermittelt Standort und Dienstkennung; der Server liefert Dienst-URIs und zugehörige Angaben. Er kann außerdem Bestandteile einer zivilen Adresse validieren. Das dabei verwendete Format beschreibt RFC 5139.

Ohne geplante Hinweise muss ein Client seinen gesamten Bestand regelmäßig neu prüfen. Ein grober Rhythmus kann am Stichtag zu spät und in ruhigen Zeiten unnötig teuer sein. Der Entwurf lässt den Server deshalb eine betroffene Teilmenge anzeigen und künftige Datensätze vorab validieren.

Der operative Gewinn heißt Vorbereitung. Seine Beweisgrenze heißt Beobachtungszeit. Eine Montagsabfrage für Freitag ist kein Freitagsbeleg.

Drei Uhren beantworten drei Fragen

Die erste Uhr gehört dem Änderungsstrom. Eine eigene REST/JSON-Schnittstelle stellt Versionsabfrage, PlannedChangePoll und GetChangeSet bereit. Ein ChangeSet enthält eine geordnete ID, den Wirksamkeitszeitpunkt und Teilstandorte. Der Client speichert die letzte ID und fragt nach Nachfolgern.

Die zweite Uhr ist asOf. Der Client kann in findService Datum und Zeit vorgeben. Der Server antwortet nach seinem Wissen zum Abfragezeitpunkt darüber, was bis zum Zielzeitpunkt gelten wird. Bezieht sich die Antwort nicht auf die Gegenwart, muss sie asOf zurückgeben und jedes Mapping mit NO-CACHE kennzeichnen.

Die dritte Uhr steuert die Wiederholungsprüfung. revalidateAfter kann raten, wann erneut validiert werden sollte. NO-EXPIRATION sagt nur, dass dem Server aktuell keine geplante Änderung bekannt ist, die das Ergebnis betrifft, und dass er keinen Zeitpunkt empfiehlt. Es ist keine Ewigkeitszusage.

Der Strom meldet Neues nach einer Position. asOf liefert eine heutige Zukunftssicht. revalidateAfter berät über die nächste Nachfrage. Keine dieser Angaben beweist den Verwaltungsakt, die Aktivierung im Client, ein dauerhaftes Dienst-Mapping oder eine erfolgreiche Kommunikation.

Ein einziges grünes „validiert“ würde Beobachtungen und Entscheidungen verschmelzen. Der Server erschiene als Gewährsmann für eine Datenbank, die er nie gesehen hat.

Ein Teilstandort ist ein Selektor

Der Server muss keine vollständige Adressliste ausgeben. Ein Teilstandort besteht aus Namespace-, Element- und Wertepaaren. Der Client vergleicht sie mit seinen Datensätzen. Stimmen alle gelieferten Paare überein, kann der Datensatz betroffen sein; nicht gelieferte Elemente bleiben außer Betracht.

So kann ein Verwaltungsgebiet unabhängig von Straßen und Hausnummern oder eine Straße unabhängig von den Hausnummern ausgewählt werden. Der Mechanismus grenzt Prüfkandidaten ein. Er entscheidet nicht über jeden Kandidaten.

Der Client sollte daher neben dem ChangeSet auch Datenbank-Snapshot, Vergleichsregel, Treffer, Ausschlüsse und Ausnahmen aufbewahren. Eine Gesamtsumme erklärt später nicht, ob sich die Grenze vergrößerte, Quelldaten korrigiert wurden oder ein lokaler Filter falsch arbeitete.

Die Trennung entspricht Lu Hengs Gedanken einer minimalen Anfangsspezifikation und lokaler späterer Entscheidungen. Die gemeinsame Ebene liefert eindeutige, interoperable Felder. Teilnehmer behalten die Verantwortung für Aktivierung und Rücknahme in ihren Systemen.

Ein ehrlicher Zukunftswert bleibt veränderbar

Abschnitt 4 erklärt ausdrücklich, dass zwei Abfragen mit identischem zukünftigem asOf unterschiedlich ausfallen können. Der Server kann nach der ersten Anfrage von geplanten oder ungeplanten Veränderungen erfahren und garantiert keine spätere Antwort für denselben Standort.

Eine Eingemeindung kann verschoben, eine Straßenliste berichtigt oder ein weiterer Wechsel ergänzt werden. Würde die erste Prognose fixiert, schützte das System seinen Änderungsplan gegen die Wirklichkeit.

NO-CACHE trägt diese Korrekturfähigkeit in die technische Behandlung. Zugleich soll ein Client LoST zeitnah benutzen, wenn er einen Dienst tatsächlich kontaktieren muss. Die vorbereitende Standortprüfung ersetzt nicht die aktuelle Dienstauflösung.

Die ECRIT-Charta umfasst Verfahren, die Standort- und Routinginformationen für die Kommunikation mit einer zuständigen Notfallstelle verwenden. Lösungen sollen über Regionen und Rechtsräume hinweg funktionieren, ohne eine einzige zentrale Stelle vorauszusetzen. Deshalb gilt: Eine gültige zivile Adresse beweist keine zugestellte Kommunikation; die Planung eines Servers beweist keine Umsetzung durch alle unabhängigen Clients.

Lu Hengs redaktionelles Gebot, Wirklichkeit statt Fürsprache zu liefern, verlangt den vollständigen Satz: Dieser Server gab zu dieser Abfragezeit für diesen Zukunftszeitpunkt diese Antwort. „Wirksam geworden“ braucht eine zweite Quelle.

Auch eine geordnete Folge kann unvollständig sein

Der Entwurf erwartet Abfragen im Abstand weniger Minuten. Der Client sendet die zuletzt gespeicherte ChangeSet-ID; der Server liefert spätere IDs. Bleibt die Antwort leer, ist die gesendete ID der letzte dem Server aktuell bekannte Eintrag.

Ein neuer Client oder einer ohne gespeicherte Position fragt ohne ID und erhält alle noch aufbewahrten ChangeSets. Der Server muss sie jedoch nicht unbegrenzt halten. Der Text nennt beispielhaft zwölf Monate in einem ruhigen und drei Monate in einem veränderungsreichen Gebiet.

Dauert ein Ausfall länger, kann die verbleibende Liste sauber geordnet und für diesen Client dennoch lückenhaft sein. Er muss die Diskontinuität festhalten, einen aktuellen Grundbestand ermitteln und eine neue Epoche eröffnen. Die älteste noch vorhandene ID ist nicht automatisch der Anfang der Geschichte.

Eine leere Antwort beweist außerdem weder die Verarbeitung früherer Sets noch die Abwesenheit ungeplanter Änderungen. Sie zeigt nur die Beziehung zwischen übermittelter ID und aktueller Serverliste.

Lu Heng unterscheidet im Policy Mirror zwischen Register und Thron. Die Liste hat Autorität über die von diesem Server erhaltene Folge, nicht über lokale Vollzüge, die er nicht beobachtet.

Vorbereitung und Vollzug getrennt quittieren

Der Vorbereitungsbeleg sollte Server, Schnittstellenversion, Abfragezeit, vorherige und neue IDs, Wirksamkeitszeit und Teilstandort enthalten. Hinzu kommen lokaler Snapshot, Selektionslogik, Kandidaten und Ausnahmen. Standort, Dienst, asOf, Antwort, revalidateAfter, Cache-Status, Uhr und Entwurfsrevision bilden den Prüfteil.

Der Vollzugsbeleg hält den lokal anerkannten Stichtag, Abschaltung alter Datensätze, Aktivierung der Ersatzwerte, eine zeitnahe Validierung, Unterschiede zur Prognose, Verschiebungen, Fehler, Rücknahme und verantwortliche Abschlussinstanz fest.

Diese Zweiteilung ist ein Vorschlag des Artikels, kein Entwurfstext. Detaildaten können geschützt bleiben; öffentlich lassen sich Mengen, Zeitfenster, ChangeSet-Verweise und offene Ausnahmen zeigen. Ein Hash kann beide Sichten binden, aber die Richtigkeit der Entscheidung nicht herstellen.

Unterscheidet sich die spätere Antwort von der früheren, sind beide aufzubewahren. Die erste erklärt die damalige Planung, die zweite den später vorgefundenen Zustand. Überschreiben zerstört entweder Entscheidungsgeschichte oder Gegenwartsbezug.

Ein Prüfintervall verteilt Risiko

Der Entwurf beschreibt die Intervallwahl als Ausgleich zwischen Aktualität, Serverlast, Datenstabilität und Richtlinie. Als Beispiele nennt er sechs Monate oder länger in stabilen und 20 bis 30 Tage in schnell wachsenden Gebieten. Daraus folgt kein universelles Serviceziel.

Der Server kennt seine Quellen und Kapazität. Der Client kennt die Folgen veralteter Einträge. revalidateAfter übermittelt Rat, ohne die lokale Risikoverantwortung zu übernehmen. Abweichungen brauchen einen Entscheider, eine Begründung, einen Geltungsbereich und Auslöser für erneute Prüfung.

Zu lange Intervalle halten ungültige Daten am Leben. Zu häufiges Polling kann andere LoST-Verarbeitung beeinträchtigen, wie der Sicherheitsabschnitt festhält. Aktualität und Verfügbarkeit greifen auf dieselbe Kapazität zu. Governanz verlangt daher nachvollziehbare Auswahl statt einer vermeintlich richtigen Zahl.

Was sich behaupten lässt

Der Vorbereitungsbeleg kann zeigen, dass ein bestimmter Client ein ChangeSet empfing, es gegen einen definierten Bestand prüfte und eine Zukunftsvalidierung erhielt. Der Vollzugsbeleg kann zeigen, was derselbe Client später aktivierte und welche zeitnahe Prüfung folgte.

Zusammen beweisen sie weder die rechtliche Wirksamkeit der zivilen Änderung noch Gleichstand aller Server, dauerhafte Mappings oder Ende-zu-Ende-Zustellung. Jede Behauptung braucht den Zeugen ihrer eigenen Ebene.

Die zivile Stelle ändert die Grenze. Der LoST-Server stellt Daten dar. Der Client ändert seinen Bestand. Eine aktuelle Abfrage löst einen Dienst auf. Das Kommunikationssystem versucht die Zustellung. Saubere Governanz hält diese Verben auseinander und ordnet ihnen die richtige Verantwortung zu.

Quellen