RFC 5222
LoST: A Location-to-Service Translation Protocol
RFC 5222: LoST: A Location-to-Service Translation Protocol 🎀
Okay bestie, this is RFC 5222, and it's a whole Standards Track spec from August 2008 🌸 Here's the title block, all the important deets in one spot:
- Series: Network Working Group
- Category: Standards Track
- Date: August 2008
- Authors: T. Hardie (Qualcomm, Inc.), A. Newton (American Registry for Internet Numbers), H. Schulzrinne (Columbia University), and H. Tschofenig (Nokia Siemens Networks) 👑
- Obsoletes / Updates: the title block doesn't list any, so this one doesn't obsolete or update anything 🦋
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract ✨
So, this document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs 🗺️ The big use case is figuring out the location-appropriate Public Safety Answering Point (PSAP) for emergency services 🚨
Table of Contents 📚
Here's the table of contents, copied over exactly as it appears in the original:
1. Introduction .................................................. 3
2. Terminology and Requirements Notation ......................... 4
3. Overview of Protocol Usage .................................... 5
4. LoST Servers and Their Resolution ............................ 6
5. The <mapping> Element ........................................ 7
5.1. The Mapping Data Source: 'source', 'sourceId', and
'lastUpdated' Attributes .................................. 7
5.2. Mapping Validity: The 'expires' Attribute ................ 8
5.3. Describing the Service with the <displayName> Element .... 8
5.4. The Mapped Service: The <service> Element ................. 8
5.5. Defining the Service Region with the <serviceBoundary>
Element .................................................. 9
5.6. Service Boundaries by Reference: The
<serviceBoundaryReference> Element ........................ 9
5.7. The Service Number: The <serviceNumber> Element ......... 10
5.8. Service URLs: The <uri> Element ......................... 10
6. Path of a Request: The <path> Element ....................... 10
7. Identifying the Location Element Used for Mapping:
<locationUsed> ............................................... 11
8. Mapping a Location and Service to URLs: <findService> ....... 11
8.1. Overview ................................................. 11
8.2. Examples ................................................. 11
8.2.1. Example Using Geodetic Coordinates ................... 11
8.2.2. Civic Address Mapping Example ....................... 13
8.3. Components of the <findService> Request ................. 15
8.3.1. The <location> Element ............................... 15
8.3.2. Identifying the Service: The <service> Element ..... 16
8.3.3. Recursion and Iteration ............................. 16
8.3.4. Service Boundary ..................................... 16
8.3.5. Requesting Civic Location Validation ................. 16
8.4. Components of the Mapping Response
<findServiceResponse> ................................... 18
8.4.1. Overview ............................................. 18
8.4.2. Civic Address Validation: The <locationValidation>
Element ............................................. 19
9. Retrieving the Service Boundary via <getServiceBoundary> ..... 19
10. List Services: <listServices> ............................... 21
11. List Services By Location: <listServicesByLocation> ......... 22
12. Location Profiles ........................................... 24
12.1. Location Profile Usage ................................... 25
12.2. Two-Dimensional Geodetic Profile ......................... 30
12.3. Basic Civic Profile ..................................... 31
13. Errors, Warnings, and Redirects ............................. 32
13.1. Errors ................................................... 32
13.2. Warnings ................................................. 34
13.3. Redirects ............................................... 36
14. LoST Transport: HTTP ......................................... 36
15. Relax NG Schema ............................................. 37
16. Internationalization Considerations ......................... 44
17. IANA Considerations ......................................... 44
17.1. U-NAPTR Registrations ................................... 44
17.2. Content-Type Registration for 'application/lost+xml' ..... 44
17.3. LoST Relax NG Schema Registration ....................... 46
17.4. LoST Namespace Registration ............................. 46
17.5. LoST Location Profile Registry ........................... 47
18. Security Considerations ..................................... 47
19. Acknowledgments ............................................. 48
20. References ................................................... 51
20.1. Normative References ..................................... 51
20.2. Informative References ................................... 52
Appendix A. Non-Normative RELAX NG Schema in XML Syntax ......... 54
Appendix B. Examples Online ..................................... 671. Introduction 🌟
Okay, so protocols like Naming Authority Pointer (NAPTR) records and the Service Location Protocol (SLP) can be used to discover servers offering a particular service 🔍 But for an important class of services, the right specific service instance depends on BOTH the identity of the service AND the geographic location of the entity that needs to reach it 📍 Emergency telecom is the big example here. The service instance is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the user making the call 🚨 The desired PSAP isn't necessarily the one that's topologically or even line-of-sight closest to the caller. It's the one that serves the caller's location based on jurisdictional boundaries 🗺️ Not the closest one, the right one. Main character energy 💅
This document describes a protocol for mapping a service identifier and location information compatible with the Presence Information Data Format Location Object (PIDF-LO) [6] to one or more service URIs 🦋 Service identifiers take the form of the service URNs described in [9]. Location information here includes revised civic location information [10] and a subset of the PIDF-LO profile [13], which consequently includes the Geo-Shapes [12] defined for GML [11]. Example service URI schemes include sip [14], xmpp [15], and tel [16] 📞 The initial focus is on mapping functions for emergency services, but it's likely that the protocol is applicable to other service URNs too 💜 For example, in the United States, the "2-1-1" and "3-1-1" service numbers follow a similar location-to-service behavior as emergency services 🌸
This document names this protocol "LoST", for Location-to-Service Translation ✨ LoST satisfies the requirements [18] for mapping protocols. It provides a number of operations, centered around mapping locations and service URNs to service URLs and associated information 🎀 LoST mapping queries can contain either civic or geodetic location information. For civic addresses, LoST can indicate which parts of the civic address are known to be valid or invalid, which gives you address validation, as described in Section 3.5 of [18] 🏠 LoST indicates errors in the location data to facilitate debugging and proper user feedback, but it also provides best-effort answers. Iconic behavior, honestly 🫶
LoST queries can be resolved recursively or iteratively 🔁 To minimize round trips and to provide robustness against network failures, LoST supports caching of individual mappings. It also indicates the region for which the same answer would be returned, called the "service region" 🧚
As defined in this document, LoST messages are carried in HTTP and HTTPS protocol exchanges. That makes it easy to use TLS for protecting the integrity and confidentiality of requests and responses 🔐 Safety first, bestie 💜
This document focuses on the protocol between the mapping client and the mapping server 🤝 Other functions, like discovery of mapping servers, data replication, and the overall mapping server architecture, are described in a separate document [19] 📄
Here's the flow: the query message carries location information and a service identifier, encoded as a Uniform Resource Name (URN) (see [9]), from the LoST client to the LoST server 📨 The LoST server uses its database to map those input values to one or more Uniform Resource Identifiers (URIs), then returns those URIs along with optional information, such as hints about the service boundary, in a response message to the LoST client 💖 If the server can't resolve the query itself, it may in turn query another server, or return the address of another LoST server, identified by a LoST server name 🔄 On top of the mapping function described in Section 8, the protocol also lets you retrieve the service boundary (see Section 9), list the services available for a particular location (see Section 11), or list the services supported by a particular server (see Section 10) 🍓
2. Terminology and 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 [1]. Those are the official requirement words, so pay attention when you see them 👀
This document uses the following terms:
Mapping 🗺️ Mapping is a process that takes a location and a service identifier as inputs and returns one or more URIs. Those URIs can point either to a host providing that service or to a host that in turn routes the request to the final destination. This definition is a generalization of the term "mapping" as used in [18], because LoST can be used for non-emergency services too 🌈
LoST client 📱 A host acts as a LoST client if it sends LoST query messages and receives LoST response messages 💌
LoST server 🖥️ A host acts as a LoST server if it receives LoST query messages and sends LoST response messages. In recursive operation, the same entity may be both a client and a server 🔁
Authoritative LoST server 👑 An authoritative server acts only as a server and successfully resolves the input location and service identifier to a URI or set of URIs. Queen behavior 👑
Service boundary 🧱 A service boundary circumscribes the region within which all locations map to the same service URI or set of URIs for a given service. A service boundary may consist of several non-contiguous geometric shapes 🔷
Validation ✅ The term "validation" describes the behavior defined as "location validation" in Section 3.5 of [18] 🫧
Additional emergency service terminology can be found in [18] 🚑
⏭️ Part 1 of 11 done, bestie! More parts coming, so stay tuned 💅✨
3. Overview of Protocol Usage 🧚
okay so LoST has a few different query and response pairs, and each one is basically its own mini mission 💅
<findService>and<findServiceResponse>: A LoST client retrieves contact URIs based on location information and a service identifier with this request and response. The same query type may also ask for location validation and for service numbers, either combined with a mapping request or separately. The details can be found in Section 8.<getServiceBoundary>and<getServiceBoundaryResponse>: A LoST client obtains a service boundary with this request and response, as described in Section 9.<listServices>and<listServicesResponse>: With this request and response, a LoST client can find out which services a LoST server supports, as described in Section 10.<listServicesByLocation>and<listServicesByLocationResponse>: A LoST client can determine with this request and response which services are available for a specific location region. Section 11 describes the details.
LoST clients may initiate any of the above queries at any time 🌸 The common triggers are:
- when the client initially starts up or attaches to a network;
- when the client detects that its location has changed sufficiently that it is outside the bounds of the service region;
- when a SIP message arrives at a SIP proxy performing location-based call routing;
- when cached mapping information has expired; and
- when invoking a particular service. At that time, a client may omit requests for service boundaries or other auxiliary information.
A service-specific Best Current Practice (BCP) document, such as [21], governs whether a client is expected to invoke the mapping service just before needing the service or whether to rely on cached answers. Cache entries expire at their expiration time (see Section 5.2), or they become invalid if the caller's device moves beyond the boundaries of the service region. Service-specific Best Current Practice documents may also provide guidance on the contact URI schemes most appropriate to the service. As a general set of guidelines, URI schemes that do not provide mechanisms for actually initiating a contact method should be avoided (examples include data, info, cid, and tag) as transforming those references into contact mechanisms requires a layer of indirection that makes the overall mechanism more fragile. Provisionally registered URI schemes should also be carefully considered before use, because they are subject to change in core semantics 🦋
4. LoST Servers and Their Resolution 🎀
LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ Dynamic Delegation Discovery Service) [8] application unique strings, in the form of a DNS name. An example is 'lostserver.example.com'.
Clients need to use the U-NAPTR [8] specification described below to obtain a URI (indicating host and protocol) for the applicable LoST service. In this document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any valid HTTP URL, including those containing path elements.
The following two DNS entries show the U-NAPTR resolution for "example.com" to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL http://lostserver.example.com, with the former being preferred 👑
example.com.
IN NAPTR 100 10 "u" "LoST:https"
"!.*!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http"
"!.*!http://lostserver.example.com!" ""Clients learn the LoST server's host name by means beyond the scope of this specification, such as SIP configuration and DHCP [25].
5. The <mapping> Element 🗺️
The <mapping> element is the core data element in LoST, describing a service region and the associated service URLs. Its attributes and elements are described in subsections below. main character energy ✨
5.1. The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated' Attributes 🔖
The 'source', 'sourceId', and 'lastUpdated' attributes uniquely identify a particular mapping record. They are created by the authoritative source for a mapping and are never modified when a mapping is served from a cache. All three attributes are REQUIRED for all <mapping> elements. A receiver can replace a mapping with another one having the same 'source' and 'sourceId' and a more recent time in 'lastUpdated'.
The 'source' attribute contains a LoST application unique string identifying the authoritative generator of the mapping (Section 4).
The 'sourceId' attribute identifies a particular mapping and contains an opaque token that MUST be unique among all different mappings maintained by the authoritative source for that particular service. For example, a Universally Unique Identifier (UUID) is a suitable format.
The 'lastUpdated' attribute describes when a specific instance of mapping, identified by the combination of 'source' and 'sourceId', was last changed. The contents of this attribute has the XML data type dateTime in its timezoned form, using the canonical UTC representation with the letter 'Z' as the timezone indicator.
5.2. Mapping Validity: The 'expires' Attribute ⏰
The 'expires' attribute contains the absolute time at which the mapping becomes invalid. The contents of this attribute is a timezoned XML type dateTime, in canonical representation. The <mapping> element MUST include the 'expires' attribute.
Optionally, this attribute may contain the values of 'NO-CACHE' and 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is an indication that the mapping should not be cached. The value of 'NO-EXPIRATION' is an indication that the mapping does not expire.
On occasion, a server may be forced to return an expired mapping if it cannot reach the authoritative server or the server fails to return a usable answer. Clients and servers MAY cache the mapping so that they have at least some information available. Caching servers that have such stale information SHOULD re-attempt the query each time a client requests a mapping. Since the expired mapping will be returned to the client as a non-error/non-warning response, the client MUST check the 'expires' attribute; if the mapping has expired, local policy at the client determines whether it discards the answer and tries again later or uses the possibly stale response. 🫶
5.3. Describing the Service with the <displayName> Element 💬
Zero or more <displayName> elements describe the service with a string that is suitable for display to human users, each annotated with the 'xml:lang' attribute that contains a language tag to aid in the rendering of text.
5.4. The Mapped Service: The <service> Element 🎯
The mandatory <service> element identifies the service for which this mapping applies. Two cases need to be distinguished when the LoST server sets the <service> element in the response message:
- If the requested service, identified by the service URN [9] in the
<service>element of the request, exists for the location indicated, then the LoST server copies the service URN from the request into the<service>element. - If, however, the requested service, identified by the service URN [9] in the
<service>element in the request, does not exist for the location indicated, the server either can return a<serviceNotImplemented>(Section 13.1) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a<service>element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request.
5.5. Defining the Service Region with the <serviceBoundary> Element 🌍
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. The service region can be indicated by value or by reference (see Section 5.6). If a client moves outside the service area and wishes to obtain current service data, it sends a new query with its current location. The service region is described by value in one or more <serviceBoundary> elements, each formatted according to a specific location profile, identified by the 'profile' attribute (see Section 12). <serviceBoundary> elements formatted according to different location profiles are alternative representations of the same area, not additive to one another; this allows a client understanding only one of the profile types to be sure it has a complete view of the serviceBoundary. Within a serviceBoundary element there may, however, be multiple locations which are additive; this is necessary because some <serviceBoundary> areas could not be easily expressed with a single shape or civic location. If included in a response, the <serviceBoundary> element MUST contain at least one service boundary that uses the same profile as the request.
A service boundary is requested by the client, using the 'serviceBoundary' attribute in the request with the value set to "value".
5.6. Service Boundaries by Reference: The <serviceBoundaryReference> Element 🔗
Since geodetic service boundaries may contain thousands of points and can thus be quite large, clients may wish to conserve bandwidth by requesting a reference to the service boundary instead of the value described in Section 5.5. The identifier of the service boundary is returned as an attribute of the <serviceBoundaryReference> element, along with a LoST application unique string (see Section 4) identifying the server from where it can be retrieved. The actual value of the service boundary is then retrieved with the getServiceBoundary (Section 9) request.
A reference to a service boundary is requested by the client using the 'serviceBoundary' attribute in the request with the value set to "reference". A LoST server may decide, based on local policy, to return the service boundary by value or to omit the <serviceBoundaryReference> element in the response.
The identifier is a random token with at least 128 bits of entropy and can be assumed to be globally unique. It uniquely references a particular boundary. If the boundary changes, a new identifier MUST be chosen. Because of these properties, a client receiving a mapping response can simply check if it already has a copy of the boundary with that identifier. If so, it can skip checking with the server whether the boundary has been updated. Since service boundaries are likely to remain unchanged for extended periods of time, possibly exceeding the normal lifetime of the service URL, this approach avoids unnecessarily refreshing the boundary information just because the remainder of the mapping has become invalid 🧚♀️
5.7. The Service Number: The <serviceNumber> Element 📞
The service number is returned in the optional <serviceNumber> element. It contains a string of digits, * and # that a user on a device with a 12-key dial pad could use to reach that particular service. 🌈
5.8. Service URLs: The <uri> Element ✨
okay so the response hands back the service URLs inside one or more <uri> elements 🔗. These URLs MUST be absolute URLs, no shortcuts 🙅♀️. The order of the URLs doesn't mean anything, so don't read into it 💅. Each URL scheme MUST only appear at most once, but you're totally allowed to include both the secured and regular versions of a protocol, like both http and https or sip and sips 🔐✨.
6. Path of a Request: The <path> Element 🛤️
bestie, this is how we stop requests from going in circles forever 🌀 and how we get to trace where a request and its response have been. Every request that allows recursion includes a <path> element, and that element holds one or more <via> elements 🦋. Each <via> has an attribute with a LoST application unique string in it (see Section 4) 💜. The order of the <via> elements matches the order of the LoST servers, so the first <via> is the server that got the request first from the client who sent it 🥇. Every single server in a recursive query gets listed in <path>, and that includes the very first server that received it 📋.
The server that answers instead of passing the request along, like the authoritative server, copies the <path> element word for word into its response 🫶. The <path> element doesn't get changed as the response travels back through the server chain to the querying client 🔁. Iconic consistency, no cap 👑.
If a query gets answered iteratively, the querier includes every server it has already contacted 📞. And when a cached mapping gets returned, the <path> element that was cached along with that mapping comes back too 🗂️.
The example in Figure 4 shows that the client got its answer from the LoST server at esgw.ueber-110.de.example, and that server got the answer from the (authoritative) LoST server at polizei.muenchen.de.example 🇩🇪✨.
7. Identifying the Location Element Used for Mapping: <locationUsed> 🎯
So a bunch of the requests can send over more than one <location> element, and the server gets to pick which one it uses 🤔. It's super useful for the client to know which one actually got used to make the result, so the <location> tag MUST contain an 'id' attribute that uniquely identifies that element 🆔. The format of the identifier is totally up to the client. It could be a hash of the location info, for example 🧁. The server then sends the identifier for whichever <location> element it used back inside the <locationUsed> tag 💖.
8. Mapping a Location and Service to URLs: <findService> 🗺️✨
8.1. Overview 🌸
The <findService> query is literally the core of LoST 👑. It maps civic or geodetic locations to URLs and their associated data 📍. We're going to walk through an example first, then break down all the elements in the query and response 🧩.
8.2. Examples 🎀
8.2.1. Example Using Geodetic Coordinates 🌍
Here's an example of mapping a service to a location using geodetic coordinates, for the police service (urn:service:sos.police) 🚓.
<?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 1: A <findService> geodetic query 📝
Okay so, based on that query, the server sends back a service plus info about it 💁♀️. In the example below, the server matched the client's location for a police service to the New York City Police Department 🗽. It tells the client it can reach them at sip:nypd@example.com and xmpp:nypd@example.com 📱. The server also gave a geodetic, two-dimensional boundary for this service 📐. The mapping was last updated on November 1, 2006, and it expires on January 1, 2007 ⏰. If the client's location moves outside the service boundary, or the expiration time comes up, it may want to requery for this info, depending on the usage environment of LoST 🔄. Lowkey important stuff 🙈.
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="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="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>Figure 2: A <findServiceResponse> geodetic answer 💫
8.2.2. Civic Address Mapping Example 🏙️
This example maps a service to a location a lot like the one in Section 8.2.1 🔁, except it uses civic address info instead ✨. Here the client asks for the police service (urn:service:sos.police) along with a specific civic address: house number 6 on Otto-Hahn-Ring in Munich, Germany 🥨.
<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true" serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>Figure 3: A <findService> civic address query 🏷️
So the server answers the query with a service and some info about it 🎁. In this one, the server matched the client's location for police to the Muenchen Polizei-Abteilung 🚨. It tells the client to reach them at sip:munich-police@example.com or xmpp:munich-police@example.com 📨. The server also gave the client a civic address boundary for the service, which is the city of Munich 🏘️. The mapping was last updated on November 1, 2006, by the authoritative source "polizei.muenchen.de.example", and it expires on January 1, 2007 🗓️. This means the client should requery if its location goes outside the boundary (so beyond the indicated district of Munich) or once January 1, 2007 rolls around 🔄💅.
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="esgw.ueber-110.de.example"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="de">
Muenchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<path>
<via source="esgw.ueber-110.de.example"/>
<via source="polizei.muenchen.de.example"/>
</path>
<locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse>Figure 4: A <findServiceResponse> civic address answer 🌷
8.3. Components of the <findService> Request 🧃
The <findService> request has attributes and elements that control a few things: whether it gets handled iteratively or recursively, whether location validation happens, and which elements are allowed in the response 🎛️. It's giving control freak energy, and I'm here for it 💅.
8.3.1. The <location> Element 📍
The <findService> query shares location info using one or more <location> elements, and each one MUST conform to a location profile (see Section 12) 📋. There MUST NOT be more than one location element for each distinct location profile 🙅♀️. The order of the location elements matters, bestie. The server uses the first location element where it understands the location profile 🥇.
8.3.2. Identifying the Service: The <service> Element 🏷️
The type of service you want gets specified by the <service> element 🎯. It contains service URNs from the registry established in [9] 📚.
8.3.3. Recursion and Iteration 🔁
LoST can run in either recursive or iterative mode, and you pick that on a request-by-request basis 🫶. In recursive mode, the LoST server starts its own queries on behalf of the requester, then sends the result back to the requester 🚀.
In iterative mode, the server that gets contacted sends back a redirection response, pointing to the next server to query, if it can't answer the question itself 👉.
For the queries in this document, only the LoST <findService> and <listServicesByLocation> queries can be recursive, and that's shown by the 'recursive' attribute 💖. A value of "true" means a recursive query, and if the attribute is left out, the default is "false" 🙃. No matter what the attribute says, a server MAY always answer a query by providing a LoST application unique string (see Section 4), which is indirection 🦋. But it MUST NOT recurse if the attribute is "false" 🛑. Iconic boundaries, no cap ✨.
8.3.4. Service Boundary 🗺️
LoST <mapping> elements can describe the service boundary either by value or by reference 🔀. Returning a boundary reference is usually more space-efficient for geospatial (polygon) boundaries, especially if the boundaries rarely change 📉. The catch is that it adds an extra <getServiceBoundary> request 😭. The querier can show a preference for one or the other with the 'serviceBoundary' attribute in the <findService> request 🙋♀️, but the server gets the final say on whether it returns a reference or a value 👑.
8.3.5. Requesting Civic Location Validation 🎀
okay so, if you want the server to check your civic address, you set the optional attribute validateLocation to true 💅 If you leave it out, it's assumed to be false, so no checking happens. The response is described in Section 8.4.2, and Figure 5 shows a validation request in action 🔍 Also, if the server picks a geodetic location from the ones you sent, the attribute just gets ignored 🙈
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true"
validateLocation="true"
serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 5: A <findService> query with address validation request<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="4db898df52b84edfa9b6445ea8a0328e">
<displayName xml:lang="de">
Muenchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse>
Figure 6: A <findServiceResponse> message with address validation
information8.4. Components of the Mapping Response <findServiceResponse>
8.4.1. Overview ✨
A mapping response is made up of the <mapping> element (Section 5), which describes the mapping itself. It can be followed by warnings (Section 13.2), location validation information (Section 8.4.2), and an indication of the path (Section 6) that the response took 🛣️
8.4.2. Civic Address Validation: The <locationValidation> Element 💖
This is where the server tells you which civic address parts it recognized as valid, which ones it ignored, and which ones it checked and found to be wrong 🧐 The server SHOULD include this info if validateLocation was true in the request, but local policy on the server is allowed to leave it out. Each element holds a whitespace-separated list of tokens, naming the civic location labels used in the child elements of <civicAddress>. The <valid> element lists the parts the LoST server recognized as valid and actually used to work out the mapping ✅ The <unchecked> element lists parts the server didn't check and didn't use in the response. The <invalid> element lists parts the server tried to check but that didn't match the other civic parts in the <valid> list ❌ Any civic location token that isn't in <valid>, <invalid>, or <unchecked> is put in the unchecked class 🫶
Heads up: the same address can give different answers if its parts contradict each other. For example, if the postal code doesn't match the city, the local server policy decides whether the postal code or the city counts as valid. The mapping always lines up with the valid elements 💀
In Figures 5 and 6, the tokens country, A1, A3, and A6 got validated by the LoST server 🎉 The server said postal code 81675 in the <PC> element isn't valid for that location. The HNO token falls into the unchecked class 🦋
9. Retrieving the Service Boundary via <getServiceBoundary> 🗺️
As we talked about in Section 5.5, the <findServiceResponse> can return a globally unique identifier in the serviceBoundary attribute. You can use that ID to fetch the boundary later, instead of getting the whole boundary by value 🧚 Figures 7 and 8 show this. The client then uses a <getServiceBoundary> request and gets the boundary back in a <getServiceBoundaryResponse>, which Figures 9 and 10 illustrate 🌈 The client sends the request to the server named in the server attribute of the <serviceBoundaryReference> element. These requests always go to the authoritative server and never recurse 🔥
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true"
serviceBoundary="reference">
<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 7: <findService> request and response with service boundary
reference<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="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="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundaryReference
source="authoritative.example"
key="7214148E0433AFE2FA2D48003D31172E"/>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
Figure 8: <findServiceResponse> message with service boundary
reference<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/>
Figure 9: Requesting a service boundary with <getServiceBoundary> <?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</getServiceBoundaryResponse>
Figure 10: Geodetic service boundary response10. List Services: <listServices> 📋
A LoST client can ask a LoST server for the list of services it understands, mostly for diagnostic purposes 🩺 The query has no location info, because it's only showing which services the server can look up, not whether a given service is offered in a certain area 🙅♀️ Usually only top-level services are listed, which implies support for all their sub-services 💜 Since the server that gets the query is the one that answers it, there's no recursion or indirection involved. If you want to know whether a specific service is offered for a specific location, use the <listServicesByLocation> query in Section 11 instead ✨ Figure 11 shows an example request and response.
<?xml version="1.0" encoding="UTF-8"?>
<listServices
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
Figure 11: Example of <ListServices> query<?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="authoritative.example"/>
</path>
</listServicesResponse>
Figure 12: Example of <ListServicesResponse>11. List Services By Location: <listServicesByLocation> ✨
okay so a LoST client can ask a LoST server for the list of services it knows about for a particular area 🗺️. The <listServicesByLocation> query holds one or more <location> elements, each from a different location profile (Section 12), and it may also include the <service> element 💅. Just like with <findService>, the server picks the first location element with a profile it understands, and it can work recursively or iteratively. <via> elements keep track of how far the request has traveled 🦋. The query asks for the services the server can list from inside the forest structure it belongs to. LoST doesn't assume one big organization runs every service type, so an area might have services that other LoST servers, hooked up to other forest structures, can describe 🌈. For example, the emergency services forest for a region could be totally separate from the forests that find commercial services in that same region 🙈.
If the query has a <service> element, the server only returns the immediate child services of the queried service that are available for the location you sent ✨. If the <service> element is missing, the server returns all the top-level services it knows about for that location 🍓.
A server answers this query with a <listServicesByLocationResponse> response. That response MAY contain <via> elements (see Section 6) and MUST contain a <serviceList> element, which is a whitespace-separated list of service URNs 💜. Figure 13 shows the query and Figure 14 shows the response.
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true">
<location id="3e19dfb3b9828c3" profile="geodetic-2d">
<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>-34.407 150.883</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos</service>
</listServicesByLocation> Figure 13: Example of <ListServicesbyLocation> query<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="3e19dfb3b9828c3"/>
</listServicesByLocationResponse> Figure 14: Example of <ListServicesByLocationResponse> response12. Location Profiles 🎀
LoST reads location information from <location> elements in requests and from <serviceBoundary> elements in responses 🌸. Location information can be written in lots of different ways, and that variety can cause interoperability headaches 😭 when a request or response uses a format the other side doesn't understand. To fix that, this document defines two mandatory-to-implement baseline location profiles that spell out how location information is sent. More profiles can be standardized in the future. The baseline profiles are:
geodetic-2d: a profile for two-dimensional geodetic location information, as described in Section 12.2;.
civic: a profile made up of civic address location information, as described in Section 12.3.
Requests and responses with <location> or <serviceBoundary> elements MUST contain location information in exactly one of the two baseline profiles, plus zero or more additional profiles. The order of the location information shows what the sender prefers 🫶.
Standards action is required for defining new profiles. A location profile MUST define:
- The token identifying it in the LoST location profile registry.
- The formal definition of the XML to be used in requests, i.e., an enumeration and definition of the XML child elements of the
<location>element. - The formal definition of the XML to be used in responses, i.e., an enumeration and definition of the XML child elements of the
<serviceBoundary>element. - The declaration of whether geodetic-2d or civic is to be used as the baseline profile. It is necessary to explicitly declare the baseline profile, as future profiles may be combinations of geodetic and civic location information.
12.1. Location Profile Usage
A location profile is identified by a token in an IANA-maintained registry (Section 17.5). Clients send location information that follows a location profile, and servers respond with location information that follows that same profile 💖.
When a LoST client sends a <findService> request that includes location information, it adds one or more <location> elements. A <location> element can carry an optional profile attribute that says what format its child elements use. Sometimes a client has location information that doesn't match any profile it recognizes, or it can't turn XML into profiles at all 🙈. In that case, a client MAY omit the profile attribute, and the server should interpret the XML location data as best it can, returning a "locationProfileUnrecognized" error if it can't do that 🧚.
The concept of location profiles is described in Section 12. Since you can include more than one <location> element, a client can send location information for multiple profiles in the same request ✨.
When a LoST server sends a response with location information, it uses <serviceBoundary> elements in much the same way the client uses <location> elements. Each <serviceBoundary> element holds location information that matches the profile named in its profile attribute. A response MAY contain multiple mappings or boundaries for the different <location> elements, subject to the restrictions below 🦋.
Using the location profiles defined in this document, the following rules keep clients and servers interoperable 👑:
- A client MUST be capable of understanding the response for the baseline profiles it used in the request.
- If a client sends location information that conforms to any location profile other than the ones described in this document, it MUST also send, in the same request, location information that conforms to one of the baseline profiles. Otherwise, the server might not be able to understand the request.
- A client MUST NOT send multiple
<location>objects that are derived from different baseline profiles. In other words, a client MUST only send location objects that follow the same baseline profile in a query, but it MAY include a location element following a baseline profile in addition to some other profile. - If a client has both location information that is primarily geodetic and location information that is primarily civic, it MUST send separate requests containing each type of location information.
- There can only be one instance of each location profile in a query.
- Servers MUST implement all profiles described in this document.
- A server uses the first-listed location profile that it understands and ignores the others.
- If a server receives a request that only contains location information using profiles it does not understand, the server responds with a
<locationProfileError>(Section 13.1). - The
<serviceBoundary>element MUST use the same location profile that was used to retrieve the answer, and it indicates which profile was used with the'profile'attribute.
These rules make room for location profiles that haven't been specified yet, while still guaranteeing baseline interoperability 💜. Take the scenario in Figures 15 and 16 as an example. Client X got a firmware upgrade so it supports the 'not-yet-standardized-prism-profile' location profile. Client X sends location information to Server Y, which doesn't understand that profile 😭. But if Client X also sends location information using the geodetic-2D baseline profile, Server Y can still understand the request and send back a response it can read. The location information might not be as precise or expressive as desired, but it works, because both Client X and Server Y understand the baseline profile 🌈.
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
recursive="true"
serviceBoundary="value">
<location id="ABC 123"
profile="not-yet-standardized-prism-profile">
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
42.556844 -73.248157 36.6
42.656844 -73.248157 36.6
42.656844 -73.348157 36.6
42.556844 -73.348157 36.6
42.556844 -73.248157 36.6
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
2.4
</gs:height>
</gs:Prism>
</location>
<location id="DEF 345" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>42.656844 -73.348157</gml:pos>
</gml:Point>
</location>
<service>urn:service:sos.police</service>
</findService> Figure 15: Example of a <findServices> query with baseline profile
interoperability<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="DEF 345"/>
</findServiceResponse> Figure 16: Example of a <findServiceResponse> message with baseline
profile interoperability12.2. Two-Dimensional Geodetic Profile
Okay bestie, this is the geodetic profile 🌍✨ It's identified by the token geodetic-2d. Clients and servers use it by putting these location shapes into the <serviceBoundary> or the <location> element (unless it says otherwise):
Point: The <Point> element is described in Section 5.2.1 of [13]. That same section also shows how to write a <Point> with either a two-dimensional position (latitude and longitude) or a three-dimensional one (latitude, longitude, and altitude). A client MAY use the three-dimensional position, and servers MAY interpret a three-dimensional position as a two-dimensional one by ignoring the altitude value. A <Point> element is not placed into a <serviceBoundary> element. 📍
Polygon: The <Polygon> element is described in Section 5.2.2 of [13]. The 16-point limit for a polygon in Section 7.2.2 of [12] doesn't apply to this document. 🔷
Circle: The <Circle> element is described in Section 5.2.3 of [13]. ⭕
Ellipse: The <Ellipse> element is described in Section 5.2.4 of [13]. 🥚
ArcBand: The <ArcBand> element is described in Section 5.2.5 of [13]. 🌙
So when a client drops a <Polygon>, <Circle>, <Ellipse>, or <ArcBand> into the <location> element, it's basically saying "I'm happy with results that fit any part of this shape" 💅. Picking the matching algorithm is up to the server. A server MAY return multiple <mapping> elements if the shape stretches across several service areas. Servers aren't required to return every possible <mapping> element. That protects them from denial-of-service attacks, where clients send queries spanning a huge number of service boundaries (think a shape covering all of the United States) 🛡️
If the server doesn't return multiple <mapping> elements but the shape crosses a service boundary, the matching algorithm chosen by the LoST server might return results that match only part of the shape and not the spot the client is actually at. A client is always free to pick a point from inside the shape to dodge this. The cases where it can't are usually the ones where the client only knows its position somewhere within the shape. In emergency service use cases, that can mean the PSAP reached at the URI provided by LoST has to forward a call to one of its neighbors. That's an expected part of the overall emergency response system 🚨. In non-emergency service use cases, the service deployment model should take this into account as part of the provisioning model, since the mix of data in the LoST server and the mapping algorithm decides which contact URIs come back when shapes overlap multiple service areas 🗺️
As a general rule, any matching algorithm that gets deployed should make sure it doesn't needlessly return no results when there are valid results for any portion of the shape. Also, if an authoritative server gets a query whose area overlaps the area it has mapping information for, it MUST return either a mapping whose coverage area intersects the query area, or a redirect to another server whose coverage area is a subset of the server's coverage area. No ghosting allowed 👻
When geodetic location information from this profile goes into the <serviceBoundary> element, the elements with geospatial coordinates are alternative descriptions of the same service region. They are not additive geometries, so they don't stack on top of each other ✨
12.3. Basic Civic Profile
The basic civic location profile is identified by the token 'civic'. Clients use it by putting a <civicAddress> element, defined in [10], inside the <location> element. 🏠
Servers use it by putting a <civicAddress> element, defined in [10], inside the <serviceBoundary> element. 🏢
A response MAY contain more than one <serviceBoundary> element with profile 'civic'. Each <serviceBoundary> element describes a set of civic addresses that fall within the service boundary, namely all addresses that textually match the civic address elements provided, no matter what the other address elements say. A location falls within the mapping's service boundary if it matches any of the <serviceBoundary> elements. So a response can have multiple <serviceBoundary> elements mixing civic and/or geodetic location profiles. It's giving variety 🌈
13. Errors, Warnings, and Redirects ✨
When a LoST server can't fully fulfill a request, it can return either an error or a warning, depending on how bad the problem is. It returns an <errors> element if no useful response can be sent back for the query. It returns a <warnings> element as part of another response element if it was able to respond in part, but the response might not be exactly what the client wanted. For both elements, the 'source' attribute names the server that originally generated the error or warning, such as the authoritative server. Unless noted otherwise, every element below can be either an error or a warning, depending on whether a default response, like a mapping, is included. 🙈
13.1. Errors
LoST defines a pattern for errors, which are defined as <errors> elements in the Relax NG schema. This pattern defines a 'message' attribute with human-readable text, and an 'xml:lang' attribute that says what language that text is in. One or more of these error elements go inside the <errors> element. 💌
These errors follow that basic pattern:
badRequest: The server couldn't parse or otherwise understand a request, for example because the XML was malformed. 🤔forbidden: The server refused to send an answer. This usually only happens for recursive queries, meaning the client tried to reach the authoritative server and got turned away. 🚫internalError: The server couldn't satisfy a request because of misconfiguration or other operational, non-protocol-related reasons. 🛠️locationProfileUnrecognized: None of the profiles in the request were recognized by the server (see Section 12). 🫥locationInvalid: The geodetic or civic location in the request was invalid. For example, the longitude or latitude values are outside the acceptable ranges. 📉SRSInvalid: The spatial reference system (SRS) in the location element wasn't recognized, or doesn't match the location profile. 🧭loop: During a recursive query, the server was about to visit a server that was already in the server list in the<path>element, which means there's a request loop. 🔁notFound: The server couldn't find an answer to the query. 🔍serverError: An answer came back from another LoST server, but it couldn't be parsed or otherwise understood. This error only happens for recursive queries. 💥serverTimeout: A timeout happened before an answer was received. ⏰serviceNotImplemented: The requested service URN isn't implemented, and there was no substitution available. 🙅♀️
Here's an example:
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
source="resolver.example">
<internalError message="Software bug." xml:lang="en"/>
</errors>Figure 17: Example of an error response
13.2. Warnings
A response MAY contain zero or more warnings. This pattern defines a 'message' attribute with human-readable text, and an 'xml:lang' attribute that says what language that text is in. One or more of these warning elements go inside the <warnings> element. To give the human-readable text in an appropriate language, a server MAY make use of the HTTP content negotiation capabilities (see Section 14). 🌐
This version of the spec defines these warnings:
locationValidationUnavailable: The<locationValidationUnavailable>element MAY be returned when a server wants to let a client know it can't fulfill a location validation request. This warning lets a server return mapping information while still flagging that exception state. 🚧serviceSubstitution: The<serviceSubstitution>element MAY be returned when a server wasn't able to fulfill a<findService>request for a given service URN. For example, a<findService>request for the 'urn:service:sos.police' service URN, for a location in Uruguay, may cause the LoST service to return a mapping for the 'urn:service:sos' service URN, since Uruguay doesn't use the police, fire, and ambulance sub-services. If this warning comes back, the<service>element in the response tells you which service URN the mapping refers to. 🔄defaultMappingReturned: The<defaultMappingReturned>element MAY be returned when a server couldn't fulfill a<findService>request for a given location, but can still respond with a default URI. For example, a nearby PSAP might be returned. 🆘
Here's an example of a warning:
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="fb8ed888433343b7b27865aeb38f3a99">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<warnings source="authoritative.example">
<defaultMappingReturned
message="Unable to determine PSAP for the given location;
using default PSAP"
xml:lang="en"/>
</warnings>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</findServiceResponse>Figure 18: Example of a warning response
13.3. Redirects 💅
okay so a LoST server can basically say "not my problem, bestie, go ask someone else" 💁♀️ by sending back a <redirect> element. It has a 'target' attribute with the LoST application unique string (see Section 4) that the client SHOULD be contacting next, a 'source' attribute for the server that generated the redirect response, and a 'message' attribute explaining why it happened. During a recursive query, a server that gets a <redirect> response can decide whether to follow the redirect or just pass the response back up to its upstream querier ✨. The "expires" value in the response from the server handling the redirected query tells you the earliest time a new query might be needed (see Section 5.2). Until that time comes, the query for the same tuple of location and service SHOULD NOT be sent to the server that gave the redirect 🙈.
Here's an example:
<?xml version="1.0" encoding="UTF-8"?>
<redirect xmlns="urn:ietf:params:xml:ns:lost1"
target="eastpsap.example"
source="westpsap.example"
message="We have temporarily failed over." xml:lang="en"/>Figure 19: Example of a redirect response
14. LoST Transport: HTTP 🦋
okay transport time 🚀 LoST needs an underlying protocol to carry its requests and responses. This document defines LoST over HTTP and LoST over HTTP-over-TLS. Client and server devs, this is your reminder that full support of RFC 2616 HTTP facilities is expected 📚. If your LoST clients or servers re-implement HTTP instead of building on existing server or client code, you have to pay careful attention to full interoperability, no cap 😭. Other transport mechanisms are left to future documents. The transport mechanisms that are available get figured out through the LoST U-NAPTR application. And in protocols that support content type indication, LoST uses the media type application/lost+xml 💜.
When you're using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP POST method 🍓. The HTTP request MUST use the Cache-Control response directive "no-cache" to turn off HTTP-level caching, even for caches that have been set up to hand out stale responses to client requests. Iconic behaviour, honestly 💅.
All LoST responses, including the ones carrying a LoST warning or error, come back in 2xx responses, usually 200 (OK) ✨. Other 2xx responses, especially 203 (Non-authoritative information), might be returned by HTTP caches that ignore the caching instructions. 3xx, 4xx, and 5xx HTTP response codes mean the HTTP request itself failed or got redirected, and these responses do not contain any LoST XML elements 🙃. The 3xx responses are different from the redirects in Section 13.3, because those redirects happen after a LoST server processes the request. An HTTP-layer redirect is kind of general, while a LoST server redirect as described in Section 13.3 might be specific to one service or come from other processing the LoST server did 🧚.
The HTTP URL is derived from the LoST server name via the U-NAPTR application, as discussed above 🌈.
15. Relax NG Schema 💖
This section gives you the Relax NG schema that LoST uses, in compact form. The verbose form is in Appendix A, so if you want the full picture, go look there 👀.
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
##
## Location-to-Service Translation (LoST) Protocol
##
## A LoST XML instance has three request types, each with
## a corresponding response type: find service, list services,
## and get service boundary.
##
start =
findService
| listServices
| listServicesByLocation
| getServiceBoundary
| findServiceResponse
| listServicesResponse
| listServicesByLocationResponse
| getServiceBoundaryResponse
| errors
| redirect
##
## The queries.
##
div {
findService =
element findService {
requestLocation,
commonRequestPattern,
attribute validateLocation {
xsd:boolean >> a:defaultValue [ "false" ]
}?,
attribute serviceBoundary {
("reference" | "value") >> a:defaultValue [ "reference" ]
}?,
attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
}
listServices = element listServices { commonRequestPattern }
listServicesByLocation =
element listServicesByLocation {
requestLocation,
commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
}
getServiceBoundary =
element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}
##
## The responses.
##
div {
findServiceResponse =
element findServiceResponse {
mapping+, locationValidation?, commonResponsePattern, locationUsed
}
listServicesResponse =
element listServicesResponse { serviceList, commonResponsePattern }
listServicesByLocationResponse =
element listServicesByLocationResponse {
serviceList, commonResponsePattern, locationUsed
}
getServiceBoundaryResponse =
element getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern
}
}
##
## A pattern common to some of the queries.
##
div {
commonRequestPattern = service, path?, extensionPoint
}
##
## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
}
##
## Location in Requests
##
div {
requestLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Service Boundary
##
div {
serviceBoundary = element serviceBoundary { locationInformation }+
}
##
## Service Boundary Reference
##
div {
serviceBoundaryReference =
element serviceBoundaryReference {
source, serviceBoundaryKey, extensionPoint
}
serviceBoundaryKey = attribute key { xsd:token }
}
##
## Path -
## Contains a list of via elements -
## places through which information flowed
##
div {
path =
element path {
element via { source, extensionPoint }+
}
}
##
## Location Used
##
div {
locationUsed =
element locationUsed {
attribute id { xsd:token }
}?
}
##
## Expires pattern
##
div {
expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}
##
## A QName list
##
div {
qnameList = list { xsd:QName* }
}
##
## A location-to-service mapping.
##
div {
mapping =
element mapping {
element displayName {
xsd:string,
attribute xml:lang { xsd:language }
}*,
service,
(serviceBoundary | serviceBoundaryReference)?,
element uri { xsd:anyURI }*,
element serviceNumber {
xsd:token { pattern = "[0-9*#]+" }
}?,
extensionPoint,
expires,
attribute lastUpdated { xsd:dateTime },
source,
attribute sourceId { xsd:token },
message
}
}
##
## Location validation
##
div {
locationValidation =
element locationValidation {
element valid { qnameList }?,
element invalid { qnameList }?,
element unchecked { qnameList }?,
extensionPoint
}
}
##
## Errors and Warnings Container.
##
div {
exceptionContainer =
(badRequest?
& internalError?
& serviceSubstitution?
& defaultMappingReturned?
& forbidden?
& notFound?
& loop?
& serviceNotImplemented?
& serverTimeout?
& serverError?
& locationInvalid?
& locationProfileUnrecognized?),
extensionPoint,
source
errors = element errors { exceptionContainer }
warnings = element warnings { exceptionContainer }
}
##
## Basic Exceptions
##
div {
##
## Exception pattern.
##
basicException = message, extensionPoint
badRequest = element badRequest { basicException }
internalError = element internalError { basicException }
serviceSubstitution = element serviceSubstitution { basicException }
defaultMappingReturned =
element defaultMappingReturned { basicException }
forbidden = element forbidden { basicException }
notFound = element notFound { basicException }
loop = element loop { basicException }
serviceNotImplemented =
element serviceNotImplemented { basicException }
serverTimeout = element serverTimeout { basicException }
serverError = element serverError { basicException }
locationInvalid = element locationInvalid { basicException }
locationValidationUnavailable =
element locationValidationUnavailable { basicException }
locationProfileUnrecognized =
element locationProfileUnrecognized {
attribute unsupportedProfiles { xsd:NMTOKENS },
basicException
}
}
##
## Redirect.
##
div {
##
## Redirect pattern
##
redirect =
element redirect {
attribute target { appUniqueString },
source,
message,
extensionPoint
}
}
##
## Some common patterns.
##
div {
message =
(attribute message { xsd:token },
attribute xml:lang { xsd:language })?
service = element service { xsd:anyURI }?
appUniqueString =
xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString }
serviceList =
element serviceList {
list { xsd:anyURI* }
}
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST namespace.
##
notLost = 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 = notLost*
}Figure 20: RelaxNG schema
16. Internationalization Considerations 🌸
LoST is mostly built for machine-to-machine chats, so most of its elements are tokens that aren't meant for humans to read directly 🤖. If those tokens do end up in front of an end user, some localization may need to happen. The content of the <displayName> element and the 'message' attributes may be shown to the end user, and that's why they're complex types designed for exactly that purpose 💬.
LoST talks in XML. All XML processors are required to understand UTF-8 and UTF-16 encodings, so all LoST clients and servers MUST understand UTF-8 and UTF-16 encoded XML 🫶. On top of that, LoST servers and clients MUST NOT encode XML with any encodings other than UTF-8 or UTF-16. Non-negotiable, periodt 💅.
17. IANA Considerations 📋
17.1. U-NAPTR Registrations ✨
This document registers the following U-NAPTR application service tag:
Application Service Tag: LoST
Defining Publication: The specification contained within this
document.This document also registers the following U-NAPTR application protocol tags:
- Application Protocol Tag:
http- Defining Publication: RFC 2616 [3]
- Application Protocol Tag:
https- Defining Publication: RFC 2818 [4]
17.2. Content-Type Registration for 'application/lost+xml' 💌
okay so this section asks for a brand new MIME type, and it's following the rules from RFC 4288 [7] and the guidelines in RFC 3023 [5] 💅
- MIME media type name:
application - MIME subtype name:
lost+xml - Mandatory parameters: none
- Optional parameters:
charset, which tells you the character encoding of the enclosed XML 🫶 - Encoding considerations: it's XML, so it can use 8-bit characters depending on the character encoding in use. Check RFC 3023 [5], Section 3.2 if you want the deets ✨
- Security considerations: this content type is built to carry LoST protocol payloads 🔐
- Interoperability considerations: None
- Published specification: RFC 5222
- Applications that use this media type: emergency and location-based systems 🚨
- Additional information:
- Magic Number: None
- File Extension:
.lostxml - Macintosh file type code:
'TEXT'
- Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@nsn.com
- Intended usage: LIMITED USE 🌸
- Author: this spec is a work item of the IETF ECRIT working group, with mailing list address
<ecrit@ietf.org> - Change controller: The IESG
<iesg@ietf.org>
17.3. LoST Relax NG Schema Registration 🧚
this one registers a URI for the Relax NG schema 🦋
- URI:
urn:ietf:params:xml:schema:lost1 - Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com)
The Relax NG schema being registered is in Section 15. Its first line is:
default namespace = "urn:ietf:params:xml:ns:lost1"and its last line is:
}17.4. LoST Namespace Registration 🌈
this is the namespace registration, and it comes with a little XHTML page attached 💖
- URI:
urn:ietf:params:xml:ns:lost1 - Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com)
- XML:
<?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 Namespace</title>
</head>
<body>
<h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">
RFC5222</a>.</p>
</body>
</html>17.5. LoST Location Profile Registry 📍
this creates a registry of location profile names for LoST ✨ profile names are XML tokens, and the registry runs under RFC 5226 [2], Standards Action. Here are the two starter profiles:
geodetic-2d:is defined in Section 12.2 🌍civic:is defined in Section 12.3 🏠
18. Security Considerations 🔐
okay bestie, this part is serious, so listen up 😭 there are a bunch of threats to the whole system that service mapping is part of. An attacker who can get hold of service contact URIs can use them to try to disrupt those services. An attacker who can stop contact URIs from being looked up can wreck the reachability of those services. An attacker who can eavesdrop on the lookup request can figure out that an emergency is happening and maybe what kind, and could possibly use that to physically attack the caller 💀
To stop an attacker from messing with the query or its result, Transport Layer Security (TLS) MUST be implemented and SHOULD be used. Using it is RECOMMENDED for both client-to-server queries and queries between servers. That server-to-server part helps prevent LoST cache poisoning, where answers given to caching LoST servers get swapped out 🙈
Using server identity checks with TLS, as described in Section 3.1 of [4], is also RECOMMENDED. If you skip the server identity check, an attacker can pretend to be a LoST server, so only skip it when getting any answer, even from a possibly malicious LoST server, is better than closing the connection and getting no answer at all. The host name checked against the server certificate is the host name in the URI, not the DNS name that was used as input to NAPTR resolution.
Heads up: the security considerations in [22] recommend comparing the input of NAPTR resolution to the certificate, not the output (the host name in the URI). That approach was NOT chosen here, and here's why. In emergency service use cases, lots of inputs to the U-NAPTR algorithm will probably resolve to a single server, typically run by a local emergency services authority. Checking the NAPTR input against the certificates would be impractical, because the list of organizations using that server would be large, change quickly, and be unknown to the LoST server operator 🫠
Server identity does leave the door open to DNS-based attacks, since an attacker could alter the NAPTR records. These include intercepting DNS packets between the client and the recursive name server, DNS cache poisoning, and deliberate changes by the recursive name server itself. See [23] for a more thorough discussion 👀
DNS Security (DNSSEC) [20] can be used to guard against these threats. DNSSEC isn't fully deployed yet, so users should be aware of the risk, especially when they request NAPTR records in environments where the local recursive name server, or the network between the client and that server, isn't trustworthy.
LoST deployments that can't use DNSSEC and won't trust DNS resolution without it can't use NATPR-based discovery of LoST servers as is. When suitable configuration mechanisms exist, one option is to configure the LoST server URIs directly, instead of the domain name used for NAPTR resolution. Future specifications for using LoST in non-emergency services may also define additional discovery mechanisms and name matching semantics 🔮
Generally, LoST servers won't need to authenticate or authorize clients that send mapping queries. If they do, authentication of the underlying transport mechanism, such as HTTP basic and digest authentication, MAY be used. Basic authentication SHOULD only be used in combination with TLS 🔑
A more detailed description of threats and security requirements is in [17]. The threats and security requirements for non-emergency service uses of LoST may be pretty different from the ones described here. For example, an attacker might want money by returning service mapping information that sends users to specific service providers 💸 Before deploying LoST in new contexts, a thorough analysis of the threats and requirements specific to that context should be done, and decisions should be made about the right mitigations.
19. Acknowledgments 🫶
we'd like to thank the following working group members for their detailed review of previous LoST document versions:
- Martin Thomson (Review July 2006)
- Jonathan Rosenberg (Review July 2006)
- Leslie Daigle (Review September 2006)
- Shida Schubert (Review November 2006)
- Martin Thomson (Review December 2006)
- Barbara Stark (Review January 2007)
- Patrik Faltstrom (Review January 2007)
- Shida Schubert (Review January 2007 as a designated expert reviewer)
- Jonathan Rosenberg (Review February 2007)
- Tom Taylor (Review February 2007)
- Theresa Reese (Review February 2007)
- Shida Schubert (Review February 2007)
- James Winterbottom (Review July 2007)
- Karl Heinz Wolf (Review May and June 2007)
we'd also like to thank the following working group members for their input on selected design aspects of the LoST protocol:
- Leslie Daigle and Martin Thomson (DNS-based LoST discovery procedure)
- John Schnizlein (authoritive LoST answers)
- Rohan Mahy (display names)
- James Polk (error handling)
- Ron Watro and Richard Barnes (expiry of cached data)
- Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James Winterbottom (indication of PSAP confidence level)
- Martin Thomson (service boundary references)
- Martin Thomson (service URN in LoST response message)
- Clive D.W. Feather, Martin Thomson (validation functionality)
- Roger Marshall (PSAP preference in LoST response)
- James Winterbottom, Marc Linsner, Keith Drage, Tom Taylor, Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule, Pierre Desjardins (location profiles)
- Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson, Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list services functionality)
- Martin Thomson, Michael Hammer (mapping of services)
- Shida Schubert, James Winterbottom, Keith Drage (default service URN)
- Otmar Lendl (LoST aggregation)
- Tom Taylor (terminology)
Klaus Darilion and Marc Linsner gave miscellaneous input to the protocol design. Finally, a huge thank you to Brian Rosen, who joined in on almost every discussion thread 💜
Early implementation work led to great feedback from two open source implementation groups. Thank you to the implementers for their work and for helping make the spec better 🍓
- Wonsang Song
- Jong-Yul Kim
- Anna Makarowska
- Krzysztof Rzecki
- Blaszczyk Piotr
Thanks also to Jon Peterson, Dan Romascanu, Lisa Dusseault, and Tim Polk for their IESG review comments. Blocking IESG comments came in from Pasi Eronen (succeeding Sam Hartman's review) and Cullen Jennings. Several pieces of text were adjusted to address these requests, most notably in the Security Considerations and in the discussion of redirection when coverage areas overlap ✨
20. References 📚
20.1. Normative References 🧾✨
okay bestie, these are the normative ones, meaning this doc leans on them for real 💅
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OGC Standard OpenGIS 03-105r1, April 2004.
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification , December 2006.
20.2. Informative References 📚🌸
these ones are just for extra context, so you don't need them to get the main vibe 🫶
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Work in Progress, February 2008.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", Work in Progress, September 2007.
[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, February 2008.
[22] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG>.
[25] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax 🎀
this schema is non-normative, so think of it as a helpful friend and not the law 💖
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1"
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>
Location-to-Service Translation (LoST) Protocol
A LoST XML instance has three request types, each with
a corresponding response type: find service, list services,
and get service boundary.
</a:documentation>
<choice>
<ref name="findService"/>
<ref name="listServices"/>
<ref name="listServicesByLocation"/>
<ref name="getServiceBoundary"/>
<ref name="findServiceResponse"/>
<ref name="listServicesResponse"/>
<ref name="listServicesByLocationResponse"/>
<ref name="getServiceBoundaryResponse"/>
<ref name="errors"/>
<ref name="redirect"/>
</choice>
</start>
<div>
<a:documentation>
The queries.
</a:documentation>
<define name="findService">
<element name="findService">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="validateLocation">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="serviceBoundary">
<choice>
<value>reference</value>
<value>value</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServices">
<element name="listServices">
<ref name="commonRequestPattern"/>
</element>
</define>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
The responses.
</a:documentation>
<define name="findServiceResponse">
<element name="findServiceResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<optional>
<ref name="locationValidation"/>
</optional>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="listServicesResponse">
<element name="listServicesResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
</element>
</define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList"/>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse">
<ref name="serviceBoundary"/>
<ref name="commonResponsePattern"/>
</element>
</define>
</div>
<div>
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<define name="commonRequestPattern">
<ref name="service"/>
<optional>
<ref name="path"/>
</optional>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
A pattern common to responses.
</a:documentation>
<define name="commonResponsePattern">
<zeroOrMore>
<ref name="warnings"/>
</zeroOrMore>
<ref name="path"/>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
Location in Requests
</a:documentation>
<define name="requestLocation">
<oneOrMore>
<element name="location">
<attribute name="id">
<data type="token"/>
</attribute>
<ref name="locationInformation"/>
</element>
</oneOrMore>
</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>
Service Boundary
</a:documentation>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source"/>
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
<define name="serviceBoundaryKey">
<attribute name="key">
<data type="token"/>
</attribute>
</define>
</div>
<div>
<a:documentation>
Path -
Contains a list of via elements -
places through which information flowed
</a:documentation>
<define name="path">
<element name="path">
<oneOrMore>
<element name="via">
<ref name="source"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
</div>
<div>
<a:documentation>
Location Used
</a:documentation>
<define name="locationUsed">
<optional>
<element name="locationUsed">
<attribute name="id">
<data type="token"/>
</attribute>
</element>
</optional>
</define>
</div>
<div>
<a:documentation>
Expires pattern
</a:documentation>
<define name="expires">
<attribute name="expires">
<choice>
<data type="dateTime"/>
<value>NO-CACHE</value>
<value>NO-EXPIRATION</value>
</choice>
</attribute>
</define>
</div>
<div>
<a:documentation>
A QName list
</a:documentation>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<div>
<a:documentation>
A location-to-service mapping.
</a:documentation> <define name="mapping">
<element name="mapping">
<zeroOrMore>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="service"/>
<optional>
<choice>
<ref name="serviceBoundary"/>
<ref name="serviceBoundaryReference"/>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
<data type="token">
<param name="pattern">[0-9*#]+</param>
</data>
</element>
</optional>
<ref name="extensionPoint"/>
<ref name="expires"/>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="source"/>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location validation
</a:documentation>
<define name="locationValidation">
<element name="locationValidation">
<optional>
<element name="valid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="invalid">
<ref name="qnameList"/>
</element>
</optional>
<optional>
<element name="unchecked">
<ref name="qnameList"/>
</element>
</optional>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
Errors and Warnings Container.
</a:documentation>
<define name="exceptionContainer">
<interleave>
<optional>
<ref name="badRequest"/>
</optional>
<optional>
<ref name="internalError"/>
</optional>
<optional>
<ref name="serviceSubstitution"/>
</optional>
<optional>
<ref name="defaultMappingReturned"/>
</optional>
<optional>
<ref name="forbidden"/>
</optional>
<optional>
<ref name="notFound"/>
</optional>
<optional>
<ref name="loop"/>
</optional>
<optional>
<ref name="serviceNotImplemented"/>
</optional>
<optional>
<ref name="serverTimeout"/>
</optional>
<optional>
<ref name="serverError"/>
</optional>
<optional>
<ref name="locationInvalid"/>
</optional>
<optional>
<ref name="locationProfileUnrecognized"/>
</optional>
</interleave>
<ref name="extensionPoint"/>
<ref name="source"/>
</define>
<define name="errors">
<element name="errors">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="exceptionContainer"/>
</element>
</define>
</div>
<div>
<a:documentation>
Basic Exceptions
</a:documentation>
<define name="basicException">
<a:documentation>
Exception pattern.
</a:documentation>
<ref name="message"/>
<ref name="extensionPoint"/>
</define>
<define name="badRequest">
<element name="badRequest">
<ref name="basicException"/>
</element>
</define>
<define name="internalError">
<element name="internalError">
<ref name="basicException"/>
</element>
</define>
<define name="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="basicException"/>
</element>
</define>
<define name="defaultMappingReturned">
<element name="defaultMappingReturned">
<ref name="basicException"/>
</element>
</define>
<define name="forbidden">
<element name="forbidden">
<ref name="basicException"/>
</element>
</define>
<define name="notFound">
<element name="notFound">
<ref name="basicException"/>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicException"/>
</element>
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicException"/>
</element>
</define>
<define name="serverTimeout">
<element name="serverTimeout">
<ref name="basicException"/>
</element>
</define>
<define name="serverError">
<element name="serverError">
<ref name="basicException"/>
</element>
</define>
<define name="locationInvalid">
<element name="locationInvalid">
<ref name="basicException"/>
</element>
</define>
<define name="locationValidationUnavailable">
<element name="locationValidationUnavailable">
<ref name="basicException"/>
</element>
</define>
<define name="locationProfileUnrecognized">
<element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles">
<data type="NMTOKENS"/>
</attribute>
<ref name="basicException"/>
</element>
</define>
</div>
<div>
<a:documentation>
Redirect.
</a:documentation>
<define name="redirect">
<a:documentation>
Redirect pattern
</a:documentation>
<element name="redirect">
<attribute name="target">
<ref name="appUniqueString"/>
</attribute>
<ref name="source"/>
<ref name="message"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
Some common patterns.
</a:documentation>
<define name="message">
<optional>
<group>
<attribute name="message">
<data type="token"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="appUniqueString">
<data type="token">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
<define name="source">
<attribute name="source">
<ref name="appUniqueString"/>
</attribute>
</define>
<define name="serviceList">
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI"/>
</zeroOrMore>
</list>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLost">
<a:documentation>
Any element not in the LoST namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost1"/>
<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="notLost"/>
</zeroOrMore>
</define>
</div>
</grammar>Figure 21 is the big schema wrap-up, and it's giving very organised vibes 🧚💖
Appendix B. Examples Online ✨
Okay so the XML examples and Relax NG schemas live online, and you can find them at [24]. 🌸
Authors' Addresses 💌
Ted Hardie
Qualcomm, Inc.
EMail: hardie@qualcomm.com
Andrew Newton
American Registry for Internet Numbers
3635 Concorde Parkway, Suite 200
Chantilly, VA 20151
US
Phone: +1 703 227 9894
EMail: andy@hxr.us
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.atFull Copyright Statement 📜
The legal bits, bestie, but they're still all here 💜
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ✨
okay so, the IETF is NOT picking a side on whether any Intellectual Property Rights (IPR) or other rights someone might claim over this tech are valid or how far they reach 🙅♀️. it also isn't saying whether any license for those rights is available, and it hasn't independently gone hunting for any rights either 🕵️♀️. if you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📚 they're the source of truth bestie 💅
ok now the paperwork bit 📄✨ copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that are supposed to be available, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🦋 the same goes for what happens when someone tries to get a general license or permission to use those proprietary rights as an implementer or user of this spec 💜
and last but not least, the IETF totally invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard 🫶🔥 send that info to the IETF at ietf-ipr@ietf.org 💌 we love a transparent crew 🌈
📦 where this page comes from
- ietf: rfc5222 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms