nic.at GmbH

Karlsplatz 1/2/9 Wien A-1010 Austria +43 1 5056416 37 karlheinz.wolf@nic.at http://www.nic.at/

RAI ECRIT LoST listservicesbylocation LoST is able to map service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the response from the LoST server does not give information about the geographical region, for which the returned service list is valid. Therefore this document proposes a ServiceListBoundary, in addition to the ServiceBoundary (which indicates the region a specific service URL is valid).

Location based service providers as well as Public Safety Answering Points only serve a specific geographic region. Therefore the LoST protocol defines the ServiceBoundary, which indicates the service region for a specific service URL. However, not all services are available everywhere. Clients can discover available services for a particular location by the <listServicesByLocation> query. The LoST server returns a list of services that are available at this particular location. But the server does not inform the client, for which geographical region the returned service list is valid. This may lead to the situation where a client initially discovered all available services by the <listServicesByLocation> query, and then moves to a different location while refreshing the service mappings, but does not notice the availability of another service. The following imaginary example illustrates the problem for emergency calling: The client is powered-up, does location determination (resulting in location A) and performs an initial <listServicesByLocation> query with location A requesting urn:services:sos. The LoST server returns the following services list: The client does the initial LoST mapping and discovers the dialstrings for these services. Then the client moves, refreshing the service mappings when necessary as told by the ServiceBoundary. However, when arriving in location B (close to a mountain), service:sos:mountainrescue is available (which is not available in location A). Nevertheless, the client does not detect this, because only the initially learned services (police, ambulance, fire) are refreshed. Consequently the dialstring for the mountainrescue is not known by the client, and the emergency call to the mountainrescue will certainly fail. Note that the ServiceBoundary (service region for an individual service) cannot be considered as an indicator for the region a specific service list is valid for. The service list may even change within the ServiceBoundary of another service. For example, the ambulance mapping is valid for a whole state, but for a part of the state there is an additional mountain rescue service. Consequently, there are two ways to tackle this issue: clients continuously ask for the service list (although it may not have changed) an additional boundary indicating the region, a specific service list is valid for (in the style of the ServiceBoundary) Since the LoST protocol has the ServiceBoundary concept in order to avoid that clients continuously try to refresh the mapping of a specific service, a ServiceListBoundary would provide a similar mechanism for service lists.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This chapter describes the necessary modifications to the LoST protocol in order to support the proposed ServiceListBoundary in a similar way as the ServiceBoundary.

The query <ListServicesByLocation> may contain an additional serviceListBoundary attribute to request the boundary for the service list returned, either by value or by reference. 48.1454 16.3774 urn:service:sos ]]> A possible response is shown below: urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.poison urn:service:sos.police AT Lower Austria ]]> This exemplary response indicates that the service list is valid for Lower Austria. The <listServicesByLocation> request has to be repeated only when moving out of Lower Austria. However, the mappings of the services itself may have other service boundaries. Additionally, the expires attribute indicates the absolute time when this service list becomes invalid. The boundary can also be requested by reference when setting the attribute serviceListBoundary to "reference". Then the response contains a serviceListBoundaryReference element: ]]>

In order to retrieve the boundary for a specific service list, the client issues a <getServiceListBoundary> request, similar to the <getServiceBoundary> request. An example is shown below: ]]> The LoST server response is shown below: US New York New York ]]>

The service list boundary indicates a region within which all <listServicesByLocation> queries with the same service identifiers result in the same serviceList. A service list boundary may consist of geometric shapes (both in civic and geodetic location format), and may be non-contiguous, like the service boundary. The mapping of the specific services within the service list boundary may be different at different locations. There is no need to include boundary information to a <listServiceResponse>. <ListServices> requests are purely for diagnostic purposes and do not contain location information at all, so no boundary information is reasonable.

Security considerations are discussed in .

TODO.