The LoST Protocol [RFC 5222
] defines a mapping service with the additional ability for a client to request that a civic address be validated. The LoST protocol allows servers to ignore a request to perform location validation. The National Emergency Number Association (NENA) has defined an architecture for all-IP emergency services (known as "i3" [NENA-i3
]), which defines the mapping (routing) and validation functions as two distinct functional elements, defined as an Emergency Call Routing Function (ECRF) and a Location Validation Function (LVF). NENA i3 requires that the mapping (ECRF) and validation (LVF) functions be separable; an entity responsible for a LoST server cluster can decide to provide mapping and validation services using consolidated or separate server clusters (i.e., using the same or separate boxes). The rationale is that the mapping service is used in real time during emergency call routing, while the validation service is used in advance, typically when data is provisioned; therefore, the mapping service has much higher availability and response-time requirements than the validation service. An organization might choose to deploy these services using different server clusters to make it easier to provide higher levels of service for the mapping function while shielding it from the potentially bursty load of validation. Another organization might choose to use the same sets of servers for both services, configured and deployed to offer the high service level demanded of the mapping service.
In order to permit this separability, any entity querying a LoST server needs to be able to resolve an Application Unique String (AUS) into a URL for a LoST server designated for the required service (mapping or validation). This separability needs to be maintained throughout the LoST tree structure, from forest guide to leaf node (LoST architecture is described in [RFC 5582
]). Because LoST referrals return an AUS rather than a URL, either a different service tag or a DNS name convention (e.g., "ecrf.example.org" and "lvf.example.org") is needed to differentiate between the services. DNS name conventions are inflexible and fragile, making a different service tag the preferred approach.
Because LoST servers may ignore a request to perform location validation, a service tag explicitly for location validation also reduces the likelihood (which has existed since [RFC 5582
]) that a client needing location validation will reach servers that are not doing so (due to configuration and/or conditions).
The key words "MUST
", "MUST NOT
", "SHALL NOT
", "SHOULD NOT
", "NOT RECOMMENDED
", and "OPTIONAL
" in this document are to be interpreted as described in BCP 14 [RFC 2119
] [RFC 8174
] when, and only when, they appear in all capitals, as shown here.