Summary

  • RFC 5222's findServiceResponse is a mapping receipt: it can identify the supplied location element used, mapping source and version, validity window, service boundary, resolution path and contact URI. None of those fields records a completed emergency call.
  • The protocol deliberately preserves degraded and conditional states. Civic fields may be unchecked, expired mappings may arrive as ordinary responses, warnings can accompany a default URI, and every LoST warning or error still travels inside HTTP 2xx.
  • Operational assurance therefore needs a joined evidence chain from location acquisition through LoST provenance and cache validity to downstream signaling, responder acceptance and service outcome. One green “mapping succeeded” light cannot inherit every later authority.

The response was complete; the event was not

At 08:14:02, in a constructed audit sequence rather than a reported incident, a device sends a findService request for urn:service:sos.police. It supplies one civic location, requests validation and asks for a service boundary.

At 08:14:03, a recursive resolver returns an XML response. The record contains source, sourceId, lastUpdated and expires. It includes a boundary reference, a SIP URI, a path of LoST servers and locationUsed. The civic-validation result marks several tokens valid and one unchecked. Every parser and schema check passes.

At 08:14:04, the mapping dashboard turns green.

At 08:14:20, the evidence set still contains no SIP establishment result, no proof that the selected responder accepted the session, no media receipt and no operational outcome. The dashboard has not lied about the mapping. It has silently changed the noun.

That is the boundary exposed by RFC 5222. The protocol translates a location-and-service tuple into one or more service contact URIs and associated information. It does not define the later signaling exchange as part of findServiceResponse, and it does not make a contact coordinate equivalent to contact.

locationUsed identifies an input, not the world

A LoST request may carry more than one location element. The server chooses one it understands and returns the chosen element's identifier in locationUsed. This is valuable provenance. An auditor can tell which submitted representation drove the mapping rather than guessing from a bag of possible locations.

The field's authority stops there. It does not say how the device obtained the location, when the underlying observation was made, whether the device moved afterward, or whether the coordinates describe the caller rather than a configured endpoint. Those questions belong to the preceding location chain.

RFC 4119, RFC 5139 and RFC 5491 define and refine ways to represent and use location objects. RFC 5985, RFC 5986 and RFC 6155 address location delivery, local-server discovery and device identity in that acquisition process. Their existence is itself an architectural warning: a mapping response cannot reconstruct evidence that was never attached to its input.

RFC 5222's optional civic validation is similarly narrow. A client sets validateLocation=true; the server may return lists of valid, invalid and unchecked civic tokens. “Valid” means the token was recognized and used for the mapping. “Unchecked” means it was not checked and not used. Contradictory fields are resolved under server policy. If the server selects a geodetic input, the civic-validation request is ignored.

This is useful validation of a mapping key. It is not a sworn statement that a person is physically present at that address. RFC 5139's representation work should not be made to carry presence authority it never claimed.

The mapping has an identity and several clocks

Every RFC 5222 mapping has source, sourceId and lastUpdated. The authoritative source creates them; caches are not supposed to rewrite them. Together they identify a particular mapping instance, and a receiver may replace the same source/sourceId with a version bearing a later lastUpdated time.

That is a proper version receipt. It is not a universal freshness certificate. lastUpdated says when that mapping instance changed according to its source. It does not reveal when the caller moved, when a responder changed capacity, when DNS changed, or when the returned URI last accepted a session.

The separate expires field sets the mapping's validity horizon. It can carry an absolute time, NO-CACHE, or NO-EXPIRATION. Even here the protocol refuses a simplistic green light. A server may be forced to return an expired mapping as an ordinary, non-warning response. The client must inspect expires and apply local policy.

Cache validity also depends on place. RFC 5222 says a cached answer expires at its time limit or becomes invalid when the device moves beyond the service region. A time-valid record can therefore be location-invalid. Conversely, NO-EXPIRATION does not promise that the institution, endpoint, network or world can never change; it states one mapping policy value.

The minimum useful audit record must therefore retain at least four clocks: location-observation time, mapping lastUpdated, mapping expires, and downstream session time. Replacing them with the dashboard's observation timestamp destroys the ability to tell which claim was stale.

A boundary can be data or a promise to fetch data

A LoST response may include the service boundary by value. It may instead include a reference with an authoritative source and key. The client can express a preference, but the server decides whether to provide a value, a reference or neither.

When a reference is returned, the client sends getServiceBoundary to the named authoritative server. That retrieval does not recurse. This separates two receipts that are often collapsed: a mapping can name a boundary reference, and a later exchange can retrieve the boundary geometry or civic region.

The distinction matters during movement and failure. If a system never resolves the reference, it cannot honestly claim to have tested whether the caller remains inside the region. If it resolves the reference but cannot link the returned boundary to the mapping's source/key and observation time, it has geometry without custody. If the caller moves after the comparison, a formerly correct decision becomes historical evidence.

RFC 5582 places these interactions in the broader location-to-URL architecture. The useful governance pattern is small: the map exposes the region within which its answer can be reused, while the client retains the decision and duty to requery when the evidence no longer fits.

Recursive success has a path, not omniscience

LoST can operate recursively or iteratively. In recursive mode, the first server asks other servers on behalf of the requester. In iterative mode, a server redirects the requester toward the next server. The path element records via entries for the LoST servers involved in recursive handling.

A path is better than a black box. It helps diagnose loops and locate which server emitted a warning or error. But it remains a protocol path, not a proof that every delegation was institutionally legitimate, every DNS answer was protected, every TLS identity check ran, every cache held the newest mapping, or the returned service URI was later reached.

RFC 5222 recommends TLS use and server-identity checking because an attacker can alter queries, poison caches or masquerade as a LoST server. It also acknowledges attacks on DNS-based discovery. RFC 5223 defines DHCP discovery of LoST servers, while RFC 8917 later gives validation services their own discovery tag. Discovery, protected transport, mapping and validation are connected controls precisely because none can stand in for the others.

RFC 5069 treats emergency mapping as a security-sensitive function. TLS can bind a transport peer and protect bytes in transit. It cannot make an inaccurate source location true, make an expired mapping current, or make an unresponsive endpoint answer.

HTTP 200 can carry a LoST failure

RFC 5222 makes a subtle status distinction that every monitoring system should preserve. All LoST responses—including protocol warnings and errors—are carried in HTTP 2xx, typically 200 OK. A 200 status proves that the HTTP exchange completed. It says nothing by itself about whether the LoST XML contains a mapping, warning, error or redirect.

Warnings are especially important because they can travel beside usable-looking data. locationValidationUnavailable says validation could not be performed even though mapping information may be returned. serviceSubstitution says the requested service URN was replaced by another. defaultMappingReturned says the server could not satisfy the given location and instead supplied a default URI, such as a nearby public-safety answering point.

A default answer may be the correct degraded behavior. The error is not returning it; the error is stripping the warning and counting it as an exact-location match. A status pipeline should preserve “default mapping returned” as a first-class outcome, not an annotation discarded before the executive chart.

The RFC Editor's frozen record also matters. The errata page lists two verified errata, one reported erratum and two held for document update. Standards Track status is not evidence that every sentence has escaped correction, nor is an erratum proof that every implementation is defective. The operational question is which text and correction an implementation actually follows.

Synchronization is a different authority surface

RFC 6739 defines how LoST nodes exchange mappings. It reuses source/sourceId/lastUpdated fingerprints, prohibits modifying received mappings and requires authoritative mapping servers to sign distributed mappings so an untrusted participant cannot simply claim a coverage region it does not control.

This is strong backend provenance. It still does not prove that a particular client resolver had already received the newest mapping, selected it under the intended policy, or delivered a session to the resulting URI. Synchronization evidence belongs between the authoritative mapping source and the serving LoST node. Client query evidence belongs between the client and resolver. Call evidence begins after mapping.

The separation is not bureaucratic overhead. It makes a false assertion diagnosable. A bad outcome can come from location acquisition, stale synchronization, cache policy, redirect selection, boundary comparison, URI reachability, signaling or the responder. If all of these are labeled “LoST failed,” the responsible layer disappears.

The URI is a coordinate, not an answered call

RFC 5031 defines service URNs such as the emergency-service namespace. The URN says what class of service is requested. LoST returns where to try to reach that service for a location. A returned SIP, XMPP or tel URI is therefore a routing coordinate with provenance and validity conditions.

RFC 5012 states the wider requirements for emergency context resolution, and RFC 6881 treats mapping as one part of endpoint and network best practice for emergency calling. Downstream signaling still has to resolve and reach the URI, negotiate a session and encounter a service able to accept it.

The smallest honest receipt chain is explicit:

  1. provenance and observation time for the location;
  2. selected location ID and profile;
  3. civic-token validation state where applicable;
  4. requested service URN;
  5. discovery, DNS and TLS identity evidence;
  6. recursive/iterative path and redirect decisions;
  7. source/sourceId/lastUpdated for the mapping;
  8. expires, cache age and movement test;
  9. boundary value or successfully retrieved reference;
  10. returned URI plus every warning or substitution;
  11. downstream session-establishment result;
  12. responder acceptance and operational outcome.

No lower receipt proves the next one. That is not a weakness of LoST. It is how a well-bounded protocol avoids claiming control over systems it does not operate.

Sources

  1. RFC 5222
  2. RFC 5222 on Datatracker
  3. RFC 5222 status
  4. RFC 5222 history
  5. RFC 5222 errata
  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