Zusammenfassung

  • Der Entwurf lässt LoST-Clients ChangeSets abrufen, möglicherweise betroffene Standortdatensätze erkennen und Ersatzdatensätze für einen künftigen asOf-Zeitpunkt prüfen.
  • Die Zukunftsantwort gibt den Kenntnisstand des Servers bei der Antwort wieder, trägt NO-CACHE, kann sich ändern und ersetzt keine zeitnahe LoST-Abfrage beim tatsächlichen Dienstkontakt.
  • Mitteilung, Streamposition, Vorabprüfung, lokale Vorbereitung, Umschaltung, aktuelles Mapping, Standortübermittlung, PSAP-Route und Notrufergebnis sind getrennte Nachweise.

Um Mitternacht wechselt die Gültigkeit, nicht das Gebäude

Ein Gebiet wird mit Tageswechsel eingemeindet. Das Gebäude bleibt stehen, doch ein Verwaltungselement der Anschrift kann vor Mitternacht einen anderen richtigen Wert haben als danach. Der Location Information Server muss den alten Datensatz außer Betrieb nehmen und den neuen aktivieren, ohne Notrufgeräte zwischen zwei Zuständen zu lassen.

Der aktuelle Internet-Draft baut dafür einen Vorbereitungsweg. RFC 5222 erlaubt bereits, eine zivile Standortangabe zu validieren und aus Standort plus Dienst eine Dienst-URI zu ermitteln. RFC 5139 definiert die Adressfelder. Hinzu kommen PlannedChangePoll, GetChangeSet und Versions.

Ein ChangeSet enthält Kennung, Wirksamkeitszeit und Teilstandorte. Der Client gleicht sie mit seinen Datensätzen ab, ermittelt Kandidaten und bereitet Ersatz vor. Mit asOf fragt er nach der voraussichtlichen Validität zu einem künftigen Zeitpunkt. revalidateAfter kann eine erneute Prüfung anregen.

Das ist nützliche Koordination. Eine geplante Datenbankoperation wird dadurch noch nicht ausgeführt.

Die Zukunftsantwort trägt absichtlich NO-CACHE

Der Server antwortet mit dem, was er zum Anfragezeitpunkt über den Zielzeitpunkt weiß. Weitere geplante oder ungeplante Änderungen können eintreffen. Zwei Abfragen desselben künftigen asOf dürfen deshalb unterschiedliche Resultate liefern. Das Mapping muss expires="NO-CACHE" tragen.

Wenn ein Dienst wirklich kontaktiert wird, soll LoST erneut zeitnah verwendet werden. Planung, Aktivierung und Nutzung bleiben damit drei überprüfbare Zustände.

Auch NO-EXPIRATION verspricht keine Ewigkeit. Es besagt nur, dass dem Server gegenwärtig keine einschlägige geplante Änderung bekannt ist und er keinen bestimmten Prüfzeitpunkt empfiehlt. Der Entwurf rät trotz Polling zu periodischer Revalidierung.

RFC 6443 zeigt die längere Notrufkette: Standortgewinnung, LoST-Mapping, Übermittlung des Standorts, Proxy- und Notrufrouting, Empfang durch die Leitstelle. RFC 6881 verlangt beim Anruf einen Aktualisierungsversuch für Standort und Mapping, kennt aber einen Rückfall auf Cachewerte, wenn die Zeit nicht reicht. Eine Vorabprüfung bescheinigt weder den gewählten Zweig noch die Ankunft beim PSAP.

Der Cursor ist Gedächtnis eines Servers, kein Konsens der Welt

Der Client speichert die letzte changeSetId und fordert spätere Einträge an. Die Zeichenfolge selbst muss keine Reihenfolge offenlegen; der Server verwaltet sie. Geht der Cursor verloren, kann der Client nur das abrufen, was der Server noch aufbewahrt.

Die Security-Directorate-Prüfung fragt daher nach dem Geltungsbereich: Ist die ID serverbezogen? Was geschieht bei Kollisionen zwischen Servern? Braucht der Client je Autorität eine eigene Warteschlange? Wie wird widersprüchlicher Zukunftsstand aufgelöst? Außerdem scheint die OpenAPI-Beschreibung den für Folge-Polls benötigten ID-Parameter nicht auszuweisen.

Der Beweiswert ist folglich eng. Der Cursor kann die Position eines Clients im aufbewahrten Stream eines Servers zeigen. Er beweist weder Übereinstimmung mehrerer Autoritäten noch Lückenfreiheit, lokale Anwendung oder die tatsächliche Umschaltung.

Die Operations-Directorate-Prüfung erkennt eine ähnliche Grenze bei den Schemata. Relax NG aus RFC 5222 bleibt maßgeblich; ein leichter verwendbares XML Schema wird als nicht maßgebliche Alternative und Erweiterungsbasis angeboten. Ohne belegte Gleichwertigkeit darf eine Prüfung gegen das bequeme Artefakt nicht als Prüfung gegen das maßgebliche ausgegeben werden.

Eine belastbare Umschaltung hinterlässt mehrere Belege

Der Mitteilungsbeleg enthält Server, ID, Wirksamkeitszeit, Teilstandort und Treffer. Der Streambeleg enthält Serverbereich, vorherigen Cursor, Rückgabefolge, Aufbewahrungsfenster und Lücken. Der Zukunftsbeleg enthält Anfragezeit, asOf, exakte Eingabe, Antwort und NO-CACHE.

Die lokale Vorbereitung dokumentiert Ersatzzeilen, Konflikte, Freigabe und Zeitplan. Zur Wirksamkeitszeit braucht es einen neuen Nachweis: alte Zeilen tatsächlich inaktiv, neue Zeilen aktiv, Fehler isoliert und Rückweg verfügbar.

Beim realen Anruf beginnt die Beweiskette im Jetzt: ermittelter Standort, aktuelles LoST-Mapping, PSAP-URI, übermitteltes Standortobjekt, Proxy- und ESRP-Pfad, Empfang, Gesprächsaufbau und Reaktion. Jeder Beteiligte darf nur über den Zustand sprechen, den er selbst kontrolliert. Prozesskontinuität verbindet Belege, sie verschmilzt keine Zuständigkeiten.

So bleibt die symbolische Aussage „vorbereitet“ von der ausführbaren Aussage „funktioniert“ getrennt. Für kritische Infrastruktur ist diese Trennung kein Formalismus, sondern die Voraussetzung für verantwortbare Entscheidungen.

Noch läuft das IESG-Verfahren

Zum Rechercheschluss führte die IESG-Tagesordnung Revision 18 für den Telechat am 24. September. Datatracker zeigte IESG Evaluation, drei DISCUSS-Positionen, noch benötigte Stimmen und offene IANA-Fragen zur XML-Registrierung. Sicherheits- und Betriebsprüfung meldeten Probleme. Das Dokument ist weder verabschiedeter RFC noch Bereitstellungs- oder Interoperabilitätsbericht.

Der Ausgang wird hier nicht vorhergesagt. Die operative Prüfung bleibt in jeder Fassung gleich: Was belegt der jeweilige Datensatz, wer besitzt den nächsten Zustandsübergang und welcher Rückweg bleibt offen, wenn die Wirklichkeit vom Plan abweicht?

Quellen

Primärquellen: aktueller Internet-Draft, IESG-Tagesordnung, Security-Directorate-Prüfung, Operations-Directorate-Prüfung, RFC 5222, RFC 5139, RFC 6443 und RFC 6881.