LoST: A Location-to-Service Translation Protocol
updated by
- rfc-6848 — Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
- rfc-8917 — The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
- rfc-9036 — Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy
Extracted elements (30)
Service boundary references rather than inline values are offered because geodetic boundaries can contain thousands of points. The 128-bit random key is globally unique and tied to a specific boundary version; clients can safely cache boundaries across multiple service URL refresh cycles without re-fetching unchanged boundary data.
Two mandatory baseline location profiles (geodetic-2d and civic) are defined rather than a single universal profile because civic and geodetic location information are fundamentally different in nature; mixing them in a single request would require separate requests anyway, and the two-profile baseline ensures all conformant implementations share common ground.
If a client sends location information conformant to a non-baseline profile, it MUST also include location information conformant to one of the two baseline profiles in the same request; otherwise a server that does not support the non-baseline profile cannot understand the request.
Multiple <serviceBoundary> elements formatted according to different location profiles within a single <findServiceResponse> are alternative representations of the same area, not additive geometries. However, multiple location elements within a single <serviceBoundary> element are additive, allowing non-contiguous service regions.
All LoST clients and servers MUST understand UTF-8 and UTF-16 encoded XML, and MUST NOT encode XML with any other encoding.
If a service boundary changes, a new identifier MUST be chosen for the <serviceBoundaryReference> key. Clients holding a boundary for a known key can therefore skip re-fetching it without consulting the server.
LoST over HTTP uses the POST method. HTTP requests MUST include the Cache-Control 'no-cache' directive to prevent stale responses from HTTP caches. All LoST responses, including errors and warnings, are carried in HTTP 2xx responses.
Requests MUST contain location information conformant to exactly one of the two baseline profiles (geodetic-2d or civic), plus zero or more additional profiles. A client MUST NOT send <location> elements derived from different baseline profiles in the same request.
Servers MUST implement all location profiles defined in this document (geodetic-2d and civic). If a server receives a request containing only unrecognized profiles, it responds with a <locationProfileError>.
Service URLs returned in <uri> elements MUST be absolute URLs. Each URL scheme MUST appear at most once, though both secured and unsecured versions of a protocol (e.g., 'sip' and 'sips') may coexist.
The <mapping> element MUST include the 'expires' attribute containing the absolute time (timezoned XML dateTime) at which the mapping becomes invalid. Alternatively, the attribute may contain 'NO-CACHE' or 'NO-EXPIRATION'.
The <serviceBoundary> element in a response MUST use the same location profile that was used to retrieve the answer and MUST indicate that profile via the 'profile' attribute.
The 'sourceId' attribute MUST be unique among all different mappings maintained by the authoritative source for a particular service. A UUID is a suitable format. All three of 'source', 'sourceId', and 'lastUpdated' are REQUIRED for every <mapping> element.
There MUST NOT be more than one <location> element for each distinct location profile in a <findService> request. The server uses the first location element whose profile it understands and ignores the others.
When a server returns an alternative service because the requested service is unavailable at the queried location, it MUST include a <service> element with the alternative service URN in the mapping response.
LoST errors are returned in an <errors> element when no useful response can be produced; warnings are returned in a <warnings> element alongside a partial response. Both carry a 'source' attribute naming the originating server. Defined conditions include badRequest, forbidden, internalError, loop, locationInvalid, locationProfileUnrecognized, notFound, serviceNotImplemented, serverTimeout, and serverError.
The <findService> request maps a location (one or more <location> elements) and a service URN to one or more service URIs. Attributes control recursion ('recursive'), service boundary format ('serviceBoundary'), and optional civic address validation ('validateLocation'). The <findServiceResponse> returns one or more <mapping> elements.
The geodetic-2d location profile supports Point, Polygon, Circle, Ellipse, and ArcBand shapes. When a non-Point shape spans multiple service areas, a server MAY return multiple <mapping> elements; servers are not required to return all mappings to prevent denial-of-service via very large query areas.
The <locationUsed> element in a response identifies by its 'id' attribute which <location> element from the request the server actually used to produce the mapping result.
The <locationValidation> response element enumerates civic address tokens as <valid> (used for mapping), <invalid> (checked but incorrect), or <unchecked> (not evaluated). Tokens absent from all three lists are implicitly unchecked. The server SHOULD include this when 'validateLocation' was true in the request.
The <mapping> element is the core data element in LoST, describing a service region and associated service URLs. It carries mandatory attributes 'source', 'sourceId', 'lastUpdated', and 'expires', plus child elements for displayName, service, serviceBoundary or serviceBoundaryReference, one or more <uri> elements, and an optional <serviceNumber>.
The <path> element tracks the chain of LoST servers through which a request has passed using one or more <via> child elements, each carrying a LoST application unique string. It is used to prevent loops and enable request tracing; the authoritative server copies it verbatim into the response.
The <serviceBoundaryReference> element returns a globally unique 'key' (a random token with at least 128 bits of entropy) and a 'source' attribute identifying the authoritative server from which the full boundary can be retrieved via a <getServiceBoundary> request.
This document creates the LoST Location Profile Registry (Standards Action required), with initial entries 'geodetic-2d' (two-dimensional geodetic profile defined in Section 12.2) and 'civic' (basic civic address profile defined in Section 12.3).
This document registers the MIME media type 'application/lost+xml' (file extension .lostxml) for carrying LoST protocol payloads in HTTP exchanges.
This document registers the U-NAPTR application service tag 'LoST' and application protocol tags 'http' and 'https' for LoST server discovery via U-NAPTR/DDDS. LoST server names are DNS domain names resolved through U-NAPTR to obtain HTTP or HTTPS URLs.
An attacker who can eavesdrop on LoST lookup requests can infer the existence and possibly the nature of an emergency, potentially enabling a physical attack on the caller. This threat motivates confidentiality protection via TLS.
Server identity checks as described in RFC 2818 Section 3.1 are RECOMMENDED. The hostname compared against the server certificate is the hostname in the URI returned by U-NAPTR, not the DNS name used as input to NAPTR resolution. Omitting the check allows an attacker to masquerade as a LoST server.
TLS MUST be implemented and SHOULD be used for both client-to-server and server-to-server LoST queries. Server-to-server TLS is specifically recommended to prevent cache poisoning attacks in which an attacker replaces answers given to caching LoST servers.
LoST operates in recursive or iterative mode per request, controlled by the 'recursive' attribute. In recursive mode the contacted server queries other servers on the client's behalf; in iterative mode it returns a redirect to the next server. A server MUST NOT recurse if 'recursive' is 'false', but MAY always return a redirect (indirection).