Zusammenfassung

  • findServiceResponse kann verwendeten Standort, Quelle und Version der Abbildung, Gültigkeit, Dienstgrenze, Auflösungspfad und Kontakt-URI dokumentieren. Keines dieser Felder meldet eine angenommene Sitzung.
  • RFC 5222 lässt Unsicherheit sichtbar: ungeprüfte Adressbestandteile, abgelaufene Abbildungen, Dienstersetzung, Default-Ziel und Redirect. Selbst LoST-Fehler werden innerhalb erfolgreicher HTTP-2xx-Antworten transportiert.
  • Belastbare Steuerung verbindet getrennte Belege von der Standortgewinnung bis zum Dienstresultat. Ein früher grüner Zustand darf die Autorität späterer Systeme nicht übernehmen.

Eine richtige Wegbeschreibung ist noch keine Ankunft

Das folgende Zeitbild ist konstruiert und kein behaupteter Vorfall. Um 08:14:02 sendet ein Endgerät eine Civic Location für urn:service:sos.police, verlangt Validierung und bevorzugt eine Grenzreferenz. Um 08:14:03 liefert ein rekursiver Resolver einen SIP-URI, locationUsed, einen path sowie source, sourceId, lastUpdated und expires.

Um 08:14:04 meldet die Oberfläche „geroutet“. Um 08:14:20 fehlt weiterhin jeder Nachweis über SIP-Sitzungsaufbau, Annahme durch die Gegenstelle, Medien oder eine operative Leistung. Die Abbildung war erfolgreich; das Wort „geroutet“ hat daraus unbemerkt eine Zustellung gemacht.

RFC 5222 definiert Location-to-Service Translation. Aus einer Civic- oder geodätischen Ortsangabe und einem Dienst-URN entstehen ein oder mehrere Kontakt-URIs mit Zusatzinformationen. Die Spezifikation beansprucht nicht, die nachfolgende Signalisierung oder die Tätigkeit der adressierten Organisation zu beobachten.

locationUsed ist Auswahlbeleg, kein Anwesenheitsnachweis

Eine Anfrage darf mehrere location-Elemente enthalten. Der Server wählt ein unterstütztes Profil und gibt dessen ID in locationUsed zurück. Dadurch bleibt nachvollziehbar, welcher Eingang die Entscheidung ausgelöst hat.

Die Herkunft des Eingangs bleibt eine vorgelagerte Frage. Das Feld sagt nicht, wer gemessen hat, wann die Messung stattfand, wie groß die Unsicherheit war oder ob sich das Gerät bewegt hat. RFC 4119, RFC 5139 und RFC 5491 beschreiben Standortobjekt, Civic-Format und PIDF-LO-Nutzung. RFC 5985, RFC 5986 und RFC 6155 trennen Standortlieferung, LIS-Erkennung und Geräteidentität.

Die Trennung hat praktische Folgen. Eine formal richtige Adresse kann veraltet sein. LoST kann einen falschen Eingang korrekt verarbeiten; Protokollkonformität heilt den Eingang nicht.

Auch Civic Validation ist begrenzt. Bei validateLocation=true kann die Antwort Tokens als valid, invalid oder unchecked markieren. Valid bedeutet: erkannt und für die Abbildung benutzt. Unchecked bedeutet: nicht geprüft und nicht benutzt. Widersprüche können nach lokaler Policy aufgelöst werden. Die Validierung bescheinigt Eignung einzelner Suchmerkmale, nicht die körperliche Anwesenheit einer Person.

Eine Versionsnummer trägt nicht alle Zeit

Jede Abbildung benötigt source, sourceId und lastUpdated. Die autoritative Quelle erzeugt die Werte; ein Cache verändert sie nicht. Für dasselbe source/sourceId-Paar kann ein neueres lastUpdated eine ältere Ausgabe ersetzen.

Damit ist die Version sauber benannt. lastUpdated sagt jedoch nur, wann diese Abbildung nach Angabe ihrer Quelle geändert wurde. Es ist weder Messzeit des Standorts noch letzter Erreichbarkeitstest, DNS-Wechsel oder Kapazitätsnachweis der Notrufstelle.

expires markiert die Nutzungsgrenze. Neben einem absoluten Zeitpunkt sind NO-CACHE und NO-EXPIRATION erlaubt. Besonders wichtig: Ein Server darf notfalls eine abgelaufene Abbildung als normale Antwort liefern. Der Client muss das Feld selbst auswerten und seine Entscheidung protokollieren.

Die zweite Gültigkeitsgrenze ist räumlich. Verlässt das Gerät das Dienstgebiet, verliert der Cacheeintrag seine Eignung, obwohl die Zeit noch läuft. Standortzeit, lastUpdated, expires, Ort bei Wiederverwendung und Zeitpunkt des Sitzungsversuchs dürfen deshalb nicht zu einem Dashboard-Zeitstempel verschmolzen werden.

NO-EXPIRATION besagt nur, dass diese Abbildung kein Ablaufdatum deklariert. Es ist keine Garantie ewiger institutioneller oder technischer Erreichbarkeit.

Eine Grenzreferenz eröffnet eine neue Beweispflicht

Der Server kann die serviceBoundary als Wert oder als serviceBoundaryReference mit Quelle und Schlüssel zurückgeben. Der Client äußert eine Präferenz; die Entscheidung liegt beim Server.

Bei einer Referenz richtet der Client getServiceBoundary direkt an den genannten autoritativen Server. Diese Abfrage rekursiert nicht. Der Mapping-Beleg und der spätere Grenzabruf sind deshalb getrennte Vorgänge.

Ohne Abruf kann ein Client nicht behaupten, den aktuellen Ort gegen die Grenze geprüft zu haben. Ohne Bindung an Schlüssel, Version und Vergleichszeit ist die Geometrie nicht revisionsfest. RFC 5582 ordnet den Mechanismus in die Gesamtarchitektur ein: Die Grenze begrenzt Wiederverwendung; sie macht eine einmalige Antwort nicht dauerhaft wahr.

Der Resolverpfad endet vor dem Rufaufbau

Im rekursiven Betrieb fragt ein Server weitere Server im Namen des Clients. Im iterativen Betrieb gibt er einen Redirect zum nächsten Ziel. path und via machen die Beteiligten sichtbar und helfen bei Schleifen, Timeouts und Warnungen.

Der Pfad ist dennoch keine allumfassende Vertrauenskette. Er belegt nicht aus sich heraus DHCP- oder DNS-Integrität, TLS-Identitätsprüfung auf jeder Strecke, vollständige Synchronisierung aller Caches oder Erreichbarkeit des Kontakt-URI.

RFC 5223 definiert die LoST-Erkennung über DHCP. RFC 8917 führt ein eigenes Discovery-Tag für Validierungsdienste ein. RFC 5069 analysiert Bedrohungen für Markierung und Abbildung von Notrufen. Discovery, Transportschutz, Abbildung und Validierung bleiben eigene Kontrollen.

RFC 5222 verlangt eine TLS-Implementierung und empfiehlt Nutzung sowie Serveridentitätsprüfung. Das schützt Anfragen und Antworten gegen Veränderung und erschwert Cache Poisoning. TLS bestätigt aber nicht die physische Wahrheit des Standorts und nicht die Reaktionsfähigkeit des URI.

HTTP 200 ist nur das Urteil der Transportschicht

Alle LoST-Antworten, auch Warnungen und Fehler, werden in HTTP 2xx transportiert, meistens 200 OK. Eine Überwachung, die nur HTTP zählt, kennt das LoST-Ergebnis nicht.

locationValidationUnavailable erlaubt eine Abbildung trotz fehlender angeforderter Validierung. serviceSubstitution zeigt an, dass ein anderer Dienst als der angefragte verwendet wurde. defaultMappingReturned bedeutet, dass der Ort nicht erfüllt werden konnte und stattdessen ein Default-URI—etwa einer nahe gelegenen Stelle—zurückkam.

Ein Default kann eine sinnvolle Notlösung sein. Wird die Warnung entfernt, erscheint eine kontrollierte Degradation als exakte Zuständigkeit. Der Informationsverlust, nicht der Fallback selbst, erzeugt die falsche Aussage.

Der eingefrorene Errata-Stand führt zwei verifizierte, einen gemeldeten und zwei für eine Dokumentaktualisierung zurückgestellte Einträge. Standards Track ersetzt nicht die Frage, welchen Text und welche Korrekturen laufender Code umsetzt.

Synchronisationssignaturen reichen nicht bis zum Anrufer

RFC 6739 regelt den Austausch von Abbildungen zwischen LoST-Knoten. Es vergleicht source/sourceId/lastUpdated, verbietet Änderungen an empfangenen Maps und verlangt Signaturen autoritativer Quellen gegen unberechtigte Gebietsansprüche.

Das schafft Herkunfts- und Integritätsbelege in der Verteilung. Es beweist nicht, dass ein bestimmter Resolver die neueste Fassung schon empfangen, installiert und ausgewählt hat. Noch weniger beweist es einen erfolgreichen Kontakt mit dem ausgegebenen URI.

RFC 5031 benennt Dienstklassen mit URNs. RFC 5012 formuliert Anforderungen an die Emergency Context Resolution. RFC 6881 beschreibt zusätzliche Pflichten von Geräten und Netzen. Dienst benennen, Kontakt bestimmen und Hilfe erbringen sind drei verschiedene Vorgänge.

Die prüfbare Aussage wächst stufenweise

Zu speichern sind: Herkunft und Alter des Standorts; gewählte ID und Profil; Civic-Validierung; Dienst-URN; Discovery, DNS und TLS; Rekursion und Redirects; source/sourceId/lastUpdated; expires, Cache und Bewegung; Grenze; URI und Warnungen; Sitzungsversuch und Aufbau; Annahme und Ergebnis.

Fehlt der nächste Beleg, endet der Satz beim letzten vorhandenen: „Die Abbildung lieferte diesen URI.“ Erst Signalisierungs- und Leistungsdaten erlauben die Ergänzung, dass jemand erreicht wurde.

Sources

  1. RFC 5222
  2. RFC 5222 im Datatracker
  3. Status von RFC 5222
  4. Historie von RFC 5222
  5. Errata zu RFC 5222
  6. RFC 5139
  7. RFC 4119
  8. RFC 5491
  9. RFC 5012
  10. RFC 5031
  11. RFC 5223
  12. RFC 6739
  13. RFC 6881
  14. RFC 5582
  15. RFC 5069
  16. RFC 8917
  17. RFC 5985
  18. RFC 5986
  19. RFC 6155
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption