RFC 6451
Location-to-Service Translation (LoST) Protocol Extensions
RFC 6451: Location-to-Service Translation (LoST) Protocol Extensions 🎀
okay so this one is an Experimental RFC from December 2011 (ISSN 2070-1721) 🦋 Written by A. Forte from AT&T and H. Schulzrinne from Columbia University. It's Experimental, not a Standards Track spec, so it's meant for people to look at, try out, and evaluate. The title block doesn't list anything it obsoletes or updates, so it's totally its own thing 💅
Abstract 💖
An important class of location-based services answers the question, "What instances of this service are closest to me?" 📍 Think finding restaurants, gas stations, stores, ATMs, wireless access points (hot spots), or parking spaces 🅿️ Right now the Location-to-Service Translation (LoST) protocol only maps locations to a single service based on service regions. This document describes an extension that adds "N nearest", "within distance X", and "served by" queries ✨
Status of This Memo 🌸
This document is not an Internet Standards Track specification. It's published so people can examine it, implement it experimentally, and evaluate it 🧪
This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🤓
For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6451 🔗
Copyright Notice 🌈
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved ©️
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚠️
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Service Regions . . . . . . . . . . . . . . . . . . . . . . . 3
4. New <findService> Query Types: "N nearest", "within
distance X", and "served by" . . . . . . . . . . . . . . . . . 4
5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5
5.2. Queries Based on Service Regions . . . . . . . . . . . . . 7
5.3. Difference between "within distance X" and "served by"
Queries . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Limiting the Number of Returned Service URIs . . . . . . . 10
5.5. The <serviceLocation> Element in Responses . . . . . . . . 12
6. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 15
7. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. LoST Extensions RELAX NG Schema Registration . . . . . . . 18
9.2. LoST Extensions Namespace Registration . . . . . . . . . . 19
10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. Normative References . . . . . . . . . . . . . . . . . . . . . 221. Introduction ✨
The Location-to-Service Translation (LoST) protocol [RFC5222] maps service identifiers (URNs) and civic or geospatial information to service URIs, based on service regions. It was originally motivated by mapping locations to the public safety answering point (PSAP) serving that location, but it was designed to generalize to other location-mapping services too 🫶
Here's the catch though: the current LoST query model assumes that each service URI has a service region and that service regions don't overlap. That fits the emergency services model, where a PSAP's service region comes from jurisdictional boundaries. It doesn't work as well for services without clearly defined boundaries 🙈 For example, any location is likely served by a bunch of different restaurants, depending on how far the customer is willing to travel 🍕
So this document adds three more <findService> query types 🎉 Now the protocol can find the N nearest instances of a service, all services within a given distance, and all services whose service region includes the user's current location 💜
2. Requirements Notation 📝
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 [RFC2119] 🔑
3. Service Regions 🗺️
Generally speaking, service regions only apply to a subset of services 🌷
Section 1 of [RFC5222] defines a service region like this:
"To minimize round trips and to provide robustness against network failures, LoST supports caching of individual mappings and indicates the region for which the same answer would be returned ("service region")."
Section 5.5 of [RFC5222] defines it again:
"A response MAY indicate the region for which the service URL returned would be the same as in the actual query, the so-called service region."
For emergency services, the service region and the service area (as defined in [RFC5222]) are the same geographical area. That's because each PSAP serves its own area without overlapping any other PSAP's service area 🚨 As long as the client is in a PSAP's service area, the LoST server returns that same PSAP, so the service region doesn't change. For emergency services, a service region is just the service area of a PSAP 💅
Non-emergency services are a different story 🍔 Different points of service can have different, overlapping service areas. That means one service region will probably include a whole bunch of service areas. Since a query can return a large number of service URIs, a service region under the definition above would be the region where a user gets the same set of service URIs. If one or more URIs in that set change, the set changes, which means the service region changes. So for non-emergency services, the service region defined in [RFC5222] would change frequently, which hugely reduces the benefit of caching responses by service region 😭
Generally speaking, location-based services split into two main categories, based on:
- how far they are from the user (e.g., automatic teller machine, food takeout);
- whether or not their service area includes the user's current location (e.g., pizza delivery, PSAP).
For services in the first category, service areas and therefore service regions aren't relevant. For services in the second category, they're important 🎯 Takeout vs. delivery makes this super clear. With takeout (first category), the user wants to go to a particular restaurant and grab dinner, no matter whether they're inside that restaurant's delivery service area. With delivery (second category), the user cares about the restaurant's service area, because the restaurant will only deliver to them if their location falls inside it 🛵
There's a clear difference between services that need service areas and services that don't, and the LoST extensions in this document take that into account by using the service classification above 🩷
4. New <findService> Query Types: "N nearest", "within distance X", and "served by" 💫
We're adding three new types of <findService> queries: "N nearest", "within distance X", and "served by" 🎀
- The first query returns the N points of interest (POIs) closest to the client's physical location.
- The second query finds all the POIs located within a given distance from the client's physical location.
- The third query returns all the POIs whose service area includes the client's current location.
5. LoST Extensions 🦋
For "within distance X" queries, the LoST client has to tell the server the range to search for instances of a particular service. To do that, we use various shapes [RFC5491] in LoST queries 📐
For "served by" queries, the LoST client needs to let the server know that it MUST return only those services whose service area includes the user's current location 🔥 To make that happen, we introduce the <region> element in <findService> queries. Service region boundaries MAY be returned in a LoST <findServiceResponse>, as described in [RFC5222] 🌸
For "N nearest" queries, the LoST client needs to tell the server N, which is the maximum number of service URIs to return in a response. To specify this, we introduce the <limit> element in <findService> queries 💜
We also introduce a new element in LoST responses, <serviceLocation> 🧚 The server uses it to tell the client where the points of interest physically are. That way the client can compute the distance and other metrics between its current location and each POI 🗺️
The new elements <region>, <limit>, and <serviceLocation> are defined in the "lost-ext" namespace. That new namespace is defined in Section 7 👑
5.1. New Use of Shapes in Queries ✨
okay so in [RFC5491] there are different shapes that describe a point plus the zone of uncertainty around it, aka where the user could be standing 🧭. that's still true for "served by" queries 💅. but for "within distance X" queries, those shapes get a new job: they're the area where we want to find a service 🎯. we search for points of service inside that area because the user's location is inside it with some probability 🥹. think of the uncertainty area as "the user might be somewhere in here," so we look for services in there too. so a "within distance X" query basically sets the user's location uncertainty by hand, using a shape with parameter X 🫶.
here's a slay example 🍕. Figure 1 is a "within distance X" <findService> geodetic query with the circular shape. with this query we're asking the LoST server to send back a list of service URIs for pizza places within 200 meters of our approximate position, which is written in <gml:pos> 🍓.
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>Figure 1: A "within distance X" <findService> geodetic query using the circular shape (a hypothetical service URN of "urn:service:food.pizza" is used)
okay but the circle isn't the only shape that's useful 👀. sometimes you care about services in a direction you're moving, not just one exact physical spot 🚗. like if someone is driving north from New York City to Boston, it'd be so helpful for them to search for stuff north of where they currently are 🙌. not right where they are, and not at the final destination either, bestie 💀.
so this document supports shapes like the ellipse to make direction-of-travel searches work ✨. the ellipse has a major and a minor dimension, so you can define a "privileged" direction by putting the major dimension along the way you're moving 🏃♀️. in this context the circle lets a device search for services in any direction around its physical location, while shapes like the ellipse let it search in a more specific direction 🧭. Figure 2 is a "within distance X" <findService> geodetic query using the elliptical shape. the ellipse shape is defined in Section 5.2.4 of [RFC5491] 📖.
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
1235
</gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
660
</gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
41.2
</gs:orientation>
</gs:Ellipse>
</location>
<service>urn:service:food.pizza</service>
</findService>Figure 2: A "within distance X" <findService> geodetic query using the elliptical shape (a hypothetical service URN of "urn:service:food.pizza" is used)
5.2. Queries Based on Service Regions ✨
okay so as we said back in Section 3, location-based services fall into two big buckets 🪣. the buckets are based on:
- how far they are from the user;
- whether or not their service area includes the user's current location.
a "within distance X" query covers services in the first bucket 📏, and a "served by" query covers services in the second bucket 🗺️.
when you ask LoST about a specific service, you have to say which bucket it's in 🫵. this matters because the LoST server uses a different metric to pick results depending on the bucket, so it's not a detail you can skip 😭.
Figure 3 shows three points of interest and their service areas 📍. the user's location (aka the LoST client location) is a circle, like a GPS fix 🛰️. if POI 1, POI 2, and POI 3 are in the first bucket ("within distance X" query), their service area doesn't matter 🙅♀️. what matters is how far away they are from the user. for those services, the shape of the user's location is the distance the user wants to search within (see Section 5.1). in the example, the LoST server only returns POI 3, since it's the only point of interest inside the user's location circle, which is the area they want to search in 🎯. but if all three are in the second bucket ("served by" query), then their service area is what counts 💜. here the circle overlaps all three service areas, so all three POIs can serve the user, and the LoST server has to return all three: POI 1, POI 2, and POI 3 🫶.
__________________________
\ ***** \
,===============***====, *** \
/ ** \ / ** \
/ POI 1 ** \ / ** \
/ o ** X ** \
/ ** / \ USER ** \
/ ** / \ 0 ** \
/ ** / \ POI 3 ** \
/ ** / \ o ** \
/ ,--------**-/---------\----------**--, \
`=====================** \________**___|___________\
| ** ** |
| o *** *** |
| POI 2 ***** |
`------------------------------------'Figure 3: LoST client location (circle) overlapping three service areas of three different points of interest (POI 1, POI 2, POI 3)
so the client needs a way to say which bucket the service is in 🥹, and that's where the new <region> element comes in 🎀. it's a boolean. when it's false, the LoST server MUST do a search based on the distance between the user and the points of service ("within distance X" query) 📏. when it's true, or when the <region> element is missing (see Section 5.3), the service is in the second bucket, and the LoST server MUST do a search based on service areas ("served by" query) 🗺️. when it's there, the <region> element MUST be sent inside the <findService> element defined in [RFC5222] 💖.
for a search based on service regions, the LoST server MUST only return services whose service area includes the user's current location 🙌. service region boundaries MAY be returned in a LoST <findServiceResponse>, as described in [RFC5222] ✨.
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value" recursive="true">
<ext:region>true</ext:region>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>Figure 4: A "served by" <findService> geodetic query with the new <region> element (a hypothetical service URN of "urn:service:food.pizza" is used)
5.3. Difference between "within distance X" and "served by" Queries 🦋
Figures 1 and 4 show a "within distance X" query and a "served by" query, respectively 👯. they look super similar, but there are three big differences 👀:
- a "served by" query can use all the shapes a "within distance X" query can use, plus the point shape 🔵. the point shape doesn't make sense for a "within distance X" query, so it SHOULD NOT be used there, since it would just be a within-zero-meters search 🙈.
- in a "within distance X" query, we set the uncertainty in user location to X by hand, and then search for services within that uncertain area 🧁. for every other type of query, including "served by," the user can't change the uncertainty level, and the search is based on service areas instead 🌸.
- in a "within distance X" query, the value of the <region> element MUST be set to false 🙅♀️. a "served by" query SHALL have the <region> element set to true 💜. if the <region> element isn't there, its value MUST be assumed to be true, and the query becomes a "served by" query 🫶. this behavior is consistent with [RFC5222] 🎀.
5.4. Limiting the Number of Returned Service URIs ✨
okay so limiting how many results come back is super helpful, especially for mobile devices with limited bandwidth 📱 (bestie, data is precious!!). For "N nearest" queries, the client needs to be able to tell the server to return no more than N service URIs. To do that we add a new element, <limit>. This new element is OPTIONAL, but when it's present it MUST be conveyed inside the <findService> element defined in [RFC5222] 🎀
Figures 5, 6, and 7 show a <findService> geodetic query where the client asks the server for no more than 20 service URIs. Figure 5 is a plain "N nearest" query, Figure 6 mixes "N nearest" with "within distance X", and Figure 7 mixes "N nearest" with "served by". When the LoST server gets these, it returns a list of no more than 20 points of interest 💅
If there are more available points of interest than N, the server has to figure out which N of them are closest to the client's physical location, and it MUST return those in the response 📍 that closest-point logic is giving main character energy.
When the <limit> element is not present in a <findService> query, then all available points of interest for the requested type of service SHOULD be returned by the LoST server. This behavior is consistent with [RFC5222] 🌸
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
serviceBoundary="value" recursive="true">
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>40.7128 -74.0092</gml:pos>
</gml:Point>
</location>
<service>urn:service:food.pizza</service>
</findService>Figure 5: An "N nearest" <findService> geodetic query with the new <limit> element (a hypothetical service URN of "urn:service:food.pizza" is used) 🍕
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
200
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>Figure 6: A <findService> geodetic query with the new <limit> and <region> elements. This query is a combination of the "N nearest" and "within distance X" queries (a hypothetical service URN of "urn:service:food.pizza" is used) 🦋
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
serviceBoundary="value"
recursive="true">
<ext:region>true</ext:region>
<ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>37.775 -122.422</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
100
</gs:radius>
</gs:Circle>
</location>
<service>urn:service:food.pizza</service>
</findService>Figure 7: A <findService> geodetic query with the new <limit> and <region> elements. This query is a combination of the "N nearest" and "served by" queries (a hypothetical service URN of "urn:service:food.pizza" is used) 💜
5.5. The <serviceLocation> Element in Responses
it's important for the LoST client to know where a point of interest is, so it can compute distance, route, and other metrics 🗺️ so we're introducing a new element, <serviceLocation>. It contains the location of a point of service. When it's used, it MUST be contained in a <mapping> element. In responses like <findServiceResponse> [RFC5222], a list of service URIs, each with its own <serviceLocation> element, SHOULD be returned. The order of service URIs in the list is not significant 🌈
The <serviceLocation> element has a single attribute, "profile", that specifies the profile used. Both civic and geodetic profiles can be used. The geodetic profiles SHOULD be used in order to compute distance, route, and other metrics, because at some point computing those metrics would require geocoding the civic address into geodetic coordinates. Because of this, the position specified in <serviceLocation> with a geodetic profile SHOULD be represented by the <Point> element. The <Point> element is described in Section 12.2 of [RFC5222] and in Section 5.2.1 of [RFC5491]. Figure 8 shows a <findServiceResponse> answer containing two location-to-service-URI mappings 🍓
[NOTE: The<locationUsed>element cannot be extended for this purpose, as it is defined outside of the<mapping>element. In particular, in a response, the<locationUsed>element is always one, while the number of service URIs is typically more than one.]
There are situations, however, where it helps to include a civic address together with the geodetic coordinates of a point of service. Usually, databases already contain the civic address of points of interest, and devices with limited capabilities can't always decode geocoordinates to figure out the civic address. Because of this, including the civic address in a response can be useful. To do this, we use a civic profile for the <serviceLocation> element and specify the POI civic address in a <civicAddress> element contained in the <serviceLocation> element. The basic civic location profile is defined in Section 12.3 of [RFC5222] 🏡
Per [RFC5139], it is RECOMMENDED to use multiple <serviceLocation> elements when multiple forms of service location are available, and it is RECOMMENDED to provide a geodetic form whenever possible. When multiple <serviceLocation> elements are present for one POI, all of them MUST be contained in the same <mapping> element, that is, the <mapping> element for that POI. Figure 8 shows a <findServiceResponse> answer with both geodetic and civic locations 🫶
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:ext="urn:ietf:params:xml:ns:lost-ext"
xmlns:gml="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="it">
Che bella pizza e all' anima da' pizza da Toto'
</displayName>
<service>urn:service:food.pizza</service>
<uri>sip:chebella@example.com</uri>
<uri>xmpp:chebella@example.com</uri>
<serviceNumber>2129397040</serviceNumber>
<ext:serviceLocation profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>33.665 -112.432</gml:pos>
</gml:Point>
</ext:serviceLocation>
<ext:serviceLocation profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
<A6>Broadway</A6>
<HNO>321</HNO>
<PC>10027</PC>
</civicAddress>
</ext:serviceLocation>
</mapping>
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9b356">
<displayName xml:lang="en">
King Mario's Pizza
</displayName>
<service>urn:service:food.pizza</service>
<uri>sip:marios@example.com</uri>
<uri>xmpp:marios@example.com</uri>
<serviceNumber>2129397157</serviceNumber>
<ext:serviceLocation profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>33.683 -112.412</gml:pos>
</gml:Point>
</ext:serviceLocation>
<ext:serviceLocation profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
<A6>Amsterdam Avenue</A6>
<HNO>123</HNO>
<PC>10027</PC>
</civicAddress>
</ext:serviceLocation>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>Figure 8: A <findServiceResponse> answer ✨
6. Emergency Services 🚨
The LoST extensions defined in this document SHOULD NOT be used when routing emergency sessions, as there may be LoST servers that do not support these extensions. Not the place to be experimenting, bestie 🙈
Figure 9 shows a <findService> query for emergency services as defined in [RFC5222]. In such a query, both the <region> element and the <limit> element are missing. According to the LoST extensions defined in this document, when the <region> element is missing, its value defaults to true, and the query is a "served by" query (see Section 5.3). When the <limit> element is missing, no limit is specified, which means the LoST server can return any number of results (see Section 5.4). This behavior is consistent with [RFC5222], so PSAPs are selected according to their service area, and when a user's location overlaps multiple service areas, the LoST server MAY return multiple PSAPs 🚓
The LoST extensions defined in this document are consistent with the behavior defined in [RFC5222], and, as such, they do not modify LoST behavior for emergency services 💖
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
</findService>Figure 9: A <findService> geodetic query for emergency services
Unlike emergency services, where information such as service boundaries of PSAPs and locations of fire stations doesn't change very often, if at all, non-emergency services have information that may become inaccurate quickly. Implementers should take this into account when designing applications for non-emergency location-based services 🌷
7. RELAX NG Schema ✨
okay so this section gives us the RELAX NG schema for the LoST extensions in the compact form 🎀 the verbose form shows up later in Section 9, so no stress if you want the long version 💅
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"
##
## Extensions to the Location-to-Service Translation (LoST)
## Protocol
##
## LoST Extensions define three new elements: limit, region, and
## serviceLocation.
##
start =
limit
| region
| serviceLocation
##
## A limit to the number of returned results.
##
div {
limit=
element limit {
xsd:positiveInteger
}
}
##
## A boolean variable to request a search
## based on either service areas or distance.
##
## NOTE: The W3C XML Schema has two different
## lexical representations for boolean:
## '1' or 'true' vs. '0' or 'false'.
##
div {
region=
element region {
xsd:boolean
}
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Location Information about the returned point
## of service.
##
div {
serviceLocation=
element serviceLocation { locationInformation }+
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST Extensions
## namespace.
##
notLostExt = element * - (ns1:* | ns1:*) { anyElement }
##
## A wildcard pattern for including any element
## from any other namespace.
##
anyElement =
(element * { anyElement }
| attribute * { text }
| text)*
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLostExt*
}8. Security Considerations 🔥
okay bestie, this one is SERIOUS 😭 the whole LoST setup is defined in [RFC5582], so go there for the full picture 🧚
so the deal is: every LoST query, emergency or not, gets sent from the LoST client to a first-hop LoST server (unless it's already cached) 💌 in [RFC5582] lingo, the client is the Seeker and that first-hop server is the Resolver ✨ the Resolver then reaches out to other LoST servers until it finds an authoritative one, and the answer gets sent back to the Seeker 🎀 for the proper definitions, go read [RFC5582] 💖
now the spicy part 🌶️ the Resolver could get overloaded by non-emergency queries and then not be able to handle emergency ones 💀 that's a big no-no 🙈 the service provider can dimension the LoST server for the combined traffic they expect, then prioritise emergency requests when things get overloaded, maybe with a little help from HTTP load balancers 🫶
The security considerations in [RFC5222] apply. In particular, in order to maintain integrity and confidentiality of requests and responses, Transport Layer Security (TLS) MUST be implemented and SHOULD be used as described in Sections 1, 14, and 18 of [RFC5222]. 🔐
translation: TLS MUST be implemented, and it SHOULD be used, following Sections 1, 14, and 18 of [RFC5222] 🔒 that's how you keep requests and responses private and untampered, so please don't skip it 😭💅
9. IANA Considerations 📋
9.1. LoST Extensions RELAX NG Schema Registration 🌸
the registration URI is urn:ietf:params:xml:schema:lost-ext 💜
the registrant contacts are Andrea G. Forte (forte@att.com) and Henning Schulzrinne (hgs@cs.columbia.edu) 🧚
the RELAX NG schema being registered is the one in Section 7 ✨ its first line is:
default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext"and its last line is:
}9.2. LoST Extensions Namespace Registration 🦋
the registration URI here is urn:ietf:params:xml:ns:lost-ext 🌈
same registrant contacts: Andrea G. Forte (forte@att.com) and Henning Schulzrinne (hgs@cs.columbia.edu) 💖
the XML for this one looks like:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Extensions Namespace</title>
</head>
<body>
<h1>Namespace for LoST Extensions</h1>
<h2>urn:ietf:params:xml:ns:lost-ext</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6451.txt">
RFC 6451</a>.</p>
</body>
</html>
END10. Non-Normative RELAX NG Schema in XML Syntax 🧚
this is the same schema but in XML syntax, so it's not normative (aka it's a helper, not the official rule) 💅
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost-ext"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
Extensions to the Location-to-Service Translation (LoST)
Protocol.
LoST Extensions define three new elements: limit, region and
serviceLocation.
</a:documentation>
<choice>
<ref name="limit"/>
<ref name="region"/>
<ref name="serviceLocation"/>
</choice>
</start>
<div>
<a:documentation>
A limit to the number of returned results.
</a:documentation>
<define name="limit">
<element name="limit">
<data type="positiveInteger"/>
</element>
</define>
</div>
<div>
<a:documentation>
A boolean variable to request a search
based on either service areas or distance.
</a:documentation>
<define name="region">
<element name="region">
<data type="boolean"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location Information
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
Location Information about the returned point of service.
</a:documentation>
<define name="serviceLocation">
<element name="serviceLocation">
<ref name="locationInformation"/>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLostExt">
<a:documentation>
Any element not in the LoST Extensions namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost-ext"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any element
from any other namespace.
</a:documentation>
<zeroOrMore>
<choice>
<element>
<anyName/>
<ref name="anyElement"/>
</element>
<attribute>
<anyName/>
</attribute>
<text/>
</choice>
</zeroOrMore>
</define>
<define name="extensionPoint">
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="notLostExt"/>
</zeroOrMore>
</define>
</div>
</grammar>11. Acknowledgments 💖
big thank-you to Shida Schubert for reviewing an early version of this doc 🫶 also shoutout to the ECRIT working group for their suggestions 🌸 and extra love to Richard L. Barnes, Robert Sparks, and Martin Thomson for their overall feedback, plus their comments on how non-emergency services can affect emergency services lookups 🚨✨
12. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.
Authors' Addresses 🎀
Andrea G. Forte
AT&T
Security Research Center
33 Thomas Street
New York, NY 10007
USA
EMail: forte@att.com
Henning Schulzrinne
Columbia University
Department of Computer Science
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
EMail: hgs@cs.columbia.edu📦 where this page comes from
- ietf: rfc6451 2011-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms